The Gateway to Computer Science Excellence
+1 vote
79 views
T1
LOCK-X (A)
LOCK-S (B)
R(A)
R(B)
W(A)
UNLOCK (A)
COMMIT
UNLOCK (B)

is this following CONSERVATIVE 2PL ?
 

doubt : in conservative locking schme ..all locks are aqured before starting but locks can be released at ANY time ..so conservative need not be strict/rigorous

OR is it only after commit ??
in Databases by Loyal (7.4k points) | 79 views
+1
release of locks can be before commit, strict only limits the acquiring of lock, the above schedule is conservative 2PL
0
above schedule is conservative but not strict then right ?
0
in Strict exclusive locks should be released only after COMMIT
0
yes
0
it is unlocking exclusive on A before commit then how it is Strict
0
ok ok, my bad, it's not strict

1 Answer

0 votes

In strict 2 PL a transaction obtains locks from dbms iff it has no common object with any other transaction or if it has a common object with any other transaction and it gets the locks first then after it will release locks (exclusive locks matter here the most as 2 transactions can have shared lock on same objects simultaneously ) ,dbms will remove suspension from another transaction's lock requests on the common object and grant locks. To satisfy that there occurs no conflicts and interleaving of two transactions are 'safe', the transaction that gets locks first, will release its exclusive lock only after commit thus resulting in a serial ordering of schedule.

here the transaction can not be strict as it releases its exclusive lock on A before it commits .suppose considering an imaginary case another transaction say T2 was on hold by dbms wanting lock for A to modify A. as soon as T1 releases lock on A ,T2 starts and modifies data and commits. Now the only operation left for T1 as per the problem is commit and before T1 could commit, T1 fails.. Now T1 rollbacks. T1 starts from beginning restoring all the initial values for A and B. But here A is already modified by T2 and T2 has committed hence T2 can not rollback. So T2 gets lost update issue because changes done by T2 on A can not be recovered now.

Strict 2PL forbids this kind of scenario to maintain recoverability of database hence this protocol strictly says that transaction will release locks(exclusive of course) only after commit.

Here,T1 is conservative 2PL, as conservative 2PL allows to release the locks whenever another transaction is in need, but it needs to lock all the data items before carrying out any operation, no wait and hold like strict. thus it is deadlock free.but in this protocol we may still face drawbacks like Cascading Rollbacks...

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 , that is because we unlock A and B before the transaction commits.
here if T1 fails before commit, T2 won't have lost update issue as T2 commits after T1 but T2 will have to unnecessarily rollback too as it has worked on A. So thus cascading rollback occurs.

Hope it is clear now

by (287 points)

Related questions

Quick search syntax
tags tag:apple
author user:martin
title title:apple
content content:apple
exclude -tag:apple
force match +apple
views views:100
score score:10
answers answers:2
is accepted isaccepted:true
is closed isclosed:true
50,737 questions
57,258 answers
198,086 comments
104,735 users