6b:T484,The **Prepare Phase** is the heart of the 2PC protocol—it ensures that every participant can commit before any participant is instructed to do so. Here is the precise sequence of events: **Step 1: Coordinator Initiates Prepare** When the application requests to commit the distributed transaction, the coordinator: 1. Writes a `` record to its local stable log 2. Sends a `PREPARE` message to all participants 3. Sets a timeout timer for collecting votes **Step 2: Participant Processes PREPARE** Upon receiving the PREPARE message, each participant decides whether it can commit. **If the participant CAN commit:** 1. It writes a `` record to its stable log 2. It replies with `VOTE_COMMIT` 3. It enters the **prepared state** (also called the **uncertain state**) 4. It releases no locks—resources remain locked! **If the participant CANNOT commit** (constraint violation, deadlock, resource unavailable): 1. It writes an `` record to its stable log 2. It replies with `VOTE_ABORT` 3. It aborts its local portion and releases locks 4. It need not wait for the coordinator's decision—the transaction will abort6c:T664,COORDINATOR: Initiate Prepare Phase ──────────────────────────────────────────── function prepare_phase(transaction T, participants P[]): // Step 1: Log prepare initiation log_to_stable_storage() // Step 2: Send PREPARE to all participants for each participant p in P[]: send(p, PREPARE, T) // Step 3: Collect votes with timeout votes = {} start_timer(PREPARE_TIMEOUT) while not all_votes_received(P[], votes): if timeout_expired(): return GLOBAL_ABORT // Missing vote = veto msg = receive_message() if msg.type == VOTE_COMMIT or msg.type == VOTE_ABORT: votes[msg.sender] = msg.type // Step 4: Determine global decision if all(vote == VOTE_COMMIT for vote in votes.values()): return GLOBAL_COMMIT else: return GLOBAL_ABORT PARTICIPANT: Process PREPARE Request ──────────────────────────────────────────── function handle_prepare(transaction T): if can_commit(T): // Durably record our promise before voting log_to_stable_storage() // Enter prepared/uncertain state set_state(T, PREPARED) send(coordinator, VOTE_COMMIT, T) else: // Log abort and release resources log_to_stable_storage() release_locks(T) rollback_changes(T) send(coordinator, VOTE_ABORT, T)6d:T779,COORDINATOR: Commit Phase ──────────────────────────────────────────── function commit_phase(transaction T, decision, participants P[]): if decision == GLOBAL_COMMIT: // THE COMMIT POINT - once logged, transaction MUST commit log_to_stable_storage() // Inform all participants of commit decision for each participant p in P[]: send(p, GLOBAL_COMMIT, T) else: // decision == GLOBAL_ABORT log_to_stable_storage() // Inform participants that voted COMMIT (others already aborted) for each participant p that voted VOTE_COMMIT: send(p, GLOBAL_ABORT, T) // Collect acknowledgments (with retry for reliability) acks = {} while not all_acks_received(P[], acks): for each p not in acks: resend_decision(p, decision, T) // Retry if needed msg = receive_message() if msg.type == ACK: acks[msg.sender] = true // Transaction complete log_to_stable_storage() forget_transaction(T) PARTICIPANT: Process Global Decision ──────────────────────────────────────────── function handle_global_decision(transaction T, decision): if decision == GLOBAL_COMMIT: // Make changes permanent log_to_stable_storage() commit_local_changes(T) release_locks(T) else: // decision == GLOBAL_ABORT // Undo any prepared work log_to_stable_storage() rollback_changes(T) release_locks(T) // Acknowledge completion to coordinator send(coordinator, ACK, T) // Clean up local transaction state forget_transaction(T)64:{"json":{"id":"seed_3f2a36400b4cba6264f65fbea6947f06","slug":"distributed-transactions","category":"Database Management Systems","topic":"Distributed Transactions","title":"Distributed Transactions","description":"Master the intricate mechanisms of distributed transaction processing. Explore the Two-Phase Commit protocol, the roles of coordinators and participants, sophisticated failure handling strategies, and the Three-Phase Commit protocol for improved fault tolerance.","difficulty":"ADVANCED","estimatedMinutes":75,"pages":[{"id":"seed_5a7ee60a5d23ebfd03d46163010ddad9","title":"Two-Phase Commit (2PC)","order":0,"content":[{"id":"opening-hook","title":"The Fundamental Challenge of Distributed Atomicity","content":[{"data":{"content":"In a centralized database system, ensuring that a transaction either fully commits or fully aborts is relatively straightforward—the single database engine controls all resources and can make a unilateral decision. However, in a **distributed database system**, where data resides across multiple independent nodes, this seemingly simple guarantee becomes extraordinarily complex.\n\nConsider a global banking transaction that transfers money between accounts stored on servers in New York, London, and Tokyo. Each server independently manages its local data and has no direct knowledge of the others' states. If the New York server commits the debit but the London server fails before crediting, the system enters an **inconsistent state** where money has vanished. The fundamental question becomes: **How can we ensure that all participating nodes either all commit or all abort, despite operating independently and potentially failing at any moment?**"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will deeply understand the Two-Phase Commit (2PC) protocol—the canonical solution for achieving atomicity in distributed transactions. You will comprehend its theoretical foundations, walk through its precise mechanics, analyze its properties, and recognize both its power and its limitations.","variant":"info"},"type":"callout"}]},{"id":"distributed-atomicity-problem","title":"The Distributed Atomicity Problem","content":[{"data":{"content":"Before we can appreciate the elegance of Two-Phase Commit, we must first understand the fundamental problem it solves. In distributed systems theory, this is known as the **atomic commitment problem**.\n\n**The Core Problem:**\n\nA distributed transaction involves multiple **participants**—independent processes or nodes that each hold a portion of the data being accessed. For atomicity, we require:\n\n1. **All-or-Nothing Execution**: Either every participant commits the transaction, or none of them do\n2. **Unanimous Agreement**: If any participant cannot commit (due to constraint violations, deadlocks, or failures), then no participant commits\n3. **Irrevocability**: Once a participant commits, it cannot later abort (and vice versa)\n4. **Eventual Termination**: The protocol must eventually reach a decision, not remain indefinitely uncertain\n\nThese requirements seem intuitive, but achieving them in the presence of **unreliable networks** and **node failures** is remarkably subtle."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Impossibility Result","content":"The Fischer-Lynch-Paterson (FLP) theorem proves that no deterministic protocol can guarantee consensus in an asynchronous system with even one faulty process. The Two-Phase Commit protocol navigates this impossibility by accepting certain trade-offs—specifically, the possibility of blocking during failures.","variant":"warning"},"type":"callout"},{"data":{"content":"**Why Simple Approaches Fail:**\n\nA naive approach might have each participant independently decide to commit once its local work succeeds. But this fails catastrophically:\n\n- **Participant A** completes its local work and commits\n- **Participant B** encounters a constraint violation and must abort\n- **Result**: Inconsistent state—A has committed changes that B has not\n\nAnother naive approach might have a central coordinator simply tell everyone to commit. But this also fails:\n\n- **Coordinator** sends 'COMMIT' to all participants\n- **Participant A** commits successfully\n- **Participant B** crashes before receiving the message\n- **Result**: A has committed, B has not—inconsistency persists\n\nThe fundamental insight is that we need a protocol where **every participant's ability to commit is verified before any participant actually commits**. This is the core idea behind Two-Phase Commit."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"two-phase-commit-overview","title":"Two-Phase Commit Protocol Overview","content":[{"data":{"content":"The **Two-Phase Commit (2PC) protocol**, introduced by Jim Gray in 1978, is the canonical solution to the atomic commitment problem. The name derives from its two distinct phases:\n\n1. **Prepare Phase (Voting Phase)**: The coordinator queries all participants to determine if they can commit\n2. **Commit Phase (Decision Phase)**: Based on the votes, the coordinator instructs all participants to either commit or abort\n\nThis two-phase structure ensures that no participant permanently commits until the coordinator has confirmed that **all participants are prepared to commit**. Let's examine each phase in rigorous detail."},"type":"text"},{"data":{"rows":[["Phase 1: Prepare","Coordinator","Coordinator → Participants (PREPARE)","Gather votes on commit readiness"],["Phase 1 Response","Participants","Participants → Coordinator (VOTE_COMMIT / VOTE_ABORT)","Report local commit capability"],["Phase 2: Commit/Abort","Coordinator","Coordinator → Participants (COMMIT / ABORT)","Enforce global decision"],["Phase 2 Response","Participants","Participants → Coordinator (ACK)","Confirm completion"]],"caption":"Two-Phase Commit Protocol Phases","headers":["Phase","Initiator","Message Flow","Purpose"]},"type":"table"},{"data":{"content":"**Protocol Actors:**\n\nThe 2PC protocol involves two types of actors:\n\n**Coordinator (Transaction Manager)**:\n- Initiates and manages the distributed transaction\n- Sends PREPARE messages to all participants\n- Collects votes and makes the global commit/abort decision\n- Logs decisions to stable storage for recovery\n- Sends the final decision to all participants\n\n**Participants (Resource Managers)**:\n- Execute local portions of the transaction\n- Respond to PREPARE with their vote (VOTE_COMMIT or VOTE_ABORT)\n- Follow the coordinator's final decision\n- Log their state transitions for recovery\n\nTypically, the client application interacts only with the coordinator, which orchestrates the entire distributed transaction transparently."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"prepare-phase","title":"Phase 1: The Prepare Phase","content":[{"data":{"content":"$6b"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Critical Prepared State","content":"When a participant votes VOTE_COMMIT, it enters the **prepared state**. This is a **commitment** to follow the coordinator's decision, whatever it may be. The participant is promising: 'I CAN commit this transaction, and I WILL commit if you tell me to—and I WILL abort if you tell me to abort.' This promise is irrevocable until the coordinator responds.","variant":"tip"},"type":"callout"},{"data":{"content":"**The Durability of PREPARED:**\n\nThe `` log record is absolutely critical. By writing this record to stable storage before voting VOTE_COMMIT, the participant ensures that:\n\n1. **If it crashes**: Upon recovery, it can determine from its log that it voted to commit and must wait for the coordinator's decision\n2. **If it is in doubt**: It knows to query the coordinator rather than unilaterally aborting\n\n**Why Voting COMMIT is Irrevocable:**\n\nOnce a participant votes VOTE_COMMIT, it cannot unilaterally abort. Consider this scenario:\n\n- Participant P1 votes VOTE_COMMIT\n- Participant P2 also votes VOTE_COMMIT\n- Coordinator decides COMMIT\n- P1 crashes before receiving COMMIT, recovers, and unilaterally aborts\n- **Result**: P2 has committed, P1 has aborted—inconsistency!\n\nBy making VOTE_COMMIT irrevocable and logging it durably, we prevent this inconsistency."},"type":"text"},{"data":{"code":"$6c","fileName":"prepare-phase-pseudocode.txt","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"commit-phase","title":"Phase 2: The Commit Phase","content":[{"data":{"content":"Once the coordinator has collected all votes (or the timeout has expired), it enters the **Commit Phase** and makes a global decision.\n\n**Decision Rule:**\n\nThe decision follows a simple but critical rule:\n\n- **If ALL participants voted VOTE_COMMIT** → Global decision is **COMMIT**\n- **If ANY participant voted VOTE_ABORT OR any participant timed out** → Global decision is **ABORT**\n\nThis rule ensures that a transaction commits only when every participant has explicitly confirmed its ability to commit. Any failure, whether an explicit VOTE_ABORT or a failure to respond, results in abort—preserving the all-or-nothing property."},"type":"text"},{"data":{"rows":[["All VOTE_COMMIT","COMMIT","Universal agreement—safe to commit"],["At least one VOTE_ABORT","ABORT","Explicit rejection—cannot commit"],["At least one timeout/no response","ABORT","Cannot confirm consensus—abort to be safe"],["Mixed VOTE_COMMIT and VOTE_ABORT","ABORT","Any ABORT vetoes the transaction"]],"caption":"Coordinator Decision Matrix","headers":["Vote Pattern","Global Decision","Rationale"]},"type":"table"},{"data":{"content":"**Step-by-Step Commit Phase:**\n\n**If Global Decision is COMMIT:**\n\n1. Coordinator writes `` to its stable log (this is the **commit point**)\n2. Coordinator sends `GLOBAL_COMMIT` message to all participants\n3. Each participant:\n - Writes `` to its stable log\n - Makes changes permanent (commit locally)\n - Releases all locks\n - Sends `ACKNOWLEDGMENT` to coordinator\n4. Coordinator waits for all acknowledgments\n5. Coordinator writes `` to log and forgets the transaction\n\n**If Global Decision is ABORT:**\n\n1. Coordinator writes `` to its stable log\n2. Coordinator sends `GLOBAL_ABORT` message to all participants\n3. Each participant that was in PREPARED state:\n - Writes `` to its stable log\n - Rolls back changes (undo local work)\n - Releases all locks\n - Sends `ACKNOWLEDGMENT` to coordinator\n4. Coordinator waits for all acknowledgments\n5. Coordinator writes `` to log and forgets the transaction"},"type":"text"},{"data":{"icon":"Info","title":"The Point of No Return","content":"The **commit point** is the moment when the coordinator writes to stable storage. Before this moment, the transaction might still abort. After this moment, the transaction is irrevocably committed. Even if the coordinator crashes immediately after writing this record, upon recovery it will see the COMMIT record and re-send GLOBAL_COMMIT to any participants that haven't acknowledged.","variant":"note"},"type":"callout"},{"data":{"code":"$6d","fileName":"commit-phase-pseudocode.txt","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"state-diagrams","title":"Protocol State Diagrams","content":[{"data":{"content":"Understanding the state transitions in 2PC is essential for implementing the protocol correctly and reasoning about failure scenarios. Both the coordinator and participants move through well-defined states.\n\n**Coordinator States:**\n\n1. **INITIAL**: Transaction is active, running normally\n2. **WAIT**: Sent PREPARE, waiting for votes from participants\n3. **COMMIT**: Decided to commit, sending GLOBAL_COMMIT\n4. **ABORT**: Decided to abort, sending GLOBAL_ABORT\n5. **END**: Transaction completed, resources freed\n\n**Participant States:**\n\n1. **INITIAL**: Executing local transaction operations\n2. **PREPARED (UNCERTAIN)**: Voted VOTE_COMMIT, waiting for global decision\n3. **COMMITTED**: Received GLOBAL_COMMIT, applied changes permanently\n4. **ABORTED**: Either voted VOTE_ABORT or received GLOBAL_ABORT"},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"stateDiagram-v2\n direction LR\n \n [*] --> INITIAL\n \n INITIAL --> WAIT: Send PREPARE\n \n WAIT --> COMMIT: All voted COMMIT\n WAIT --> ABORT: Any voted ABORT or timeout\n \n COMMIT --> END: All ACKs received\n ABORT --> END: All ACKs received\n \n END --> [*]\n \n note right of WAIT\n Collecting votes\n from participants\n end note\n \n note right of COMMIT\n Commit point reached\n Decision is irrevocable\n end note"},"type":"mermaid-excalidraw"},{"data":{"content":"**The Critical PREPARED State:**\n\nThe **PREPARED** state for participants is uniquely important—and uniquely dangerous. A participant in the PREPARED state:\n\n1. Has promised to follow the coordinator's decision\n2. Cannot unilaterally abort or commit\n3. Is holding locks that block other transactions\n4. Must wait for the coordinator to resolve the uncertainty\n\nIf the coordinator fails while participants are in PREPARED state, those participants are **blocked**. They cannot proceed—they cannot commit (they don't know if others prepared) and they cannot abort (perhaps the coordinator decided to commit). This is the famous **blocking problem** of 2PC."},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"stateDiagram-v2\n direction LR\n \n [*] --> INITIAL\n \n INITIAL --> PREPARED: Receive PREPARE, vote COMMIT\n INITIAL --> ABORTED: Vote ABORT (constraint violation)\n \n PREPARED --> COMMITTED: Receive GLOBAL_COMMIT\n PREPARED --> ABORTED: Receive GLOBAL_ABORT\n \n COMMITTED --> [*]\n ABORTED --> [*]\n \n note right of PREPARED\n UNCERTAIN STATE\n Cannot proceed without\n coordinator decision\n Holding locks!\n end note"},"type":"mermaid-excalidraw"}],"titleType":"number","titleNumber":5},{"id":"message-flow","title":"Message Flow Visualization","content":[{"data":{"content":"Let's trace through a complete successful 2PC execution with three participants to see how the messages flow and how state transitions occur.\n\n**Scenario**: A distributed transaction T spans three database servers (P1, P2, P3). The transaction coordinator (C) manages the commit process.\n\n**Timeline of Events:**"},"type":"text"},{"data":{"rows":[["t0","Client","Request COMMIT for transaction T","-"],["t1","Coordinator","Log , send PREPARE to P1, P2, P3","WAIT"],["t2","P1","Receive PREPARE, can commit, log , send VOTE_COMMIT","PREPARED"],["t3","P2","Receive PREPARE, can commit, log , send VOTE_COMMIT","PREPARED"],["t4","P3","Receive PREPARE, can commit, log , send VOTE_COMMIT","PREPARED"],["t5","Coordinator","Receive all VOTE_COMMIT, log , send GLOBAL_COMMIT","COMMIT"],["t6","P1","Receive GLOBAL_COMMIT, log , commit locally, send ACK","COMMITTED"],["t7","P2","Receive GLOBAL_COMMIT, log , commit locally, send ACK","COMMITTED"],["t8","P3","Receive GLOBAL_COMMIT, log , commit locally, send ACK","COMMITTED"],["t9","Coordinator","Receive all ACKs, log ","END"]],"caption":"2PC Message Sequence for Successful Commit","headers":["Time","Actor","Action","State After"]},"type":"table"},{"data":{"height":"500px","mermaidSyntax":"sequenceDiagram\n participant Client\n participant C as Coordinator\n participant P1 as Participant 1\n participant P2 as Participant 2\n participant P3 as Participant 3\n \n Client->>C: COMMIT Transaction T\n \n rect rgb(240, 248, 255)\n Note over C,P3: Phase 1: Prepare (Voting)\n C->>P1: PREPARE\n C->>P2: PREPARE\n C->>P3: PREPARE\n \n P1->>C: VOTE_COMMIT\n P2->>C: VOTE_COMMIT\n P3->>C: VOTE_COMMIT\n end\n \n Note over C: Decision: COMMIT\n \n rect rgb(240, 255, 240)\n Note over C,P3: Phase 2: Commit\n C->>P1: GLOBAL_COMMIT\n C->>P2: GLOBAL_COMMIT\n C->>P3: GLOBAL_COMMIT\n \n P1->>C: ACK\n P2->>C: ACK\n P3->>C: ACK\n end\n \n C->>Client: Transaction Committed"},"type":"mermaid-excalidraw"},{"data":{"content":"**Abort Scenario:**\n\nNow consider a case where P2 cannot commit (perhaps due to a constraint violation):\n\n- P1 and P3 vote VOTE_COMMIT\n- P2 votes VOTE_ABORT\n- Coordinator decides GLOBAL_ABORT\n- P1 and P3 rollback their prepared work\n- P2 has already aborted\n\nThe key insight: P2's abort vote **vetoes** the entire transaction. This preserves atomicity—either all participants commit or none do."},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"logging-wal","title":"Logging and Write-Ahead Protocol","content":[{"data":{"content":"The correctness of 2PC depends critically on **write-ahead logging (WAL)** and the **force-write** discipline. Every state transition must be logged to stable storage **before** the corresponding message is sent. This ensures that crashes can be recovered correctly.\n\n**Write-Ahead Logging Rules for 2PC:**"},"type":"text"},{"data":{"items":["**Log ** before sending PREPARE to any participant — Records that the prepare phase has begun","**Log ** before sending GLOBAL_COMMIT to any participant — This is the commit point; after this record is on disk, the transaction MUST commit","**Log ** before sending GLOBAL_ABORT to any participant — Records the abort decision for recovery","**Log ** after receiving all acknowledgments — Signals that the transaction is complete and can be forgotten"],"title":{"icon":"CheckCircle","text":"Coordinator Logging Rules","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"items":["**Log ** before sending VOTE_COMMIT — Records the promise to follow coordinator's decision; includes undo/redo information","**Log ** if voting abort or after receiving GLOBAL_ABORT — Records the abort for recovery","**Log ** after receiving GLOBAL_COMMIT — Records successful completion"],"title":{"icon":"CheckCircle","text":"Participant Logging Rules","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Force-Write Requirement","content":"These log records must be **force-written** to stable storage (typically using fsync or equivalent). They cannot remain in volatile buffer cache. If a crash occurs after a log record is written but before the corresponding action, recovery can correctly handle the situation. If the log record were still in volatile memory, it would be lost, and recovery would produce incorrect results.","variant":"warning"},"type":"callout"},{"data":{"content":"**Log Contents:**\n\nThe log records contain essential information for recovery:\n\n****:\n- Transaction ID\n- List of participants\n- Timeout value\n\n**** (at participant):\n- Transaction ID\n- Coordinator identity\n- All undo/redo information for local changes\n\n****:\n- Transaction ID\n- List of participants (at coordinator)\n\n****:\n- Transaction ID\n\n****:\n- Transaction ID\n- Signal that all participants have acknowledged"},"type":"text"}],"titleType":"number","titleNumber":7},{"id":"properties-of-2pc","title":"Properties of Two-Phase Commit","content":[{"data":{"content":"The Two-Phase Commit protocol provides several important guarantees, but also has notable limitations. Understanding these properties is essential for correct application.\n\n**Safety Properties (Always Hold):**"},"type":"text"},{"data":{"items":["**Atomicity**: If any participant commits, all participants eventually commit. If any participant aborts, no participant commits. This is the core guarantee.","**Consistency**: The protocol never leaves the distributed database in an inconsistent state where some participants have committed and others have aborted.","**Agreement**: All participants that reach a terminal state reach the SAME terminal state (all COMMITTED or all ABORTED).","**Validity**: If all participants vote COMMIT and there are no failures, the transaction commits. The protocol doesn't abort unnecessarily in the failure-free case."],"title":{"icon":"CheckCircle","text":"Safety Guarantees","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Liveness Properties (Hold Under Conditions):**\n\nUnfortunately, 2PC has a significant limitation regarding liveness—specifically, it can **block** in certain failure scenarios."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Blocking Problem","content":"If the coordinator fails after sending PREPARE but before sending the global decision, participants in the PREPARED state are blocked. They cannot commit (they don't know if all others prepared) and cannot abort (perhaps the coordinator decided to commit). These participants hold their locks indefinitely, blocking other transactions that conflict with them.","variant":"error"},"type":"callout"},{"data":{"left":[{"data":{"items":["Guarantees atomicity across distributed nodes","Relatively simple to understand and implement","Works correctly despite network partitions","Widely supported by databases and transaction monitors","Optimal in terms of message complexity (4n messages)"],"title":{"icon":"CheckCircle","text":"Strengths of 2PC","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Blocking protocol—participants can be stuck indefinitely","Coordinator is a single point of failure","Performance impact from synchronous logging","Locks held during entire commit process","Latency depends on slowest participant"],"title":{"icon":"XCircle","text":"Limitations of 2PC","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"}],"titleType":"number","titleNumber":8},{"id":"summary","title":"Summary: Two-Phase Commit Foundations","content":[{"data":{"content":"We've established the foundational understanding of the Two-Phase Commit protocol, the canonical solution for distributed transaction atomicity. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Phase 1 (Prepare)**: The coordinator gathers votes from all participants. Each participant either promises to commit (VOTE_COMMIT) or aborts (VOTE_ABORT).","**Phase 2 (Commit)**: Based on unanimous consent, the coordinator instructs all participants to either COMMIT or ABORT together.","**Prepare State**: Once a participant votes COMMIT, it enters the PREPARED state—a binding promise to follow the coordinator's decision.","**Write-Ahead Logging**: All state transitions must be logged to stable storage before the corresponding message is sent, ensuring crash recovery.","**Atomicity Guarantee**: 2PC ensures that all participants either commit or abort together—never a mix.","**The Blocking Problem**: 2PC can block if the coordinator fails while participants are prepared—a fundamental limitation addressed by 3PC."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nThe next page examines the **Coordinator Role** in depth—how the coordinator manages the protocol, tracks participant states, handles timeouts, and ensures reliable recovery. Understanding the coordinator's responsibilities is essential for implementing robust distributed transactions."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the Two-Phase Commit protocol—its motivation, mechanics, and properties. Next, we'll dive deep into the coordinator's responsibilities and see how it orchestrates the entire distributed transaction process.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":9}],"isLocked":false},{"id":"seed_50b3f0feced050279962964a1026fce1","title":"Coordinator Role","order":1,"content":null,"isLocked":true},{"id":"seed_b32aad891e64cfcff1828bdac04cedc4","title":"Participant Role","order":2,"content":null,"isLocked":true},{"id":"seed_1c10575fc5827550a68ec2d84c774501","title":"Failure Handling","order":3,"content":null,"isLocked":true},{"id":"seed_0717953f16ff65d1c62c58d638d67658","title":"Three-Phase Commit (3PC) Overview","order":4,"content":null,"isLocked":true}]}}