Hi everybody,

I am after a bit of architectural guidance - I have been using Hibernate for quite a while now and am familiar with most of the concepts and patterns.

I have just started a small project using NextApp's Echo2 framework, which is an AJAX-based web application framework.
The framework basically sits somewhere in between a traditional web application with a request/response cycle and a fat-client GUI application. For each user interaction (which could include selecting an entry from a list box, clicking a button, changing text in a text field, etc.), an XmlHttpRequest is issued to the application in the background, and upon response from the server, certain parts of the page displayed in the browser are updated. The main difference to a traditional webapp is that there is a single instance of the application, which is tied to the Http session. This instance contains the complete tree of GUI comopnents, which in turn are tied to the underlying model objects (which, of course, are provided through Hibernate). The main difference to a fat-client GUI app is that each interaction with the application occurs in a different thread, as with a traditional webapp.

Now, for a normal webapp, I would use the Open Session In View pattern, whereas for a GUI app I would create a single session on application startup and use explicit transaction management managing the read/write cycle of the application.

However, none of these approaches seem to work too well - I either end up with the SessionPerUserSession antipattern, or run into problems with lazy initialisation as there are many model objects stored in the Http Session. OpenSessionInView does not work as commonly described, as there are a lot more (very small) requests going back and forth.

What would be th best way to approach this problem? Is the SessionPerUserSession antipattern acceptable in this instance? Or is there a better way to manage the Hibernate session?

I have been thinking about the method described in http://www.hibernate.org/168.html (session-per-application-transaction), which may be applicable - the only problem is that I cannot clearly define the boundaries for an application transaction, as any UI element in a page may initiate a different request, so I do not have a clearly defined request cycle for an application transaction.

Any thoughts on this would be greatly appreciated.

Thanks,
Max