In a two-phase commit protocol, participant P has voted 'yes' in the prepare phase. Before P receives the coordinator's commit or abort decision, the coordinator crashes. What must P do?
AImmediately abort the transaction to release its locks and become available again
BImmediately commit the transaction, since it already voted yes and promised it could commit
CBlock indefinitely — hold its locks and wait for the coordinator to recover before taking any action
DContact other participants to take a vote on whether to commit or abort
A 'yes' vote is a binding promise: P has guaranteed it can commit if asked. It cannot abort unilaterally because the coordinator might have sent 'commit' to other participants before crashing — aborting would violate atomicity if others committed. It cannot commit unilaterally because the coordinator might have decided to abort (perhaps another participant voted no). Contacting other participants does not help if they are also in the uncertain state. P must block and wait — this is the fundamental weakness of 2PC.
Question 2 Multiple Choice
The coordinator in a two-phase commit logs the commit decision and begins sending commit messages. It successfully notifies two of three participants before crashing. When the coordinator recovers, what does it do?
ARestart the entire transaction from the prepare phase because the commit was not fully delivered
BSend abort messages to all participants to ensure a clean state
CRe-send commit messages to complete the delivery, since the logged commit decision is authoritative
DAsk participants to vote again to determine the correct outcome
The coordinator's log entry is the single point of truth. Once a commit record exists in the log, the transaction is committed — period. Recovery simply means re-delivering the decision to participants who haven't yet received it. This is why logging before sending is critical: the log establishes the outcome before any participant learns of it, so recovery can always reconstruct the correct decision.
Question 3 True / False
Two-phase commit guarantees that a distributed transaction will complete within a bounded time, even if the coordinator crashes partway through.
TTrue
FFalse
Answer: False
This is 2PC's fundamental limitation. If the coordinator crashes after participants have voted yes but before sending the commit or abort decision, those participants are in an uncertain state: they've promised to commit but don't know the outcome. They must hold their locks and block until the coordinator recovers — an indefinite wait. This blocking behavior is why 2PC is called a blocking protocol and why it is unsuitable for long-running transactions or high-availability requirements.
Question 4 True / False
A participant that votes 'yes' in the prepare phase of 2PC is not permitted to unilaterally abort the transaction, even if it has been waiting for the coordinator's decision for an extended period.
TTrue
FFalse
Answer: True
This constraint is essential for atomicity. A 'yes' vote is a durable commitment: the participant has logged that it can commit and promised to honor the coordinator's decision. If it were allowed to unilaterally abort after a timeout, and the coordinator had already decided to commit and notified some other participants, the transaction would be partially committed — violating atomicity. The blocking behavior is the price of this atomicity guarantee.
Question 5 Short Answer
Explain the fundamental tradeoff that 2PC makes between atomicity and availability. What specific failure scenario exposes this tradeoff, and why can't the remaining participants resolve it on their own?
Think about your answer, then reveal below.
Model answer: 2PC guarantees atomicity (all participants commit or all abort) by requiring unanimous agreement before committing, and by making 'yes' votes irrevocable. The cost is availability: if the coordinator crashes after participants have voted yes but before sending the decision, participants are blocked — they cannot commit (maybe another participant voted no) or abort (they promised to commit if asked). They cannot resolve it by consulting each other because no participant knows whether others voted yes or no, and even if all voted yes, no one knows whether the coordinator logged a commit or abort decision before crashing. The only safe option is to wait for the coordinator to recover and reveal its decision.
The key insight is that the blocking arises specifically because 2PC places the decision authority in a single coordinator and makes participant votes binding. The coordinator is the only entity that knows the complete vote tally and the final decision. In the absence of the coordinator, participants have incomplete information and must choose between violating atomicity (aborting when the coordinator might have committed) or blocking. There is no third option that preserves atomicity without availability loss.