What is "Strict recoverable" schedule?

Question

Consider the following schedule:

$S: r_1(A), w_2(A), Commit_2, w_1(A),w_3(A), Commit_3, Commit_1$

Which of the following is true?
a. Schedule is view serializable schedule and strict recoverable schedule
b. Schedule is non serializable schedule and strict recoverable schedule
c. Schedule is non serializable schedule and not strict recoverable schedule
d. Schedule is serializable schedule and not strict recoverable schedule

What is the answer? Also I know what is "strict schedule" and "recoverable schedule", But then what it means by "strict recoverable"?

Comments

strict recoverable means if their is two transaction let t1,t2....let t1 perform write operation w1(a)

after t2 perform write operation before t1 commit it not be strict recoverable ..

Answer 1

First of all it is a view serialisable schedule as it  has view equal serial schedule T1 : T2 : T3 which satisfies the initial and updated reads and final write on variable A which is required for view serialisability.

So now coming to strict recoverability.A schedule is said to be strict recoverable iff :

If   say T_i   writes before T_j  writes or reads, then T_j must read or write after T_i  commits or aborts then only the schedule will be strict recoverable.

Now we  can see there is write - write pair done by transactions T₁  followed by T₃  which is violating the above mentioned condition as T₃  is supposed to do write operation only after T₁ commits which is not happening in the given schedule..

Hence the given schedule is serialisable but not strict recoverable.Hence the correct option is D) 

Comments

good. Though I guessed the same definition of strict recoverability, am just curious from which book this definition came? Korth? Navathe? or Gherke? Didnt came across it earlier!!!

---

well....this definition of strict recoverable sounds similar to that of cascadeless:

A cascadeless schedule is one where, for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti , the commit operation of Ti appears before the read operation of Tj .

The only difference is that above we deal with only commit of Ti and read of Tj while your definition of Strict Recoverable deals with commit and abort of Ti and read and write of Tj. However if we take recoverability and cascadeless into consideration and after giving some thought I felt both:

• abort of Ti sounds obvious, that is even if above definition of cascadelessness does not explicitly specifies that abort of Ti should appear before read of Tj, it is assumed so when it says commit (or abort) of Ti should appear before read of Tj 
• write of Tj does not makes much sense in this context (as if it is write after write, its blind write and recoverability makes sense only when there is a read after write)

So, is strict receverable just another name of cascadeless?

---

Any comment friend?

---

Strict recoverable is just an extension to cascadeless schedule. Where both read and write of a variable by a later transaction is performed only after commit of earlier transaction which has done write

---

Still some doubt.

---

This definition of "strict recoverable" schedule sounds exactly same as definition of "strict" schdeuld as given in Korth or Elmasri. Is it supposed to be so? Or is it just that it is recoverable which is also strict thats why "strict recoverable" as definition of "recoverable" is less constraining than "strict", and above definition of "strict recoverable" is exacly same as "strict". And again "strict" schedule is always "recoverable".

---

unable to understand :- "view equal serial schedule T1 : T2 : T3" need more explanation. As final write is done by T1 commit. so View view equivalent serial schedule :T1 only. ???

---

As final write is done by T1 commit.

final write on A is by T$_3$,  but not T$_1$ ( note that commit operation is not deleing with the resource A )

---

@Shaik Masthan  Is this correct? As initial read is 100 (done by T1) and final write is 400 (done by T3)

T1:T2:T3

---

YES,it is correct !

---

Source: https://en.wikipedia.org/wiki/Schedule_(computer_science)#Strict

A schedule is strict - has the strictness property - if for any two transactions T1, T2, if a write operation of T1 precedes a conflicting operation of T2 (either read or write), then the commit or abort event of T1 also precedes that conflicting operation of T2.

Any strict schedule is cascade-less, but not the converse. Strictness allows efficient recovery of databases from failure.

Answer 2

Strict recoverable means when write to read /write sequence present in two different transaction then first transaction which write is commit then only another transaction read/ write it .

Here it is not strict recoverable since Transaction1 write(A) is not commit and Transaction3 write(A) is done so not strict recoverable.

Schedule is not conflict serializable and thier is blind write so yes view seriablizable ( Serializable).

D is answer.

Comments

if it's not CSS & if blind write is present then it's view serializable?? this is any rule??

---

^ not necessarily.

But if It is not CSS and there is no BLIND WRITE, then definitely it is not view-serializable.

---

Hii, can you please tell me how it different from strict schedule