Two Phase Commit

Two-phase commit (2PC) is a distributed consensus protocol that ensures all participating nodes in a distributed transaction either all commit or all roll back, preserving atomicity across multiple independent databases.

This sequence diagram illustrates the two distinct phases. In Phase 1 (Prepare), a coordinator — typically the application server or a transaction manager — sends a PREPARE message to every participant (each database node involved in the transaction). Each participant checks whether it can commit: it writes the proposed changes to its WAL and acquires necessary locks, then responds VOTE-YES if it is ready to commit or VOTE-NO if it cannot (due to a constraint violation, lock conflict, or resource issue).

In Phase 2 (Commit or Abort), the coordinator collects all votes. If every participant voted YES, the coordinator sends COMMIT to all participants; each participant then finalizes its changes, releases locks, and acknowledges. If any participant voted NO, the coordinator sends ABORT to all participants, and each rolls back its prepared changes.

The critical failure scenario is when the coordinator crashes between Phase 1 and Phase 2. Participants that voted YES are stuck in a "prepared but not yet committed" state, holding locks and blocking other transactions. This is the blocking problem of 2PC — it cannot make forward progress without the coordinator recovering. This vulnerability motivates the Paxos and Raft-based protocols used by systems like Google Spanner.

For developers, 2PC appears implicitly when using XA transactions (supported by MySQL, PostgreSQL, and Java EE), distributed ORMs, or service meshes that coordinate cross-service database writes. The Saga Pattern is a common alternative that avoids 2PC by replacing the distributed transaction with a sequence of local transactions and compensating actions.