Seata 2.6.0 AT Distributed Transactions: From Deployment, Integration to Failure Boundaries

This article is written based on Seata 2.6.0, Spring Boot 3, the corresponding Spring Cloud Alibaba versions, and MySQL 8. Seata, Spring Boot, Spring Cloud Alibaba, Nacos, and client dependencies must be used according to the official compatibility matrix—upgrading just one component is not supported.

TL;DR

Seata AT is suitable for scenarios where a business operation needs to modify multiple relational databases, participants can tolerate brief global lock contention, and stronger rollback semantics than eventual consistency is required.

AT is not "automatic rollback for all distributed operations." It cannot automatically undo messages already sent, third-party APIs already called, or cached data written, nor can it replace idempotency, retry, compensation, and reliable messaging.

The core flow is:

Application Thread
  -> TM starts global transaction
  -> RM proxies local datasource
  -> TC records global transaction and branch transaction
  -> Database commits locally and saves undo_log
  -> TC decides global commit or rollback

1. Components and Terminology

• TC (Transaction Coordinator): Stores global transactions, branch transactions, and global locks.
• TM (Transaction Manager): Responsible for starting, committing, and rolling back global transactions.
• RM (Resource Manager): Responsible for registering branches, reporting results, and executing local rollbacks.

Seata clients typically contain both TM and RM:

Order Service (TM + RM)
  -> Inventory Service (RM)
  -> Account Service (RM)
                    |
                    v
              Seata TC

@GlobalTransactional is typically placed at the global transaction entry point. Participating services don't need to start new global transactions, but every service that participates in a database must properly integrate with the Seata datasource proxy.

2. AT Actual Execution Process

Taking an UPDATE as an example, the RM roughly completes the following within the local transaction:

1. Parse the SQL to identify the table, primary key, and modification scope.
2. Query the before image (data before modification).
3. Execute the business SQL.
4. Query the after image (data after modification).
5. Write undo_log.
6. Register branch transaction and commit local transaction.

During global commit, TC notifies each branch to commit. Phase one has already completed local commit, so phase two is mainly async cleanup of undo_log.

During global rollback, RM reads undo_log, validates whether current data matches the after image, generates reverse operations based on the before image, and executes the rollback within a local transaction.

So AT is neither a database snapshot nor a fixed reverse SQL. It depends on SQL parsing, before/after images, undo_log, and global locks.

3. Seata 2.6.0 Deployment Principles

The current reference version is Seata 2.6.0. Do not use latest, and do not copy Seata 1.x configuration files, fields, and database scripts directly to 2.x.

For learning environments, TC can use file registration and file storage to first verify the business flow. Production environments should typically use Nacos or other service discovery and configuration centers, and use databases or officially supported high-availability storage.

When TC uses store.mode=db, execute the MySQL scripts from the corresponding database directory in the Seata 2.6.0 release package. Scripts must include at least:

global_table       Global transactions
branch_table       Branch transactions
lock_table         Global locks
distributed_lock   TC cluster coordination
vgroup_table       Transaction group mapping

Each business database participating in AT also needs to execute the undolog table script from the same version of the client. TC tables and business library undolog are not the same type of table.

AT datasource typically requires:

• MySQL uses InnoDB;
• Business tables have stable primary keys;
• SQL can be parsed by Seata;
• Database account has permission to create and write undo_log;
• undo_log, business SQL, and local transactions use the same database connection boundary.

Docker images, JDK, client dependencies, and database scripts must come from the same compatible solution. Do not expose the TC management port to the public internet in production.

4. Spring Boot Client Integration

Do not manually fill in a set of independent version numbers for dependencies. Use BOM or dependency management according to the compatibility matrix of Spring Boot, Spring Cloud, Spring Cloud Alibaba, and Seata.

Configuration concepts are as follows—actual property names should follow the current client version's configuration metadata:

seata:
  enabled: true
  tx-service-group: order_tx_group
  enable-auto-data-source-proxy: true
  data-source-proxy-mode: AT

When using Nacos, both service discovery and configuration center must explicitly configure server-addr, namespace, group, username, and password. Credentials should be injected via environment variables or secrets, not committed to Git.

After startup, confirm:

• Seata client has been initialized;
• Datasource is proxied by Seata;
• RM has registered with TC;
• TM has registered with TC;
• Transaction group has mapped to available TC cluster.

For multi-datasource scenarios, do not rely solely on auto-configuration—explicitly verify each datasource's proxy, Mapper scanning, and transaction manager.

5. Business Example

Global entry point:

@Service
public class OrderApplicationService {
    private final OrderMapper orderMapper;
    private final InventoryClient inventoryClient;
    private final AccountClient accountClient;

