Understanding of two-phase submissions and three-phase submissions

Two phase submission and three-phase submission understanding

This paper mainly through the carding process to explain the shortcomings of 2PC, and summarize the advantages of 3PC.

One, 2PC process and deadly problem

As shown in the figure, the 2PC process is brief:
1. The coordinator participant is in Init state and the participant waits for the message.
2. The coordinator enters the prepare state to send the vote_request message.
3. Coordinator waits for Message
4. The participant receives the message, enters the ready state and sends the VOTE_COMMIT
5. Participants wait for messages
6. The coordinator receives all messages, changes from prepare to commit send Global_commit (or send abort). Coordinator complete
7. Participants receive a message to perform a commit.
The participant has two states: a commit state or an abort state.

Wait is a problem-prone place: Once the timeout is handled.
Wait 1 (init status Wait): Participant abort the transaction himself
Wait 2 (Prepare status Wait): Coordinator can multicast abort command abort
Wait 3 (Ready state waits): When the participant is in the ready state difficulty. The reason for the timeout may be three points
1. The collaborator crashes without issuing global_commit.
Workaround: Persist the collaborator state. It will get the current state after the reboot, if the prepare phase, the direct abort, if the commit phase sends a commit again.
2. The participants collapsed
Solution: can only be solved if the participants can communicate with each other.
3. Network packet loss
Solution: can only be solved if the participants can communicate with each other.

participant Mutual communication resolves timeout issues:
Participant p times out at some stage, checking the status of another participant q to determine its state.
Participant state must be persisted
Q in Commit, Abort, init State, then p only need to change the corresponding state on the line.
Q in the ready state, check the rest, if all in the ready state, you must block the waiting coordinator. Because it is possible that the coordinator is in a commit state crash, after the recovery will be executed, if the participants because of ready super-time termination, but the coordinator thinks that has been committed, it causes the two inconsistencies.

In summary, the fatal problem with 2PC: timeouts cause the process to block so that resources cannot be freed.

Second, 3PC How to solve the blocking problem

As shown, we know that all 2PC problems are in the ready phase, and 3pc has joined the precommit phase to solve the blocking problem when the ready phase is completed. We analyze how it is cleverly solved.
Wait Timeout status:
WAIT 3:ready Status Timeout, the participant can abort directly. Because the ready state times out, the other participants can only be the ready, Precommit, Abort state.
WAIT 4: Coordinator Precommit Status timeout (not yet sent Perpare_commit, participant is ready), abort directly. The reason is ditto.
WAIT 5: Participant precommit status timeout, direct commit. (problematic), both of these States represent the meaning of a possible commit.
In short, the Precommit state (pre-commit) gives both parties a credential that can be "backed up" before committing to a commit. Participant part ready, partial precommit can be directly abort without affecting eventual consistency. Participants are all precommit state, then commit can be done entirely.

There is still a problem:

If a participant is a percommit state, other participants must be in a ready percommit commit, which can commit in all three states.

However, if there are ready and percommit participants in the cluster, the participants are not able to make a decision without knowing the other participant status.

References: Distributed principles and generics