This question has probably been asked to death, but I have not found an answer yet [at least, not an answer I am happy with ;-)]

Obviously, this has to do with using Spring's Hibernate supporting classed and lazy loading. At typical use case for us is this:

1. Spring Controller handles a request.
2. Tries to retrieve an object from the service layer.
3. The service object manages the transaction and retrieves the object from the DAO.
4. The controller puts the object in the request and passes the request on to a JSP.
5. The JSP attempts to access a lazy-loaded connection of the object and exceptions start flying.

From what I can tell, the Hibernate supporting classes open a Session at the start of a transaction and then close the Session after the transaction - entering and exiting the getFoo() call in the service layer.

Is there a better way? In other (non-Spring apps) we have, we basically create a ThreadLocal Session at the begininng of the web request and close it at the end, via a Filter or something like that. Is this possible in Spring. If I want to do this, do I need to abandon the HibernateDaoSupport class.

The only suggestions I have seen so far is to initialize all the lazy collections within the transaction boundary before returning the object. If that is the case, what good are lazy collections if I eagerly load them everytime?

Thanks.

Ryan

Take a look at the OpenSessionInViewFilter and OpenSessionInViewInterceptor classes in the org.springframework.orm.hibernate.support package.

Joe

Seconding Joe: Use OpenSessionInViewInterceptor when working with Spring's DispatcherServlet, and OpenSessionInViewFilter when working with a different web framework. Both will reuse the same Session across an entire request, automatically letting Spring-managed transactions work with that Session - the business layer does not have to change. As the Session will be open during view rendering, lazy loading will work then.

OpenSessionInViewInterceptor can be registered with a Spring HandlerMapping, via the "interceptors" property. If you just want to apply it to a selection of your controllers, simply split your handler mappings into two: one for all controllers with OpenSessionInViewInterceptor, one for the rest. A Spring DispatcherServlet can work with any number of HandlerMappings (typically explicit SimpleUrlHandlerMappings here).

Note that there can be side effects when applying OpenSessionInViewInterceptor to existing business-level transactions: Without the interceptor, each transaction uses its own Session; with the interceptor, all transactions within a single web request share the same Session. For example:

- You might want to reassociate objects via Session.update: Equal instances must not be loaded in the Session before. But other code has executed on the same Session before here, potentially having loaded such equal instances.

- You might rely on being able to modify a Hibernate-loaded object without persisting the changes, after the transaction that loaded it has finished. This does not apply if further transactions are executed on the same Session - they will flush those changes!

Actually, Spring's "Open Session in View" support is pretty new (1.0 M4), so the question hasn't been asked to death yet ;-) There have been quite a few feature requests in that direction before, though. BTW, Atlassian are using Spring's OpenSessionInViewFilter with WebWork2 on a Spring middle tier in their new product Confluence.

Juergen

Thanks for the reply guys. That is exactly what I was looking for.

<rant>
You ever have one of those days when you come in to work jazzed about trying something new. *This* was that something. I got in a to work a little early and started digging around the Spring API docs to look for the solution you mentioned (I assumed it existed already - I just needed to find it). Before I get started, I get side tracked by a handful of trivial bug fixes to production applications, which is compounded by build problems and my computer sporadically seizing up. This is topped off with two hours of eye-gougingly useless meetings.

The Spring javadocs are still just sitting there like they were at 7:45 this morning :-( Some day are better than others.
</rant>

Ahh - I feel better now. I look forward to plugging in this new functionality *first thing* tomorrow morning.

Ryan