Mastering Seata: A Deep Dive into Distributed Transaction Management

This article explains Seata’s architecture, core components, and step‑by‑step AT mode workflow—including transaction initiation, branch handling, undo‑log mechanisms, and two‑phase commit/rollback—providing a practical guide for implementing reliable distributed transactions in microservice systems.

Java High-Performance Architecture
Java High-Performance Architecture
Java High-Performance Architecture
Mastering Seata: A Deep Dive into Distributed Transaction Management

1. Overview of Seata

Seata (Simple Extensible Autonomous Transaction Architecture) is an open‑source distributed transaction framework from Alibaba that follows the two‑phase commit model. It has gained significant popularity on GitHub, with over 12,000 stars and frequent recent commits.

In a monolithic application, multiple modules share a single data source and rely on local transactions for consistency. In a microservice architecture, each module becomes an independent service with its own data source, requiring a distributed transaction solution.

Seata handles this by introducing three roles:

TM (Transaction Manager) : the business entry that starts a global transaction and receives a global transaction ID (XID) from the Transaction Coordinator (TC).

TC (Transaction Coordinator) : a separate service that generates XIDs, tracks branch transactions, and coordinates commit or rollback.

RM (Resource Manager) : each microservice (e.g., Storage, Order, Account) that registers its branch transaction with TC, executes local database operations, and reports results.

After all branch transactions complete, TM decides to commit or roll back the global transaction, and TC instructs all RMs accordingly.

Important Mechanisms

(1) Rollback Log : each branch transaction writes a before‑image to an UNDO_LOG table. On rollback, TC uses this log to generate SQL that restores the original state; on commit, the log entries are deleted.

(2) Automatic RM‑TC Interaction : Seata intercepts JDBC calls; when a local transaction starts, it automatically registers with TC, creates undo logs, and reports execution results.

(3) Two‑Phase Rollback Failure : if an RM fails during rollback, TC will retry the rollback once the service recovers.

1.3 Core Components

Transaction Coordinator (TC): maintains global and branch transaction states and directs commit or rollback.

Transaction Manager (TM): initiates, commits, or rolls back a global transaction.

Resource Manager (RM): manages branch transactions, registers them with TC, reports status, and controls commit/rollback of the local resources.

1.4 Detailed Process

The overall workflow is:

TM requests TC to start a new global transaction; TC generates an XID.

The XID propagates through the microservice call chain.

Each RM registers its local transaction as a branch under the XID with TC.

TM asks TC to commit or roll back the XID.

TC directs all branch transactions to commit or roll back.

2. Detailed Workflow Example

This example demonstrates a branch transaction that updates a product name.

SQL statement:

update product set name = 'GTS' where name = 'TXC';

2.1 Phase One (Prepare)

(1) Parse SQL to identify type, table, and conditions.

(2) Query before‑image:

select id, name from product where name = 'TXC';

Result (before image): id=1, name=TXX.

(3) Execute business SQL, changing the name to GTS.

(4) Query after‑image: select id, name from product where id = 1; Result (after image): id=1, name=GTS.

(5) Insert an undo log record into UNDO_LOG containing the before and after images and the original SQL.

(6) Register the branch with TC, acquiring a global lock on the affected row.

(7) Commit the local transaction, persisting both the data change and the undo log.

(8) Report the branch result to TC.

2.2 Phase Two – Rollback

(1) TC sends a rollback request to the RM.

(2) RM locates the corresponding UNDO_LOG entry using XID and branch ID.

(3) Validate current data against the after‑image in the undo log.

(4) Generate and execute rollback SQL using the before‑image: update product set name = 'TXC' where id = 1; (5) Commit the local rollback transaction and report the result to TC.

Phase Two – Commit

(1) TC sends a commit request; the RM queues the request and immediately acknowledges success.

(2) An asynchronous task later deletes the related UNDO_LOG entries.

3. Summary

Seata’s AT mode provides automated, non‑intrusive distributed transaction management based on two‑phase commit, using undo logs to guarantee consistency. While documentation is limited, the framework is mature and widely used. Seata also supports TCC and Saga modes, though AT is the primary and most mature option.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

MicroservicesDistributed Transactionstransaction-managementSeataAT Mode
Java High-Performance Architecture
Written by

Java High-Performance Architecture

Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.