A beginner’s guide to the Phantom Read 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). 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 Phantom Read 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

This is the third part of the optimistic locking series, and I will discuss how we can implement the automatic retry mechanism when dealing with JPA repositories. You can find the introductory part here and the MongoDB implementation here. JPA requires running the Persistence Context code inside a Transaction, and if our Transaction Manager catches a RuntimeException, it initiates the rollback process. This makes the Persistence Context unusable since we should discard it along with the roll-backed Transaction. Therefore it’s safer to retry the business logic operation when we are not within… Read More

Optimistic locking retry with MongoDB

In my previous post I talked about the benefit of employing optimistic locking for MongoDB batch processors. As I wrote before, the optimistic locking exception is a recoverable one, as long as we fetch the latest Entity, we update and save it. Because we are using MongoDB we don’t have to worry about local or XA transactions. In a future post, I’ll demonstrate how you can build the same mechanism when using JPA. The Spring framework offers a very good AOP support and, therefore, it makes easy implementing an automatic retry mechanism,… Read More

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

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.