could not initialize proxy – the owning session was closed

Hibernate proxies can be very handy if you have performance concerns, the idea is to load the objects lazily as proxies and never hit the database. The proxies are initialized meaning fetched from the database when they are first accessed, however life is not so easy:) Whether there is a configured filter-interceptor of spring to manage hibernate sessions or you manually take care of the session’s life cycle, once the session was closed, the proxies attached to that will lead to a proxy initialization error if they are accessed later.

The reason is tricky, a hibernate session is created and some data is loaded to the session as a proxy, later the session is closed without an access to the proxy occurred. Then proxy is decided to be used and accessed, at this point one may get the error “no session or session was closed” since the session which the proxy is attached is “closed”. In order to deal with this situation there are some solutions.

1) Reloading the proxy “before” using it in the new session, this will attach the new proxy to the new session. 

2) Using static method Hibernate.initialize(obj) before the owning session was closed, this will hit the db and replace the proxy with the actual data.

3) Using a Session lock via Session.lock(obj,lockmode), this will reattach the proxy to the new session.

As you see this proxy business isn’t simple as it seems but I belive once you learn how to use them they are the best way to optimize the performance.In the end who has not the need for speed?



4 Responses to could not initialize proxy – the owning session was closed

  1. Akram says:

    Do you have any suggestions on how to setup your first suggestion ?
    1) Reloading the proxy “before” using it in the new session, this will attach the new proxy to the new session.

  2. Anonymous says:

    Proxy objects have their id but their other attributes are not initialized. This id is the db id of the object. So you can reload the object by using hibernate load(Class class, Long id) and get the new proxy.Then you should use the new proxy.This solution is an easy one but I prefer the third one because that one uses the same proxy.

  3. Cybernd says:

    Hmm im glad to read that others try to deal with the proxy issue ;o)

    Mostly i tried to use 3 because its easy to use.
    But my applications complexity growth, so i started to get into troubles with 3.)

    Some of my reportqueries deliver proxies of the same object id. But when i try to lock such a proxy it simple failes, because the session does not allow ambiguous content.

    When i use 1) instead, the errour does not occour, but mostly i need 3) more often to avoid the same lazy proxy errors.

    Would be fine to find some kind of best practice doku, because its not so easy to chose the proper strategy dealing with lazy proxies.

    2) is mostly not ideal, because it loads the data to early into my app.


  4. aheryan says:

    Gosh, it’s awesome. Well, I’d go for (1), as it’ll reload everything from the persistence again. (2) and (3) don’t work in most cases, especially when I have a object within my proxy. But one thing I’m gonna say, YOU SAVED MY DAY!! Thanks a million…

%d bloggers like this: