Two Phase Commit Protocol

1. The two phase commit protocol is a distributed algorithm which lets all
sites in a distributed system agree to commit a transaction
The phase results in either all nodes committing the transaction
or aborting, even in the case of site failures and message losses
2 Phase Commit Protocol

2. 2 Phase Commit Protocol
Assumptions
One node is designated the coordinator, which is the master site, and the rest of the nodes in
the network are called cohorts
Stable storage at each site and use of a write ahead log by each
node
The protocol assumes that no node crashes forever

3. 2 Phase Commit Protocol
During phase 1
Initially the coordinator sends a query to commit message to all cohorts. Then it waits for all
cohorts to report back with the agreement message.
Then the cohorts reply with an agree message, or an abort if the transaction failed at a cohort
node

4. 2 Phase Commit Protocol
If the coordinator receives an agree message from all cohorts, then it writes a commit record into
its log and sends a commit message to all the cohorts
If all agreement messages do not come back the coordinator sends an abort
message
Next the coordinator waits for the acknowledgement from the cohorts. When acks are received
from all cohorts the coordinator writes a complete record to its log
During phase 2

5. Disadvantage
The greatest disadvantage of the two phase commit protocol is the fact that it is a blocking
protocol
A node will block while it is waiting for a message. This means that other processes competing for
resource locks held by the blocked
Another disadvantage is the protocol is conservative

6. At Coordinator
1. The COORDINATOR sends the message to each COHORT. The COORDINATOR is now in the
preparing transaction state.
2. Now the COORDINATOR waits for responses from each of the COHORTS. If any COHORT
responds ABORT then the transaction must be aborted, proceed to step 5. If all COHORTS respond
AGREED then the transaction may be commited, and proceed to step 3. If after some time period all
COHORTS do not respond the COORDINATOR can either transmit ABORT messages to all
COHORTS or transmit COMMIT-REQUEST messages to the COHORTS that have not responded.
In either case the COORDINATOR will eventually go to state 3 or state 5.

7. 3. Record in the logs a COMPLETE to indication the transaction is now completing. Send COMMIT
message to each of the COHORTS.
4. Wait for each COHORT to respond. They must reply COMMIT. If after some time period some
COHORT has not responded retransmit the COMMIT message. Once all COHORTS have
replied erase all associated information from permanent memory (COHORT list, etc. ). DONE.
5. Send the ABORT message to each COHORT.
At Coordinator

8. At Cohorts
1. If a COMMIT-REQUEST message is received for some transaction t which is unknown at the
COHORT ( never ran, wiped out by crash, etc ), reply ABORT. Otherwise write the new state of the
transaction to the UNDO and REDO log in permanent memory. This allows for the old state to be
recovered ( in event of later abort ) or committed on demand regardless of crashes. The read locks
of a transaction may be released at this time; however, the write locks are still maintained. Now
send AGREED to the COORDINATOR.
2. If an ABORT message is received then kill the transaction, which involves deleting the new state if
the transaction from the REDO and UNDO log the new state of the transaction and restoring any
state before the transaction occured.

9. 3. If a COMMIT message is received then the transaction is either prepared for commital or already
committed. If it is prepared, perform all the operations necessary to update the database and
release the remaining locks the transaction possesses. If it is already commited, no further action
is required. Respond COMMITED to the COORDINATOR.
At Cohorts