How does Hibernate READ_ONLY CacheConcurrencyStrategy work
Introduction As I previously explained, enterprise caching requires diligence. Because data is duplicated between the database (system of record) and the caching layer, we need to make sure the two separate data sources don’t drift apart. If the cached data is immutable (neither the database nor the cache is able to modify it), we can safely cache it without worrying about any consistency issues. Read-only data is always a good candidate for application-level caching, improving read performance without having to relax consistency guarantees.
A beginner’s guide to Cache synchronization strategies
Introduction A system of record is the authoritative data source when information is scattered among various data providers. When we introduce a caching solution, we automatically duplicate our data. To avoid inconsistent reads and data integrity issues, it’s very important to synchronize the database and the cache (whenever a change occurs in the system). There are various ways to keep the cache and the underlying database in sync and this article will present some of the most common cache synchronization strategies.
Things to consider before jumping to application-level caching
Introduction Relational database transactions are ACID and the strong consistency model simplifies application development. Because enabling Hibernate caching is one configuration away, it’s very appealing to turn to caching whenever the data access layer starts showing performance issues. Adding a caching layer can indeed improve application performance, but it has its price and you need to be aware of it.
How does Hibernate store second-level cache entries
Introduction The benefit of using a database access abstraction layer is that caching can be implemented transparently, without leaking into the business logic code. Hibernate Persistence Context acts as a transactional write-behind cache, translating entity state transitions into DML statements. The Persistence Context acts as a logical transaction storage, and each Entity instance can have at-most one managed reference. No matter how many times we try to load the same Entity, the Hibernate Session will always return the same object reference. This behavior is generally depicted as the first-level cache. The Hibernate… Read More
JDBC Statement fetchSize property
Introduction In this article, we are going to see how the JDBC Statement fetchSize property works when using Oracle, SQL Server, PostgreSQL, or MySQL. JDBC ResultSet fetching The JDBC ResultSet offers a client-side cursor for fetching the current statement return data. When the statement gets executed, the result must be transferred from the database cursor to the client-side one. This operation can either be done at once or on demand.
How to batch DELETE statements with Hibernate
Introduction In my previous post, I explained the Hibernate configurations required for batching INSERT and UPDATE statements. This post will continue this topic with DELETE statements batching. Domain model entities We’ll start with the following entity model:
How to batch INSERT and UPDATE statements with Hibernate
Introduction JDBC has long been offering support for DML statement batching. By default, all statements are sent one after the other, each one in a separate network round-trip. Batching allows us to send multiple statements in one-shot, saving unnecessary socket stream flushing. Hibernate hides the database statements behind a transactional write-behind abstraction layer. An intermediate layer allows us to hide the JDBC batching semantics from the persistence layer logic. This way, we can change the JDBC batching strategy without altering the data access code. Configuring Hibernate to support JDBC batching is not… Read More
How does CascadeType.LOCK works in JPA and Hibernate
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.
A beginner’s guide to JPA and Hibernate Cascade Types
Introduction In this article, we are going to learn how the JPA and Hibernate Cascade Types work. JPA translates entity state transitions to database DML statements. Because it’s common to operate on entity graphs, JPA allows us to propagate entity state changes from Parents to Child entities. This behavior is configured through the CascadeType mappings.
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
