Unlocking Distributed Transactions: XA Protocol and Seata’s Two‑Phase Commit Optimizations

XA Protocol Overview

The XA protocol, defined by the X/Open consortium, specifies the interface between a Transaction Manager (TM) and a Resource Manager (RM) for distributed transaction processing. Major databases such as Oracle, DB2, and MySQL (InnoDB engine since version 5.0) support XA.

Two‑Phase Commit (2PC)

2PC splits a global transaction into a prepare phase and a commit phase. In an e‑commerce scenario with Order, Account, and Inventory services, the coordinator sends prepare requests; participants reply yes or no. If all reply yes, the coordinator sends commit; otherwise it sends rollback.

Problems of 2PC:

Synchronous blocking – resources are locked during prepare, causing performance degradation.

Coordinator single‑point failure – if the coordinator crashes after prepare but before commit, all participants remain locked.

Data inconsistency – a failure in the commit step can leave some participants committed while others are not.

Three‑Phase Commit (3PC)

3PC adds a timeout mechanism and splits the prepare phase into canCommit and preCommit. After preCommit, the coordinator re‑checks participant states before issuing commit. However, if a rollback request times out, some nodes may still commit, leading to inconsistency.

XA Transaction Syntax

Typical XA commands are:

XA START|BEGIN xid [JOIN|RESUME]

XA END xid [SUSPEND [FOR MIGRATE]]

XA PREPARE xid

XA COMMIT xid [ONE PHASE]

XA ROLLBACK xid

XA RECOVER

Seata XA Mode

Seata, an open‑source distributed transaction framework from Alibaba, supports AT, TCC, SAGA, and XA modes. Its XA mode relies on a data‑source proxy (e.g., Druid) to interact with the underlying database’s native XA support.

@Bean
@ConfigurationProperties(prefix = "spring.datasource")
public DruidDataSource druidDataSource() {
    return new DruidDataSource();
}

@Bean("dataSourceProxy")
public DataSource dataSource(DruidDataSource druidDataSource) {
    return new DataSourceProxyXA(druidDataSource);
}

Seata optimizes the traditional 2PC by merging the first two phases into a single step:

XA START, execute SQL with autocommit = false, then XA PREPARE.

In the second phase, Seata directly issues XA COMMIT or XA ROLLBACK.

Key source code excerpts:

public void commit() throws SQLException {
    try {
        xaResource.end(xaBranchXid, XAResource.TMSUCCESS);
        xaResource.prepare(xaBranchXid);
        keepIfNecessary();
    } catch (XAException xe) {
        DefaultResourceManager.get().branchReport(BranchType.XA, xid, xaBranchXid.getBranchId(),
            BranchStatus.PhaseOne_Failed, null);
        throw new SQLException("Failed to end/prepare xa branch on " + xid + "-" + xaBranchXid.getBranchId(), xe);
    } finally {
        cleanXABranchContext();
    }
}

public void xaCommit(String xid, long branchId, String applicationData) throws XAException {
    XAXid xaXid = XAXidBuilder.build(xid, branchId);
    xaResource.commit(xaXid, false);
    releaseIfNecessary();
}

The xaResource instance comes from the MySQL driver ( MysqlXAConnection), which implements the native XA interface.

Architecture Highlights

Seata’s RM side uses classes such as AbstractNettyRemotingClient and ClientHandler to receive TC requests and delegate to RmBranchCommitProcessor. The processor ultimately calls ResourceManagerXA.finishBranch, which invokes connectionProxyXA.xaCommit to complete the transaction.

Seata’s XA mode works well with MySQL but has limited support for Oracle because Oracle implements the standard XA flow (separate prepare and commit), making Seata’s optimization incompatible.

Conclusion

Seata implements XA by leveraging the database’s native XA support through a data‑source proxy, providing a low‑intrusion distributed transaction solution. MySQL’s MysqlXAConnection supplies the underlying XA calls, while Seata’s optimized two‑phase flow reduces latency compared to classic 2PC.

References

http://seata.io/zh-cn/docs/overview/what-is-seata.html

https://github.com/seata/seata