Java Persistence API comes with a thorough concurrency control mechanism, supporting both implicit and explicit locking. The implicit locking mechanism is straightforward and it relies on:
- Optimistic locking: Entity state changes can trigger a version incrementation
- Row-level locking: Based on the current running transaction isolation level, the INSERT/UPDATE/DELETE statements may acquire exclusive row locks
While implicit locking is suitable for many scenarios, an explicit locking mechanism can leverage a finer-grained concurrency control.
In my previous posts, I covered the explicit optimistic lock modes:
In this post, I am going to unravel the explicit pessimistic lock modes:
Continue reading “How do LockModeType.PESSIMISTIC_READ and LockModeType.PESSIMISTIC_WRITE work in JPA and Hibernate”
In my previous post, I introduced the OPTIMISTIC_FORCE_INCREMENT Lock Mode and we applied it for propagating a child entity version change to a locked parent entity. In this post, I am going to reveal the PESSIMISTIC_FORCE_INCREMENT Lock Mode and compare it with its optimistic counterpart.
Continue reading “How does LockModeType.PESSIMISTIC_FORCE_INCREMENT work in JPA and Hibernate”
In my previous post, I explained how OPTIMISTIC Lock Mode works and how it can help us synchronize external entity state changes. In this post, we are going to unravel the OPTIMISTIC_FORCE_INCREMENT Lock Mode usage patterns.
With LockModeType.OPTIMISTIC, the locked entity version is checked towards the end of the current running transaction, to make sure we don’t use a stale entity state. Because of the application-level validation nature, this strategy is susceptible to race-conditions, therefore requiring an additional pessimistic lock .
The LockModeType.OPTIMISTIC_FORCE_INCREMENT not only it checks the expected locked entity version, but it also increments it. Both the check and the update happen in the same UPDATE statement, therefore making use of the current database transaction isolation level and the associated physical locking guarantees.
It is worth noting that the locked entity version is bumped up even if the entity state hasn’t been changed by the current running transaction.
Continue reading “How does LockModeType.OPTIMISTIC_FORCE_INCREMENT work in JPA and Hibernate”
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 to commit the Product price change
- Alice transaction is committed without realizing the Product price has just changed
Continue reading “How to fix optimistic locking race conditions with pessimistic locking”