database - How to determine the whether the transaction is conflict-serializable or not?

Question

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

Answer 1

等待大神答复