Mastering Distributed Transactions: From 2PC to Seata AT Mode

0. Introduction

From CPU to memory, disk, OS, and network, computer systems contain many unreliable factors. Engineers use various hardware and software techniques—TCP for reliable transmission, RAID for storage, ARIES‑based transaction mechanisms for databases—to ensure correct processing. This article first introduces ACID properties of single‑node database transactions, then highlights the difficulties of operating multiple data sources in distributed scenarios, and finally presents common distributed‑transaction solutions that aim to provide ACID guarantees across multiple databases.

1. Single‑Data‑Source vs Multi‑Data‑Source Transactions

A single‑data‑source transaction (local transaction) relies on the database's built‑in transaction mechanism to guarantee atomicity, consistency, isolation, and durability (ACID). In a microservice‑based e‑commerce system, services such as shopping, inventory, and order each maintain independent databases. When a shopping service calls inventory and order services to complete an order, the overall business spans multiple databases, and local transaction mechanisms cannot ensure global consistency.

2. Common Distributed Transaction Solutions

2.1 Distributed Transaction Model

Key terms include transaction participants (e.g., each database), transaction coordinator (the service that accesses multiple data sources), resource manager (often synonymous with participant), and transaction manager (often synonymous with coordinator). The transaction manager coordinates multiple participants to achieve a global ACID property.

2.2 Two‑General Problem and Idempotency

The classic network two‑general problem illustrates uncertainty when a messenger may be captured. In distributed systems, similar uncertainty arises when a client does not receive a server response due to network failures, making it impossible to know whether an operation succeeded. Idempotent handling ensures that repeated requests produce the same effect.

2.3 Two‑Phase Commit (2PC) & Three‑Phase Commit (3PC)

2PC consists of a prepare phase (participants report readiness) and a commit phase (coordinator instructs commit or rollback). Participants must implement Prepare(), Commit(), and Rollback() interfaces, often via the XA protocol. Drawbacks include performance loss due to blocking, coordinator failure leading to uncertainty, and limited applicability in microservice environments where XA is not used. 3PC adds an extra inquiry phase to mitigate blocking but still cannot fully handle coordinator crashes.

2.4 TCC (Try‑Confirm‑Cancel)

TCC splits a global transaction into Try (resource lock), Confirm (commit), and Cancel (rollback) phases. If all Try calls succeed, the transaction proceeds to Confirm; otherwise, Cancel is invoked. Idempotency is achieved through deduplication tables or KV stores.

2.5 Transaction Status Table

A central status table records the progress of each sub‑operation (e.g., inventory deduction, order creation). A background task scans the table and retries incomplete steps until the transaction reaches a final state or is marked error for manual intervention.

2.6 Message‑Middleware Based Final‑Consistency

This approach uses a message queue (e.g., RabbitMQ) to achieve eventual consistency. The correct workflow places the database write and message enqueue in the same local transaction, ensuring atomicity. Consumers process messages idempotently using deduplication tables. The article contrasts a mistaken implementation that ignores the two‑general problem with the proper design that guarantees no message loss and no duplicate consumption.

3. Implementation of Seata in AT Mode

3.1 Overview of AT Mode Workflow

Seata’s AT mode builds on relational database local transactions, intercepting SQL to record custom undo logs. The two phases are: (1) acquire local lock, execute local transaction, record undo log, and release local lock; (2) if global commit is required, asynchronously delete undo logs; if rollback is needed, replay undo logs to compensate.

3.2 Detailed AT Mode Workflow

An e‑commerce example shows a user purchasing a mouse, involving inventory deduction and order creation. The article presents the relevant t_repo and t_order tables, the SQL sequence wrapped in <code>start global_trx call inventory service call order service commit global_trx</code> , and the undo_log table structure that stores before‑ and after‑images for each branch transaction.

During the first phase, each branch commits its local transaction and records undo logs. Seata aggregates branch statuses to decide global commit or rollback. On commit, branches simply delete their undo logs; on rollback, they use undo logs to generate compensation SQL and restore original data, ensuring atomicity, consistency, and durability.

For isolation, AT mode uses a global lock. Write isolation prevents concurrent writes to the same record by requiring a global lock before committing the local transaction. Read isolation operates at the “read‑uncommitted” level by default, but can be upgraded to “read‑committed” using Seata’s SelectForUpdateExecutor , which acquires a global lock for SELECT FOR UPDATE statements.

4. Conclusion

All discussed solutions—2PC, 3PC, TCC, transaction‑status‑table, and Seata AT mode—share the core idea of a coordinator managing the progress of local transactions to achieve a global ACID property, each with its own trade‑offs. Practical innovations, such as message‑queue‑based eventual consistency, often inspire new standards in distributed transaction processing.