Now, we know both Strict 2-PL and Rigorous 2-PL avoids Cascading Rollbacks and ensures a Strict schedule but still cannot guarantee that our schedule is Deadlock free. We have seen both Strict and Rigorous 2-PL are similar in application and a general misconception is common that Conservative 2-PL also follows the same sets of protocols as the above two. For clarity let’s go through Conservative 2-PL in detail.
Conservative 2-PL –
A.K.A Static 2-PL, this protocol requires the transaction to lock all the items it access before the Transaction begins execution by predeclaring its read-set and write-set. If any of the predeclared items needed cannot be locked, the transaction does not lock any of the items, instead, it waits until all the items are available for locking. So the operation on data cannot start until we lock all the items required.
Now let’s see an interesting example on Conservative 2-PL. Tell me if the following schedule follows Conservative 2-PL?
Schedule: Lock-X(A) Lock-X(B) Read(A) Read(B) Write(A) Unlock(A) Commit Unlock(B)
Do you think the above Schedule does not follow Conservative 2-PL? Don’t confuse the protocol as just a modified version of Rigorous 2-PL, We can release the locks whenever we want, but we need to lock all the data items before carrying out any operation. This is what makes it Deadlock-free. The above schedule follows Conservative 2-PL.
Some interesting traits about Conservative 2-PL:
- Schedule following this will not have a Growing Phase as we’ve seen in Basic, Strict and Rigorous 2-PL. As locking the data before using it is mandatory so this protocol has no Growing phase. Moreover, this rule makes it Deadlock free as if an item is not available for locking the transaction releases all the locks and tries again later, i.e, no Hold and Wait. This makes one of the four necessary conditions for deadlock void.
- We only have to lock all the items beforehand, so releasing or unlocking them has no restrictions as we had in Strict or Rigorous 2-PL.
- As no operations are done before acquiring all the locks, we have no Growing phase in this protocol unlike Basic, Strict, Rigorous 2-PL.
- Although we get a Deadlock free schedule in this protocol, we may still face drawbacks like Cascading Rollbacks. So this protocol doen not ensure Strict Schedules. This is a disadvantage in comparison to Strict and Rigorous 2-PL.
Let’s discuss an example now. See how the schedule below follows Conservative 2-PL but does not follow Strict and Rigorous 2-PL.
|4||*operation on A|
|9||*operation on A|
|13||*operation on B|
Look at the schedule, it completely follows Conservative 2-PL, but fails to meet the requirements of Strict and Rigorous 2-PL, that is because we unlock A and B before the transaction commits.
How can cascading abort happen in Conservative 2-PL?
This can happen because a Transaction may carry out a Dirty Read from another Transaction. We don’t have such restrictions in our protocol so this situation is possible.
Look at the Example given above, we have a Dirty Read operation from T1 to T2 at Step 8. If T1 aborts, then T2 would be rolled back.
GATE related question:
GATE-CS-2016 (Set 1) | Question 61
- Two Phase Locking Protocol
- Lock Based Concurrency Control Protocol in DBMS
- Graph Based Concurrency Control Protocol in DBMS
- Categories of Two Phase Locking (Strict, Rigorous & Conservative)
- Concurrency Control Techniques
- Concurrency Control in DBMS
- Timestamp based Concurrency Control
- Real-time Transport Control Protocol (RTCP)
- Difference between Stop and Wait protocol and Sliding Window protocol
- Difference between Flow Control and Congestion Control
- Implementation of Locking in DBMS
- Multiple Granularity Locking in DBMS
- Concurrency problems in DBMS Transactions
- Gossip Protocol in Cassandra
- User Datagram Protocol (UDP)