Distributed Transaction Solutions in Apache ShardingSphere: XA, Saga, and Flexible Transactions

Distributed transactions remain a challenging problem for architects because traditional two‑phase commit (2PC) suffers from performance bottlenecks and flexible (BASE) transactions require significant business refactoring. Apache ShardingSphere (Incubating) introduced a unified transaction module in early 2019 that aims to offer a one‑stop solution covering local transactions, 2PC, and flexible transactions.

The article first revisits the ACID properties (Atomicity, Consistency, Isolation, Durability) and explains why they are hard to maintain in a microservice‑based distributed environment. While relational databases provide strong ACID guarantees for single‑node transactions, scaling these guarantees across multiple services and databases introduces latency and contention.

Local Transaction Local transactions operate on a single data node without coordination and have no performance overhead, but they cannot guarantee consistency across multiple services.

Two‑Phase Commit (2PC) Based on the XA protocol, 2PC offers transparent, strong ACID guarantees. However, it locks all involved resources for the entire transaction duration, making it unsuitable for long‑running or high‑concurrency workloads.

Flexible Transactions (BASE) Flexible transactions relax consistency and isolation in favor of availability and eventual consistency. The article describes two main implementations:

Saga: a series of short local transactions each paired with a compensating action. If any step fails, the saga rolls back by executing compensations in reverse order.

TCC (Try‑Cancel/Confirm): similar to Saga but adds an explicit resource reservation phase (Try) and a confirmation phase (Confirm). It provides stronger guarantees at the cost of higher implementation complexity.

ShardingSphere’s transaction module, named sharding-transaction , integrates these approaches. It consists of three sub‑modules:

sharding-transaction-core : defines user‑facing APIs and developer SPI.

sharding-transaction-2pc : implements XA‑based 2PC, currently supporting Atomikos, Bitronix, and Narayana engines, with the ability to add custom XA managers.

sharding-transaction-base : provides flexible transaction support via the Apache ServiceComb Saga actuator, automatically generating reverse SQL and snapshots for compensation.

XA Transaction Highlights ShardingSphere reuses mature XA engines, automatically switches implementations via SPI, and transparently adapts ordinary DataSource objects into XA resources. It supports default Atomikos (Apache‑licensed) and optional Bitronix or Narayana (LGPL) jars. Developers can also implement custom XA managers if needed.

Flexible Transaction Highlights The Saga engine automatically builds a directed acyclic graph of sub‑transactions and their compensations, handling retries and rollbacks without requiring developers to write compensation logic. ShardingSphere adds reverse‑SQL generation to the ServiceComb Saga actuator, eliminating manual compensation code and keeping the transaction logic at the database layer.

Transaction Isolation Engine (Roadmap) Future work will add isolation levels (read‑committed, repeatable‑read, serializable) for flexible transactions using optimistic/pessimistic locking and multi‑version concurrency control.

External XA Interface Both Sharding‑JDBC and Sharding‑Proxy will expose XA‑compatible data sources, allowing them to participate in external JTA transactions and support XA recovery for in‑doubt transactions.

Transaction Type Switching Developers can change the transaction type at runtime via:

SCTL command (e.g., SCTL:SET TRANSACTION_TYPE=BASE ) for SQL‑based control.

ThreadLocal API (e.g., TransactionTypeHolder.set(TransactionType.XA) ) for programmatic control.

Annotation @ShardingTransactionType(TransactionType.BASE) when using Spring.

The article concludes with a comparative table summarizing the capabilities of local, 2PC, and flexible transactions across business transformation, consistency, isolation, concurrency impact, and suitable scenarios. It emphasizes that ShardingSphere’s distributed transaction module is now ready for production (targeting version 4.0.0‑M1) and will continue to evolve with community contributions.

Finally, the author encourages readers to share, use, and contribute to the open‑source project, providing links to the GitHub repository and official website.