Consider this schedule of two transactions:
T1 | T2 |
---|---|
r(X) | |
r(X) | |
w(Y) | |
w(Y) | |
commit | |
commit |
Is this schedule:
conflict serializable?
serializable?
recoverable?
cascadeless?
Consider this schedule of two transactions:
T1 | T2 |
---|---|
r(Y) | |
r(Y) | |
w(X) | |
r(X) | |
w(Y) | |
w(Y) | |
commit | |
commit |
Is this schedule:
conflict serializable?
serializable?
recoverable?
cascadeless?
Would any of the answers for schedule 2 change if we swapped the order of the two commits?
Consider this schedule of four transactions:
T1 | T2 | T3 | T4 | |
---|---|---|---|---|
1 | r(X) | |||
2 | r(X) | |||
3 | w(Y) | |||
4 | r(Y) | |||
5 | r(Y) | |||
6 | w(X) | |||
7 | r(W) | |||
8 | w(Y) | |||
9 | r(W) | |||
10 | r(Z) | |||
11 | w(W) | |||
12 | r(Z) | |||
13 | w(Z) |
Draw a precedence graph to determine if this schedule is conflict serializable.
Consider the following schedule of two transactions:
T1 | T2 |
---|---|
r(X) | |
r(Y) | |
w(X) | |
r(X) | |
w(Y) | |
commit | |
r(Y) | |
w(X) | |
commit |
Which of the reads is a dirty read?
Would two-phase locking prevent the dirty read from occurring? If so, explain why. If not, modify the schedule so that it uses two-phase locking but still includes a dirty read.
How can we use locking to prevent dirty reads? Explain how your proposed approach would prevent the dirty read in the schedule from problem 1.
Does the approach that you specified in your answer to problem 3 replace two-phase locking (2PL), or do we still need 2PL as well? Explain your answer.
Last updated on March 20, 2024.