Vlad Mihalcea - Transactions and Concurrency Control Patterns

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.
Last, I'm going to talk about Concurrency Control strategies used in the Hibernate second-level caching mechanism, which can boost performance without compromising strong consistency.

[@dlrhi573]

thank you very much. excellent talk. essential for backend developers.

[@husnutapan1336]

excellent explanation,thank you Vlad

[@hegdevishwa]

Fantastic talk

[@ruixue6955]

15:34
16:23 2PL - two-phase locking - the first implementation of *concurrency control*

[@alterX2ego]

good stuff

[@sriganeshnagaraj9626]

Great video, I have one doubt:
To prevent the anomolies is using the database transaction isolation levels everywhere sufficient or should the optimistic locking in hibernate as explained in the video be used or is it a combination of both?

[@DaffyDuckzXd]

depending, if you use the strictest transaction isolation level, which covers all the anomalies, then you don't need optimistic locking, but it will be less performant. If you want a higher performance, you can choose a combination between the two solutions

[@jvm-tv]

great content poor presentation skills.

[@karthik8159]

Just a quick one, at 24:50 you said when u delete a row u set the xmax and all transaction ids > 313410 cannot see the record once it has been committed but from the diagram, the last select statement from Alice sees empty result set although her transaction id (313409) is less than Bob's.(313410)
As per what you said Alice should still be able to see the record.