Two-Phase Commit (2PC) Protocol

Overview

Two-Phase Commit is an atomic commitment protocol used to coordinate distributed transactions across multiple databases or resource managers. It guarantees that either all participants commit the transaction or all abort it -- achieving atomicity in a distributed environment.

2PC is a foundational protocol in distributed systems, used in:

• MySQL XA Transactions -- cross-engine and cross-server atomicity
• PostgreSQL Prepared Transactions -- PREPARE TRANSACTION / COMMIT PREPARED
• Oracle Distributed Transactions -- via database links
• Java EE / Jakarta EE -- JTA (Java Transaction API) with XA data sources
• Microsoft DTC -- Distributed Transaction Coordinator for SQL Server

Architecture

Transaction Coordinator

A central process responsible for orchestrating the protocol. The Coordinator assigns a transaction ID, sends protocol messages to all participants, collects votes, makes the commit/abort decision, and logs the decision to durable storage before broadcasting it.

Participants (Resource Managers)

Database instances that hold the data being modified. Each participant independently evaluates whether it can commit the transaction, writes to its Write-Ahead Log (WAL), acquires and holds locks on affected rows, and votes YES or NO.

Transaction Log

A durable log maintained by the Coordinator that records the transaction state and the final decision. This log is critical for crash recovery -- if the Coordinator restarts, it consults the log to determine whether to commit or abort in-doubt transactions.

Key Concepts

Phase 1: Prepare (Voting)

The Coordinator sends a PREPARE message to every participant. Each participant performs all transaction work (constraint checks, WAL writes, lock acquisition) and responds with either YES (ready to commit, locks held) or NO (cannot commit). A YES vote is a binding promise: the participant guarantees it can commit the transaction if asked.

Phase 2: Commit or Abort (Decision)

If all participants voted YES, the Coordinator writes a COMMIT decision to its log and sends COMMIT to all participants. If any participant voted NO or timed out, the Coordinator writes an ABORT decision and sends ROLLBACK. Participants apply the final decision, write the outcome to their WAL, and release locks.

The Point of No Return

The moment the Coordinator writes COMMIT to its durable log is the point of no return. After this, the Coordinator will retry COMMIT to every participant until all acknowledge, regardless of crashes or network failures. Before this point, any failure defaults to ABORT.

The Blocking Problem

2PC is a blocking protocol. After a participant votes YES, it holds locks and waits for the Coordinator's decision. If the Coordinator crashes between Phase 1 and Phase 2, participants remain blocked -- holding locks indefinitely until the Coordinator recovers. This is the fundamental weakness of 2PC.

Three-Phase Commit (3PC)

3PC was proposed as a non-blocking improvement. It adds a PRE-COMMIT phase between voting and committing, allowing participants to time out and make progress without the Coordinator. However, 3PC is rarely used in practice because it cannot handle network partitions correctly (it may violate safety under partition) and adds extra round trips, increasing latency. Most systems prefer 2PC with heuristic recovery or move away from distributed transactions entirely.

When to Use 2PC

2PC is appropriate when you need strong atomicity across a small number of databases within the same data center, with low-latency, reliable networks. Common use cases include XA transactions spanning two databases, prepared transactions in PostgreSQL, and cross-shard commits in distributed databases.

When NOT to Use 2PC

2PC is a poor fit for microservices communicating over HTTP, cross-datacenter transactions (high latency amplifies the blocking window), high-throughput systems where lock contention is unacceptable, or any environment where participants or the network are unreliable. In these cases, the Saga pattern or event-driven architectures with eventual consistency are preferred.

Scenarios

1. Commit (All Vote YES) -- Client initiates a distributed transaction. Coordinator sends PREPARE to all three database participants. All vote YES after writing to their WAL. Coordinator logs COMMIT decision and broadcasts COMMIT. All participants apply changes and release locks.
2. Abort (Participant Votes NO) -- A transaction that violates a constraint on one participant. The Payments DB votes NO due to exceeding its transaction limit. Coordinator aborts the entire transaction, and all participants roll back regardless of their individual votes.
3. Timeout (Participant Unreachable) -- A network partition makes one participant unreachable during the PREPARE phase. The Coordinator times out waiting for the vote, treats it as a NO, and aborts. The unreachable participant holds locks until it reconnects and receives the ROLLBACK, demonstrating the blocking nature of 2PC.