A beginner’s guide to the Write Skew anomaly, and how it differs between 2PL and MVCC
Introduction Unlike SQL Server which, by default, relies on the 2PL (Two-Phase Locking) to implement the SQL standard isolation levels, Oracle, PostgreSQL, and MySQL InnoDB engine use MVCC (Multi-Version Concurrency Control), so handling the Write Skew anomaly can differ from one database to the other. However, providing a truly Serializable isolation level on top of MVCC is really difficult, and, in this post, I’ll demonstrate that it’s very difficult to prevent the Write Skew anomaly without resorting to pessimistic locking.
How to fix optimistic locking race conditions with pessimistic locking
Recap In my previous post, I explained the benefits of using explicit optimistic locking. As we then discovered, there’s a very short time window in which a concurrent transaction can still commit a Product price change right before our current transaction gets committed. This issue can be depicted as follows: Alice fetches a Product She then decides to order it The Product optimistic lock is acquired The Order is inserted in the current transaction database session The Product version is checked by the Hibernate explicit optimistic locking routine The price engine manages… Read More
How to address the OptimisticLockException in JPA and Hibernate
Introduction Application-level repeatable reads are suitable for preventing lost updates in web conversations. Enabling entity-level optimistic locking is fairly easy. You just have to mark one logical-clock property (usually an integer counter) with the JPA @Version annotation and Hibernate takes care of the rest. The catch Optimistic locking discards all incoming changes that are relative to an older entity version. But everything has a cost and optimistic locking makes no difference. The optimistic concurrency control mechanism takes an all-or-nothing approach even for non-overlapping changes. If two concurrent transactions are changing distinct entity… Read More
How does Hibernate guarantee application-level repeatable reads
Introduction In my previous post I described how application-level transactions offer a suitable concurrency control mechanism for long conversations. All entities are loaded within the context of a Hibernate Session, acting as a transactional write-behind cache. A Hibernate persistence context can hold one and only one reference to a given entity. The first level cache guarantees session-level repeatable reads. If the conversation spans over multiple requests we can have application-level repeatable reads. Long conversations are inherently stateful so we can opt for detached objects or long persistence contexts. But application-level repeatable reads… Read More
The data knowledge stack
Concurrency is not for the faint-hearted We all know concurrency programming is difficult to get it right. That’s why threading tasks are followed by extensive design and code review sessions. You never assign concurrent issues to inexperienced developers. The problem space is carefully analyzed, a design emerges and the solution is both documented and reviewed. That’s how threading related tasks are usually addressed. You will naturally choose a higher level abstraction since you don’t want to get tangled up in low-level details. That’s why the java.util.concurrent is usually better (unless you build… Read More
How to retry JPA transactions after an OptimisticLockException
Introduction In this article, I will discuss how we can implement an automatic Retry mechanism when dealing with the JPA OptimisticLockException. You can find the introductory part here and the MongoDB implementation here.
Optimistic locking retry with MongoDB
As I explained this article, there are many benefits of employing optimistic locking for MongoDB batch processors. The Spring framework offers very good AOP support and, therefore, makes it easy to implement an automatic retry mechanism that we can use for optimistic locking.
MongoDB optimistic locking
Introduction When moving from JPA to MongoDB you start to realize how many JPA features you’ve previously taken for granted. JPA prevents “lost updates” through both pessimistic and optimistic locking. Optimistic locking doesn’t end up locking anything, and it would have been better named optimistic locking-free or optimistic concurrency control because that’s what it does anyway. Lost updates So, what does it mean to “lose updates”? A real-life example would be when multiple background tasks update different attributes of some common Entity. In our example, we have a Product Entity with a quantity and… Read More
Lock processing logic by customer
Introduction In the current application we are developing there was one use case where we wanted to synchronize message processing by message provider (customer generating those messaging). The flow looks something like this: So messages may come randomly since there are more customer jobs running in parallel, but we want to ensure that messages belonging to the same customer are processed one after the other (analog to the Serializable database isolation level) while allowing messages coming from different customers to be processed in parallel.
