Two Phase Commit Protocol (Distributed Transaction Management)

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 T_n at the n^th store and a store S₀ corresponds to T₀ where the manager is located. The following sequence of activities are performed by T are below:

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

b) T₀ sends messages to all the stores to order them to create components T_i.

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

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(S_n) 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 T_n may crash, and the instructions from T₀ are never received by T_n 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 S₁, S₂, S₃, ….S_n. Where every S_i made to maintains a separate log record of all corresponding activities and the transition T has also been divided into the subtransactions T₁, T₂, T₃, …., T_n and each T_i are assigned to S_i. This all maintains by a separate transaction manager at each S_i. 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(C_i), 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(C_i) 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:

Phase-1st– 

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

b) Then, the coordinator(C_i) 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 C_i.

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 C_i. Once the ready T message at C_i is sent nothing can prevent it to commit its portion of transaction T except Coordinator(C_i).

Messaging in Phase- 1st

Phase- 2nd–

The Second phase started as the response abort T or commit T receives by the coordinator(C_i) 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

Disadvantages:

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(T_i). This problem is known as Blocking Problem.