May be I am missing some subtleties here: At ua-cam.com/video/mYFo1aE47xE/v-deo.html, Prof Pavlo says that if there are no cycles in the graph, then the schedules are conflict serializable. However, if we go back to the write-read conflict (dirty reads) example, where T1 writes a value of $12 for object A and T2 reads $12 and writes a value of $14 for the same object (T2->T1), commits the transaction T2 after which T1 aborts, I don't believe there is a cycle. But clearly, there is a conflict. Could someone clarify this?
1:10:34, Assume that these 3 transactions were issued to RDBMS, when it received T3 Commit, would it just wait until T1 & T2 issue commit statements? how does DB make use of what has been just explained? Thanks
love your courses. Thank you so much. A small question, at time around 1:16:52, if w(A) = A +1, which depend on previous value of A, then it isn't safe? So the order also matters. Am I right? Thanks!
Can precedence graph detect write-read conflict? For example, t1 = [write(A), abort]. t2 = [read(A), commit]. Schedule is [write(A), read(A), abort T1, commit T2]. The precedence graph is from t1 to t2, which does not have a cycle. However, T2 should never get the value written by T1 if they were executed in sequence.
One thing comes to mind. Abort is not a single operation. It contains the reverse back of the object version, which is a read-write operation in the end. Given this, the precedence graph is completed. There will be a cycle and it is not conflict-serializable.
At 58:00 the sum is supposed to be 2114. Andy forgets to add 100 to B in the end. The error is $6 and not $106.
I was thinking of exactly the same!
Yeah I'm so mad at this, took me a while to figure out it was just a typo since I was only reading the slides
May be I am missing some subtleties here: At ua-cam.com/video/mYFo1aE47xE/v-deo.html, Prof Pavlo says that if there are no cycles in the graph, then the schedules are conflict serializable. However, if we go back to the write-read conflict (dirty reads) example, where T1 writes a value of $12 for object A and T2 reads $12 and writes a value of $14 for the same object (T2->T1), commits the transaction T2 after which T1 aborts, I don't believe there is a cycle. But clearly, there is a conflict. Could someone clarify this?
Think of the abort as another "write" which undo's the first write, and there you will have your cycle :D
1:10:34, Assume that these 3 transactions were issued to RDBMS, when it received T3 Commit, would it just wait until T1 & T2 issue commit statements? how does DB make use of what has been just explained? Thanks
Andy! You are the best PERIOD.
best thing in this course is that if u didn't understand anything from the lecture u gonna enjoy the outro
my Greetings from Egy
best instructor ever
love your courses. Thank you so much. A small question, at time around 1:16:52, if w(A) = A +1, which depend on previous value of A, then it isn't safe? So the order also matters. Am I right? Thanks!
Can precedence graph detect write-read conflict? For example, t1 = [write(A), abort]. t2 = [read(A), commit]. Schedule is [write(A), read(A), abort T1, commit T2]. The precedence graph is from t1 to t2, which does not have a cycle. However, T2 should never get the value written by T1 if they were executed in sequence.
Probably not? They are committed at the end, without an abort.
One thing comes to mind. Abort is not a single operation. It contains the reverse back of the object version, which is a read-write operation in the end. Given this, the precedence graph is completed. There will be a cycle and it is not conflict-serializable.