2PC

Distributed Transactions & Atomic Commit

Two-Phase Commit (2PC)

The Concept

• Distributed systems use Two-Phase Commit to ensure atomicity across multiple sites participating in a transaction.
• Coordinator: The site where the transaction originates; it controls the execution.
• Participants: The other sites that execute the transaction.

The Two Phases

1. Phase 1 (Voting): The coordinator gets participants ready to commit. It sends a "Vote?" request to all participants.
2. Phase 2 (Completion): Based on the votes, everybody either commits or aborts the transaction.

Global Commit Rules

• Abort: The coordinator aborts the transaction if at least one participant votes to abort.
• Commit: The coordinator commits if and only if all participants vote to commit.

Centralized 2PC Communication

Message Flow

• Request: A client sends a request to the coordinator.
• Voting: Coordinator sends "Vote?" to participants. Participants reply with "Commit" or "Abort".
• Decision: Coordinator broadcasts the final decision (Commit/Abort) to all participants.
• Acknowledgment: Participants send an "ack" back to the coordinator. The coordinator then acknowledges the client.

Logging and State Management (2PC State)

To handle failures, the protocol uses persistent logs at both the coordinator and participant sides:

• L1: Coordinator logs the transaction ID, participant list, and metadata.
• L2: Participants log the request and their local vote.
• L3: Coordinator logs the final global decision.
• L4: Participants commit the transaction to disk.
• L5: Coordinator cleans up the log after receiving all acknowledgments.
  • The cleanup at L5 signifies the formal end of the coordinator's responsibility for that specific transaction ID. It safely removes the "trail" of intermediate states because the "Global Commit" is now a permanent fact across the entire distributed system.

Failure Recovery

• Coordinator Role: Beyond coordinating commits, it must maintain a copy of the database and answer questions from participants about old transactions.
• Participant Inquiry: If a participant is uncertain about a transaction (e.g., after a crash), it can ask the coordinator for the decision.

2PC Failures and Error Handling

Overview of 2PC Failures

The Two-Phase Commit (2PC) protocol must be robust against failures at various points in the communication cycle between the Coordinator and Participants. Failures are handled through a combination of timeouts, log checks, and status queries.

Failure Scenarios and Solutions

The system identifies seven critical failure points (marked 1-7 in diagrams) and provides specific recovery logic for each:

Point	Failure Event	Specific Timing & State	Immediate Action / Outcome	Detailed Explanation & Solution
1	Coordinator Crash	Phase 1 Initiation: During the initial multicast of the "Vote?" request.	Abort.	Since the coordinator crashed before receiving any votes or logging a decision, the transaction cannot safely proceed. All participants eventually time out and abort.
2	Participant Crash	Pre-Voting: After receiving "Vote?" but before sending a reply.	Abort.	The coordinator cannot reach a unanimous decision without this vote. It waits for a timeout period and then issues a global Abort.
3	Participant Crash	Uncertain Phase: After sending a "Commit" vote but before receiving a decision.	Abort.	The coordinator cannot confirm the participant is alive to finalize the write. For safety, the coordinator forces a global Abort.
4	Participant Crash	Post-Decision: After receiving the global decision but before acknowledging.	Log Check & Query.	The Solution: Upon restart, the participant checks its local log (L2). If its vote was "Abort," it's safe. If its vote was "Commit," it is in an uncertain state and must ping (check with) the coordinator to learn the final outcome.
5	Coordinator Crash	Decision Delivery: While broadcasting the final Commit/Abort.	Timeout \(\rightarrow\) Ping/Pull.	The Solution: Participants who never received the message time out. They cannot decide on their own; they must repeatedly "ping" the coordinator or "pull" the status from the coordinator's L3 log once it recovers.
6	Coordinator Recovery	Post-Restart (Phase 1): Waking up after a crash that occurred before logging a decision.	Consult Log \(\rightarrow\) Abort.	On restart, the coordinator checks its disk. Finding no L3 (Decision) log entry, it realizes the transaction was incomplete and tells all inquiring participants to Abort.
7	Coordinator Recovery	Post-Restart (Phase 2): Waking up after crashing during the decision multicast.	Consult Log \(\rightarrow\) Answer Queries.	The coordinator finds the L3 "Commit" entry in its persistent log. It then answers queries from participants (from Point 4 or 5) to finish the synchronization.

