Transactions and Concurrency Control Patterns by Vlad Mihalcea

Transactions and Concurrency Control are very of paramount importance when it comes to enterprise systems data integrity.
However, this topic is very tough since you have to understand the inner workings of the database system, its concurrency control design choices (e.g. 2PL, MVCC), transaction isolation levels and locking schemes.
In this presentation, I'm going to explain what data anomalies can happen depending on the transaction isolation level, with references to Oracle, SQL Server, PostgreSQL, and MySQL.
I will also demonstrate that database transactions are not enough, especially for multi-request web flows.
For this reason, I'm going to present multiple application-level transaction patterns based on both optimistic and pessimistic locking mechanisms.

[@pajotrus]

this talk should be essential to watch for every backend developer. I love when the talks are structured like this when you gradually introduce more complexity, but you can actually understand why it was needed. 10/10

[@elbozo5723]

the man the myth the legend. anyone who's ever touched hibernate before has seen this man's answers on stack overflow

[@loirenhuh]

Performance and Hibernate, thats crazy)

[@sakcee]

Thank you, excellent explanation

[@leozilla]

at 26:26 he says that "lost update can happen even with serializability". Thats not correct.

[@vladmihalcea]

Yes, it is possible. I'm talking about multi-request logical transactions that span over multiple Http requests and multiple DB physical transactions.
Check out this article for more details:
vladmihalcea.com/2014/09/22/preventing-lost-updates-in-long-conversations/

[@vladmihalcea]

Read and Write Skew are a different class of anomalies that are prevalent in MVCC-based systems since the write lock is only held for a single tuple.
Anyway, all these anomalies were meant to be prevented in the scope of a single physical DB transaction: the 2 tier-based approach used by Mainframes in the 70's.
Internet and web-based application have changed the way we interact with data since now we use 3-tier architectures and a web-flow can span over multiple web requests, hence multiple database transactions.
That's why Serializable is not enough.

[@Tom1m1m1m3k]

Spanner is a joke (or used to be - at least a year ago, I have not used it since)