Distributed Transaction Solutions: 2PC, 3PC, XA, TCC, Saga, Local Message Table, Transactional Messages, and Seata

Overview

In the era of micro‑service architecture, guaranteeing data consistency across multiple distributed services is crucial; this article introduces distributed transaction concepts and various solutions, including the XA protocol, TCC and Saga models, local message tables, transactional messages, and Alibaba’s open‑source framework Seata.

Distributed Transactions

Before discussing distributed transactions, recall the four ACID properties of a single‑node (database) transaction:

Atomicity (A): all operations in a transaction must either all succeed or all fail.

Consistency (C): data integrity must be preserved before and after the transaction.

Isolation (I): defines visibility rules for concurrent transactions.

Durability (D): once a transaction commits, its results are permanently stored.

Distributed transactions must also satisfy these properties, but network communication introduces uncertainty, turning the simple success/failure outcome into success, failure, or unknown, and leading to issues such as node crashes, message loss, out‑of‑order delivery, and other anomalies.

Distributed Transaction Solutions

2PC/3PC

Two‑phase commit (2PC) is a protocol that ensures all participants either commit or roll back a transaction, providing strong consistency.

Two‑phase Commit (English: Two‑phase Commit) is an algorithm designed to keep all nodes in a distributed system consistent when committing a transaction.

2PC introduces a coordinator and participants. The process consists of a prepare phase and a commit phase.

Prepare phase: the coordinator sends a Prepare message to each participant; participants perform a pre‑commit and return success or failure.

Commit phase: if all participants reported success, the coordinator sends Commit messages; otherwise it sends Rollback messages.

2PC provides strong consistency but suffers from several drawbacks:

Synchronous blocking leads to long transaction latency.

The coordinator is a single point of failure.

Data inconsistency may occur if some participants do not receive the Commit message.

3PC

Three‑phase commit (3PC) adds an extra phase (CanCommit and PreCommit) and a timeout mechanism to mitigate the blocking problem of 2PC, but it does not fundamentally solve the coordinator single‑point issue.

XA

XA is a specification that implements the 2PC protocol for relational databases; common databases supporting XA include MySQL and Oracle.

Local Message Table

The local‑message‑table pattern, originally proposed by eBay, splits a distributed transaction into a local transaction and a reliable message‑driven eventual‑consistency step.

Process:

Transaction initiator writes business data and a message record within the same local transaction.

A scheduled task polls the message table and sends unsent messages to a message broker.

The consumer processes the message and acknowledges success.

The initiator updates the message status to “success”.

The approach is simple and low‑cost but has limitations such as coupling between message and business data and applicability only to eventual‑consistency scenarios.

Transactional Messages

Transactional messages, supported by RocketMQ, decouple the local message table from business tables and work for any eventual‑consistency scenario.

Steps:

Producer sends a “prepare” (half) message to RocketMQ; the message is in a prepare state and not consumable.

Producer executes the local transaction.

Producer confirms the message, making it consumable.

If steps 1 or 3 fail, RocketMQ periodically scans unconfirmed messages and asks the producer to commit or cancel them.

TCC

Try‑Confirm‑Cancel (TCC) is a compensation‑based model where each operation defines a try, confirm, and cancel method, effectively an application‑level 2PC.

Try: reserve resources and perform preliminary checks.

Confirm: commit the reserved resources.

Cancel: release the reserved resources.

Implementation considerations include allowing empty rollbacks, preventing hanging (Cancel before Try), and ensuring idempotency.

Saga

Saga, proposed by H. Garcia‑Molina, breaks a long‑running transaction into a series of local transactions coordinated by a saga engine; on failure, compensating actions are executed in reverse order.

Saga offers weaker consistency but higher performance compared with XA/TCC, making it suitable for long‑running business processes.

TCC vs Saga

Both are compensation models; TCC uses a two‑phase approach with explicit Cancel, while Saga commits immediately and relies on compensations.

TCC: short, high‑consistency, strong isolation.

Saga: long‑running, high‑throughput, looser consistency.

Seata

Seata is an open‑source framework backed by Alibaba that provides AT, TCC, Saga, and XA modes for distributed transactions.

AT Mode

AT intercepts business SQL, creates before/after images, and locks rows, achieving transaction atomicity without code intrusion.

TCC Mode

Seata’s TCC follows the standard TCC flow (see diagram).

Saga Mode

Seata’s Saga uses a state‑machine engine to orchestrate local transactions, offering a declarative approach with optional annotation support.

Consistency vs Paxos

Although 2PC and Paxos both address “consistency”, they operate at different layers: 2PC ensures atomicity of a transaction, while Paxos achieves consensus among replicas. For example, Paxos can replace a failed coordinator in 2PC through leader election.

Conclusion

Distributed transaction solutions trade off consistency, performance, and complexity; in practice the guiding principle is to prefer business avoidance, then eventual consistency, and finally strong consistency when necessary.

References

https://www.sofastack.tech/blog/sofa-meetup-3-seata-retrospect/

https://juejin.im/post/5b5a0bf9f265da0f6523913b

https://www.zhihu.com/question/275845393