Login
C Tutorials C++ Tutorials Java Tutorials Python Tutorials JavaScript Tutorials TypeScript Tutorials C# Tutorials Go Tutorials Rust Tutorials PHP Tutorials Kotlin Tutorials Swift Tutorials
HTML Tutorials CSS Tutorials Frontend Development Backend Development React Tutorials Next.js Tutorials Node.js Tutorials Django Tutorials Mobile App Development
Beginner Tutorials Advanced Guides Coding Roadmaps Interview Preparation DSA Tutorials Projects & Examples Cheat Sheets
About Us Contact Privacy Policy Terms & Conditions Disclaimer Sitemap

Distributed Atomic Commit: Two-Phase and Three-Phase Commit Protocols

In a distributed transaction spanning multiple independent database nodes, all participating shards must satisfy the ACID Atomicity guarantee: either every participant commits its localized changes permanently, or all participants abort and roll back completely.

Because individual nodes can crash and network links can drop packets, distributed systems utilize atomic commitment protocols. The **Two-Phase Commit (2PC)** protocol is the standard consensus mechanism for cross-shard ACID transactions, while the **Three-Phase Commit (3PC)** protocol modifies the flow to mitigate coordinator blocking issues under specific network models.

Two-Phase Commit (2PC) Architecture

2PC divides distributed transaction commitment between a designated Coordinator node and a set of Participant (cohort) nodes across two sequential phases:

Phase 1: Prepare Phase (Voting Phase)

  1. The Coordinator writes a `START_2PC` record to its Write-Ahead Log (WAL) and sends a `PREPARE` RPC to all participants.
  2. Each participant executes the transaction locally up to the point of committing (acquiring necessary locks, validating constraints, and writing undo/redo logs to persistent storage).
  3. Each participant replies with either `VOTE_COMMIT` (if ready and resources are locked) or `VOTE_ABORT` (if constraints failed or resources are unavailable).

Phase 2: Commit / Abort Phase (Decision Phase)

  1. If ALL participants voted `VOTE_COMMIT`: The Coordinator writes a `GLOBAL_COMMIT` record to its log and broadcasts a `GLOBAL_COMMIT` message to all participants. Participants commit changes permanently, release locks, and reply with `ACK`.
  2. If ANY participant voted `VOTE_ABORT` (or a timeout expires): The Coordinator writes a `GLOBAL_ABORT` log record and broadcasts a `GLOBAL_ABORT` command. Participants roll back changes using undo logs and release locks.
  3. Once all `ACK` messages are received, the Coordinator writes an `END` log record, terminating the transaction.

The Critical Weakness: The Blocking Problem

2PC is classified as a **blocking protocol** due to a fundamental failure mode:

  • Coordinator Crash during Decision Phase: If the coordinator crashes after participants have voted `VOTE_COMMIT` but before broadcasting the `GLOBAL_COMMIT` / `GLOBAL_ABORT` decision, participants enter an indefinite state of uncertainty.
  • Resource Deadlocks: Participants that voted `VOTE_COMMIT` cannot unilaterally decide to abort (because the coordinator might have already committed) or unilaterally decide to commit (because another participant might have voted abort).
  • Lock Contention: As a result, participants must keep table and row locks held indefinitely until the coordinator recovers, causing cascading timeouts and system-wide stalling.

Three-Phase Commit (3PC): Eliminating the Blocking State

Introduced by Dale Skeen in 1981, Three-Phase Commit (3PC) eliminates indefinite blocking under crash-stop failure models (with bounded network latency) by splitting the decision phase into two separate stages:

  1. Phase 1: Can-Commit? (Voting): Coordinator asks participants if they can commit. Participants vote `YES` or `NO` without locking resources irreversibly.
  2. Phase 2: Pre-Commit: If all voted `YES`, the coordinator issues a `PRE_COMMIT` message. Participants acknowledge and enter a state where they know every other node also agreed to commit.
  3. Phase 3: Do-Commit: Upon receiving acknowledgements from all participants, the coordinator issues the final `DO_COMMIT` command.

Key Non-Blocking Guarantee: If the coordinator crashes while participants are in the `PRE_COMMIT` state, any newly elected coordinator knows that all participants previously agreed to commit, allowing it to safely proceed with the commit without stalling. However, 3PC assumes a synchronous network and can still fail or cause split-brain data divergence during arbitrary asynchronous network partitions.

2PC vs. 3PC vs. Modern Consensus Protocols

  • Failure Resilience: 2PC handles fail-recovery nodes but blocks on coordinator loss; 3PC avoids blocking in fail-stop systems but fails in partitioned networks; Raft/Paxos handles partitions safely via quorums.
  • Latency Overhead: 2PC requires 2 round-trip times (RTTs); 3PC requires 3 RTTs; Modern distributed databases combine 2PC for cross-shard coordination with Raft/Paxos for intra-shard replication.
  • Saga Pattern Alternative: For long-running asynchronous workflows spanning microservices, systems replace synchronous 2PC blocking locks with the Saga pattern (compensating transactions).

Real-World Systems and Engineering Use Cases

  1. Google Spanner & CockroachDB: Using Two-Phase Commit layered directly on top of Multi-Raft / Paxos consensus groups to coordinate cross-range atomic SQL transactions with TrueTime ordering.
  2. XA Transactions (Java JTA / PostgreSQL / MySQL): Standardizing enterprise distributed transactions across heterogeneous relational databases and message brokers (JMS, ActiveMQ).
  3. Distributed Object Stores & Storage Appliances: Synchronizing file metadata updates and multi-region volume commits across storage clusters.
  4. Financial Settlement & Payment Gateways: Ensuring funds deduction and credit issuance across distinct banking ledgers maintain all-or-nothing transactional guarantees.