Understanding Distributed Transactions: ACID Principles, Two‑Phase Commit, Three‑Phase Commit, and TCC

Author: Wen Dao (WeChat: jishuhui_2015), Java Web full‑stack engineer, senior architect, and technical evangelist with experience in micro‑service architecture, DevOps, e‑commerce, LBS, and IoT.

To grasp distributed transactions , one must first understand what a transaction is in the context of transactional databases.

A transaction groups several database operations that either all succeed or all fail, ensuring isolation between concurrent transactions and guaranteeing durability of the committed changes.

The key property of a transaction is the "all‑or‑nothing" principle: either every operation is applied, or none are.

Transactions provide an isolated environment that preserves data consistency and enables reliable recovery.

0. Transaction Characteristics

Database transactions exhibit four classic ACID properties:

Atomicity : All operations within a transaction must succeed; a single failure aborts the entire transaction.

Consistency : Transactions must transition the database from one valid state to another, respecting all defined constraints (unique keys, cascades, triggers, etc.).

Durability : Once a transaction commits, its effects are permanently stored on disk, surviving power loss.

Isolation : Concurrent transactions do not interfere; each transaction cannot see the intermediate state of others.

1. What Is a Distributed Transaction?

A distributed transaction extends the ACID guarantees to a multi‑node environment where databases may reside on different hosts, operating systems, or network segments. As data volumes grow and micro‑service architectures adopt independent databases, distributed transactions become unavoidable.

2. Two‑Phase Commit (2PC)

The classic solution for distributed transactions is the two‑phase commit protocol, involving a Coordinator and multiple Participants .

Phase 1 – Pre‑commit (Voting) : The coordinator asks each participant if it can commit. If any participant votes "NO", the transaction is aborted; only unanimous "YES" votes allow proceeding.

Phase 2 – Commit Decision : Based on the votes, the coordinator issues a global Commit or Abort command, which participants acknowledge.

During 2PC, participants cannot change their vote after the voting phase, making the protocol vulnerable to coordinator failures and requiring all nodes to be highly available.

While 2PC ensures strong consistency, it suffers from performance drawbacks: high latency due to multiple message exchanges, blocking behavior, and a single point of failure at the coordinator.

3. Three‑Phase Commit (3PC)

Three‑phase commit builds on 2PC by adding a timeout mechanism to avoid indefinite blocking.

Phase 1 – Inquiry : The coordinator asks participants if they can commit; participants respond "YES", "NO", or timeout (treated as "NO").

Phase 2 – Pre‑commit : If all responses are affirmative, the coordinator sends a Commit or Abort decision. Participants acknowledge receipt; if the coordinator times out, it aborts the transaction.

Phase 3 – Commit : The coordinator sends a final DoCommit command; participants perform the actual commit and send an ACK. If the ACK is not received in time, the coordinator aborts.

4. TCC (Try‑Confirm‑Cancel)

TCC is a flexible transaction model popularized by Alipay, consisting of three stages:

Try : Execute business logic, perform checks, and reserve necessary resources.

Confirm : If Try succeeds, commit the business operation using the reserved resources; this step must be idempotent.

Cancel : If Try fails, roll back any reserved resources; also idempotent.

Example: An order service creates an order in DRAFT state, then in the Try phase reserves funds from a capital account service and a red‑packet service. If any reservation fails, Cancel releases the resources and marks the order PAY_FAILED . If all succeed, Confirm finalizes the payment and updates the order to CONFIRMED .

Summary

This article introduced the basic concept of transactions, detailed the ACID properties, and examined several distributed transaction solutions, including two‑phase commit, three‑phase commit, and the TCC model.

Hope it helps you understand distributed transactions!