Three-Phase Commit (3PC)

The Problem with Two Phases

If you've read about the Two-Phase Commit (2PC) protocol, you know its fatal flaw. If the Coordinator crashes right after all participants vote "Yes," the participants are left holding locks indefinitely. They are stuck in a blocking state, freezing your database until the Coordinator comes back online.

Computer scientists looked at this problem and asked, "How can we make this non-blocking?" The answer was the Three-Phase Commit (3PC) protocol.

It adds an extra phase specifically to ensure that if the Coordinator dies, the participants can talk to each other and safely figure out what to do next without getting stuck.

The Core Concept: The "Pre-Commit"

Think of the wedding analogy from 2PC. The priest asks if everyone is ready, they say yes, and then the priest faints. Everyone is left hanging.

3PC adds a step. After everyone says "Yes, I'm ready," the priest says, "Okay, everyone, I'm about to pronounce you married. If I faint right now, just assume you're married and go to the reception."

This new step is called the Pre-Commit phase.

Phase 1: Can Commit? (The Proposal)

The Coordinator asks all participants: "Can you commit this transaction?" Participants check their locks and reply Yes or No. (This is identical to Phase 1 of 2PC).

Phase 2: Pre-Commit (The Warning)

If everyone said Yes, the Coordinator sends a "Pre-Commit" message.

• This message means: "Everyone agreed. We are going to commit this. Prepare yourselves."
• The participants acknowledge this message.
• The magic trick: If a participant receives a Pre-Commit message, it knows for a fact that no one voted to abort.

Phase 3: Do Commit (The Final Execution)

The Coordinator sends the final "Do Commit" message. The participants execute the write and release the locks.

How 3PC Solves the Coordinator Crash

Let's say the Coordinator crashes during Phase 3. The participants are waiting for the final "Do Commit" message, but it never arrives. Their timeout expires.

In 2PC, they would freeze. In 3PC, they talk to each other. They say, "Did anyone get a Pre-Commit message?"

• If the answer is Yes, they know the original vote was unanimous. They can safely go ahead and commit the transaction themselves.
• If the answer is No (meaning the Coordinator crashed during Phase 1 before sending Pre-Commit), they safely abort the transaction.

No more indefinite blocking!

Why Don't We Use 3PC?

You might be thinking, "Wow, 3PC fixes the biggest problem with distributed databases! Why doesn't everyone use it?"

Here's the cruel irony of distributed systems: 3PC only works if the network is perfectly reliable. It assumes nodes only crash. It completely falls apart during Network Partitions (when nodes are alive but can't talk to each other).

If a network splits, and half the nodes got the Pre-Commit message while the other half didn't, the two halves might make different decisions. One half commits, the other half aborts, and now your database is corrupted.

Because networks do fail, and partitions do happen (the 'P' in the CAP Theorem), 3PC is considered mathematically flawed for real-world networks.

Summary

• Three-Phase Commit (3PC) is an extension of 2PC designed to eliminate the blocking problem when a Coordinator crashes.
• It introduces a Pre-Commit phase, ensuring participants know the result of the vote before the final commit happens.
• While it solves the crash-blocking problem, it fails catastrophically during network partitions, leading to split-brain data corruption.
• Because of this flaw, 3PC is almost never used in practice. It remains primarily an academic concept, while the industry moved on to consensus algorithms like Paxos/Raft and asynchronous patterns like Saga.