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 andT2
reads, writes and commit.Is it cascedeless? I think no, since
T1
andT2
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