    public OrderApplicationService(
            OrderMapper orderMapper,
            InventoryClient inventoryClient,
            AccountClient accountClient) {
        this.orderMapper = orderMapper;
        this.inventoryClient = inventoryClient;
        this.accountClient = accountClient;
    }

    @GlobalTransactional(
        name = "create-order",
        rollbackFor = Exception.class
    )
    public void create(Order order) {
        orderMapper.insert(order);
        inventoryClient.deduct(order.productId(), order.quantity());
        accountClient.debit(order.userId(), order.amount());
    }
}

Participating services handle local business:

@Service
public class InventoryService {
    private final InventoryMapper inventoryMapper;

    public InventoryService(InventoryMapper inventoryMapper) {
        this.inventoryMapper = inventoryMapper;
    }

    @Transactional
    public void deduct(long productId, int quantity) {
        int affected = inventoryMapper.deduct(productId, quantity);
        if (affected != 1) {
            throw new IllegalStateException("Insufficient inventory");
        }
    }
}

The key is not the number of annotations, but the boundaries:

• Global entry point uses @GlobalTransactional;
• Each database-participating local operation has a clear transaction;
• Remote call failures throw identifiable exceptions;
• Inventory deduction and account debit must be idempotent;
• Retries must not deduct inventory or debit accounts repeatedly.

If using HTTP, RPC, or message queues, ensure XID can propagate. Adding annotations only at the entry point without propagating XID will cause participating services to not join the same global transaction.

6. AT Failure Boundaries

The following SQL must be validated with extra attention:

• Complex JOINs, subqueries, and batch updates;
• Tables without primary keys;
• Modifying primary keys or partition keys;
• Large batch data updates;
• Stored procedures, triggers, and database-specific syntax;
• Long-running transactions and high-contention hot rows.

Don't just check if business methods return success—use fault injection testing to verify rollback results, lock release, and undo_log cleanup.

AT does not cover external side effects:

Database commit -> Send MQ message -> Call payment API -> Write Redis

These actions should choose based on business requirements: Outbox pattern, local message table, reliable messaging, idempotent consumption, state machine, compensating transaction, TCC, or Saga.

Global locks are also not a free capability. Hot products, accounts, and inventory create lock contention, leading to slower branch registration, transaction waiting, slower rollbacks, and thread pool accumulation. Transactions should be shortened, unnecessary remote calls within transactions should be avoided, resources should be updated in a stable order, and lock waiting and rollback retries should be monitored.

7. Fault Testing Checklist

Test at least:

1. Inventory service timeout;
2. Account service returns business failure;
3. One branch commits locally but another branch fails;
4. TC restart;
5. Database connection pool exhaustion;
6. After image validation failure;
7. Duplicate requests and client retries;
8. Network response loss;
9. Version compatibility during service deployment.

Each check:

Business table final state
global_table
branch_table
lock_table
undo_log
XID in logs

Production logs should uniformly print XID in request, database branch, remote call, and exception logs, but should not print passwords, tokens, or sensitive business data.

8. Production Checklist

• Seata Server, client, Spring Boot, Spring Cloud Alibaba versions are compatible.
• All images and dependencies are pinned to specific versions.
• TC uses high-availability deployment; file storage is not used for production fault recovery.
• Nacos, database, and TC are accessed via internal network.
• Configuration and credentials are injected via secrets or external configuration.
• Each business database has undo_log for the corresponding version.
• TC database is backed up and has cleanup strategy configured.
• Global transactions have timeout, retry, and degradation strategies.
• External side effects have idempotent or compensation solutions.
• Monitor XID, transaction duration, rollback rate, lock waiting, timeout, retry, and undo_log count.

9. When NOT to Use AT

The following situations typically warrant considering other solutions:

• Transactions span messages, payments, files, and third-party APIs;
• A single global transaction has a very long duration;
• Hot row contention is severe;
• SQL cannot be stably parsed or there is no primary key;
• Business requires eventual consistency more than ACID;
• Team lacks capability to maintain TC, database scripts, monitoring, and fault drills.

Seata AT does not turn a distributed system into a single-node transaction. It provides automated coordination and compensation mechanisms within suitable database boundaries. The prerequisite for using it correctly is to define boundaries, pin versions, control transaction length, and perform real testing on failure paths.

References

• Seata Official Repository & v2.6.0 Release
• Seata AT Mode Official Documentation
• Seata 2.6.0 Same Version Database Scripts
• Spring Boot, Spring Cloud Alibaba Official Compatibility Matrix
• Nacos Official Deployment & Authentication Documentation

Last review time: 2026-07.