The Gateway to Computer Science Excellence
+33 votes
3.9k views

Consider the following two transactions : T1 and T2.

T1 :

read (A);

T2 :

read (B);

   read (B);    read (A);
   if A = 0 then B ← B + 1;    if B ≠ 0 then A ← A - 1;
   write (B);    write (A);

Which of the following schemes, using shared and exclusive locks, satisfy the requirements for strict two phase locking for the above transactions?

  1. S1 :  lock S(A); S2 : lock S(B);
       read (A);    read (B);
       lock S(B);    lock S(A);
       read (B);    read (A);
       if A = 0    if B ≠ 0
       then B ← B + 1;    then A ← A - 1;
       write (B);    write (A);
       commit;    commit;
       unlock (A);    unlock (B);
       unlock (B);    unlock (A);
  2. S1 : lock X(A); S2 : lock X(B);
       read (A);    read (B);
       lock X(B);    lock X(A);
       read (B);    read (A);
       if A = 0    if B ≠ 0
       then B ← B + 1;    then A ← A - 1;
       write (B);    write (A);
       unlock (A);    unlock (A);
       commit;    commit;
       unlock (B);    unlock (A);
  3. S1 : lock S(A); S2 :  lock S(B);
       read (A);    read (B);
       lock X(B);    lock X(A);
       read (B);    read (A);
       if A = 0    if B ≠ 0
       then B ← B + 1;    then A ← A - 1;
       write (B);    write (A);
       unlock (A);    unlock (B);
       commit;    commit;
       unlock (B);    unlock (A);
  4. S1 : lock S(A); S2 : lock S(B);
       read (A);    read (B);
       lock X(B);    lock X(A);
       read (B);    read (A);
       if A = 0    if B ≠ 0
       then B ← B + 1;    then A ← A - 1;
       write (B);    write (A);
       unlock (A);    unlock (A);
       unlock (B);    unlock (B);
       commit;    commit;
in Databases by Boss (16.3k points)
edited by | 3.9k views
+1
Please explain me someone what's wrong in option a if they mention exclusive lock on b in option a
Thin this option is best suitable for strict 2 pl as it is regorous 2 pl
0

Strict 2 PL ensures  conflict serializable serial schedule based on Lock Point but above mentioned scheduled not conflict serializable. And 2 PL says other transaction can not R/W uncommitted values but it is happening here.

So how is this  2 P L ?

ping @Krish__, @rahul sharma 5,  @Red_devil, @Shivam Chauhan, @Tuhin Dutta, @Anu007,  @Ashwin Kulkarni @reena_kandari  and @srestha ji.

+4

The above question just asks if the modified transactions can lead to a strict 2PL schedule. The schedule itself hasn't been given and we can only check if:

1. Exclusive locks should be released after the commit for each transaction.   

2. No Locking of the same data item done after the first Unlock and vice versa.

3. The transactions have proper shrinking and growing phase.

0
@krish_ first of all, are the two schedules S1 and S2 independent?
Secondly, why can't option (a) be strict 2PL? It satisfies the condition for both Strict as well as Rigorous 2PL.
0
Also, is it necessary that a schedule has to have an exclusive lock for it to follow strict 2PL? As maybe the case with option (a).....kinda stupid doubt but it exists!
0
same doubt @jerry
+1
in option (a) since we have just acquired shared lock  and hence we can only read not write. for writing we need exclusive locks.

4 Answers

+40 votes
Best answer

Answer is (C).

Many of you would point a DEADLOCK and I won't deny But see Question just asks for requirement to follow Strict 2PL. Requirement are

  1. Exclusive locks should be released after the commit.
  2. No Locking can be done after the first Unlock and vice versa.

In 2Pl deadlock may occur BUT it may be that it doesn't occur at all.

Consider that in option (C) if both execute in serial order without concurrency. Then that is perfectly valid and YES it follows Strict 2PL.

