As discussed, let's assume that there is one proposing process (P0) and a bunch of other [P1...PN] processes (let's call them executors) that need to perform the value update. In the Two-Phase Commit protocol, the proposing process (P0) coordinates the consensus in two phases:

• Prepare phase: P0 sends a message, Prepare Update V = x, to the other executor processes [P1...PN]. Each executor process either votes PREPARED or NO, and if PREPARED possibly locally stages the change. A process can say NO if, for example, there is another concurrent transaction.
• Commit phase: Once all responses have been received, P0 sends either a COMMIT or ABORT message. Each of the executor processes obey this command and thus complete the transaction.

To enable easy handling of things such as restarts, each Process records its current state in durable storage before sending a message. For example, once all executors reply with PREPARED, P0 can record that it's in the Commit phase.

This algorithm is susceptible to failures in the Commit phase:

• P0 may crash after the Prepare phase. Here, all the other Executors are blocked on P0, and until P0 is up and current, the system comes to a halt in terms of consensus. P0 did know whether the crashed node wanted to go ahead or abort the transaction.
• If an executor process crashes in Phase 2, P0 does not know whether the process failed before or after committing.

To summarize, the biggest disadvantages of the two-phase commit is the blocking we just described. If one of the processes dies at a critical stage, things come to a grinding halt.