retagged by
12,016 views
11 votes
11 votes
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.
retagged by

2 Answers

Best answer
22 votes
22 votes
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.
selected by
1 votes
1 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).

Related questions

2 votes
2 votes
4 answers
3