Hibernate, Tapestry & Lazy loading

[greg johnson]

hi guys,
when using Tapestry, what is the best way keep a hibernate session open for a complete request cycle to allow for lazy loading with HibernateDaoSupport - is the OpenSessionInViewInterceptor the way to go?

eg, after a call to say getHibernateTemplate.find() to get an object with a lazily loaded contained collection, a subsequent attempt to access the contained collection will normally cause a net.sf.hibernate.LazyInitializationException.

the tapestry BaseEngine class already has setupForRequest and cleanupAfterRequest methods that intercept the beginning and end of a request cycle.

an example configuration would be much appreciated as there do not seem to be many example of how to configure the OpenSessionInViewInterceptor.

many thanks,
regards,
greg johnson

[Colin Sampaleanu]

You can indeed use the OpenSessionInViewFilter. I would personally recommend going the extra mile and just making your service interface methods return the appropriate data, by touching any collections that are going to be needed by the view layer. This requires more work up front, but is a clear setup

If you do use the OpenSessionInViewFilter, it's cleanest to use it with the singleSession"="false" setting. In this mode, it is still expected that all data will be assembled by one call down to your transactional service layer, and all the filter is doing is deferring the close. So your service layer would no longer have to touch lazy collections, but you would have problems if you do multiple calls down from the view layer into the service layer and try to combine that data, as there would still be multiple Sessions. However, doing multiple calls like this is not a great idea anyways, as it mixes up data from different transactions.

Regards,

[greg johnson]

thanks colin,
i always prefer to put the work in up front for a better downstream return, so i'll take your first recommendation.
thanks again, regards,
greg johnson

[Colin Sampaleanu]

Well, the filter with the singleSession"="false" is not _that_ bad. Ultimately, if you use it in that mode and ensure that you still call down to just one all encompassing sue-case based transaction, then all you're using it for is as a replacement for the touch, and all write data access is being handled inside one transaciton as it should be. What I consider bad is the mode in which most people use it, with singleSession"="true", and they do multiple calls down into their transactional service layer, mixing and matching data from unrelated transactions.

Colin