DDBMS

2 phase commitment protocol

Two-phase commitment (2PC) protocol

Two phase commit (2PC) protocol is a very simple and elegant way to ensure the atomic
commitment of distributed transactions. It extends the effects of local atomic commit actions to
distributed transactions by insisting that all sites involved in the execution of a distributed
transaction agree to commit the transaction before its effects are made permanent.
Why is this protocol required?
The implementation of commit primitive is most difficult. The main difficulty arises from the
fact that the correct commitment of a distributed transaction requires that all its subtransactions
to commit locally even in the case of failure. So it is not acceptable that a subtransaction is
locally aborted because of a failure and the other subtransactions are correctly committed. In
order to implement commit primitive in a distributed environment a new idea has been
developed, called the 2 phase commitment protocol. As the name suggests, this protocol has
two phases first is to reach a common decision and prepare for commitment (prepare phase)
and second is to implement the decision i.e. to commit or to abort globally (commit phase).
Coordinator : Coordinator is an agent with special role.
Participant : All other agents which must take part in the commit protocol are called participants.

The basic 2 phase commitment protocol (assuming no failure)

Coordinator : Write prepare record in the log
Send PREPARE message and activate timeout
Participant

: Wait for prepare message;

If the participant is willing to commit then
Begin
Write substransactions records in the log
Write ready record in the log
Send READY answer message to coordinator
End
Else
Begin
Write abort record in the log
Send ABORT answer message to coordinator
End

Coordinator : Wait for ANSWER message (READY or ABORT) from all participant or timeout
If timeout expired or at least one answer message is ABORT then
Begin
Write global_abort record in the log
Send ABORT command message to all participants
End
Else // all the sites are READY
Begin
Write global_commit record in the log
Send COMMIT command message to all participants
End
Participant

: Wait for command message

Write abort or commit record in the log

Prepared by Somenath Sengupta for MCA 3rd Year

DDBMS

2 phase commitment protocol

Send the ACK message to coordinator
Execute command

Coordinator : Wait for ACK message from all participants

Write complete record in the log

Coordinator
1. Responsible for taking final decision of
commit or abort
2. If a transaction performs write operation
at the same site of the coordinator, then
the coordinator and a participant are there
at the same site and it is not mandatory
that they have to communicate directly.

Participant
1. Corresponds to subtransactions which
have performed some write operation at
the local database.
2. Each participant is at a different site.

Global commit rule

1. If even one participant votes to abort the transaction, the coordinator has to reach a global
abort decision.
2. If all the participants vote to commit the transaction, the coordinator has to reach a global
commit decision.
Centralized 2PC communication is only between the coordinator and the participants; the
participants do not communicate between each other.
Coordinator

Prepare

Participant

Coordinator

Vote-abort/
Vote-commit

Participant

global-commit/
global-abort

Coordinator

committed/
aborted

Centralized two-phase commit protocol

Prepared by Somenath Sengupta for MCA 3rd Year

DDBMS
Linear 2PC

2 phase commitment protocol

participants can communicate between each other. The sites are assumed to be
ordered for the purpose of communication.

The following abbreviations are used in the next diagram:

VC/VA Vote-commit/Vote-abort
C Coordinator
GC/GA Global-commit/Global-abort
P Participant
Prepare

Phase 1
1(C)
Phase 2

VC/VA
2(P)

GC/GA

VC/VA
3(P)

GC/GA

VC/VA
4(P)

GC/GA

5(P)
GC/GA

Linear two-phase commit protocol

Note: Linear two-phase commit protocol is also called Nested two-phase commit protocol.
This protocol may need fewer messages but does not provide any parallelism. So, it suffers from
low response-time performance. It is suitable for networks without having broadcasting
capability.
Distributed 2PC involves communication among all the participants during the first phase of
the protocol so that they all independently reach their termination decision
with respect to the specific transaction. Because of the nature of
communication, the second phase of 2PC is not required at all.
Coordinator

Participants

Coordinator
+ Participants
C

Prepare

VA/VC

GA/GC decision made

Independently

Basic differences between centralized 2PC and linear 2 PC + distributed 2PC are as follows:

Prepared by Somenath Sengupta for MCA 3rd Year

DDBMS

