In modern software engineering, distributed database systems and microservices need a way to ensure data consistency across multiple servers. If a user makes a transaction, it must either succeed everywhere or fail everywhere. This is where commit protocols come into play.
While the Two-Phase Commit (2PC) protocol is widely known, it suffers from a major flaw: blocking. If the coordinator node crashes, the participating nodes can get stuck indefinitely waiting for instructions.
To solve this, the Three-Phase Commit (3PC) Protocol introduces an extra step to remove this blocking vulnerability. Here is how it works.
The Three Phases of 3PC
The protocol is divided into three distinct steps managed by a central "Coordinator" communicating with multiple "Cohorts" (participants).
1. Phase One: CanCommit (Voting Phase)
The Coordinator sends a CanCommit query to all cohorts asking if they are ready to process a transaction.
If a cohort is ready, it replies with a
Yesvote.If it is not ready, it replies with a
Novote, and the Coordinator immediately aborts the transaction.
2. Phase Two: PreCommit (Preparation Phase)
If the Coordinator receives a Yes from all cohorts, it sends a PreCommit message.
This is the crucial step that 2PC is missing.
The cohorts acknowledge this message and prepare to commit, but they do not commit yet. By acknowledging this, the cohorts agree that they know the transaction is about to happen. If the Coordinator crashes right after this, a new Coordinator can take over, ask the cohorts what state they are in, and safely proceed.
3. Phase Three: DoCommit (Execution Phase)
Once the Coordinator receives acknowledgments for the PreCommit from all cohorts, it sends the final DoCommit message.
The cohorts officially commit the transaction to their databases.
They release any locked resources and send a final confirmation back to the Coordinator.
3PC vs. 2PC: Is it worth it?
While 3PC successfully solves the blocking problem of 2PC by using timeouts and the intermediate PreCommit state, it introduces significant network overhead. Because it requires three full round-trips of network communication, it is often considered too slow for highly responsive, low-latency applications.
Today, many modern distributed systems (like those built with Spring Boot microservices) prefer eventual consistency models, the Saga pattern, or consensus algorithms like Raft and Paxos over strict 3PC.
Keep Reading!
PreCommit state, it introduces significant network overhead. Because it requires three full round-trips of network communication, it is often considered too slow for highly responsive, low-latency applications.Today, many modern distributed systems (like those built with Spring Boot microservices) prefer eventual consistency models, the Saga pattern, or consensus algorithms like Raft and Paxos over strict 3PC.