I've the following question:
read(T1, x)
read(T2, x)
write(T1, x)
write(T2, x)
commit(T1)
commit(T2)
State whether the schedule is conflict-serializable, recoverable and avoids cascading abort?
I approach the problem like:
----------------------
| T1 | T2 |
----------------------
| read(x) | |
----------------------
| | read(x) |
----------------------
| write(x)| |
----------------------
| | write(x) |
----------------------
| commit | |
----------------------
| | commit |
----------------------
I thought like, since there was no cycle (acyclic) in the precedence graph , it was conflict-serializable. Also transaction T1
can be transformed to the transaction T2
by swapping:
----------------------
| T1 | T2 |
----------------------
| read(x) | |
----------------------
| write(x)| |
----------------------
| commit | |
----------------------
| | read(x) |
----------------------
| | write(x) |
----------------------
| | commit |
----------------------
Is it recoverable? I think yes, since T1
commits after writing and T2
reads, writes and commit.
Is it cascedeless? I think no, since T1
and T2
are not committing after writing.
Is it avoiding cascadeless abort? I think yes, since it is recoverable.
However, the answer is:
Not conflict serializable
Recoverable
Avoids cascading abort
Now, why is this conflict-seriable?
Most probably the answer is the cycle occurs between T2
read(x) -> T1 write(x) -> T2 write(x).
If I'm correct, then why the schedule 3 is conflict-serializable?
Regards
I thought like, since there was no cycle (acyclic) in the precedence graph , it was conflict-serializable.
Wrong assumption. If we draw the precedence graph:
The schedule is not conflict-serializable
T1
first writes to the X
and first T1
is committed.T2
does not read the committed data.X
can be reverted back to its original value.