393 views

Consider the following schedule

$\text{S : r2(A), w1(B), w1(C), R3(B), r2(B), r1(A), commit_1, r2(C), commit_2, w3(A), commit_3 }$

Consider the following statements :
S1 : Schedule(S) is conflict serializable schedule.
S2 : Schedule(S) is allowed by 2PL.
S3 : Schedule(S) is strict recoverable schedule.
S4 : Schedule(S) is allowed by strict 2PL.
How many above statements true about schedule(S) ?

retagged | 393 views
0

Why isn't the schedule recoverable? Though there is dirty read but since the transactions are ultimately getting committed(and that also in the order of the dirty read) so can't we say it is cascadeless and hence recoverable?

EDIT: I guess i got it.. there is a difference b/w strict recoverable schedule and a recoverable schedule..

0
yes :p
+1
Key word - STRICT.
0
can someone give the proper answer
0
For S2, try to give the locks and release the locks as needed and see if you are being able to form such a schedule where locking of items and releasing of items are taking place in 2 phases or not. If u can form such a schedule and at the same time if u can satisfy the lock requests of all the transactions, then the schedule is in 2PL.

For S4, according to the definition of strict 2PL, see whether the transactions are being able to hold the exclusive locks on data items until they commit. If you can form such a schedule and at the same time if you can satisfy their requests, then the schedule becomes a strict 2PL schedule.
+4

This is the schedule that is possible in 2PL. There is no way by which u can get this schedule to be under strict 2PL since transaction T1 has to unlock its exclusive mode locks on B and C even before it commits.

0
i didn't see any such ques in prev year :(
+2

only regarding 2PL has been asked in GATE before..https://gateoverflow.in/1484/gate1999-2-6

0

i m confused about S3 they saying strict recoverable....i beleive those 2 are different terms

0
The schedule isnt strict recoverable also. Strict recoverable means if a transaction is performing Write operation on some data item, any Read/Write on that same data item can occur only after the transaction which performed the Write commits. But here this isnt the case. So S3 is false.
0
saying strict recoverable is as good as saying strict schedule ..every strict is recoverable !!
0

yes exactly!

0
three types we have

1) recoverable

3) strict

and they are saying term strict recoverable which is not valid term according to their definitions i think bcz strict is superset of recoverable if strict then must recoverable

u r saying just definition of strict  above .

they should nt have written that recoverable thing there ... i am just saying that ...
0

Strict recoverable implies a strict schedule.

And the second type of schedule is "Cascadeless schedule" which is a recoverable schedule and has no cascading aborts.

0

@Somoshree Datta 5

Just for confirmation

If Shared lock already taken on item other CAN take SHARED LOCK  on that item but NOT EXCLUSIVE

if Exclusive lock is already taken on item then other CAN'T take SHARED NOT EXCLUSIVE also

0

Yes, right!

0
0
any one explain
0

@Shubhanshu can you please tell what's the final answer for this question, which statements are correct so that we can understand which part we r going wrong if any nd understand from the comments.

because it's not clear what is the exact conclusion of this discussion.

+2

s1: True: conflict serializable to schedule >> $T_{1}\rightarrow$$T_{2}\rightarrow T_{3}$

S2: True: allowed in basic  2PL.

s3: False

strict recoverable schedule>> if transaction $T_{i}$ updates the data item A, then any other transaction $T_{j}$ not allowed to R(A) or W(A) until commit or rollback of $T_{i}$.

 $T_{i}$ $T_{j}$ W(A) ..... commit or rollback R(A) or W(A)

s4: False>>>  strict 2PL is basic 2PL in which all exclusive locks should be hold until commit or rollback

but here R$_{2}$(B) request for shared lock on B and B is already locked(xclusive) by   $T_{1}$.

S1 : true

S2 : true

S3 : false

S4: false
by (385 points)