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

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

The Bottom Line

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

AT does not mean “every distributed operation rolls back automatically.” It cannot automatically undo messages that have already been sent, third-party APIs that have already been called, or cache entries that have already been written. Nor can it replace idempotency, retries, compensation, or reliable messaging.

The core flow is:

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 performing local rollbacks.

A Seata client usually contains both the TM and RM:

订单服务（TM + RM）
  -> 库存服务（RM）
  -> 账户服务（RM）
                    |
                    v
              Seata TC

@GlobalTransactional usually goes at the entry point of the global transaction. Participating services do not need to start another global transaction, but every service that participates through a database must be properly integrated with Seata's data source proxy.

2. How AT Actually Executes

For an UPDATE, the RM performs roughly the following steps within a local transaction:

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

During a global commit, the TC notifies the branches to commit. The local transactions have already been committed in phase one, so phase two primarily handles asynchronous cleanup of undo_log.

During a global rollback, the RM reads undo_log and verifies that the current data still matches the after image. It then generates the inverse operation from the before image and performs the rollback in a local transaction.

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

3. Seata 2.6.0 Deployment Principles

The reference version used here is Seata 2.6.0. Do not use latest, and do not copy configuration files, fields, or database scripts from Seata 1.x directly into 2.x.

For a learning environment, the TC can use the file registry and file storage modes so you can validate the business flow first. A production environment should generally use a registry and configuration center such as Nacos, along with database storage or an officially supported highly available storage option.

When the TC uses store.mode=db, run the MySQL script from the corresponding database directory in the Seata 2.6.0 release package. The script includes at least:

global_table       全局事务
branch_table       分支事务
lock_table         全局锁
distributed_lock   TC 集群协调
vgroup_table       事务组映射

Every business database participating in AT also needs the undolog table script from the matching client version. The TC tables and the business database's undolog table serve different purposes.

AT data sources generally require:

• MySQL with InnoDB;
• Business tables with stable primary keys;
• SQL that Seata can parse;
• A database account with permission to create and write to undo_log;
• The undo_log table, business SQL, and local transaction to operate within the same database connection boundary.

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

4. Spring Boot Client Integration

Do not manually specify a group of unrelated dependency versions. Instead, use a BOM or dependency management based on the compatibility matrices for Spring Boot, Spring Cloud, Spring Cloud Alibaba, and Seata.

The configuration concepts are as follows. The actual property names are determined by the configuration metadata for the current client version:

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

When using Nacos, explicitly configure server-addr, namespace, group, username, and password for both the registry and the configuration center. Inject credentials through environment variables or secrets, and do not commit them to Git.

After startup, confirm that:

• The Seata client has been initialized;
• The data source is proxied by Seata;
• The RM has registered with the TC;
• The TM has registered with the TC;
• The transaction group has been mapped to an available TC cluster.

In a multi-data-source setup, do not rely solely on auto-configuration. Explicitly validate the proxying, Mapper scanning, and transaction manager for each data source.

5. Business Example

The global entry point is:

Each participant service handles its local business logic:

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

• The global entry point uses @GlobalTransactional;
• Every local operation involving a participating database has a clear transaction boundary;
• A failed remote call raises an identifiable exception;
• Inventory deductions and account debits must be idempotent;
• Retries must not deduct inventory or funds twice.

If you use HTTP, RPC, or a message queue, make sure the XID can propagate. Merely adding the annotation at the entry point without propagating the XID means participating services will not join the same global transaction.

6. AT Failure Boundaries

The following SQL patterns require focused validation:

• Complex JOINs, subqueries, and bulk updates;
• Tables without primary keys;
• Changes to primary or partition keys;
• Large-scale data updates;
• Stored procedures, triggers, and database-specific syntax;
• Long-running transactions and highly contended hot rows.

A successful return from the business method is not enough. Use fault injection to verify the rollback outcome, lock release, and cleanup of undo_log.

AT does not cover external side effects:

数据库提交 -> 发送 MQ 消息 -> 调用支付接口 -> 写入 Redis

Depending on the business requirements, choose an appropriate approach such as an Outbox pattern, local message table, reliable messaging, idempotent consumption, state machine, compensating transaction, TCC, or Saga.

Global locks are not free. Hot products, accounts, and inventory records create lock contention, slowing branch transaction registration, increasing transaction waits, making rollbacks slower, and causing thread pool buildup. Keep transactions short, avoid unnecessary remote calls within a transaction, update resources in a stable order, and monitor lock waits and rollback retries.

7. Failure Test Checklist

Test at least the following scenarios:

1. The inventory service times out;
2. The account service returns a business failure;
3. One branch commits locally and another branch then fails;
4. The TC restarts;
5. The database connection pool is exhausted;
6. After-image validation fails;
7. A request is duplicated or the client retries;
8. A network response is lost;
9. Versions remain compatible during a service rollout.

After each test, check:

业务表最终状态
global_table
branch_table
lock_table
undo_log
日志中的 XID

Production logs should print the XID consistently across request, database branch, remote-call, and exception logs, but must never include passwords, tokens, or sensitive business data.

8. Production Checklist

• The Seata Server, client, Spring Boot, and Spring Cloud Alibaba versions are compatible.
• All images and dependencies are pinned to specific versions.
• The TC uses a highly available deployment; file storage is not used for production failure recovery.
• Nacos, the database, and the TC are accessed over the internal network.
• Configuration and credentials are injected through secrets or external configuration.
• Every business database has an undo_log table from the matching version.
• The TC database is backed up and has a cleanup policy.
• Global transactions have timeout, retry, and fallback strategies.
• External side effects have idempotency or compensation mechanisms.
• Monitor XID, transaction duration, rollback rate, lock waits, timeouts, retries, and undo_log count.

9. When Not to Use AT

Consider a different approach in the following situations:

• The transaction spans messaging, payments, files, and third-party APIs;
• A single global transaction runs for a long time;
• Hot rows are heavily contended;
• SQL cannot be parsed reliably or has no primary key;
• The business prioritizes eventual consistency;
• The team lacks the ability to maintain the TC, database scripts, monitoring, and failure drills.

Seata AT does not turn a distributed system into a single-node transaction. It provides automated coordination and compensation within database boundaries suited to it. Using it correctly requires clearly defined boundaries, pinned versions, controlled transaction duration, and realistic testing of failure paths.

References

• Seata's official repository and the v2.6.0 Release
• Official documentation for Seata AT Mode
• Seata 2.6.0 database scripts from the matching version
• Official Spring Boot and Spring Cloud Alibaba compatibility matrices
• Official Nacos deployment and authentication documentation

Last reviewed: 2026-07.