How do LockModeType.PESSIMISTIC_READ and LockModeType.PESSIMISTIC_WRITE work in JPA and Hibernate
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
How does LockModeType.PESSIMISTIC_FORCE_INCREMENT work in JPA and Hibernate
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.
The best way to use OPTIMISTIC_FORCE_INCREMENT with JPA and Hibernate
Introduction In this article we are going to see what is the best way to use the OPTIMISTIC_FORCE_INCREMENT LockModeType with JPA and Hibernate. 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… Read More
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
A beginner’s guide to transaction isolation levels in enterprise Java
Introduction A relational database strong consistency model is based on ACID transaction properties. In this post we are going to unravel the reasons behind using different transaction isolation levels and various configuration patterns for both resource local and JTA transactions. Isolation and consistency In a relational database system, atomicity and durability are strict properties, while consistency and isolation are more or less configurable. We cannot even separate consistency from isolation as these two properties are always related. The lower the isolation level, the less consistent the system will get. From the least… Read More
A beginner’s guide to database locking and the lost update phenomena
Introduction A database is highly concurrent system. There’s always a chance of update conflicts, like when two concurring transactions try to update the same record. If there would be only one database transaction at any time then all operations would be executed sequentially. The challenge comes when multiple transactions try to update the same database rows as we still have to ensure consistent data state transitions. The SQL standard defines three consistency anomalies (phenomena): Dirty reads, prevented by Read Committed, Repeatable Read and Serializable isolation levels Non-repeatable read, prevented by Repeatable Read… Read More
A beginner’s guide to ACID and database transactions
Introduction Transactions are omnipresent in today’s enterprise systems, providing data integrity even in highly concurrent environments. So let’s get started by first defining the term and the context where you might usually employ it. A transaction is a collection of read/write operations succeeding only if all contained operations succeed. Inherently a transaction is characterized by four properties (commonly referred as ACID): Atomicity Consistency Isolation Durability
Asciidoctor for collaborative book writing
I’ve been searching for the most suitable tools I’d use for my book writing process, and I’ve settled for Asciidoctor. In the first place, I decided to use a markup text language that’s implicitly supported by GitHub, and after reviewing Markdown and Asciidoc, I opted for the latter for it offers a richer syntax.
An open Java Transaction book
We live in a world of both commercial and open-source software, each one having strengths and weaknesses. But when it comes to books, there hasn’t been any noticeable revolution towards embracing new writing methodologies. The current book market shares the same philosophy with commercial software business model. There is a fee for obtaining a book copy, evolution is rather slow and usually, there is a single person carrying all the weight of writing. It’s worth noticing that this model offers only the author’s point of view on a particular subject. Yet, there… Read More
