"Transactions: myths, surprises and opportunities" by Martin Kleppmann

[@ruixue6955]

3:40 Durability 4:28 Consistency 4:36 != C in CAP theorem 5:08 5:27 associated as the transactions the application executed in the database, move the database one consistent state to another 6:06 6:21 Atomicity 6:55 fault handling 9:54 Isolation 11:26 Question: *repeatable read* VS *read committed* 12:00 explain by example 13:02 read committed - 13:18 14:57 *read skew* (can occur under *read committed*) 15:06 assumption: 2 accounts: x & y 15:33 consider: you have concurrently running a read-only transaction ( *backup process* or *analytic query* ) 16:30 problem for the *backup* : you've seen different part of databases at different point in time 16:39 can happen under *read committed* 16:48 *repeatable read* and *snapshot isolation* to prevent *read skew* 17:25 more common: *snapshot isolation* 18:36 example of *write skew* - 18:45 INVARIANT: at least 1 doctor is on-call 19:42 assumption on data in database 20:15 result in violation on INVARIANT: there has to be doctors on-call 20:33 in *Oracle* this can not be prevented unless

[@aminigam]

Brilliant enlightening session, a gem. Listening to Martin is a pleasure

[@arunsatyarth9097]

Listening to Martin Kleppmann is like an orchestra. You enjoy it to the very limit!

[@rkmr41]

The definitive guide on ACID properties.

[@Peeja]

Fantastic talk! It's worth noting, spacetime itself obeys the same upper bound on consistency without coordination: causality.

[@proudindian-73]

That was very deep..

[@valentinwaeselynck8124]

"Every sufficiently large deployment of microservices contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half transactions" :D

[@implemented2]

What is half transactions?

[@SimplyaGameAholic]

@@implemented2 I think he meant the transaction contains partial failures with no reversibility. Basically you have no atomicity, and you're leaving things messed up after any failures :)

[@gurjarc1]

i have a doubt on 2 phase locking at 23:00 in the video say you have 2 txns t1 and t2 that executes the unit of read first, check some condition and update secnario1 - t1 has got exclusive lock on the row (for write), before t2 can get shared lock to read. So read of t2 has to wait for t1 to commit. So we get consistency. scenario2 - say both t1 and t2 both executed the read part, but not yet executed the modify part, so both got shared lock that read all the doctors where oncall=true. Now neither t1 nor t2 can commit, because t1 cant write as t2 is holding shared lock and vice versa. so it is a deadlock in this scenario Can anyone confirm that scenario1 was a case where in 2pl successfully was able to serialize and scenario2, the timing was bad that it resulted in a deadlock which required the db system to interfere and victimize one of the two txns. Thanks for helping a guy in advance trying to understand these concepts

[@samlaf92]

At 14:33 does read committed implementation with row-locking lead to deadlock here?

[@michaeleaster1815]

Thanks! I enjoyed this talk very much, esp. the sanity check of "who can describe read committed vs repeatable reads, from memory?".

[@ChumX100]

Absolutely brilliant! Very entertaining as well.

[@BillBurcham]

At 34:35 kzbin.info/www/bejne/a4vNmYGKgp2Li5om35s "Every sufficiently large deployment of microservices contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of transactions"

[@a3090102735]

This is a great talk! I'm also reading your books, the transactions section, however, listening to your explanations makes more sense to me now!

[@ruixue6955]

21:53 how to implement serializability 22:08 two-phase lock

[@darshanime]

at 14:34, how does read commited prevent the inconsistency? isn't it that transaction serializability prevents it?

[@ykochubeev]

Thank you so much! Very interesting problem highlighting!

[@barcelona.netcore4191]

Brilliant!

[@PaulSladekb]

great talk!

[@BethKjos]

Never did get to that explanation of "repeatable read"...

[@bigphatkdawg]

I think it was implied: Not susceptible to read skew

[@DanHaiduc]

Consensus is indeed expensive; blockchains are proof of that. Cryptocurrencies' transaction rate are limited either artificially, or by the fastest (single) node's processing power. For anything faster, you'd have to do sharding, which sacrifices consensus.

[@sabirove]

brilliant! ty!

[@gijduvon6379]

Это просто ахуительный видос!

[@valtih1978]

Which `read skew` is he talking about? Read Committed means that lock is take for the duration of select statement. This read lock should prevent any commit during the 'backup process'.

[@stIncMale]

Probably the best way to get an answer to your question is by reading the remarkable article called "A Critique of ANSI SQL Isolation Levels" (just google it).

[@implemented2]

You can have a long running read transaction, for instance, making a dump. Locking the whole database for writes for the duration of dumping is not possible.