Hacker News Comments on
"Transactions: myths, surprises and opportunities" by Martin Kleppmann
Strange Loop
·
Youtube
·
33
HN points
·
3
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.I mean, I hear you that people do that and it does allow you to avoid needing distributed transactions. When you're stuck with an underlying NoSQL database without transactions, this is the best thing you can do. This is the whole "invert the database" idea that ends up with [1].I'm arguing that that usage pattern was painful and that if you can have horizontally scalable transaction processing and a stream of events due to committed transactions downstream, you can use that to power correct and easy to reason about materializations as well as asynchronous task processing.
Transact to change state. React to state changes. Prosper.
It's great. Incredibly dense with useful information and it just blows my mind how much knowledge Martin has about the topic. I recommend watching this talk from him to give a little glimpse of the book: https://www.youtube.com/watch?v=5ZjhNTM8XU8 This is just about a little part of one of the chapters.
⬐ mirekrusinOh man, this is good, thank you.
Rich Hickey - "simple made easy" https://youtu.be/rI8tNMsozo0Rob Pike - "concurrency is not parallelism" https://youtu.be/cN_DpYBzKso
Uncle Bob Martin - "future of programming" https://youtu.be/ecIWPzGEbFc
Martin Kleppmann - "transactions: myths, surprises and opportunities" https://youtu.be/5ZjhNTM8XU8
Simon Brown - "software architecture vs code" https://youtu.be/GAFZcYlO5S0
⬐ sparq_beamThat transaction talk is really good, thank you. I can now finally name the effect that I had noticed but had trouble explaining and referring to, write skews.It's interesting that he doesn't mention phantom reads as the difference between repeatable read/snapshot isolation, and serializable, which is what other sources tend to do.
Snapshot isolation always seemed to me like cheating the intended meaning of repeatable read, insofar as some databases refer to their snapshot isolation level as repeatable read.
That is, in the strictest sense, if you read a row twice, you get the same value with snapshot isolation, but you don't actually know that the value will be the same when you commit, which as I understand is a case of a write skew.
In fact, if one thinks of the definition of these levels in terms of locking semantics, one would expect a repeatable read to have the same meaning as obtaining a read lock on the row you read, which I understand would prevent at least some types of write skew, since no modification would be possible on that row, because it would need a write lock. There could still be hazards related to phantom reads (and possibly other effects), such as making a decision based on a computed aggregate that can change if new rows are inserted. Still, this meaning of repeatable reads would already provide a useful isolation level for various cases, except that it doesn't work with snapshot isolation.
I have a suspicion that applications out there made incorrect assumptions as to the actual isolation provided by the DB they use.
⬐ jzelinskieThis talk is super relevant to anybody writing a traditional monolithic web app. Eventually bugs creep in and you learn that your initial assumptions about transactions are basically all wrong. I really enjoyed that the talk extended to micro-services -- it gave a lot of insight into what you take for granted in your monolithic architecture when you start breaking things down.One tiny improvement I think could benefit the talk would be if the speaker commented about the usage of "SELECT FOR UPDATE" and maybe gap-locking.