#18 - Optimistic Concurrency Control ✸ Weaviate Database Talk (CMU Intro to Database Systems)

Andy Pavlo (www.cs.cmu.edu...)
Slides: 15445.courses....
Notes: 15445.courses....
🛢🗲Database Flash Talk🗲🛢
Etienne Dilocker ( / etienne-dilocker-60727... )
Weaviate (weaviate.io/)
Jump to 01:05:21
15-445/645 Intro to Database Systems (Fall 2024)
Carnegie Mellon University
15445.courses....

[@gergoszabo4758]

What’s the music at the beginning?

[@robwells3713]

Mad Fanatic, RagChyld - Official Members kzbin.info/www/bejne/m2iVlnlpacd_os0

[@gergoszabo4758]

@@robwells3713thanks 😊

[@evanxg852000]

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?

[@andypavlo]

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.

[@mohamedyasser5285]

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?