Introduction Having introduced Hibernate explicit locking support, as well as Cascade Types, it’s time to analyze the CascadeType.LOCK behavior. A Hibernate lock request triggers an internal LockEvent. The associated DefaultLockEventListener may cascade the lock request to the locking entity children. Since CascadeType.ALL includes CascadeType.LOCK too, it’s worth understanding when a lock request propagates from a Parent to a Child entity.
Introduction 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: OPTIMISTIC OPTIMISTIC_FORCE_INCREMENT PESSIMISTIC_FORCE_INCREMENT In this post, I am… Read More
Introduction 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.
Introduction 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… Read More
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
Explicit optimistic locking In my previous post, I introduced the basic concepts of Java Persistence locking. The implicit locking mechanism prevents lost updates and it’s suitable for entities that we can actively modify. While implicit optimistic locking is a widespread technique, few happen to understand the inner workings of explicit optimistic lock mode. Explicit optimistic locking may prevent data integrity anomalies when the locked entities are always modified by some external mechanism.