1. Distributed Commit Phases

2. Two-Phased Commit
Don't confuse this with Two Phased Locking, they are entirely separate concepts dealing with different problems. (Don't blame me, I didn't name them)
If you need to make a commit to a distributed database, you need to ensure consistency.
You need to ensure that all sites agree on the state of the database.
One way to make this happen is to break the commit action into two phases with the Primary Copy / Coordinator managing communications
Phase 1 - Asking all relevant sites (cohort) to make sure they can perform their part of the commit
Phase 2 - Telling the cohort to make the commit happen
Problems can occur in each of the phases, leading to the necessity of recovery (undoing/redoing until you reach a consistent state).

3. Commit Request Phase (Phase 1)
The cohort (sites involved in the commit) is informed (by the coordinator) of what changes need to be made to their own data. The coordinator does this with a "prepare for commit" message.
The cohort then makes their local changes, and returns the message "OK". If they can't perform their work, they either don't send a message or send an error message.

4. Commit Phase (Phase 2)
If the coordinator receives "OK" messages from the cohort (and the coordinator is also "OK"), then the coordinator sends out a "commit" message. If not all sites have given an "OK" message in some time window, the coordinator sends out a "rollback" message.
If a site receives a "do commit" message, it commits the local changes. If a site receives a "rollback" message, it rollback the local changes.

5. What can break the two-phased commit protocol?
1. A site can't make the local changes
2. A site can't communicate with the coordinator
3. A coordinator fails mid-commit
4. The protocol is perfect in every way

6. Problems with Two-Phased Commits
Two-Phased Commits is a blocking protocol.
After a site has replied with whether it can commit or not, it has to wait (block) for the coordinator to respond.
If the coordinator fails, all the other sites must wait while the coordinator recovers.
This can cause a huge degradation in performance.

7. Three-Phased Commit
To combat the blocking nature of Two-Phased Commit, the Three-Phased Commit was invented.
Phases:
Coordinator sends a "can commit?" message asking the cohort if they could perform the commit. If not all sites in the cohort respond with "OK", coordinator aborts.
Coordinator sends a "prepare to commit" message. The cohort responds with "ACK (acknowledgment)". If a "prepare to commit" message isn't received by the cohort, they abort.
If the coordinator, doesn't receive "ACK" messages from the entire cohort, it aborts. Otherwise, the coordinator sends a "do commit" message. If the cohort receives that message, it commits. If the coordinator fails to respond for a period of time, the cohort commits anyway.

8. Pros and Cons of Three Phase Commits
If the coordinator fails after the cohort has signaled that it can perform the commit, they commit regardless. Hence no blocking needed.
Con
This mode of communication requires 3 roundtrip messages, which can cause a large degree of latency.