2 phase commitment protocol

A participant has to know the identity of the neighboring participant (linear 2PC) or all other
participants (distributed 2PC) taking part in the transaction. A list of participants is attached
with the prepare message to solve this problem. This is not required in case of centralized 2PC.
Variations of 2PC are proposed to improve its performance. This is achieved by two ways:
1. Reducing the number of messages that are transmitted between the coordinator and the
participants and
2. Reducing the number of times the logs are written.
Two protocols are suggested for performance improvement:
Presumed Abort 2PC Protocol In this variation of 2PC protocol the following assumption is
made: Whenever a prepared participant pools the coordinator about a transactions outcome and
there is no information in virtual storage about it, the response to the inquiry is to about the
transaction. Since it saves some message transmission between the coordinator and the
participants in case of aborted transactions, presumed abort two-phase protocol is expected to be
more efficient.
Presumed Commit 2PC Protocol The coordinator, prior to sending the prepare message,
force-writes a collecting record, which contains the names of all the participants involved in the
execution of that transaction. The participant then enters in the COLLECTING state. It then
sends the prepare message and enters the WAIT state. After receiving the prepare message, the
participants decide what to do with the transaction write an abort record or write a ready record
and respond with either vote-abort or vote-commit message. When the coordinator receives
decisions from all the participants, it decides to abort or commit transaction. If the decision is to
abort, coordinator writes an abort record, enter the ABORT state and sends global-abort
message. If the decision is to commit, it writes a commit record, sends a global-commit
message and forgets the transaction. When the participants receive a global-commit message,
they write a commit record and update the database. If they receive a global-abort message,
they write an abort record and acknowledge. The participant, upon receiving the abort
acknowledgement, writes an end record and forgets about the transaction.
Comparison between presumed abort and presumed commit protocol The presumed
commit protocol is more efficient than presumed abort protocol with participants which
perform update transaction successfully, since it does not require acknowledgements and
forcing of commit records. On the other hand, the presumed abort protocol shows efficiency
with participants which performs read-only transactions successfully, because the additional
record with the participant information need not be forced in the log of the coordinator.

The two-phase commitment protocol is flexible enough to handle problems like site failure and
network partitioning. Let us examine how 2PC works in such situations.
2PC is resilient to all failure in which no log information is lost. Some of the most common types
of failures and the way 2PC handle the failures are discussed below in brief:

Prepared by Somenath Sengupta for MCA 3rd Year

DDBMS

2 phase commitment protocol

Site failure
When site Si recovers, it examines its log to determine the fate of
transactions active at the time of the failure.

Log contain <commit T> record: site executes redo (T)

Log contains <abort T> record: site executes undo (T)

Log contains <ready T> record: site must consult Ci to determine the fate of T.
If T committed, redo (T)
If T aborted, undo (T)

The log contains no control records concerning T replies that Sk failed before
responding to the prepare T message from Ci
since the failure of Sk precludes the sending of such a
response C1 must abort T
Sk must execute undo (T)

Coordinator Failure

If coordinator fails while the commit protocol for T is executing then participating sites
must decide on Ts fate:
1. If an active site contains a <commit T> record in its log, then T must be
committed.
2. If an active site contains an <abort T> record in its log, then T must be aborted.
3. If some active participating site does not contain a <ready T> record in its log,
then the failed coordinator Ci cannot have decided to commit T. Can therefore
abort T.
4. If none of the above cases holds, then all active sites must have a <ready T>
record in their logs, but no additional control records (such as <abort T> of
<commit T>). In this case active sites must wait for Ci to recover, to find
decision.
Blocking problem: active sites may have to wait for failed coordinator to recover.

Network partitions

If the coordinator and all its participants remain in one partition, the failure has no effect
on the commit protocol.
If the coordinator and its participants belong to several partitions:
Sites that are not in the partition containing the coordinator think the coordinator
has failed, and execute the protocol to deal with failure of the coordinator.
4 No harm results, but sites may still have to wait for decision from
coordinator.
The coordinator and the sites are in the same partition as the coordinator think that the
sites in the other partition have failed, and follow the usual commit protocol.
4 Again, no harm results

Prepared by Somenath Sengupta for MCA 3rd Year