I am currently working on an application that uses Spring Boot and Spring Data (its JpaRepository
interfaces to be precise) together with Hibernate.
One thing I love about Hiberante is its caching feature - when you submit multiple queries that match a particular object, you will get back the same instance of that object on every query execution (with respect to Java's == operator). However, when using Spring Data and JpaRepository
classes, this does not always seem to be the case. For that reason, I assume that there are multiple HibernateSession
instances at work here.
My question therefore is: how does Spring Data handle Hibernate Sessions? When does it open or close them? Is there a way to configure it to use the same session for the entire runtime of my application to make full use of Hibernate's object cache? Is there a reason not to do it that way?
Thanks,
Alan
I think I've found the answer myself. If somebody finds this question, here's my answer.
How does Spring manage Hibernate Sessions?
By default, Spring Boot applies transaction management at the repository level. In this case, when calling a JpaRepository
method (or in general any Repository
method), Spring will:
SessionFactory
to create a new sessionRepository
methodHowever, if you apply @Transactional
to the service class or method, Spring will open the session and the transaction on entry to the service method, and the repository method will be performed within the existing transaction.
What are the consequences?
As a programmer...
@Transactional
on a larger scope than the repository. Caching only works within the same HibernateSession
.@Entity
objects by their Hibernate ID value, rather than by using Java's ==
operator.@OneToMany
reference) in your @Entity
classes (see FetchMode.LAZY
as opposed to FetchMode.EAGER
) are used exclusively within an @Transactional
-annotated methodAlso for reference, the following link has been quite helpful: Multiple Transactions in single session
As with many other aspects of Spring, there is a lot to be gained here, if you are willing to sacrifice direct control over your application.