The 3PC protocol is designed as a non-blocking protocol. In this context, it is necessary to mention that 2PC protocol is not a non-blocking protocol, as in certain circumstances it is possible for sites to become blocked. The coordinator can be blocked in the wait state, whereas the participants can be blocked in the ready state. The requirements for the 3PC protocol are as follows:

i. Network partition should not occur.

ii. All sites should not fail simultaneously, that is, at least one site must be available always.

iii. At the most k sites can fail simultaneously, where k is less than total number of sites in the distributed system.

In 3PC, a new phase is introduced, known as pre-commit phase, in between the voting phase and the global decision phase, for eliminating the uncertainly period for participants that voted commit and are waiting for the global decision from the coordinator. In 3PC, if all participants vote for commit, the coordinator sends a “global pre-commit” message to all participants. A participant who has received a “pre-commit” message to the coordinator will definitely commit by itself, if it has not failed. Each participant’s acknowledgements the coordinator sends a “global commit” message to all participants.

Termination protocols for 3PC

Like in 2PC, the termination protocol is used in 3PC to handle timeouts.

Coordinator In 3PC, the coordinator may timeout in four different states: wait, precommit, abort and commit. Timeouts during the abort and the commit states are handled in the same manner as in 2PC, therefore, only three cases are considered here.

i. Timeout in the wait state - The action taken here is identical to that in the coordinator timeout in the wait state for the 2PC protocol. In this state, the coordinator can decide to globally abort the transaction. Therefore, the coordinator writes an "abort" record in the log and sends a "global_abort" message to all participants.

ii. Timeout in the precommit state - In this case, the coordinator does not know whether the non-responding participants have already moved to the precommit state or not, but the coordinator can decide to commit the transaction globally as all participants have voted to commit. Hence, the coordinator sends a "prepare-to-commit" message to all participants to move them into the commit state, and then globally commits the transaction by writing a commit record in the log and sending "global_commit" message to all participants.

iii. Timeout in the commit or abort state - In this state, the coordinator is waiting for all par-ticipants to acknowledge whether they have successfully committed or aborted and timeout occurs. Hence, the participants are at least in the precommit state and can invoke the termina-tion protocol as listed in case (ii) and case (iii) in the following section. Therefore, the coordina-tor is not required to take any special action in this case.

Participant

A participant may timeout in three different states; initial, ready and precommit.

i. Timeout in the initial state- In this case, the action taken is identical to that in the termination protocol of 2PC.

ii. Timeout in the ready state- in this state, the participant has voted to commit and is waiting for the global decision from the coordinator. As the communication with the coordinator is lost, the termination protocol continues by electing a new coordinator.