How to avoid the Hibernate Query Cache N+1 issue

Introduction I recently answered this question on the Hibernate forum, and since it’s a very good one, I decided to turn it into an article. In this post, we will describe how the N+1 query issue is generated when using the second-level Hibernate Query Cache.

How to cache non-existing entity fetch results with JPA and Hibernate

Introduction Sergey Chupov asked me a very good question on Twitter: My use-case is a search by complex primary key, but the performance test still showed a degrade. I'm now using a query cache instead, which helps, but it doesn't look right to have a separate query for the search by PK. So I'm wondering if there's a better approach — Sergey Chupov (@scadgek) December 29, 2017 In this article, I’m going to show you how to cache null results when using JPA and Hibernate.

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