I'm looking at Hibernate for use in a rich-client GUI with long running transactions. I've researched this subject and it points to the session-per-conversation pattern. I have two areas of concern with using this pattern and I want to verify that my concerns are valid and I want some advice on working around them.

Exceptions: If you receive an exception, you're supposed to rollback the transaction and discard the session cache. The discussions on this topic seem to apply to user exceptions as well. For example, if you call a simple setter on a POJO and it throws some type of "value not allowed" exception, must you discard everything?

FlushMode: The advantage of the session-per-conversation approach (from my perspective) is in it's ability to maintain a cache of related objects and their changes over the life of the conversation without holding database connections. If you operate with FlushMode.NEVER during the conversation, you may get invalid query results, especially if joining data. Is this what the documentation means by "stale" data? This seems to be more serious than "stale" data.

Assuming that my concerns are valid, I have the following comments:

The reason for long transactions is to allow user interaction. It would be a huge development savings if this application could operate on the POJOs directly, allowing the user to enter changes and navigate the business data. It seems very natural to check contraints and throw user exceptions from within the POJOs. Likewise, as changes are made, you would expect navigation (queries) to yield the proper results. But based on my research, it doesn't appear that I can use Hibernate in this way. Am I correct? Are there ways to work around these issues?

Thanks,
Glenn

You only need to rollback if Hibernate encounters a situation which results in Hibernate's view of the DB being inconsistent. Essentially, internal Hibernate exceptions, including SQLExceptions. If you throw an user exception before any database changes are made, and if in recovering from that exception you undo any changes to POJOs in hibernate's session cache, then you don't need to clean the hibernate session.

The invalid query results are the stale data being referred to. That is the problem with long application transactions, and it's why so many of us don't use them. If you can handle the potential inconsistencies (e.g. by adopting a simple last-update-is-always-correct policy), then you should be fine with them.

The reason for long transactions is not to allow user interaction. The reason for short transactions is to allow user interaction. The reason for long transactions is developer convenience, and/or modification isolation. Correct user interaction with the database is possible only through very short transactions.

tenwit,

I think you misunderstood my post. If you read it carefully, you will see that I am NOT refering to database transactions when I say long running transaction. I am talking about the session-per-conversation approach which implies many short database transactions that form one "long running user transaction".

Nevertheless, I'm still searching for some insight here. The concept of session-per-conversation is wonderful. However, it sounds like maybe this is either not really useful or only useful for simple dialogs.

Here's some text from the Hibernate manual regarding long conversations (notice they also call this an "application transaction"). Later in the text is a suggestion that the session-per-conversation pattern is a solution to this problem.


Is there anyone out there implementing this session-per-conversation pattern?

I've been considering a switch to this pattern for a while in the current application I've been using. The maintenance of detached objects is starting to become a burden. Let me know how it goes for you.