Demystifying Database Systems: An Introduction to Transaction Isolation Levels
1–10 of 23 posts
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#2> If any of my readers are aware of any real lawsuits that came from application developers who believed they were getting a SERIALIZABLE isolation level, but experienced write skew anomalies in practice
Doubt this ever really happened. Can hardly imagine debating serializability in a court of law Oracle v. Google was bad enough.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#3Glad to see to see this post on HN. I'm the author and happy to respond to questions in this thread.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#4> If any of my readers are aware of any real lawsuits that came from application developers who believed they were getting a SERIALIZABLE isolation level, but experienced write skew anomalies in practice Doubt this ever really happened. Can hardly imagine debating serializability in a court of law Oracle v. Google was bad enough.
A quick search shows data integrity lawsuits do happen: https://www.healthcareinfosecurity.com/1-billion-lawsuit-foc...
But I'd like to hear from engineers who have seen write skew bugs and other transaction anomalies cause business issues.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#5> If any of my readers are aware of any real lawsuits that came from application developers who believed they were getting a SERIALIZABLE isolation level, but experienced write skew anomalies in practice Doubt this ever really happened. Can hardly imagine debating serializability in a court of law Oracle v. Google was bad enough.
A quick search shows data integrity lawsuits do happen: https://www.healthcareinfosecurity.com/1-billion-lawsuit-foc... But I'd like to hear from engineers who have seen write skew bugs and other transaction anomalies cause business issues.
This is some nice work on the issue from Peter Bailis: http://www.bailis.org/blog/understanding-weak-isolation-is-a...
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#6It seems grossly irresponsible to encourage the use of serializable without even mentioning deadlocks. I guess you won't have deadlocks if your db interprets as serializable as "lock the whole database on transaction start", but that means literally no concurrency whatsoever, which also seems like a grossly irresponsible recommendation.
I dunno, maybe I didn't get the memo that the database of the future will be single-threaded.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#7It seems grossly irresponsible to encourage the use of serializable without even mentioning deadlocks. I guess you won't have deadlocks if your db interprets as serializable as "lock the whole database on transaction start", but that means literally no concurrency whatsoever, which also seems like a grossly irresponsible recommendation. I dunno, maybe I didn't get the memo that the database of the future will be sing…
In postgresql at least, serializable cannot deadlock. It uses predicate locks to provide serializable consistency with high levels of concurrency. You can have serialization failures though.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#8It seems grossly irresponsible to encourage the use of serializable without even mentioning deadlocks. I guess you won't have deadlocks if your db interprets as serializable as "lock the whole database on transaction start", but that means literally no concurrency whatsoever, which also seems like a grossly irresponsible recommendation. I dunno, maybe I didn't get the memo that the database of the future will be sing…
As mentioned in the post: "There are several ways to achieve [serializability] — such as via locking, validation, or multi-versioning."
Deadlock happens under some, but not all implementations of serializability via locking. There have been several database systems developed in my lab that use locking to achieve serializability, but yet never deadlock. Examples include:
(1) Calvin: http://www.cs.umd.edu/~abadi/papers/calvin-sigmod12.pdf (2) Orthrus: http://www.cs.umd.edu/~abadi/papers/orthrus-sigmod16.pdf (3) PWV: http://www.cs.umd.edu/~abadi/papers/early-write-visibility.p...
Bottom line: serializability does not necessarily mean deadlock. Deadlock can be avoided via non-locking implementations, or even in well-designed locking implementations.
One of the points in the conclusion of the post warrants being reiterated at this point:
"If you find that the cost of serializable isolation in your system is prohibitive, you should probably consider using a different database system earlier than you consider settling for a reduced isolation level."
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#9It seems grossly irresponsible to encourage the use of serializable without even mentioning deadlocks. I guess you won't have deadlocks if your db interprets as serializable as "lock the whole database on transaction start", but that means literally no concurrency whatsoever, which also seems like a grossly irresponsible recommendation. I dunno, maybe I didn't get the memo that the database of the future will be sing…
In postgresql at least, serializable cannot deadlock. It uses predicate locks to provide serializable consistency with high levels of concurrency. You can have serialization failures though.
I'm not too familiar with postgresql, but isn't that serializable snapshot rather than serializable? I'm pretty sure all RDMBs have deadlocks in serializable. But in serialiable snapshot, a transaction doesn't deadlock, but simply fails.
Re: Demystifying Database Systems: An Introduction to Transaction Isolation Levels
#10Earlier quoted context omitted.
In postgresql at least, serializable cannot deadlock. It uses predicate locks to provide serializable consistency with high levels of concurrency. You can have serialization failures though.
I'm not too familiar with postgresql, but isn't that serializable snapshot rather than serializable? I'm pretty sure all RDMBs have deadlocks in serializable. But in serialiable snapshot, a transaction doesn't deadlock, but simply fails.
a transaction system in which its impossible for transactions to ever fail kind of isn't a transaction system.
see above comment from abadid - its entirely possible to impose a global ordering of all transactions either up front or retroactively without admitting deadlocks.