Hi all.

We are looking for one design pattern so we can retrieve an object and some of its childrens (one-to-one, one-to-many or many-to-many objects) before we close the session. If we are using a MVC model and we can't retrieve objects from the view (where session is closed) we need a way to make (in an automatic maner) that lazy objects that are going to be needed later will be touched and retrieved from database. Is there any design pattern to do something like this?

Thanks a lot.

Right now we use PropertyUtils in order to pass in a list of "." deliimited property name to walk the chain of objects before the object is finally passed back to the client.

However, I'd be interested in also hearing a better solution.

Gavin had teased me at one point of having another FetchMode for criteria queries where you could go FetchMode.LOAD_THIS_NOW but I think it fell off the radar again.

You could use the ThreadLocal pattern and an interceptor. THe interceptor (servlet filter) opens a session and sticks it in a static ThreadLocal before executing the filter chain. On the other side of the filter chain, the session is retreived from the static ThreadLocal and closed. Using this pattern in conjunction with RequestDispatcher.forward( "my.jsp" ) from your servlet means that the session is still open in the view (the JSP). If you are doing a Response.sendRedirect( "my.jsp" ) then it won't work the same way; the Filter will catch the JSP and open a session, but it will be a new session, so you will have to re-attach your objects to the session before you can use them in the view (Session.lock( object, LockMode.NONE )).

There are some complications if the "view" portion of your application spans multiple requests (long application transaction), but there are some design patterns on the Wiki that address that.

- Jesse

Well, you're making the assumption that the application is a web based one and I gave my answer with a fat client spin as that's the fun I get to deal with on a daily basis :D

What can be done if the application is based on swing without any application server?

You could create an abstract implementation of EventListener with an abstract execute( ) method (HibernateEventListener). The onWhatever( ) method would open a session and transaction, call perform( ), and then commit/rollback the transaction and close the session, as in the traditional interceptor pattern. All EventListener implementations that deal with Hibernate would extend HibernateEventListener and implement the perform( ) method. Inside the perform( ) method you can instantiate DAOs and perform your business, persistence, and view update logic and trust the underlying onWhatever( ) method(s) to handle the Hibernate concerns.

I've never done Swing development before, but it seems like that would work to approximate a web architecture interceptor pattern.

- Jesse