Read Committed and Pessimistic Locking in Distributed SQL Databases

Valencia, where, a Kubecon, we got many questions about YugabyteDB compatibility with PostgreSQL
  • one of the users, when writing her new state, will get an error message like “sorry, someone booked the same room since, it was not actually free, bad luck”. Here, with optimistic locking, the transactions work on their initial state and can commit only if there were no concurrent changes on them.
  • optimistic locking is achieved by lock intents, similar to breakable locks, cancelling one transaction in case of conflict, rather than waiting. This, when the probability of conflict stays low, is scalable, because many transactions can happen at the same time. Serializable is the highest isolation level, guaranties no intermediate state anomalies, and is scalable with optimistic locking. This is perfect, but only when your application has adapted its exception handling to receive this kind of serialization error, and retry the transaction. This is not easy to do because you cannot just retry indefinitely. Your code should catch the exception, cancel whatever it did that is not transactional (like saying to the user that a room is free and finally telling her that it was not), wait a bit (like ethernet exponential backoff on collisions), and give up after a few attempts.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Franck Pachot

Franck Pachot

502 Followers

Developer Advocate at Yugabyte, Open Source distributed SQL database 🚀 Also Oracle ACE Director, Oracle Certified Master, AWS Data Hero, OakTable member