DBMS | Concurrency Control Protocol | Two Phase Locking (2-PL)-III



Prerequisite – Basics of Two Phase Locking protocol(2-PL), Types of 2-PL.

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 same sets of protocols as the above two. For clarity let’s go through Conservative 2-PL in details.

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-S(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 like 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 but 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.

T1 T2
1

Lock-X(A)
2 Lock-X(B)
3 Read(A)
4 *operation on A
5 Write(A)
6 Unlock(A)
7 Lock-X(A)
8 Read(A)
9 *operation on A
10 Write(A)
11 Unlock(A)
12 Read(B)
13 *operation on B
14 Write(B)
15 Unlock(B)
16 Commit
17 Commit

Look at the schedule, it completely follows Conservative 2-PL, but fails to meet the requirements of Strict and Conservative 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



My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.



Improved By : Deeksharmaaa

Article Tags :
Practice Tags :



Be the First to upvote.


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.