Distributed concurrency control

Concurrency control in DBMS ensures the parallel execution of transaction without interleaving the transaction. In DDBMS, we implement concurrency control assuming few points. The assumptions are stated as follows:

• Each site in DBMS participates in a transaction and commits the transaction from the respective sites.
• All the replicas present in DDBMS are updated

Generally, we execute the concurrent transaction by implementing locks that can be a read lock or write lock or a shared lock. One is single–lock manager approach and the other is distributed-lock manager approach.

Single-lock Manager Approach

Single – lock manager approach states that there should be one dedicated site in DDBMS that will manage all the locks, which are requested by the other sites in DBMS. To explain this approach. Let’s name the site where the lock manager resides as LS (1). Now, when a transaction is first raised by one site, the transaction manager of that particular site distributes the transaction in all the other site distributes the transaction in all the other remaining sites in the network. Then, when one partial transaction in one site needs to lock a data item Q. It sends a lock request to sites LS(0). The data item Q can be locked depending on the priority of the request. If the priority is low. Then the lock request can be delayed until the request can be granted. After granting the test, a message is sent back to the transaction initiator site. If the priority is high, then lock request is granted immediately and a message is sent back to the site back to the site that raised the transaction. If the lock is a write lock on Q, then one should make sure that the write. Which is locked, must be performed on each replica of Q. The main advantages of this approach is that it is simple to understand and simple enough to element. Deadlock management can be done with perfection. The main drawback is that we depend on the single site that maintains the locks. If that site falls, then concurrent cannot take place. Since we need to depend on the single site for executing locking. Bottleneck can be formed between the lock manager site and the other sites. To overcome disadvantages of single-lock manager approach, new approach known as distributed lock approach has been derived.

Distributed lock manager Approach

Distributed lock manager Approach, the lock managers reside at every site and they control the locking operation of their own site. The distribution of lock manager helps to avoid the point of failure, thus making the system more robust to failure. However, deadlock management in this approach is quite difficult to handle.

Two protocols to implement distributed lock manger approach:

1) Majority protocol

2) Biased protocol

1. Majority Protocol

   The name majority comes from the fact majority protocol handles majority of replica of a item Q, which is required to be locked by some transaction. This protocol works on the replica that is replicated and also the data that is not replicated. We will describe this protocol for the aforementioned two conditions as follows:-

• Since this protocol follows distributed-lock manager approach, all the sites in the network consisting DDBMS have their own lock manager who is responsible for locking the data and also unlocking the data stored at their own site.
• In case of data that has no replicas present in the network and a transaction wants to lock that data item. Say Q, stored at site S(i), the requesting site sends a message to S(i) starting the operation. The request cannot be granted until the state of Q is incompatible whenever the lock request is granted by the lock manager at site S(i), a message has been sent to the requesting node starting the success of the operation.
• In case of data Q that has replicas stored at n different sits in the network, whenever lock request is sent to any site that stores Q, that request needs to be sent to more than n sites holding the replicas of Q. This is the most important task in this protocol because until the majority of the sites holding Q are not being informed about the locking operation, the transaction does not operate on Q. Another point that needs to follow this case is whenever the WRITE operation takes place in any replicas of Q, all the replica should also write the updated value of Q.
• The main advantage of majority protocol is that single point failure never occurs in this case. If some sites are not available to execute the transaction, still the transaction runs following the protocol. On the other hand, the disadvantage of majority protocol include it needs to send (n/2+1) lock request messages and (n/2+1) unlock messages all over the network. To handle the replicated data. At any point of time, it looks one-third of the site; thus, it is more susceptible to deadlocks.

1. Biased Protocol

• As we know that in case of the READ operation, we generally use shared lock instead of exclusive lock, but for WRITE operation, only exclusive lock is used. Unlike majority protocols, biased protocol uses shared lock to READ a data item on a single site. Similar to majority protocol, in biased protocol. All the sites have their own lock manager who can lock and unlock the data items stored in his/her own site.
• When a data item Q needs to be locked by some transaction by executing shared lock, that initiator site should send a request to the site holding the data item. No need to send the lock request message to all the other sites holding the replicas of Q. When a data item Q needs locked by some transaction by executing exclusive lock, the initiator site must send the request message to all the other sites holding the data item Q.

The advantage of biased protocol includes the less overhead in case of a READ operation. However, the WRITE operation takes an extra overhead (since all the nodes containing replicated data item need to be informed). The deadlock susceptibility is very high for protocol also because while executing the WRITE operation on a data item Q, all the containing Q are locked, leading the network vulnerable to deadlocks