Understanding Seata AT Mode: How Distributed Transactions Work in Microservices

Seata Transaction Modes Overview

Seata is an open‑source distributed‑transaction solution for microservice architectures, providing high‑performance and easy‑to‑use transaction services.

1. Transaction Definition in Seata

Seata defines a global transaction as the coordination of multiple branch transactions. 1. TM requests TC to begin, commit, or roll back a global transaction. 2. TM binds the global transaction ID (XID) to each branch transaction. 3. RM registers the branch transaction with TC, associating it with the XID. 4. RM optionally reports the execution result to TC. 5. TC sends branch‑commit or branch‑rollback commands to RM.

2. Integration of Other Two‑Phase Models

TCC Transaction Mode

The TCC model integrates with Seata by letting the RM manage the try phase and the confirm/cancel phases, while the TM still initiates the transaction. The flow mirrors Seata’s own diagram, but the RM handles the first‑phase try execution and the second‑phase confirm/cancel.

XA Transaction Mode

XA mode leverages the XA interface: during the first phase the RM creates an XAConnection, starts an XA transaction, and performs an XA‑prepare which persists all operations. In the second phase TC notifies the RM to commit or roll back the XA branch.

3. AT Mode

First Phase

Example SQL: update product set name = 'GTS' where name = 'TXC'.

Parse the SQL and query the pre‑image: select id, name, since from product where name = 'TXC'.

Execute the business SQL.

Query the post‑image: select id, name, since from product where id = 1.

Second Phase

Commit : delete transaction‑related information such as undoLog and row locks.

Rollback : retrieve the pre‑image and restore the data, then delete undoLog and locks.

How AT Guarantees Distributed Consistency

Seata proxies the application's DataSource at startup, intercepts JDBC calls, generates pre‑images, executes the business SQL, generates post‑images, and registers branch information with the TC.

During the first phase a global lock is acquired; the transaction cannot commit locally without this lock, preventing dirty writes.

Write Isolation

Before committing the local transaction, the global lock must be obtained.

If the global lock cannot be obtained, the local transaction is not allowed to commit.

Lock acquisition attempts are bounded; exceeding the limit triggers a rollback and lock release.

Comparison of AT, TCC, and XA Modes

Data Locking : AT uses a global lock managed by TC; TCC relies on local transaction locks; XA locks data for the entire transaction duration.

Deadlock / Protocol Blocking : XA can block after prepare until commit/rollback; AT can downgrade because locks reside in TC; TCC does not suffer this issue.

Performance : AT incurs lock‑management overhead but benefits from row‑level locks and fast unlocks; TCC has minimal RPC overhead but requires intrusive business code; XA suffers higher latency due to distributed locks.

Future Roadmap (v1.5.0)

Console UI : visual interface for observability and manual intervention.

Raft Integration : replicate transaction metadata across Seata‑Server nodes to eliminate single‑point failures of external storage.

UndoLog Compression : reduce overhead of large undoLog entries in high‑volume branches.

Conclusion

AT mode proxies resource operations, records before‑and‑after states, and uses global locks to guarantee isolation; when an exception occurs, it restores all branch data, achieving atomicity in distributed transactions.