Hi Folks,

I am writing a web application in which users complete a series of forms, each of which contains several fields. We are using Hibernate to persist the state of our model, and since the application is ajax-enabled, the value contained within a field is submitted via an xml http request immediately after the user has de-focussed that field.

Additionally, the application has an event driven action controller that allows actions to be hooked up to fields that appear on the form. For instance, when a use enters their telephone number in a field, an action might be asynchronously kicked off in which that telephone number is added to to a message queue for submission to the telesales department.

Our Hibernate model shares a transaction manager with the action controller. I would like transactions to last for the scope of a single page, so that any actions that have been kicked off as a result of data changing on the form are rolled back, along with the actual form field values, should a user click "cancel".

At the moment we have a long running Hibernate session that spans the entire application. That is to say that a new Hibernate session is created on login, and is closed when the user has completed the application. Hibernate transactions are begun just before a user lands on a page, and are committed once the user has clicked "next" and various bits of post page processing have been completed. Immediately after committing the transaction, another is begun ready for the next page. We therefore always have an open transaction while the user sits on a page.

Unfortunately there are issues with our approach... as you might have expected with long running transactions, we have run into a locking problem. If a user is working on application id '1', navigates to the load page by entering the URL in their address bar and attempts to reload application id '1', they will not be able to do so since that application is locked by the previously opened Hibernate transaction.

What design patterns / strategies do other people use in ajax enabled applications? In the past I've always used open session in view, but clearly that doesn't quite translate to an ajax application like ours. Any suggestions would be appreciated!

Cheers,
Richard.

Hibernate version:
3.2.6

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:
Derby & DB2

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:


Problems with Session and transaction handling?

Read this: http://hibernate.org/42.html

Hi Richard,

I can not direct answer your question. But I'm sure you should have a look at SEAM and it's documentation, because I think what they are doing with long running transactions might be the strategy you are looking for. And, to my knowledge, Seam also supports Ajax.

Thanks for your reply Carlo.

Yes, I've heard good things about Seam, though unfortunately the company I work for are not easily convinced about the uptake of new software! In any case I think our project may be a little too far down the line to consider such a significant architectural change.

I had hoped that one of the long running session patterns with optimistic locking (as mentioned in Hibernate's documentation) might save me, but none of them employ a long running transaction - just a long running session.

The only solution I can think of is to implement our own "cache". We would then revert to using a pattern similar to open session in view, storing up the asynchronously updated field updates in our "cache" before opening a hibernate session/transaction on page transition (as in a regular web app) and committing any outstanding changes. I want to explore some other possibilities first though, if there are any, as I think this would be a significant amount of work.

Cheers,
Richard.

You never want to hold a database transaction open past a page render.

You're on the right track: Use optimistic locking, keep the Hibernate session open. Optimistic locking will behave similarly to a long-running database transaction, just that concurrent modifications will be detected only at commit time.