GATE CSE
First time here? Checkout the FAQ!
x
+5 votes
470 views
1) T1: R(X), T2: W(X), T1: W(X), T2: Abort, T1: Commit

2) T1: W(X), T2: R(X), T1: W(X), T2: Abort, T1: Commit

3) T1: W(X), T2: R(X), T1: W(X), T2: Commit, T1: Abort

Can anyone explain whether these schedules are serializable, conflict-serializable, view serializable,
recoverable, avoids-cascading-aborts, and strict?

The abort operation actually bugging me.
asked in Databases by Junior (709 points)  
retagged by | 470 views
@Arjun sir could you plz clarify ?

2 Answers

+9 votes
Best answer
See whenever you find abort, it becomes more easier to answer the question.

If in any transaction, abort is given it simply means that by the end that( transaction having abort) transaction will roll back and so consider it doesnot exists when answering for conflict serializable, view serializable or serializable. And then since only one transaction remains it will be conflict serializabe, and if it is conflict serializable then it is both view serializable and serializable.

So, all the three parts above are C.S, V.S and Serializable.

In recoverable, we just check if the transaction which is reading the value of a data item( X here) which is written by other transaction, is commiting only after the transaction writing the value has committed. In (1) part there is no such dependency of read write so nothing to check for commits thus recoverable. In (2), T2  reads the value of X written by T1 and it doesnot commits before T1 has committed so it is recoverable but in (3), T2 is reading the value of X written by T1, so T2 must commit only after T1 commits, but it doesnot happens so (3) is not recoverable.

Now, if any schedule is not recoverable, it is cascading and not strict. So (3) is cascading and not strict.

In cascadless, if Tj is reading the value of a data item written by Ti, then Ti must commit the value before Tj reads it. If there is no such dependency, then also it is cascadless. Here, in (1) no dependency exists so it is cascadless. But in (2) and (3) there is dependency and T2 is reading the value written by T1 before T1 actually commits so it is cascading. And if it is cascading it is not strict.

In strict, a value written by a transaction Ti cannot be read or write both by any other transaction until Ti commits it. But in (1), between two w(x) there is no commit by T1 so it is not strict.
answered by Active (1.6k points)  
selected by
Thank you for nicely putting it at one place. It helps.

One small doubt : you said that ' if any schedule is not recoverable, it is cascading and not strict' What do mean when you say 'cascading' ? Do you mean that it has cascading rollbacks or something else ?
Yes. By cascading I mean the cascading rollbacks.
Why is it the case that we ignore such transactions for serializability but not for recoverability?
0 votes
I think the concept of serializability shouldnt apply if there are abort operations. WHenever we consider the concept of serializability, I think we implicitly asume that all operations are committed or will commit in future and then determine the serializabilty order. Here, what is important is final state of the database and we do ensure that view/conflict equivalent schedule has same effect as the original schedule.

There may be a schedule where  there may be read operation for T2 after the write operation of T1 and T1 aborts before T2 commits. So, we cant establish the serializability order because the final database state depends upon both the transactions and not only T2(which commits).
answered by Veteran (15.4k points)  
Why is it the case that we ignore such transactions for serializability but not for recoverability?


Top Users Sep 2017
  1. Habibkhan

    7096 Points

  2. Warrior

    2574 Points

  3. Arjun

    2412 Points

  4. rishu_darkshadow

    2402 Points

  5. A_i_$_h

    2204 Points

  6. nikunj

    1980 Points

  7. manu00x

    1846 Points

  8. makhdoom ghaya

    1760 Points

  9. Bikram

    1744 Points

  10. SiddharthMahapatra

    1718 Points


26,115 questions
33,691 answers
79,845 comments
31,098 users