Mastering Distributed Transactions with ShardingSphere: From ACID to TCC

Background

Distributed transactions aim to preserve ACID properties across multiple databases. Traditional relational‑database local transactions provide ACID but become performance bottlenecks in distributed scenarios.

ACID and CAP/BASE

ACID consists of Atomicity, Consistency, Isolation, and Durability. In large‑scale internet applications, the CAP theorem forces a trade‑off between Consistency and Availability, leading to the BASE model (Basically Available, Soft state, Eventual consistency). Rigid (strong) transactions follow ACID, while flexible transactions adopt BASE semantics.

Industry Approaches

XA

XA, defined in the X/Open CAE specification, specifies communication between a Transaction Manager (TM) and Resource Managers (RM). In Java, javax.transaction.xa.XAResource implements the XA interface; concrete drivers such as com.mysql.jdbc.jdbc2.optional.MysqlXAConnection provide MySQL support. Implementations include weak XA (omits the Prepare phase for higher concurrency), Atomikos, and Narayana.

Weak XA reduces lock time but cannot roll back if a failure occurs during commit, making it suitable for low‑cost, high‑concurrency workloads. Sharding‑Sphere supports weak XA by default.

Two‑Phase Commit (2PC)

2PC is the standard XA implementation. It consists of a Prepare phase where all participants vote, followed by a Commit or Rollback phase based on the votes. If a participant crashes after Prepare, the TM can recover and complete the transaction.

Flexible Transactions

Flexible (or “soft”) transactions lower the strictness of ACID to reduce lock time. Common strategies include:

BED (Best Effort Delivery) : Logs each SQL operation; on failure, retries up to a configured limit. No resource lock, but cannot roll back after repeated failures.

TCC (Try‑Confirm‑Cancel) : Business code implements three phases. Try reserves resources and checks consistency; Confirm executes the final operation; Cancel releases resources. TCC provides quasi‑isolation through the Try phase.

Saga

Saga decomposes a distributed transaction into a series of local transactions, each with a compensating action (similar to TCC’s Confirm/Cancel). If any local transaction fails, the system invokes compensations to roll back previous steps. Saga supports forward and backward recovery but does not guarantee isolation; application‑level locking is required.

Sharding‑Sphere Support

Sharding‑Sphere is an open‑source distributed database middleware consisting of Sharding‑JDBC, Sharding‑Proxy, and Sharding‑Sidecar. It provides standardized data sharding, read/write splitting, flexible transactions, and data‑governance features, suitable for Java, heterogeneous languages, containers, and cloud‑native deployments.

Project address: https://github.com/sharding-sphere/sharding-sphere/

Transaction Models

XA: SPI allows switching among weak XA, Atomikos, and Narayana.

Flexible: Each connection can select an appropriate transaction manager implementing ShardingTransaction, handling begin/commit/rollback per transaction.

Sharding‑Proxy Implementation

Sharding‑Proxy, built on Netty, implements the MySQL protocol and acts as a database proxy. For XA transactions, it creates a dedicated thread per channel, ensuring all sub‑transactions run in the same thread. Performance tests show linear scaling of insert/update latency with the number of shards, while query latency remains stable.

Atomikos Integration

Atomikos embeds a transaction manager inside the JVM. When TransactionManager.begin() is called, an XA transaction is created and bound to the current thread. It wraps JDBC connections to carry transaction context, intercepts createStatement, and follows the XA lifecycle (start, end, prepare, commit/rollback).

Saga Integration

Through a collaboration with Apache ServiceComb, Sharding‑Sphere adopts ServiceComb’s Saga engine. ServiceComb provides a centralized coordinator that receives a JSON‑described transaction graph, executes sub‑transactions (serial or parallel), records events in a Saga log, and triggers compensations on failure.

Future Roadmap

Weak XA (already released)

Atomikos‑based XA (upcoming)

Narayana‑based XA (planned)

BED flexible transaction (released)

Saga (under development)

TCC (planned)

Q&A Highlights

XA can be used in micro‑service architectures for low‑concurrency, short‑lived transactions.

Implementation order follows difficulty; TCC is scheduled last.

Sharding‑Proxy enables multi‑language support (e.g., Go).

Current 3.0 version bundles the transaction module with Sharding‑JDBC and Proxy; standalone use requires publishing Sharding‑Sphere events in custom code.