Single Lock Manager - Concurrency Control in Distributed Database

Concurrency Control in Distributed Database - Single Lock Manager Approach

In this approach, the distributed database system which consists of several sites, maintains a single lock manager at a chosen site as shown in Figure 1.Observe Figure 1 for Distributed Sites S1, S2, …, S6 with Site S3 chosen as Lock-Manager Site.

Figure 1 - Single Lock Manager Approach

The technique works as follows;

When a transaction request for locking some data items, the request must be forwarded to the chosen lock manager site for locks. This is done by the Transaction manager of site where the request is initiated.

The lock manager at the chosen lock-manager site decides to grant the lock request immediately based on the usual procedure. [That is, if a lock is already held on the requested data item by some other transactions in an incompatible mode, lock cannot be granted. If the data item is free or data item is locked in a compatible mode, the lock manager grants the lock]

If lock request granted, the transaction can read from any site where the replica is available.

On successful completion of transaction, the Transaction manager of initiating site can release the lock through unlock request to the lock-manager site.

Example – Transaction handling in Single Lock-Manager Approach:

Figure 2 - Steps of Transaction handling in Single Lock Manager approach

Let us assume that the Transaction T1 is initiated at Site S5 as shown in Figure 2 (Step 1). Also, assume that the requested data item D is replicated in Sites S1, S2, and S6. The steps are numbered in the Figure 2. According to the discussion above, the technique works as follows;

• Step 2 - The initiator site S5’s Transaction manager sends the lock request to lock data item D to the lock-manager site S3.

          The Lock-manager at site S3 will look for the availability of the data item D.

• Step 3 - If the requested item is not locked by any other transactions, the lock-manager site responds with lock grant message to the initiator site S5.
• Step 4 - As the next step, the initiator site S5 can use the data item D from any of the sites S1, S2, and S6 for completing the Transaction T1.
• Step 5 - After successful completion of the Transaction T1, the Transaction manager of S5 releases the lock by sending the unlock request to the lock-manager site S3.

Advantages:

• Locking can be handled easily. We need two messages for lock (one for request, the other for grant), and one message for unlock requests. Also, this method is simple as it resembles the centralized database.
• Deadlocks can be handled easily. The reason is, we have one lock manager who is responsible for handling the lock requests.

Disadvantages:

• The lock-manager site becomes the bottleneck as it is the only site to handle all the lock requests generated at all the sites in the system.
• Highly vulnerable to single point-of-failure. If the lock-manager site failed, then we lose the concurrency control.

Related Posts:

Concurrency Control in Distributed Databases
Distributed Lock-Manager Approach
Primary Copy Protocol
Majority Protocol
Biased Protocol
Quorum-Consensus Protocol

“Tell me and I forget. Teach me and I remember. Involve me and I learn.” Benjamin Franklin