Problem With Simple Locking
Consider the Partial Schedule:
S.No | T1 | T2 |
---|---|---|
1 | lock-X(B) | |
2 | read(B) | |
3 | B:=B-50 | |
4 | write(B) | |
5 | lock-S(A) | |
6 | read(A) | |
7 | lock-S(B) | |
8 | lock-X(A) | |
9 | …… | …… |
1. Deadlock
In deadlock consider the above execution phase. Now, T1 holds an Exclusive lock over B, and T2 holds a Shared lock over A. Consider Statement 7, T2 requests for lock on B, while in Statement 8 T1 requests lock on A. This as you may notice imposes a deadlock as none can proceed with their execution.
2. Starvation
Starvation is also possible if concurrency control manager is badly designed. For example: A transaction may be waiting for an X-lock on an item, while a sequence of other transactions request and are granted an S-lock on the same item. This may be avoided if the concurrency control manager is properly designed.
Lock Based Concurrency Control Protocol in DBMS
In a database management system (DBMS), lock-based concurrency control (BCC) is used to control the access of multiple transactions to the same data item. This protocol helps to maintain data consistency and integrity across multiple users.
In the protocol, transactions gain locks on data items to control their access and prevent conflicts between concurrent transactions. This article will look deep into the Lock Based Protocol in detail.