Atomic Commit in Distributed System

In this tutorial you are going to learn about Atomic Commit in Distributed System.

Atomic Commit Protocol

Atomic commit protocol (ACP) is a protocol used by database managers to ensure that all the sub-transactions are consistently committed as aborted.

In this each server applies local consistency control to its own objects which ensure that transactions are initialised locally as well as serialized globally.

When a distributed transaction comes to an end, either all the servers commit the transaction or abort the transaction.

• In the problem of atomic commit, sites of distributed systems must agree whether the transaction should be committed or aborted.
• In the first phase of the atomic commit, sites execute their part of the distributed transaction and broadcast their decision (commit or abort) to all other sites.
• In the second phase, each site based on what it received from others sites in the first phase, decides whether to commit or to abort its part of the distributed systems.
• If every site receives an identical response from all other sites they will reach the same decision.
• If some sites behave maliciously, they can send a conflicting response to other sites, causing them to make conflicting decisions.
• In these situations, we can use algorithms for the byzantine agreement to ensure that all non-faulty processes have a common decision about distributed transactions.

Atomic Commit operates as:

1. All the processes in a system execute an algorithm to collect values of the clock that satisfies the given conditions as C1, C2.
2. In the first phase, after the site has made the decision, it starts the byzantine agreement.
3. In the second phase, processors determine a common decision based on the agreed vector of values.
4. One coordinator responsible for initiating protocol.
5. All other entities called participants.
6. If the coordinator or participants are unable to commit, all parts transactions are aborted.

There are two phase commit protocols in distributed database systems. They are:

• Phase 1: In the first phase of commit protocol the coordinator asks all the participants if they are prepared to commit. The coordinator sends a “can” commit? to all the other participants that are in the transaction.
• Phase 2: In the second phase, it tells them to commit or abort the transaction to implement all the decision at all sites.
  1. If the participants crash after voting to commit, it can ask the coordinator about results of the vote.
  2. Time outs are used when message are expected
  3. Introduces a new state in transaction to commit.

Operations for two phase commit protocol:

• Cancommit?(trans)-> Yes/no

Call from the coordinator to the participant to ask whether it can commit a transaction. The participant replies with its value.

• doCommit(trans)

Call from the coordinator to the participant to tell the participant to commit its part of a transaction.

• doApart(trans)

Call from the coordinator to the participant to tell the participant to abort its part of a transaction.

• haveCommitted(trans,participate)

Call from the participant to coordinator to confirm that it has committed the transaction.

• getDecision(trans)

Call from the participant to coordinator to ask for the decision on the transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages.

---

This article on Atomic Commit in Distributed System is contributed by Hemalatha P. If you like TheCode11 and would like to contribute, you can also write your article and mail to thecode11info@gmail.com