Algorithms for Two-Phase Commit (2PC) Protocol in Distributed Environment

The Two-Phase Commit (2PC) protocol is a distributed transaction commit protocol used to ensure that all participating database sites either commit or abort a transaction together. It is mainly used when a transaction accesses data from multiple sites in a distributed database system.

The protocol involves two types of processes: the Coordinator and the Participants. The coordinator controls the commit decision, while participants execute their local part of the transaction and respond to the coordinator.

Figure 1: Two-Phase Commit Protocol in a distributed environment.

Phases of 2PC Protocol

The 2PC protocol has two major phases:

• Phase 1: Voting Phase / Prepare Phase
• Phase 2: Decision Phase / Commit-Abort Phase

In the first phase, the coordinator asks all participants whether they are ready to commit. In the second phase, the coordinator makes the final decision based on the votes received.

Coordinator Algorithm

Algorithm: Two-Phase Commit Protocol at Coordinator

Input:
    T = Distributed transaction
    P = Set of participating sites {P1, P2, ..., Pn}

Begin

1. Start transaction T.

2. Send PREPARE message to all participants Pi.

3. Wait for votes from all participants.

4. If VOTE-COMMIT is received from every participant before timeout, then
       Write GLOBAL-COMMIT record in coordinator log.
       Send GLOBAL-COMMIT message to all participants.
   Else
       Write GLOBAL-ABORT record in coordinator log.
       Send GLOBAL-ABORT message to all participants.

5. Wait for ACK messages from all participants.

6. After receiving ACK from all participants,
       Write END record in coordinator log.

7. Terminate the protocol.

End

The coordinator first sends a PREPARE message to all participating sites. If all participants reply with VOTE-COMMIT, the coordinator decides to commit the transaction. If even one participant replies with VOTE-ABORT, or if any participant fails to reply within the timeout period, the coordinator decides to abort the transaction.

Participant Algorithm

Algorithm: Two-Phase Commit Protocol at Participant

Input:
    T = Distributed transaction received from coordinator

Begin

1. Wait for PREPARE message from coordinator.

2. After receiving PREPARE message,
       Check whether local transaction T can be committed.

3. If local transaction can be committed, then
       Write READY record in local log.
       Send VOTE-COMMIT message to coordinator.
       Enter waiting state.
   Else
       Write ABORT record in local log.
       Send VOTE-ABORT message to coordinator.
       Abort local transaction.
       Terminate the protocol.

4. If GLOBAL-COMMIT message is received from coordinator, then
       Write COMMIT record in local log.
       Commit local transaction.
       Send ACK message to coordinator.

5. Else if GLOBAL-ABORT message is received from coordinator, then
       Write ABORT record in local log.
       Abort local transaction.
       Send ACK message to coordinator.

6. Terminate the protocol.

End

The participant executes its local part of the transaction and waits for the coordinator’s prepare request. If it is ready to commit, it records a READY state in its local log and sends a VOTE-COMMIT message. After voting commit, the participant cannot independently abort or commit; it must wait for the final decision from the coordinator.

Message Flow of 2PC Protocol

Coordinator                         Participants
     |                                    |
     | -------- PREPARE ----------------> |
     |                                    |
     | <------ VOTE-COMMIT / ABORT ------ |
     |                                    |
     | -------- GLOBAL-COMMIT/ABORT ----> |
     |                                    |
     | <-------------- ACK -------------- |
     |                                    |

The first message exchange belongs to the voting phase, and the second message exchange belongs to the decision phase. The transaction commits only if all participants vote to commit.

Important Log Records

Site	Log Record	Purpose
Coordinator	GLOBAL-COMMIT	Records final commit decision
Coordinator	GLOBAL-ABORT	Records final abort decision
Coordinator	END	Indicates completion of protocol
Participant	READY	Indicates participant is prepared to commit
Participant	COMMIT	Records local commit decision
Participant	ABORT	Records local abort decision

Failure Handling in 2PC

If a participant fails before sending its vote, the coordinator treats it as an abort and sends a global abort decision. If a participant fails after sending VOTE-COMMIT, it enters a blocked state after recovery and must contact the coordinator to know the final decision. This is why 2PC is called a blocking protocol.

If the coordinator fails after receiving all votes but before sending the final decision, participants that have already voted commit may remain blocked until the coordinator recovers. This is one of the major limitations of the 2PC protocol.

Conclusion

The Two-Phase Commit protocol ensures atomic commitment in distributed database systems. The coordinator collects votes from all participants and makes a global decision. Participants follow the coordinator’s decision to either commit or abort their local transactions. Although 2PC provides strong consistency and atomicity, it may suffer from blocking when failures occur, especially if the coordinator crashes during the decision phase.

---

Happy Exploring!