29:39 if we abort t1, t2 could find it self in the same situation where down the road it conflicts with something that started earlier. This comes down to cascading abort right?
Yes, T2 could end up conflicting with future txns and it will have to abort. This is not the same as cascading aborts, since the outcome of one txn (T_x) does *not* depend on the commit outcome of another txn (T_y) because T_x cannot read uncommitted data from T_y.
Say I put a latch on each page/frame, and make the validation and write phases atomic (validation acquires an upgradable latch and write upgrades said latch). Transactions can now validate directly with the global state instead of cross-validating with each other, right? This is backwards validation and operates as read-committed (can be upgraded to repeated-read by checking if a tuple exists in the read set first before returning it) Also for phantom reads, if I use 2 timestamps per transaction, one assigned at the beginning (call it read ts) and another one before validation phase. While reading, I can check if the ts of the global tuple > my read ts AND the tuple is not in my read set then skip it. Enabling this check guarantees repeated-reads without phantoms, disabling it gives read-committed. Is that viable?
What’s the music at the beginning?
Mad Fanatic, RagChyld - Official Members ruclips.net/video/e72eF34bLlk/видео.html
@@robwells3713thanks 😊
29:39 if we abort t1, t2 could find it self in the same situation where down the road it conflicts with something that started earlier. This comes down to cascading abort right?
Yes, T2 could end up conflicting with future txns and it will have to abort.
This is not the same as cascading aborts, since the outcome of one txn (T_x) does *not* depend on the commit outcome of another txn (T_y) because T_x cannot read uncommitted data from T_y.
Say I put a latch on each page/frame, and make the validation and write phases atomic (validation acquires an upgradable latch and write upgrades said latch). Transactions can now validate directly with the global state instead of cross-validating with each other, right? This is backwards validation and operates as read-committed (can be upgraded to repeated-read by checking if a tuple exists in the read set first before returning it)
Also for phantom reads, if I use 2 timestamps per transaction, one assigned at the beginning (call it read ts) and another one before validation phase. While reading, I can check if the ts of the global tuple > my read ts AND the tuple is not in my read set then skip it. Enabling this check guarantees repeated-reads without phantoms, disabling it gives read-committed. Is that viable?