Mastering TCC: Application‑Level Distributed Transactions Explained

TCC is Alipay's distributed transaction solution, standing for Try‑Confirm‑Cancel.

Similar to the 2PC two‑phase commit, but operates at the application layer rather than the database layer.

Workflow

Each participant implements three interfaces: try, confirm, and cancel (confirm corresponds to 2PC commit, cancel to rollback). For example, in a transfer service, Service A handles debit, Service B handles credit, both implement these interfaces.

TCC consists of two phases:

Prepare phase

In the prepare phase, the caller invokes the try interface of each service; each service checks resources and locks them if it can complete, returning yes; otherwise returns no.

Commit phase

If all try calls return yes, the caller proceeds to the commit phase, invoking each service's confirm interface to finalize the locked resources.

If any try returns no or times out, the caller invokes each service's cancel interface to release the locked resources.

For abnormal situations, the handling method is to keep retrying, regardless of whether confirm or cancel failed.

Process Example

Consider a transfer with two services: debit and credit, each implementing try, confirm, cancel.

Account A transfers 30 units to account B.

Phase 1: Prepare phase

The caller calls the try interface of both services.

The debit service checks A's balance; if at least 30, it freezes 30 and returns yes; otherwise returns no.

The credit service validates B's account and returns yes if valid.

This phase ensures debit can be deducted and credit can be added.

Phase 2: Commit phase

If both try calls returned yes, the caller calls confirm on both services.

The debit service actually deducts 30 from A; the credit service adds 30 to B.

If any try returned no or timed out, the caller calls cancel on both services.

The debit service unfreezes the 30; the credit service does nothing.

Exception Control

Typical abnormal cases include:

Empty rollback: cancel is called without a preceding try.

Solution: make cancel detect empty rollback by recording transaction state.

Idempotency: confirm or cancel may be called repeatedly during failures.

Solution: record execution state and skip repeated actions.

Hang: cancel executes before try, leading to resources never released.

Solution: record transaction state; try checks if cancel has already run.

Summary

TCC is an application‑level distributed transaction solution, similar to 2PC, with prepare and commit phases.

Implementation must handle empty rollback, idempotency, and hanging issues, typically by recording transaction status.

Advantages:

High reliability

High real‑time performance

Disadvantages:

High development complexity

Performance overhead due to multiple DB operations for transaction state management

TCC frameworks:

https://github.com/changmingxie/tcc-transaction

https://github.com/seata/seata