Mastering Seata TCC: A Practical Guide to Distributed Transactions

Why Seata TCC Is Needed

Seata AT mode works only with relational databases because the undo log table must stay atomic with business data. When a transaction also involves non‑relational stores such as Redis or Elasticsearch, AT cannot guarantee atomicity, so an alternative is required.

Seata TCC Mode Overview

TCC (Try‑Confirm‑Cancel) is a compensating transaction model where developers write explicit compensation logic for each business step. Unlike AT, TCC is not non‑intrusive but offers fine‑grained control.

Three‑Phase Execution Flow

The TCC workflow consists of:

Try : Reserve necessary resources and validate data without committing.

Confirm : If all Try operations succeed, permanently commit the business operation and release the reserved resources.

Cancel : If any Try fails or a rollback is required, undo all previously executed Try steps and release resources.

Understanding TCC with a Money Transfer Example

Consider account A (balance 1000) transferring 100 to account B (balance 2000). In the Try phase, 100 is frozen in A and a provisional 100 is added to B in a non‑usable state. The Confirm phase finalizes the transfer, while the Cancel phase restores the original balances if Try fails.

When both Try operations succeed, Confirm makes the frozen amount in A become zero and the provisional amount in B become real. If either Try fails, Cancel releases the frozen amount and discards the provisional increase, keeping both accounts unchanged.

Three Common Anomalies in TCC Transactions

1. Empty Rollback

If a network glitch prevents service C from receiving the Try request, the timeout triggers a rollback. Since C never executed Try, its Cancel would run without a corresponding reservation, potentially causing data inconsistency.

Solution: Record in a log whether Try has been executed; only run Cancel when a Try record exists.

2. Idempotency

Second‑phase methods may be invoked repeatedly by retry timers. To ensure idempotent processing, update a status field in a log table and check the affected row count; if no rows are updated, skip further processing.

3. Hanging (Cancel Before Try)

Network congestion may cause the Try request to reach C, but the connection drops, leading A to think C failed. The coordinator may then issue Cancel before C has completed Try, resulting in Cancel executing first.

Solution: After Cancel finishes, insert a Cancel record in the log. When Try later attempts to run, it will detect the existing Cancel record and abort, preventing out‑of‑order execution.

Key Takeaways

TCC shortens resource lock time compared with traditional 2PC.

Business logic is highly flexible because each phase can be customized.

It guarantees strong consistency: a transaction either fully succeeds or fully rolls back.

Complexity increases due to the need for explicit Try/Confirm/Cancel implementations, coordination overhead, and tighter coupling between business and transaction logic.