What is Two-Phase Commit?

Two-Phase Commit (2PC) is a distributed algorithm used to coordinate a commit or abort decision across multiple participants (resource managers) that take part in a single atomic transaction. It is a blocking protocol with two distinct phases: the prepare phase and the commit phase. In the prepare phase, a designated coordinator sends a prepare request to every participant and waits for their votes. Each participant writes a prepare log record, forces its state to disk, and replies with either a Yes vote (promising it can commit) or a No vote (forcing an abort). If the coordinator receives Yes votes from all participants, it decides to commit; otherwise it decides to abort.

In the second phase, the coordinator broadcasts the decision (commit or abort) to all participants and waits for acknowledgments. Each participant that receives a commit must write a commit log record, apply the changes permanently, and acknowledge. Once all acknowledgments are received, the coordinator records the transaction outcome in a log and considers the transaction complete. The protocol guarantees that all participants converge on the same outcome because a participant that voted Yes is blocked until it hears the final decision: it cannot unilaterally commit or abort after promising to commit. This blocking property is the main weakness of 2PC. If the coordinator crashes after sending prepare requests but before sending the final decision, participants may remain locked indefinitely until the coordinator recovers, which reduces availability.

Two-Phase Commit is a foundational building block for distributed transactions, appearing in X/Open XA (eXtended Architecture) standard, where it coordinates between a transaction manager and resource managers such as relational databases, message queues, and other transactional resources. It is also used in many distributed databases and transaction monitors, though modern systems often prefer alternative protocols (Paxos, Raft, or relaxed consistency models) to avoid the blocking problem. The protocol does not require Byzantine fault tolerance; it assumes honest (fail-stop) failures and synchronous communication for the critical voting phase.