What’s New in Seata 1.6.x? Deep Dive into AT‑Mode Enhancements and Cloud‑Native Communication

Introduction

Seata is an open‑source distributed transaction framework with over 23,000 stars and a highly active community. Version 1.6.x brings several major enhancements aimed at improving performance and usability in cloud‑native microservice architectures.

AT‑Mode Syntax and Feature Enhancements

Extended AT‑mode syntax : Supports MySQL UPDATE JOIN, Oracle and PostgreSQL multi‑primary‑key operations.

Global lock strategy control : Introduces configurable optimistic and pessimistic lock acquisition to match different business scenarios.

JDK 17 and Spring Boot 3.0 support : Fully compatible with Spring Boot 2 while adding native support for the latest runtime and framework versions.

Multi‑registry service exposure : Allows a single Seata‑Server instance to register with multiple service registries simultaneously.

AT‑Mode Principle Review

When an application starts, Seata proxies the user’s DataSource without intruding on the application. During a transaction, Seata parses the SQL, extracts table metadata, creates a before‑image, executes the business SQL, captures an after‑image, generates a global lock, and registers the branch with the Transaction Coordinator (TC).

Update‑Join and Multi‑Primary‑Key Support

For an UPDATE JOIN statement, Seata first determines the number of tables involved, then builds a SELECT query to fetch the before‑image of each affected row. Example:

update table1 inner join table2 on table1.name = table2.name set table1.money = money+100 where table2.name="张三"

The corresponding before‑image query is:

Select table1.pk, table1.money from table1 inner join table2 on table1.name = table2.name where table2.name="张三" for update

For multi‑primary‑key tables, Seata can obtain the keys either directly from the INSERT statement or via the JDBC getGeneratedKeys API, ensuring correct identification for the second phase of AT‑mode rollback.

LockStrategyMode

Seata 1.6 introduces lockStrategyMode with two options: OPTIMISTIC and PESSIMISTIC . In the pessimistic mode, Seata checks the lock table before inserting a lock, providing full traceability for debugging. In the optimistic mode, the lock is assumed to be available, skipping the existence check and reducing latency. The framework automatically switches to pessimistic mode after the first lock acquisition fails more than once.

Request/Response Model Optimization

Pipeline + Parallel processing : Batch and pipeline features are maximized to increase throughput between Seata Server and Client.

Batch response : Responses are aggregated and sent back without strict ordering, allowing faster completion of independent requests.

Previously (pre‑1.5), requests were queued and processed serially, causing head‑of‑line blocking. The new model merges concurrent RPC messages, dispatches them to a CompletableFuture pool, and processes them in parallel, leveraging CPU cores efficiently.

Service Discovery Model

Seata’s client‑server discovery follows the typical RPC pattern: the TC registers its address to a registry, while TM and RM discover it. Earlier, only a single registry could be used, leading to complications when mixing frameworks such as Spring Cloud (Eureka/Nacos) and Dubbo (Zookeeper/Nacos). Version 1.6 adds multi‑registry exposure, allowing a single Seata‑Server to register with several registries at once, simplifying hybrid microservice environments and reducing operational overhead.

Conclusion

Seata 1.6.x extends the AT‑mode with UPDATE JOIN and multi‑primary‑key support, introduces a dual lock‑strategy to balance safety and performance, revamps the networking model for higher concurrency, and enables multi‑registry service discovery, making it a more robust choice for cloud‑native distributed transactions.