Mastering TCC Distributed Transactions: Key Design Principles and Pitfalls

1. TCC Global Transactions Must Rely on RM Local Transactions

TCC services consist of Try/Confirm/Cancel operations that access a Resource Manager (RM); these accesses must participate in the RM's local transaction so that all changes either commit or rollback together.

If a service like B does not use RM local transactions (e.g., auto‑commit is true), a failure during B:Try requires the Cancel phase to inspect which writes succeeded, leading to complex idempotency and consistency issues.

Therefore, without RM local transaction support, a TCC framework cannot reliably manage global transactions.

2. TCC Framework Should Take Over Spring's TransactionManager

By treating each Try/Confirm/Cancel as an atomic service whose RM operations are committed or rolled back by Spring's PlatformTransactionManager, the TCC framework can monitor the state of each RM transaction.

Only when a Try's RM transaction is committed should its corresponding Cancel be executed during rollback; otherwise, Cancel must be skipped to avoid inconsistency.

The framework must also understand Spring's exception‑driven transaction semantics (unchecked vs. checked exceptions) and respect explicit @Transactional settings.

3. Fault‑Recovery Mechanism Is Essential

A robust TCC framework must record transaction logs and be able to resume incomplete global transactions after failures such as server crashes, network outages, or power loss, ensuring that all branch transactions reach the same final state.

4. Provide Idempotency Guarantees for Confirm/Cancel

Since Confirm/Cancel may be invoked multiple times due to retries, the framework must guarantee idempotent execution, preventing duplicate effects and data inconsistency.

5. Avoid Blindly Relying on Cancel for Rollback

Cancel should only be executed when the corresponding Try's RM transaction has been committed; otherwise, Cancel must be omitted.

6. Handle Parallel Try and Cancel Execution

Network glitches can cause Cancel to run before Try completes. The framework should mark the Try's transaction as rollback‑only and prevent further propagation to avoid inconsistency.

7. Service Reusability

TCC services expose only the Try interface to callers; Confirm/Cancel are internal to the framework and should not be directly invoked by other services.

8. Do Not Expose Three Separate Interfaces

A TCC service needs only one external endpoint (the Try), while Confirm/Cancel remain hidden within the transaction framework.

9. Avoid Calling Dependent Services' Confirm/Cancel

Confirm/Cancel should not invoke other services' Confirm/Cancel to prevent recursive global transactions and maintain clear transaction boundaries.

In summary, implementing a generic TCC distributed transaction manager is complex; most applications should adopt an existing solution such as ByteTCC, which integrates with Spring, supports multiple data sources, and handles the challenges described above.