Two-Phase Commit (2PC) is a distributed transaction coordination protocol that ensures atomic commitment across multiple participant nodes: either all participants commit a transaction or all abort it, with no partial updates persisted. In the prepare phase, a coordinator polls all participants for their readiness to commit; in the commit phase, it broadcasts the final decision based on unanimous consensus from the prepare phase. 2PC is the foundational protocol for distributed ACID transactions but is blocking in the presence of coordinator failure, a limitation addressed by Three-Phase Commit and Paxos-based variants.
Content
- The Two-Phase Commit protocol was formalised by Jim Gray in his 1978 notes on transactions and database recovery, building on the theoretical work of Lampson and Sturgis on crash recovery. It emerged as the standard mechanism for coordinating distributed transactions in XA (eXtended Architecture) environments, which became an ISO/IEC standard in 1991 and is implemented by all major relational database systems including Oracle, IBM DB2, PostgreSQL, and MySQL. The protocol’s simplicity and correctness guarantees made it the default choice for distributed ACID transactions throughout the 1990s and 2000s.
- 2PC operates through a coordinator and multiple resource managers (participants). In Phase 1 (Prepare), the coordinator sends a PREPARE message to all participants; each either writes its transaction log to durable storage and replies VOTE-COMMIT, or replies VOTE-ABORT. In Phase 2 (Commit/Abort), if all votes are VOTE-COMMIT the coordinator broadcasts COMMIT and participants make the transaction durable; if any participant voted ABORT or timed out, the coordinator broadcasts ABORT and all roll back. The critical durability guarantee is that a participant that votes COMMIT must be able to commit or roll back even after a crash, relying on write-ahead logging.
- The protocol’s fundamental limitation is that it is blocking: if the coordinator fails after participants have voted COMMIT but before broadcasting the final decision, participants are stuck in a prepared state — holding locks and unable to proceed — until the coordinator recovers. This can cause minutes-long outages in systems with hardware failures. Three-Phase Commit (3PC) adds a pre-commit phase to eliminate this blocking behaviour in a synchronous network, though it cannot tolerate network partitions. Practical systems typically add coordinator redundancy via Paxos or Raft to achieve non-blocking distributed transactions.
- By 2024-2025, 2PC underpins distributed transaction support in cloud-native databases (Google Spanner uses Paxos-enhanced 2PC across globally distributed nodes), microservice choreography via the saga pattern as a 2PC alternative, and blockchain cross-chain atomic swaps that adapt its two-phase logic to smart-contract lock-and-release mechanisms. Google Spanner’s TrueTime demonstrates that correct 2PC with external consistency is achievable at global scale using hardware-assisted clock synchronisation, achieving sub-10ms commit latency across continents.