# Transactions

1 vote
210 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 ??
2
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
0

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)
4 *operation on A
5 Write(A)
6 Unlock(A)
7   Lock-X(A)
9   *operation on A
10   Write(A)
11   Unlock(A)
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

In 2PL, there is growing phase and shrinking phase, both base can be visualized as an time interval. If we convert growing phase timer interval as an instant of time then simple 2PL is conservative 2PL.

In the above example at a point it accumulate all the required locks initially so it’s conservative 2PL.

## Related questions

1
154 views
Which of the following time stamp ordering protocol(s) allow the following schedules? $T:W_1(A)\ W_2(A)\ W_3(A)\ R_2(A)\ R_4(A)$ Time stamps: $T_1=5,T_2=10,T_3=15,T_4=20$ Thomas write rule Multiversion time stamp protocol Basic Time stamp All of these