org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed

[abid-khan]

This exception is thrown when audited entry contains @manytoone relationship.

Assume below entity

@Audited
@Entity
@Table(name = "user")
public class User  {

         ....

    @Audited
    @NotFound(action = NotFoundAction.IGNORE)
    @ManyToOne
    protected User lastModifiedBy;

        ...
        ...

}

For above entity, revision entry has value of ID for lastModifiedBy. And if I try to access lastModifiedBy, below exception is thrown.

Revisions<Integer, User> revisions = userRepository.findRevisions(user
                .getId());
for (Revision<Integer, User> revision : revisions.getContent()) {
       User revisonEntity = revision.getEntity();
       revisonEntity.getLastModifiedBy().getId()
}

org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed
    at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:168)
    at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:286)
    at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:185)

[odrotbohm]

As long as the code snippet you showed does not run inside a transaction (@Transactional) this is expected behavior. Repository methods close the session/transaction by default. If you want to traverse related entities you either need to create a bigger transaction boundary or eagerly load the related entities.

[abid-khan]

@olivergierke

Already I am calling it with in @transactional block. I have tested with @manytoone(fetch=FetchType.EAGER), this is also not working.

[nealeu]

Often the cause of this is that the @transactional is not getting picked up (such as @EnableTransactionManagement or <tx:annotation-driven missing).

You can confirm that it is behaving correctly by setting logging on org.springframework.transaction.interceptor.TransactionInterceptor to TRACE and look for the method you marked @transactional showing as starting a transaction.

[visusnet]

@abid-khan Please check that the transaction is really open using a debugger. Make sure that the annotated method is not private or called by a method of the same class.

[abid-khan]

@visusnet , @nealeu

If I use TransactionTemplate, it is working properly.

transactionTemplate.execute(new TransactionCallback<User>() {
    ...

   Revisions<Integer, User> revisions = userRepository.findRevisions(user
                .getId());
    for (Revision<Integer, User> revision : revisions.getContent()) {
       User revisonEntity = revision.getEntity();
       revisonEntity.getLastModifiedBy().getId()
    }

   .....

});

[odrotbohm]

Glad to hear it's working for you. Also thanks for the others to chime in!

[deeTEEcee]

in a different case, i had controller -> service -> DAO object using @transactional, but the service object class was autowired rather than the interface, so i never saw that @transactional was not going through the DAO object. (TLDR: didn't know about AOP & non-interface issues. the proxy error would not show up at run-time until i added @transactional to the service method itself)

[ValentinBossi]

As long as the code snippet you showed does not run inside a transaction (@Transactional) this is expected behavior. Repository methods close the session/transaction by default. If you want to traverse related entities you either need to create a bigger transaction boundary or eagerly load the related entities.

@odrotbohm
where can I find the documentation to this statement "Repository methods close the session/transaction by default." ?

[schauder]

The documentation for this is effectively that about transaction management of Spring Framework. Repositories are annotated with @Transactional. So a transaction starts before and ends after every call to a repository, if you don't specify any other transactions with a larger scope.

[kaikun213]

I have a similar problem. Just in my case, I am dealing with Graphql Resolvers, which makes it difficult to expand the Transactional scope.

Similar to the author has tried, I have the property of the entity annotated with @ManyToOne(fetch= FetchType.EAGER), shouldn't that load the entity either way and avoid the lazy exception? @schauder

In my regular queries, this is not an issue, as the entity property is loaded. Only in the introduced revisions. Currently, I use the workaround to initialize them via one field within the method, to later retrieve. (Similar to Hibernate.initialize) E.g.

        revisions
                .map(r -> (MyEntity)r.getEntity())
                .forEach(MyEntity::initMyEntity);

[kaikun213]

In my case I have to explicitly initialize and unproxy the fields which are annotated with fetchType=EAGER in order to prevent the graphql type-matcher to missmatch with the hibernate proxy.

E.g.

    public static <T> T initializeAndUnproxy(T entity) {
        if (entity == null) {
            return null;
        }

        Hibernate.initialize(entity);
        if (entity instanceof HibernateProxy) {
            entity = (T) ((HibernateProxy) entity).getHibernateLazyInitializer()
                    .getImplementation();
        }
        return entity;
    }

And within an entity I call it for the required fields:

    public void initLazyFields() {
        super.initLazyFields();
        setBar(initializeAndUnproxy(getBar()));
    }

During the regular spring-data queries this fields are initialized by default and not only proxied. What am I missing?