? TCC事務機制相對于傳統事務機制（X/Open XA Two-Phase-Commit），其特征在于它不依賴資源管理器(RM)對XA的支持，而是通過對（由業務系統提供的）業務邏輯的調度來實現分布式事務。
? 對于業務系統中一個特定的業務邏輯S，其對外提供服務時，必須接受一些不確定性，即對業務邏輯執行的一次調用僅是一個臨時性操作，調用它的消費方服務M保留了后續的取消權。如果M認為全局事務應該rollback，它會要求取消之前的臨時性操作，這將對應S的一個取消操作；而當M認為全局事務應該commit時，它會放棄之前臨時性操作的取消權，這對應S的一個確認操作。每一個初步操作，最終都會被確認或取消。因此，針對一個具體的業務服務，TCC事務機制需要業務系統提供三段業務邏輯：初步操作Try、確認操作Confirm、取消操作Cancel。
1. 初步操作（Try）
TCC事務機制中的業務邏輯（Try），從執行階段來看，與傳統事務機制中業務邏輯相同。但從業務角度來看，卻不一樣。TCC機制中的Try僅是一個初步操作，它和后續的確認一起才能真正構成一個完整的業務邏輯。可以認為
1
[傳統事務機制]的業務邏輯 = [TCC事務機制]的初步操作（Try） + [TCC事務機制]的確認邏輯（Confirm）。
TCC機制將傳統事務機制中的業務邏輯一分為二，拆分后保留的部分即為初步操作（Try）；而分離出的部分即為確認操作（Confirm），被延遲到事務提交階段執行。
TCC事務機制以初步操作（Try）為中心的，確認操作（Confirm）和取消操作（Cancel）都是圍繞初步操作（Try）而展開。因此，Try階段中的操作，其保障性是最好的，即使失敗，仍然有取消操作（Cancel）可以將其不良影響進行回撤。
2. 確認操作（Confirm）
確認操作（Confirm）是對初步操作（Try）的一個補充。當TCC事務管理器決定commit全局事務時，就會逐個執行初步操作（Try）指定的確認操作（Confirm），將初步操作（Try）未完成的事項最終完成。
3. 取消操作（Cancel）
取消操作（Cancel）是對初步操作（Try）的一個回撤。當TCC事務管理器決定rollback全局事務時，就會逐個執行初步操作（Try）指定的取消操作（Cancel），將初步操作（Try）已完成的事項全部撤回。
在傳統事務機制中，業務邏輯的執行和事務的處理，是在不同的階段由不同的部件來完成的：業務邏輯部分訪問資源實現數據存儲，其處理是由業務系統負責；事務處理部分通過協調資源管理器以實現事務管理，其處理由事務管理器來負責。二者沒有太多交互的地方，所以，傳統事務管理器的事務處理邏輯，僅需要著眼于事務完成（commit/rollback）階段，而不必關注業務執行階段。
而在TCC事務機制中的業務邏輯處理和事務處理，其關系就錯綜復雜：業務邏輯（Try/Confirm/Cancel）階段涉及所參與資源事務的commit/rollback；全局事務commit/rollback時又涉及到業務邏輯（Try/Confirm/Cancel）的執行。