by Loyal (7.8k points)
edited by
+1
but in c) we have unlocked write lock on A before commit in S2....then how can it be in 2PL?
+3
@dhingrak :I think that is a printing mistake !! See they have unlocked the X_lock(A) two times . First one must have been Unlock(B)

If it is exactly same as given NO option matches in that case !!
+4
What's wrong with option A?
0
If t2 has shared lock on A,then can T1 can get that lock as an exclusive lock?
+2
Why not option A ?
+1
In Option C there is also cycle in precedance graph. If it is in 2PL then there shouldn't be any cycles  because it wil be in CS
0
In option A, in S2 there has to be an Exclusive lock on A.
0
@Arjun sir, I can't see the deadlock that is being talked about. Please help.
+15
In strict 2PL all the exclusive locks must be unlocked after the commit operation.

Option (a) write operation in both schedules need exclusive locks,thus it is wrong option because it does not follows locking protocol

option(b) In S1 shared lock is unlocked after commit operation. So,wrong.

option (c) correct. Since, all exclusive locks in both S1 and S2 are unlocked after commit operation

option (d) exclusive locks are not unlocked after commit operation. So wrong.
+1
No locking can be done after the first unlock and vice versa .

is this point checking necessary ?

becoz i feel exclusive lock should be release after the commit is enough.
+2

"No locking can be done after the first unlock and vice versa" .

This is the basic requirement of 2PL.

0
Option (A) is wrong because only shared locks are used in that case. Since we are also using write operation in that case, so shared lock isn't sufficient. Am i right?
0
It must have to aquire exclusive lock
+9 votes

A) is eliminated because write (B) is done in S1 without acquiring Exclusive lock on B.

B) is eliminated because unlock (A) should happen only after commit in a strict 2pL.

D) is also eliminated. The reason is exactly same as B)

C) is the answer.

  •  It can be clearly seen that it is a 2 pL because all acquired locks are released only after locking_point.
  •  It is also clear that it is also a strict 2 pL as all Exclusive locks acquired by a transaction are released only after commit operation.
by Loyal (7.9k points)
0
Check your reasons it's contradicts.
+8 votes

3) Shared lock can be unlocked anytime Exclusive only after commityes
4) is 2plno
2) is Wrong Exclusive cannot take other's Exclusive Lock.no

1) To write X you need Exclusive Lock So WRONG crying
Correct If Wrong.

by Junior (889 points)
edited by
0
How option 4 ? 4 has commit after release of xclusive locks, it shud commit before releasing....

Moreover the option 2 and 3 i guess incorrectly given... both didnt hav release of B for A
0
@Abhinav

can u explain

2) is Wrong Exclusive cannot take other's Exclusive Lock
0
@cse23 ,  " if schedule in 2PL then it is CS " This is correct , right ?

If not CS then not 2PL is this also correct ??
+5 votes
Here in option some mistake is there in original paper.

The requirements for strict two phase locking for the above transactions  = strict two phase locking says unlock exclusive lock i.e. unlock X(); after commit or rollback.

Shared lock used for Read , exclusive lock used for  Write data.

Releasing exclusive lock after commit restrict the deadlock condition. i.e. we cannot get lock on item were exclusive lock already taken.
by Veteran (62.7k points)
0
Thanks
0
But strict 2PL can have deadlock...
+2
whats wrong with, option (a), it is rigorous so implying strict 2PL

Edit: only shared locks no exclusive so wrong
0
You need exclusive lock to write data.

No exclusive locks are present in A , yet write was performed
0
@Dulqar

we know p-->q is equivalent to ~q-->~p

if 2PL implies CSS

hence If schedule is not CSS then It is not 2PL also
0
@cse23 in option C there is cycle in precedence graph so it is not CSS and hence not 2PL
correct me if im wrong
0
the exact interleaving of operations is not even shown in the diagram, how are u drawing the precedence cycle??? Moreover if every transaction in a schedule individually follows 2PL then the schedule is always serializable. Hence option C
0
Then 2PL is conflict serializable?

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,645 questions
56,597 answers
195,839 comments
102,146 users