Why a TCC Framework Must Own the Spring TransactionManager

1. TCC Global Transactions Must Use RM Local Transactions

All data‑access operations performed by Try, Confirm, and Cancel methods must participate in the Resource Manager (RM) local transaction so that the changes are either all committed or all rolled back. This guarantees consistency of the global TCC transaction.

2. The Framework Should Take Over Spring’s TransactionManager

By integrating with Spring’s PlatformTransactionManager, the TCC framework can monitor the commit/rollback status of each RM transaction. Knowing whether a Try’s RM transaction was committed is essential because only committed Trys require a Cancel during a global rollback, and Confirm/Cancel operations themselves must also run within committed RM transactions.

2.1 Why the Framework Needs RM Transaction State

Only Try operations whose RM transaction was committed need a corresponding Cancel. If the Try’s RM transaction was rolled back, executing Cancel would corrupt data.

2.2 Can Exceptions Reveal RM Commit Status?

Exceptions in business methods do not reliably indicate the underlying RM transaction outcome, especially with propagation modes (REQUIRED, REQUIRES_NEW) or multiple RM transactions. Intercepting Spring’s TransactionManager is the only reliable way to obtain accurate transaction state.

3. Fault‑Recovery Mechanism Is Mandatory

The framework must persist transaction logs so that after failures (server crash, network outage, power loss) it can restore incomplete global transactions, resume pending Confirm or Cancel actions, and eventually reach a consistent state.

4. Provide Idempotency for Confirm/Cancel Services

Confirm and Cancel may be invoked multiple times due to retries or network glitches. The framework must guarantee that repeated executions have the same effect as a single execution, preventing duplicate updates.

5. Do Not Blindly Use Cancel to Roll Back

If a Try operation never committed (or was never executed), its Cancel must not be run; otherwise the system may attempt to roll back a non‑existent change, leading to inconsistency.

6. Cancel (or Confirm) May Run Parallel to or Before Try

Network failures can cause Cancel to start while Try is still in progress. The framework should mark the Try’s transaction as rollbackOnly, block further propagation, and skip or neutralize the Cancel to avoid inconsistent states.

7. Service Reuse Is Limited

Try/Confirm/Cancel form a single logical unit; they cannot be reused independently. Reuse should target the whole TCC service component rather than individual methods.

8. Only the Try Interface Needs to Be Exposed

External callers interact solely with the Try method; Confirm and Cancel are internal to the TCC framework and should not be visible to other services.

9. Confirm/Cancel Should Not Call Other TCC Services

Allowing Confirm/Cancel to invoke other services could start new global TCC transactions, creating uncontrolled nesting and breaking transaction isolation.

Implementation Note

Building a generic TCC distributed‑transaction framework is complex and error‑prone. Most projects benefit from using an existing open‑source solution such as ByteTCC, which integrates with Spring, supports multiple data sources, and provides the required fault‑tolerance and idempotency.

Repository: https://github.com/liuyangming/ByteTCC