Questions: Three-Phase Commit Protocol

Question 1

In 2PC, all participants have voted 'yes' in the prepare phase and the coordinator then crashes before sending any commit or abort. A new coordinator takes over. What is the fundamental problem?

• A. The new coordinator must restart the entire transaction because participant votes expire after a timeout
• B. The new coordinator cannot determine whether to commit or abort safely — it doesn't know whether the original coordinator decided to commit or abort, and participants cannot distinguish these cases either
• C. The participants will automatically abort after a timeout, safely rolling back the transaction
• D. The new coordinator can safely commit because all participants already voted yes and no abort was sent

Answer: (B)

This is the blocking problem of 2PC. After voting yes, participants hold locks and wait. The new coordinator queries participants and finds them all in the 'prepared' state — but this is consistent with both a commit decision (coordinator crashed after deciding commit) and an abort decision (coordinator crashed before sending anything). The new coordinator cannot safely choose either. Option D is tempting but wrong: a participant could have received an abort before the crash, and committing would violate atomicity.

Question 2

Why does 3PC's non-blocking guarantee break down when the network can partition, even though it solves the coordinator-crash scenario?

• A. Network partitions prevent the preCommit acknowledgment from reaching the coordinator, stalling the protocol indefinitely
• B. Participants on one side of a partition may time out waiting for the coordinator and abort, while participants on the other side receive preCommit and eventually commit — violating atomicity
• C. The 3PC protocol uses UDP, which is unreliable, making partitions catastrophic in a way that TCP-based 2PC handles gracefully
• D. Network partitions corrupt the flow table in the coordinator's switch, causing it to route preCommit messages incorrectly

Answer: (B)

3PC's non-blocking property depends on participants being able to communicate with each other to determine the global state. A network partition isolates groups of participants. Those who received preCommit know everyone voted yes and will eventually commit. Those who didn't receive preCommit (because the partition occurred before it arrived) will time out and abort. Both groups are acting rationally given the 3PC rules — but the outcome violates atomicity. This failure mode doesn't exist in 2PC's original blocking scenario because 2PC doesn't allow participants to act autonomously.

Question 3

In 3PC, if a participant has received a preCommit message, it knows that all other participants voted 'yes' in the canCommit phase, which enables a new coordinator to safely issue doCommit.

• T. True
• F. False

Answer: True

This is the key informational property that preCommit creates. The coordinator only sends preCommit after receiving unanimous yes votes. So a participant in the preCommit state has a guarantee: the commit decision is safe because no participant voted no. If the coordinator crashes now, the new coordinator queries participants, sees they're all in preCommit state, and can safely issue doCommit. This shared knowledge — absent in 2PC — is what breaks the blocking deadlock.

Question 4

Three-phase commit was designed to improve transaction throughput over 2PC by reducing the total number of messages exchanged during the commit process.

• T. True
• F. False

Answer: False

3PC actually adds a phase and increases message overhead compared to 2PC — it requires more round trips, not fewer. Its purpose is to eliminate the indefinite blocking problem, not to improve throughput. In practice, 3PC is rarely used in production systems because its added complexity and message overhead are not worth the benefit when network partitions (which 3PC cannot handle anyway) are the more realistic failure mode. Systems instead use 2PC with careful logging, or avoid distributed transactions entirely.

Question 5

What specific knowledge does the preCommit phase give participants that allows 3PC to avoid the indefinite blocking problem of 2PC, and what failure assumption must hold for this to work?

Model answer: The preCommit phase gives every participant the knowledge that all other participants voted 'yes' — a fact no participant has in 2PC. In 2PC, a participant in the 'prepared' state cannot tell whether others also voted yes or whether some voted no. In 3PC, receiving preCommit is proof that the commit is globally safe. This allows any participant (or a new coordinator) to complete the commit autonomously without needing the original coordinator. The assumption that must hold is fail-stop: nodes either operate correctly or crash cleanly, and the network delivers messages reliably. If the network can partition, participants may diverge despite following the protocol correctly.

The blocking problem in 2PC arises from ambiguity — prepared participants cannot distinguish 'coordinator decided commit' from 'coordinator decided abort.' 3PC resolves this by creating an intermediate state (preCommit) that is only reachable if the commit is globally safe. Participants in preCommit can complete the transaction; participants not yet in preCommit can safely abort. The fail-stop assumption is critical: with partitions, this disambiguation breaks down.