An Overview of the Seata Distributed Transaction Framework and Its Modes

Background: As business scale grows, monolithic systems can no longer meet the requirements, and distributed architecture becomes the preferred choice for large‑scale Internet platforms. Traditional local transaction solutions are insufficient, prompting the emergence of distributed transaction specifications and frameworks.

Seata, originally named Fescar and open‑sourced by Alibaba, is a distributed transaction processing framework that simplifies the handling of distributed transactions for developers.

1. Distributed Transaction Concepts

Transaction: A unit of program execution that must satisfy ACID properties.

Local transaction: Managed by a local resource manager.

Distributed transaction: Operations span multiple nodes.

Branch transaction: A local transaction managed by a resource manager within a distributed transaction.

Global transaction: A set of branch transactions that together constitute a distributed transaction.

2. Distributed Transaction Implementation Models

Two main approaches exist: the strong‑consistency XA protocol and the eventual‑consistency flexible transaction model.

2.1 XA

Based on a two‑phase commit (2PC) protocol. The transaction manager (TM) generates a global transaction ID, while the resource manager (RM) handles commit/rollback.

2.2 Flexible Transaction (Eventual Consistency)

Three common implementations: TCC, MQ transactional messages, and local message tables (plus less common approaches such as Saga).

TCC: Try/Confirm/Cancel – resources are locked in the try phase, committed in confirm, and released in cancel.

MQ Transactional Message: Uses a message system that supports transactions (e.g., RocketMQ). A prepare message is sent before the local transaction; on success, a commit message is sent.

Local Message Table: Similar to MQ, but relies on the database’s transaction capability to persist messages together with the local transaction.

3. Seata Architecture

The system consists of three core components:

Transaction Coordinator (TC): Maintains the state of global and branch transactions and drives commit/rollback.

Transaction Manager (TM): Defines the scope of a global transaction, starts, commits, or rolls it back.

Resource Manager (RM): Manages resources for branch transactions, registers branches with TC, reports status, and drives branch commit/rollback.

TC runs as an independent server; TM and RM are embedded in the application.

4. Seata Working Modes

Seata supports four modes:

4.1 AT (Auto Transaction)

Default mode; works with relational databases that support local ACID transactions. It records business data and undo logs in the same local transaction.

Two phases:

Phase 1: Business data and undo log are committed together; local locks are released.

Phase 2: Asynchronous commit; rollback is performed by replaying the undo log.

Advantages: non‑intrusive, high concurrency, no need for XA support. Disadvantages: limited to ACID‑compliant relational DBs; SQL parsing not fully complete.

4.2 TCC

Three phases: prepare, commit, cancel. TM requests a global XID from TC, registers branch transactions, and TC decides commit or rollback based on branch results.

Advantages: does not rely on local transactions. Disadvantages: higher business intrusion, manual rollback logic.

4.3 Saga

Long‑lived transactions are split into a series of sub‑transactions, each with a compensating action. If a sub‑transaction fails, previously successful sub‑transactions are compensated.

Advantages: lock‑free, high throughput, easy to implement compensation. Disadvantage: does not guarantee isolation.

4.4 XA

Implements the classic two‑phase commit protocol. Requires resource managers that support XA and Java applications using JDBC.

Advantages: strong consistency. Disadvantages: long‑running branch transactions, low concurrency.

5. Core Implementation of AT Mode

5.1 Transaction Coordinator (TC) Startup

TC runs as a standalone server, maintaining global and branch transaction states.

5.2 Transaction Manager (TM) Startup

TM is embedded in the application. It requires a GlobalTransactionScanner bean for initialization.

5.3 Resource Manager (RM) Startup

RM is also embedded. Besides GlobalTransactionScanner , a DataSourceProxy is needed to intercept SQL, generate undo logs, and commit them together with business SQL.

5.4 Global Transaction Workflow Example

BusinessService initiates a purchase, calls StorageService.deduct via Dubbo, and is annotated with @GlobalTransactional :

@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")
public void purchase(String userId, String commodityCode, int orderCount) {
    storageService.deduct(commodityCode, orderCount);
    // throw new RuntimeException("xxx");
}

Diagrams illustrate successful commit, failure after remote call, write‑lock isolation, and read‑isolation mechanisms.

6. Summary

Seata is a powerful Java‑based distributed transaction framework offering multiple modes. The default AT mode provides zero‑intrusion distributed transactions, improving concurrency compared with traditional 2PC/XA. Seata’s server can be clustered with various storage back‑ends to avoid single‑point failures.