DBLE XA Transaction Implementation and Recovery Analysis

1. XA Overview – XA is a two‑phase commit protocol defined by the X/Open XA standard. The basic SQL statements are XA START|BEGIN xid , XA END xid , XA PREPARE xid , XA COMMIT xid [ONE PHASE] , XA ROLLBACK xid and XA RECOVER . These statements define the boundaries of a branch transaction and coordinate the global commit or rollback.

2. DBLE XA Implementation – DBLE acts as a transaction manager (TM) and embeds the XA logic inside the DBLE Server process. The client first issues SET xa=1 to enable XA mode, then uses standard BEGIN / COMMIT / ROLLBACK commands. DBLE generates a global XID (e.g., 'Dble_Server.01.1234' ) and appends the appropriate XA statements to each physical MySQL request.

Key Java classes include:

com.actiontech.dble.backend.mysql.nio.handler.transaction.xa.XACommitNodesHandler

com.actiontech.dble.backend.mysql.nio.handler.transaction.xa.XARollbackNodesHandler

com.actiontech.dble.backend.mysql.xa.TxState – defines global and branch transaction states such as TX_PREPARING_STATE , TX_COMMITTING_STATE , TX_ROLLBACKING_STATE , etc.

3. Execution Flow – The typical flow is:

Client sends SET xa=1 → DBLE creates XID.

BEGIN → DBLE disables autocommit and starts XA on each backend.

DML statements are sent prefixed with XA START xid and executed on the appropriate shards.

On COMMIT , DBLE issues XA END , XA PREPARE , then XA COMMIT for each branch; on ROLLBACK it issues XA END followed by XA ROLLBACK .

Handlers are reused for the multiple statements in the commit/rollback phase, so they must clear previous state to avoid interference.

4. Error Handling – If a backend connection fails before XA PREPARE , MySQL automatically rolls back the branch. After XA PREPARE succeeds, DBLE must either retry COMMIT / ROLLBACK a configurable number of times or, if all retries fail, close the client connection and propagate a TRANSACTION_RESOLUTION_UNKNOWN error to the JDBC driver. The code checks session.getXaState() and uses flags such as NonBlockingSession.CANCEL_STATUS_COMMITTING to decide whether to proceed.

5. Transaction Logging and Recovery – DBLE persists a coordinator log entry (global transaction) and participant log entries (branch transactions). The log records the XID, state, and involved shards. State changes that may lose durability (e.g., TX_PREPARING_STATE , TX_COMMITTING_STATE , TX_ROLLBACKING_STATE ) trigger a checkpoint write. On server restart, DbleServer.performXARecoveryLog() scans the logs and decides whether to retry commit or perform rollback based on the recorded state, ensuring no prepared transaction is left hanging.

6. Summary – The article details how DBLE implements XA across sharded MySQL instances, covering topology, code structure, execution steps, failure scenarios, logging, and recovery. It also highlights practical issues such as handler reuse, connection closure during XA phases, and the importance of durable logging to avoid transaction leaks.