Skip to content
Related Articles

Related Articles

Two Phase Commit Protocol (Distributed Transaction Management)
  • Difficulty Level : Medium
  • Last Updated : 29 Dec, 2020

Consider we are given with a set of grocery stores where the head of all store wants to query about the available sanitizers inventory at all stores in order to move inventory store to store to make balance over the quantity of sanitizers inventory at all stores. The task is performed by a single transaction T that’s component Tn at the nth store and a store S0 corresponds to T0 where the manager is located. The following sequence of activities are performed by T are below:

a) Component of transaction( T ) T0 is created at the head-site(head-office).

b) T0 sends messages to all the stores to order them to create components Ti.

c) Every Ti executes a query at the store “i” to discover the quantity of available sanitizers inventory and reports this number to To.

d) Each store receives instruction and update the inventory level and made shipment to other stores where require.

But there are some problems that we may face during the execution of this process:

1) Atomicity property may be violated because any store(Sn) may be instructed twice to send the inventory that may leave the database in an inconsistent state. To ensure atomicity property Transaction T must either commit at all the sites, or it must abort at all sites. 

2) However, the system at store Tn may crash, and the instructions from T0 are never received by Tn because of any network issue and any other reason. So the question arises what will happen to the distributed transaction running whether it abort or commit? Whether it recover or not?

Two-Phase Commit Protocol: This protocol is designed with the core intent to resolve the above problems, Consider we have multiple distributed databases which are operated from different servers(sites) let’s say S1, S2, S3, ….Sn. Where every Si made to maintains a separate log record of all corresponding activities and the transition T has also been divided into the subtransactions T1, T2, T3, …., Tn and each Ti are assigned to Si. This all maintains by a separate transaction manager at each Si. We assigned anyone site as a Coordinator.  

Some points to be considered regarding this protocol:

a) In a two-phase commit, we assume that each site logs actions at that site, but there is no global log. 

b) The coordinator(Ci), plays a vital role in doing confirmation whether the distributed transaction would abort or commit.

c) In this protocol messages are made to send between the coordinator(Ci) and the other sites. As each message is sent, its logs are noted at each sending site, to aid in recovery should it be necessary.

The two phases of this protocol are as follow:


a) Firstly, the coordinator(Ci) places a log record <Prepare T> on the log record at its site.

b) Then, the coordinator(Ci) sends a Prepare T message to all the sites where the transaction(T) executed.

c) Transaction manager at each site on receiving this message Prepare T decides whether to commit or abort its component(portion) of T. The site can delay if the component has not yet completed its activity, but must eventually send a response.

d) If the site doesn’t want to commit, so it must write on log record <no T>, and local Transaction manager sends a message abort T to Ci.

e) If the site wants to commit, it must write on log record <ready T>, and local Transaction manager sends a message ready T to Ci. Once the ready T message at Ci is sent nothing can prevent it to commit its portion of transaction T except Coordinator(Ci).

Messaging in Phase- 1st

Phase- 2nd

The Second phase started as the response abort T or commit T receives by the coordinator(Ci) from all the sites that are collaboratively executing the transaction T. However, it is possible that some site fails to respond; it may be down, or it has been disconnected by the network.  In that case, after a suitable timeout period will be given, after that time it will treat the site as if it had sent abort T. The fate of the transaction depends upon the following points:

a)  If the coordinator receives ready T from all the participating sites of T, then it decides to commit T. Then, the coordinator writes on its site log record <Commit T>  and sends a message commit T to all the sites involved in T. 

b) If a site receives a commit T message, it commits the component of T at that site, and write it in log records <Commit T>.

c) If a site receives the message abort T, it aborts T and writes the log record <Abort T>.

d) However, if the coordinator has received abort T from one or more sites, it logs <Abort T> at its site and then sends abort T messages to all sites involved in transaction T.

Messaging in Phase- 2nd


a) The major disadvantage of the Two-phase commit protocol is faced when the Coordinator site failure may result in blocking, so a decision either to commit or abort Transaction(T) may have to be postponed until coordinator recovers.

b) Blocking Problem: Consider a scenario, if a Transaction(T) holds locks on data-items of active sites, but amid the execution, if the coordinator fails and the active sites keep no additional log-record except <readt T> like <abort> or <commit>. So, it becomes impossible to determine what decision has been made(whether to <commit> /<abort>). So, In that case, the final decision is delayed until the Coordinator is restored or fixed. In some cases, this may take a day or long hours to restore and during this time period, the locked data items remain inaccessible for other transactions(Ti). This problem is known as Blocking Problem.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

My Personal Notes arrow_drop_up
Recommended Articles
Page :