NOTE

2.2 Distributed Transaction Solution: TCC

1. What Is TCC - A distributed transaction solution that guarantees eventual consistency. 2. TCC Process - TCC: Try, Confirm, Cancel. - Divide the transaction into two phases. - In Phase 1, execute Try to perform business checks and reserve resources. - Phase 2 depends on the result of Phase 1.

Distributed SystemsCreated Updated 2 min readhistorical

This is a historical learning note and may contain outdated or incomplete understanding.

1. What Is TCC?

A distributed transaction solution that guarantees eventual consistency.

2. TCC Process

  • TCC: Try, Confirm, Cancel.
  • Divide the transaction into two phases:
    • In Phase 1, execute Try to perform business checks and reserve resources.
    • Phase 2 depends on the result of Phase 1.
      • If Phase 1 succeeds, execute Confirm to perform business confirmation.
      • If Phase 1 fails, execute Cancel (perform an operation opposite to Try, similar to a manual rollback).
    • TCC

3. 2PC vs TCC

  • It is very similar to 2PC; both have two phases.
    • 2PC is a two-phase approach at the database layer, while TCC is a two-phase approach at the application layer.
    • Each Try, Confirm, and Cancel in TCC runs in a separate transaction, while 2PC operates within one transaction.
  • TCC solves several shortcomings of 2PC:
    • Performance problem: Phase 1 only checks and reserves resources; it does not need to lock them until Phase 2.
    • Single-point problem: after Phase 1 is complete, if the business activity manager goes down in Phase 2, there are still other business activity managers.
    • Consistency problem: after Phase 1 is complete, if any participant goes down in Phase 2 and does not return an ACK, keep retrying until it succeeds (because Phase 1 has already reserved the resources and can guarantee success).

4. Problems with TCC

  • Highly intrusive: depends on the business side to cooperate by providing Try, Confirm, and Cancel interfaces.

5. Use Cases for TCC

  • Suitable for business results that require strong consistency, high real-time performance, and whose distributed transactions can be rolled back, such as the three core services in Internet finance companies: trading, payments, and accounting.
  • Multiple services use multiple data sources, and the data sources do not have to be DBs.

6. Implementations of TCC

6.1. Seata TCC Mode

  • Does not depend on transaction support from the underlying data resources:
    • Phase-one prepare behavior: call custom prepare logic.
    • Phase-two commit behavior: call custom commit logic.
    • Phase-two rollback behavior: call custom rollback logic.

6.2. Seata AT Mode

  • Based on relational databases that support local ACID transactions.
  • Java applications access the database through JDBC.
  • In Seata’s AT mode, we do not need to write Phase 2 at all; it is entirely implemented by Seata itself.

7. References

Discussion

Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub