Understanding Global Transaction Models and Seata's AT Mode

Preface

Why a global transaction is needed: a complete business often calls multiple sub‑services, and as the number of services and data grows, the system becomes distributed, bringing data‑consistency challenges that lead to distributed transactions.

Main Transaction Models

XA Model

Supported frameworks: Atomikos, Bitronix, Narayana.

During an XA transaction, both data and connections are locked. The data lock is maintained by the database engine, so in extreme failure cases the lock cannot be released without manual database intervention, making graceful degradation difficult.

LCN Model

Supported framework: tx‑lcn.

LCN works by proxying the Connection to operate local transactions, then a TxManager coordinates them globally. The coordination intercepts the connection pool, so uncommitted transactions occupy connections, which can exhaust the pool under high concurrency.

TCC Model

Supported frameworks: tx‑lcn, tcc‑transaction, Hmily, Seata.

Code changes are costly because the transaction must be split into prepare + commit phases with a rollback path. Performance is good and resources are not blocked; isolation can be high because the two‑phase logic is defined by the application.

SAGA Model

Supported frameworks: ServiceComb‑Saga, Seata.

Code changes are less intensive than TCC but more than AT; it requires compensation (rollback) interfaces. Performance is good, but the first phase commits branch transactions without isolation.

AT Model

Supported framework: Seata.

Seata’s AT mode combines the advantages of XA, LCN, TCC, and SAGA, offering high availability, no need for business‑level transaction control, and does not hold connections while a global transaction is pending. The trade‑off is some performance overhead.

Triangular Principle

All models balance performance, transformation cost, and isolation. AT, LCN, and XA favor isolation and low transformation cost; TCC favors performance and isolation; SAGA favors performance and low transformation cost.

What Is Seata?

Seata is an open‑source distributed‑transaction solution that aims to provide high performance and ease of use.

It offers AT, TCC, SAGA, and XA transaction modes, delivering a one‑stop solution for distributed transactions (AT is the mode originally promoted by Alibaba, with a commercial version GTS on Alibaba Cloud).

Seata AT Mode

AT (Automatic Transaction) is based on SQL parsing to achieve a non‑intrusive automatic compensation and rollback mechanism.

Basic Concepts

Global transaction: the overall transaction that spans multiple micro‑services.

Branch transaction: the individual transaction of each participating service.

Role Division

Seata’s AT mode consists of three modules: TM (Transaction Manager), RM (Resource Manager), and TC (Transaction Coordinator). TM and RM are client‑side components integrated with the business system.

TC (Transaction Coordinator) runs as the Seata‑Server, persisting global transaction, branch transaction, and lock information, and notifies RMs to commit or rollback.

TM (Transaction Manager) defines the global transaction scope, starts, commits, or rolls back the transaction, and generates the XID that identifies the transaction across RMs.

RM (Resource Manager) manages the resources used by branch transactions, registers branches with TC, reports branch status, and executes commit/rollback commands from TC.

Execution Flow in Seata

TM starts a global transaction (registers it with TC).

RMs report resource preparation status to TC according to business scenarios.

TM ends the first phase of the global transaction (notifies TC to commit or rollback).

TC aggregates information and decides commit or rollback.

TC notifies all RMs to commit or rollback, completing the second phase.

Plain Description

Start global transaction.

Register branch transactions.

Branches report normal or abnormal status.

Global transaction is committed or rolled back.

Seata‑Server (Transaction Coordinator)

The server can be deployed via package, Docker, or Kubernetes.

Registry Center

Since version 1.1, Seata‑Server supports high‑availability mode with Consul, Nacos, Eureka, Etcd3, Zookeeper.

Configuration Center

Supports Apollo, Consul, Nacos, Etcd3, Zookeeper.

Transaction Data Store Modes

Three store modes: file (single‑node, in‑memory + local file, high performance), db (high‑availability, shared via database, slightly slower), redis (available from 1.3, high performance but risk of data loss if not properly persisted).

file mode : stores global transaction sessions in memory and persists to a local file root.data . db mode : stores sessions in a shared database for HA. redis mode : stores sessions in Redis; requires appropriate persistence configuration.

Example DB mode tables:

global_table : stores global transaction data.

branch_table : stores branch transaction data.

lock_table : stores global locks for read/write isolation.

Seata‑Client

The client consists of a Transaction Manager and a Resource Manager.

Add the following Maven dependencies:

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-seata</artifactId>
    <version>2.1.0.RELEASE</version>
</dependency>

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-all</artifactId>
    <version>1.2.0</version>
</dependency>

Transaction Manager

Declare a global transaction with @GlobalTransactional on the business method:

class BusinessService {
    @GlobalTransactional
    public void purchase(String userId, String commodityCode, int orderCount) {
        LOGGER.info("purchase begin ... xid: " + RootContext.getXID());
        // deduct inventory
        storageClient.deduct(commodityCode, orderCount);
        // create order
        orderClient.create(userId, commodityCode, orderCount);
    }
}

Provide file.conf and register.conf files that match the server configuration; file.conf defines client settings, while register.conf specifies the coordinator to which the client connects.

Resource Manager

AT mode requires an undo_log table in each micro‑service database to store before‑and‑after snapshots for rollback.

CREATE TABLE `undo_log` (
    `id` bigint(20) NOT NULL AUTO_INCREMENT,
    `branch_id` bigint(20) NOT NULL,
    `xid` varchar(100) NOT NULL,
    `context` varchar(128) NOT NULL,
    `rollback_info` longblob NOT NULL,
    `log_status` int(11) NOT NULL,
    `log_created` datetime NOT NULL,
    `log_modified` datetime NOT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

Snapshot logic (two snapshots before and after the business SQL):

set autocommit = 0;
-- before execution snapshot
select * from product where product_id = 1 for update;
-- business SQL
UPDATE Product SET count = count - 1 WHERE product_id = 1;
-- after execution snapshot
select * from product where product_id = 1 for update;
commit;

DataSource Proxy Configuration

Configure a proxy data source to register branch transactions and report their status after local commit:

@Configuration
public class DataSourceConfig {
    @Primary
    @Bean
    public DruidDataSource druidDataSource() {
        DruidDataSource druidDataSource = new DruidDataSource();
        // ...
        return druidDataSource;
    }

    @Bean
    public DataSourceProxy dataSourceProxy(DruidDataSource druidDataSource) {
        return new DataSourceProxy(druidDataSource);
    }

    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSourceProxy dataSourceProxy) throws Exception {
        SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean();
        factoryBean.setDataSource(dataSourceProxy);
        // ...
        return factoryBean.getObject();
    }
}

Other Features

Automatic Degradation Strategy

Every 2 seconds, Seata performs 10 begin‑commit tests; continuous failures are counted, and if the threshold is reached, Seata disables distributed transactions to avoid prolonged unavailability. When the system recovers, successful tests reset the counter and re‑enable transactions.

Metrics Monitoring

Seata can enable metrics collection on TC, TM, and RM and export them to Prometheus.

New Oriental Xcloud

xcloud‑transaction Component

xcloud‑transaction is a micro‑service‑oriented distributed‑transaction solution built on Seata, offering high performance, easy configuration, and a high‑availability global coordinator without requiring users to set up their own server. It is compatible with native Seata projects, requiring no code or configuration changes for migration.

Dependency

<dependency>
    <groupId>cn.xdf.xcloud</groupId>
    <artifactId>xcloud-starter-transaction</artifactId>
    <version>1.1.0.RELEASE</version>
</dependency>

Feel free to try it out and provide feedback for further improvements.