Understanding XA Distributed Transactions in MySQL and Sharding-JDBC with Atomikos

Hello everyone, I am Chen, the author of the "Spring Cloud Alibaba Practical Project" video tutorial covering Alibaba middleware, OAuth2 microservice authentication, gray release, and distributed transaction practice.

This article is part of the "Billion-Scale Data Sharding Practice" series (article 6) and introduces the XA specification for distributed transactions.

What is the XA Specification

The XA specification, defined by the X/Open organization, is a standard for Distributed Transaction Processing (DTP) that describes the interface between a global transaction manager and local resource managers, enabling ACID properties across multiple resources such as databases, application servers, and message queues.

XA uses a two‑phase commit protocol to ensure that all resources either commit or roll back a transaction together.

XA Transactions in MySQL

MySQL acts as a participant (resource) in XA transactions, not as the coordinator. XA transactions in MySQL can be external or internal:

External XA : participates in external distributed transactions coordinated by a transaction manager.

Internal XA : used for cross‑engine transactions within the same MySQL instance, coordinated by the binary log.

XA transactions are non‑intrusive for business code but have lower performance due to strong consistency and longer lock times, making them suitable for short, low‑concurrency scenarios.

MySQL XA Command Demo

The following commands illustrate a typical XA workflow in MySQL:

XA START "test_xid" – start an XA transaction with global ID test_xid .

update product_base set price=1000 where product_id=743948772064624640 – execute SQL.

XA END "test_xid" – end the transaction, moving it to the IDLE state.

XA PREPARE "test_xid" – move the transaction to the PREPARE state.

XA COMMIT "test_xid" – commit the transaction (state becomes COMMITTED).

XA ROLLBACK "test_xid" – roll back the transaction.

XA Transactions in Sharding-JDBC

Sharding-JDBC now supports XA transactions through implementations such as Atomikos, Narayana, and Bitronix, with Atomikos being the default. The SPI‑based transaction manager class is org.apache.shardingsphere.transaction.xa.XAShardingTransactionManager .

1. Add Dependency

<!-- Dependency for XA transaction support -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-transaction-xa-core</artifactId>
</dependency>

2. Configure Transaction Manager

@Configuration
@EnableTransactionManagement
public class TransactionConfiguration {
    @Bean
    public PlatformTransactionManager txManager(final DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

3. Use @ShardingTransactionType Annotation

To enable XA transactions, annotate the method with @ShardingTransactionType(value = TransactionType.XA) together with @Transactional :

@ShardingTransactionType(value = TransactionType.XA)
@Transactional
public void method() {
    // cross‑database operations
    ...
}

4. Run and Verify

When the application runs, Atomikos creates an xa_tx.log file under the logs directory, which records transaction logs required for crash recovery; do not delete it. Additional Atomikos settings can be customized via a jta.properties file placed on the classpath.

For more details, refer to the accompanying video tutorial and source code.

--- Promotional content omitted for brevity ---