Summary of Logic

• Points 1, 2, 3: Result in an Abort because the agreement is incomplete.
• Point 4 & 5: Require checking with the coordinator to see if the global decision was already reached.
• Point 6 & 7: Rely on the coordinator restarting and checking its logs to either abort or answer participant queries.

Clarifying Points 6 and 7 vs. Others

The confusion usually stems from the difference between active runtime failures and post-restart recovery.

• Points 1–5 are about "The Crash Event": These describe the immediate reaction of the remaining live nodes while one node is currently down.
  • Example: If a Participant crashes at Point 2, the Coordinator handles it by timing out and aborting.
• Points 6 and 7 are about "The Recovery Process": These describe what a node does after it wakes up from a crash.
  • In Point 6 (Phase 1 recovery): The Coordinator wakes up, looks at its disk, and sees it only got as far as "L1" (starting the transaction). Since there is no "L3" (Decision), it tells everyone "I crashed, so we are aborting".
  • In Point 7 (Phase 2 recovery): The Coordinator wakes up, looks at its disk, and sees an "L3" entry saying "Commit". It now knows the transaction was successful and can tell any waiting participants: "The decision was Commit, you can finish now".

Key Takeaway:

Points 1-5 determine the immediate fate of the transaction, while 6-7 determine how a node synchronizes back with the rest of the system using its persistent logs.

Points 6 and 7 represent the Coordinator's recovery process after it has already crashed and is now attempting to reboot. While points 1–5 describe what happens the moment a crash occurs, 6 and 7 describe the logic the Coordinator follows once it wakes up to determine the final state of the transaction.

Understanding Points 6 and 7 (Recovery)

When the Coordinator restarts, it immediately consults its persistent logs (L1–L5) to see how far the transaction progressed before the power went out.

• Point 6 (Recovery from Phase 1 crash): The Coordinator wakes up and sees it only logged L1 (the start of the transaction) but has no L3 (the decision). Because it doesn't know if everyone was ready, it must default to Abort.
• Point 7 (Recovery from Phase 2 crash): The Coordinator wakes up and finds an L3 entry in its log saying "Commit". It now knows the transaction was successful and can safely answer any "uncertain" Participants who are still waiting for instructions.

What "Permanent Failure" Means

A permanent failure occurs if the Coordinator (at point 6 or 7) or a Participant (at point 4) crashes and never reboots(e.g., the hardware is physically destroyed).

In the 2PC protocol, this leads to a critical problem called Blocking:

• The Problem: If the Coordinator is permanently gone, the Participants are stuck in an "uncertain" state. They have voted "Commit," but they cannot finalize the transaction because they don't know the global decision.
• The Constraint: Participants cannot simply decide to abort or commit on their own because that might break the atomicity rule (one node might commit while another aborts).
• The Result: The entire system "blocks"—the resources (like database rows) remain locked indefinitely, and no other transactions can use them until the failed node is manually recovered or replaced.

Key Recovery Mechanisms

• Persistent Logging: Both parties must log their state (L1-L5) to disk to ensure they can determine the transaction status after a reboot.
• Participant Inquiry: If a participant crashes and recovers at Point 4, it must verify the final outcome with the coordinator if its local vote was "commit".
• Handling Permanent Failure: If either the coordinator or a participant suffers a permanent failure at points 6 or 7, the remaining active nodes will block (wait indefinitely) because the global state cannot be safely determined.

The Locking Life Cycle

To prevent "lost updates" or inconsistent reads during a transaction, the system locks the relevant data regions.

• Ready State & Locking (Phase 1 of 2PC): During normal transaction execution, participants acquire locks on the data they read or write. When the coordinator sends a “Vote?” request, the participant checks whether it can commit. If it can, it writes its vote record to its log and sends a YES vote, thereby entering the READY state.
  • The participant must already hold all required locks when voting YES and must keep these locks until the final COMMIT or ABORT decision, ensuring the transaction can still be completed exactly as promised.
• The "Uncertain" Period: From the moment a participant writes its vote to the log (L2) until it receives the final decision, the resources remain locked.
• Unlocking (After L4): Participants only release the locks after they have successfully committed (or aborted) the data to the disk at step L4.