Distributed Transaction Solutions with Seata: ACID, CAP, BASE and Implementation Modes

1 Background Knowledge

As business complexity grows, most systems evolve from monolithic to distributed micro‑service architectures, inevitably encountering the distributed transaction problem. This article summarizes several solutions using the Seata framework.

1.1 ACID

Relational databases provide ACID guarantees:

Atomicity : all operations succeed or none do.

Consistency : the database remains in a valid state.

Isolation : concurrent transactions do not interfere.

Durability : once committed, data is permanent.

1.2 CAP

The CAP theorem states that in a distributed system you can only simultaneously guarantee two of the three properties: Consistency, Availability, and Partition tolerance.

C : Consistency – all data changes are synchronized.

A : Availability – the system responds correctly within an acceptable time.

P : Partition tolerance – the system continues to operate despite network partitions.

1.3 BASE

BASE (Basically Available, Soft state, Eventually consistent) relaxes CAP to improve availability while accepting temporary inconsistency.

BA : Basically Available – the system remains operational.

S : Soft state – state may become temporarily out‑of‑sync.

E : Eventually consistent – data will become consistent over time.

2 Implementation Modes

2.1 Two‑Phase Commit (2PC)

Phase 1 – Prepare : The Transaction Manager (TM) sends a prepare message to every Resource Manager (RM). Each RM writes a local transaction log (redo/undo) but does not commit.

Phase 2 – Commit/Rollback : TM decides to commit or rollback globally; the Transaction Coordinator (TC) drives each branch transaction accordingly.

Seata splits the workflow into three core modules:

TM (Transaction Manager) : controls the global transaction boundary, initiates, commits or rolls back the transaction.

RM (Resource Manager) : manages branch transactions, registers branches, reports status and executes local commit/rollback.

TC (Transaction Coordinator) : maintains global transaction state and coordinates the commit or rollback of all branches.

A typical distributed transaction proceeds as follows:

TM requests TC to create a global transaction and receives a unique XID.

The XID propagates through the micro‑service call chain.

Each RM registers a branch transaction with TC using the XID.

TM asks TC to commit or rollback the global transaction.

TC coordinates all branch transactions to complete the commit or rollback.

2.2 XA

In XA mode each participant follows the standard XA protocol: xa start , execute business SQL, xa end , xa prepare in phase 1; then xa commit or xa rollback in phase 2, guaranteeing atomicity across all participants.

2.3 AT (Automatic Transaction)

AT is a non‑intrusive solution: developers write normal business SQL; Seata automatically generates the second‑phase commit and rollback logic.

During the first phase, Seata’s JDBC proxy (RM) records before‑image and after‑image data as rollback logs within the same local transaction, ensuring that every committed change has a corresponding rollback record.

Before committing, RM registers the branch with TC, obtains write locks for all affected rows (resourceId+tableName+PK), and proceeds only after all locks are granted. If any lock cannot be obtained, TC returns a fast‑fail response and RM retries until timeout.

After the local transaction commits, RM reports the outcome to TC and the business RPC call completes.

In the second phase, TC drives either fast commit (if TM decides global commit) or rollback (if TM decides global rollback). The commit path releases global locks immediately, while rollback retains locks until the branch rollback finishes.

2.4 TCC (Try‑Confirm‑Cancel)

TCC requires the business to implement three operations: Try (pre‑check and reserve resources), Confirm (finalize), and Cancel (release resources). TM registers a global transaction, executes Try in phase 1, and TC invokes Confirm or Cancel in phase 2 based on the global decision.

TCC’s core is the implementation of the three interfaces; it is more intrusive than AT because developers must write explicit Try, Confirm and Cancel logic, but it offers fine‑grained control over resource reservation and release.

2.5 Saga

Saga is a long‑running transaction model where each participant provides a forward service and a compensating (reverse) service. All forward services execute; if any fails, previously successful participants invoke their compensating actions to roll back.

Saga provides high throughput for long‑duration workflows, but because the first phase commits locally without a reservation step, it cannot guarantee strict isolation.

2.6 Message‑Based Component

This approach uses a reliable message service and MQ to achieve a two‑phase commit across upstream and downstream applications.

Steps:

Upstream sends a pending message to the reliable message service.

The service stores the pending message.

Upstream executes its local business logic within the same transaction.

Upstream confirms the message, which is then sent to MQ.

Downstream consumes the MQ message, processes its local business, and acknowledges consumption.

Both upstream and downstream exceptions are handled by the reliable message service, which periodically scans for timed‑out messages, retries delivery, or marks them as dead for manual intervention.

3 Summary

3.1 SQL Support

AT relies on SQL parsing and currently lags behind XA in terms of native SQL support; many users rewrite SQL to make AT work, while XA enjoys full database‑level support.

3.2 Isolation

AT achieves isolation via global row‑level locks stored in the Seata server; XA relies on the underlying database’s isolation mechanisms.

3.3 Intrusiveness

XA is the least intrusive because the database itself participates in the transaction protocol, whereas AT and TCC require additional middleware or application‑level code.

3.4 Compensation Issues

Compensating transaction models (AT, TCC, Saga) cannot guarantee true global consistency because intermediate states may be visible to external observers; XA, by involving the resource directly, prevents such dirty reads when the isolation level is set appropriately.