Key Considerations for Building a Generic TCC Distributed Transaction Framework

A TCC transaction framework must base its global transaction management on the local transactions of each Resource Manager (RM); without RM‑local transactions, rollback and consistency become impossible.

By integrating with Spring's PlatformTransactionManager , the framework can monitor the commit/rollback status of each RM transaction, ensuring that only successful Try operations trigger Cancel during rollback and that Confirm operations are executed only after their corresponding Try has been committed.

Fault‑recovery is critical: the framework should log transaction details and be able to resume incomplete global transactions, handling scenarios such as service crashes, network failures, or server restarts.

Idempotency must be guaranteed for Confirm and Cancel services because they may be invoked multiple times during retries; the framework should provide this guarantee rather than relying on individual business services.

When Try, Confirm, or Cancel operations execute in parallel or out of order, the framework should mark the offending Try's local transaction as rollbackOnly , prevent further propagation, and avoid executing ineffective Cancel or Confirm logic.

Additional considerations include avoiding blind reliance on Cancel for rollback, limiting exposure of TCC services to a single Try interface, and preventing Confirm/Cancel from invoking other TCC services to avoid nested global transactions.

Overall, implementing a robust, generic TCC framework is complex and generally not recommended for ad‑hoc development; using established open‑source solutions such as ByteTCC is advisable.