I am using Hibernate through Spring JPA repository to build my Spring Boot apps. Since the apps will be running on docker in Kubernetes pod with limited resources, I want to have a good sense of how memory is being used by Hibernate for 1st level cache. As far as I understand, 1st level cache is only exist within a session which only spans over 1 request/response (default open-in-view session strategy of spring boot). However, within a request, there are quite a number for Spring JPA repositories being used to fetch data. As I did some tests, I found that when a findAll() is used, I saw one sql query being executed which means the cache was not used. However, when a findById() was used, only the 1st call resulted in a SQL query being executed which means the result was from the cache.
Here is my questions
1/is there a documentation about which query Hibernate will cache the result?
2/is there anyway to limit the cache size ?
3/if there is no reference to the query result, is the cache still valid? For example
BigEntity bigEntity1 = bigEntityRepo.findById(1);//load 1 record, cached it and make bigEntitys refer to the cached objecy
bigEntity1 = null; //now nothing refer to the cached object, it is still valid or being marked for GC
4/if i have to look at the source, which class should i look to understand the impl of 1st level cache
I think you should read a book or tutorial about JPA/Hibernate and the entity lifecycle as it seems you are lacking some basic understanding of the concepts. The persistence context, also referred to as 1st level cache, contains all managed entities that you worked with within a transaction. You can flush the changes you did to these entities and then clear the persistence context or detach individual entities, but in general you shouldn’t be concerned too much about the memory use of that, unless you are loading a lot of data. If you load a lot of data and do so for read-only purposes, you should probably consider using a scrollable result list, but that’s usually not necessary. Either way, a lookup by primary key will always look into the persistence context first so e.g. findById will return an object that is contained in the persistence context, whereas every other query will be executed against the database unless you configure a second level cache provider and enable query caching.
Thank you for answering my question. I have to admit that my knowledge of hibernate is very limited since most of the time I just work with Spring JPA and the amount of data processed in a transaction is small until now. I’ll checkout some document about entity life cycle.
For large datasets (when you dump data to CSV/XLS) it is desirable to work with projections: avoiding N+1 (if it is the case) and loading unnecessary data.
Hibernate JPQL & Spring Data provides conveniences for projections, like you can write select new com.evil.reports.Salary(p.id, p.amount, p.currency) from Payment p in JPQL.
First level cache is associated with session” object. The scope of cache objects is of session. Once session is closed, cached objects are gone forever.