Understanding Distributed Transactions: Concepts, XA Protocol, and TCC Model

1. Transaction

A transaction is a logical unit of work in a database, consisting of a finite sequence of operations and characterized by the ACID properties: Atomicity, Consistency, Isolation, and Durability.

Atomicity : All operations are executed completely or none at all.

Consistency : The database moves from one consistent state to another, preserving integrity constraints.

Isolation : Concurrent transactions do not interfere with each other.

Durability : Once committed, changes survive system failures.

1.2 Local Transaction

Initially, a transaction only accessed a single database resource. In a micro‑service architecture, a service that touches only one database still performs a local transaction.

When a service accesses multiple databases, the transaction is still local to that service.

2. Distributed Transaction Architecture

Local transactions are confined to a single session. In SOA or micro‑service environments, applications often need a single transaction that spans multiple databases and services, giving rise to distributed transactions.

Distributed transaction architectures become more complex, requiring coordination of multiple participants and propagation of transaction context across services.

3. Common Distributed Transaction Models and ACID Implementation

3.1 X/Open XA Protocol

The XA protocol, defined by the X/Open DTP model, introduces a global Transaction Manager (TM) and multiple Resource Managers (RM). The TM coordinates the two‑phase commit (2PC) to ensure atomicity across resources.

Application requests TM to start a global transaction.

Application registers each RM with TM; TM notifies RM to start a branch transaction.

After all RM operations, the application tells TM to commit or rollback; TM performs a prepare phase followed by a commit or rollback phase.

All RMs finish, and the global transaction ends.

3.1.1 Atomicity

XA uses 2PC to guarantee atomic commit: a prepare phase where each RM votes, and a commit phase that proceeds only if all votes are positive.

3.1.2 Isolation

XA does not define isolation; each RM must provide its own local isolation (e.g., MySQL uses two‑phase locking). Global isolation is achieved by ensuring all branch transactions are isolated locally.

3.1.3 Consistency

Consistency is ensured by atomicity and the isolation provided by each RM. For global consistency, XA recommends using the SERIALIZABLE isolation level, or implementing a distributed MVCC (e.g., Google Spanner’s TrueTime).

3.1.4 Summary

XA operates at the resource layer, offering strong ACID guarantees with minimal intrusion but can suffer from performance penalties due to long‑lasting locks.

3.2 TCC Model

The Try‑Confirm‑Cancel (TCC) model achieves distributed transactions without requiring RM support. Business logic is split into three phases: Try (pre‑check and reserve resources), Confirm (finalize), and Cancel (release resources).

3.2.1 Atomicity

TCC also relies on 2PC: Try corresponds to the prepare phase, Confirm to commit, and Cancel to rollback.

3.2.2 Isolation

Isolation is handled at the business layer; TCC shifts lock ownership from the database to the application, reducing lock contention.

3.2.3 Consistency

Atomicity and business‑level isolation together ensure consistency. The model accepts temporary visibility gaps (e.g., funds frozen during Try) that are acceptable in many scenarios.

3.2.4 Summary

TCC enables cross‑DB and cross‑service atomic operations with better performance by releasing database locks after the Try phase, though it requires significant business logic changes.

4. Conclusion

The article first outlines typical distributed transaction scenarios, then examines two prevalent models—XA and TCC—detailing how each achieves the ACID properties. XA provides strict resource‑level guarantees, while TCC offers flexibility and performance by moving isolation to the application layer.

— END —