> 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<p>Doubt this ever really happened. Can hardly imagine debating serializability in a court of law Oracle v. Google was bad enough.
It 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.<p>I dunno, maybe I didn't get the memo that the database of the future will be single-threaded.
In many real world applications using common databases you do not always need “transaction safety”, in particular when reading data for statistical purposes.<p>Performance gains and not blocking the database for many other readers and writers will in many scenarios outweigh the possibly of reading uncommitted/dirty data.<p>Use:<p>SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED<p>(whether you are are querying from within a transaction or not)<p>and you may be surprised how this may solve many of your performance problems in your application/service.