Key Considerations for Building a General TCC Distributed Transaction Framework

A TCC (Try‑Confirm‑Cancel) transaction framework must manage distributed transactions by ensuring that each service's operations participate in a Resource Manager (RM) local transaction, so that all changes are either committed or rolled back together.

The article explains that without RM‑local transaction support, a failure in a Try operation would require the Cancel phase to inspect which database writes succeeded, leading to complex idempotency and consistency problems.

It argues that a TCC framework should take over Spring's PlatformTransactionManager to monitor the commit/rollback status of RM local transactions, because only when a Try's RM transaction is committed should its corresponding Cancel be executed during a global rollback.

The framework must also provide fault‑recovery mechanisms by persisting transaction logs, allowing interrupted global transactions to be resumed and correctly completed.

Idempotency of Confirm and Cancel services is essential; the framework should guarantee that repeated calls to these services produce the same effect, relieving individual services from handling idempotency themselves.

The article warns against blindly invoking Cancel operations when a Try has not been committed, and outlines strategies for the framework to decide when Cancel can be safely skipped.

It discusses scenarios where Cancel or Confirm may run in parallel with or even before Try due to network failures, recommending that the framework either block such operations until Try finishes or mark the Try transaction as rollbackOnly to prevent inconsistency.

Additional concerns such as service reuse, interface exposure, and avoiding nested TCC calls between services are also covered, concluding that building a robust, generic TCC framework is complex and recommending the open‑source ByteTCC solution for most projects.