I think an important point missed for the Optimistic concurrency protocol was that once a transaction is validated to not conflict with younger transactions, no transaction can be allowed to read a value before the write phase of the validated transaction completes (so that validation performed holds true "till" the values from the private workspace of the validated transaction are flushed to the main database/ global workspace). But at 51:55 Prashanth says it was a hand-wavy description with some details excluded and maybe this point was included in those details. Edit: At 58:20 professor mentions that latches are indeed required on the local workspaces of other transactions; but the latch held by the transaction being validated can't be released till the write phase for that transaction also completes.
At 47:35 a student asks if the Write phase of T2 should immediately follow the Validate phase of T2 without any interleaving with the Validate phase of T1 (assuming that was said earlier in the slide titled "OCC - Serial Validation"). A possible answer for this is - after a validation phase of some transaction (say X), we can have any number of validation/ write phases of other transactions, with requirement of only this invariant - no read from the main database occurs before the write phase of X. In a nut shell, no read from the main database should be allowed if there is a transaction which completed the validation phase but not the write phase (and the write need not strictly follow the validation phase, it might have other validations/ writes in between). Someone correct me if wrong.
Alex Petrov's Database Internals book (Page 93) defines both 2PL and Timestamp Ordering as Pessimistic Concurrency Control methods. I could see that TO is _more optimistic_ than 2PL, but is it correct that they're both still PCC methods?
Matt and Prashanth are awesome. Thanks, guys!
I think an important point missed for the Optimistic concurrency protocol was that once a transaction is validated to not conflict with younger transactions, no transaction can be allowed to read a value before the write phase of the validated transaction completes (so that validation performed holds true "till" the values from the private workspace of the validated transaction are flushed to the main database/ global workspace). But at 51:55 Prashanth says it was a hand-wavy description with some details excluded and maybe this point was included in those details.
Edit: At 58:20 professor mentions that latches are indeed required on the local workspaces of other transactions; but the latch held by the transaction being validated can't be released till the write phase for that transaction also completes.
anyone know the name of the song in the outro ?
ruclips.net/video/oeYBdghaIjc/видео.html&lc=Ugx7gWOoQZh8sU6DaaB4AaABAg
At 47:35 a student asks if the Write phase of T2 should immediately follow the Validate phase of T2 without any interleaving with the Validate phase of T1 (assuming that was said earlier in the slide titled "OCC - Serial Validation"). A possible answer for this is - after a validation phase of some transaction (say X), we can have any number of validation/ write phases of other transactions, with requirement of only this invariant - no read from the main database occurs before the write phase of X. In a nut shell, no read from the main database should be allowed if there is a transaction which completed the validation phase but not the write phase (and the write need not strictly follow the validation phase, it might have other validations/ writes in between). Someone correct me if wrong.
Alex Petrov's Database Internals book (Page 93) defines both 2PL and Timestamp Ordering as Pessimistic Concurrency Control methods. I could see that TO is _more optimistic_ than 2PL, but is it correct that they're both still PCC methods?
Ah, see that OCC is a subset of Timestamp ordering? (1:52) - funky
After watching the rest, that taxonomy makes sense!