This is a fairly general question involving the use of optimistic locking. The way my middle works is that I manage a home-grown "Session" that spans the lifetime of a typical user request. That in turn manages a Hibernate session/transaction. Within a session I perform operations against the ORM of arbitrary complexity and commit the Hibernate transaction at the end of the request. This removes the need for my business "action" classes to handle starting and committing transactions. Now, for some types of requests it is sometimes it is necessary to commit changes to the database in the middle of the request, so that I know for sure the transaction will not be rolled back before completing further operations. My use of optimistic locking (via the version mapping element) ensures that subsequent operations will be correct as long as the transaction properly committed.

There are two ways I can think of to handle this. I can commit the transaction and begin a new one during a single Hibernate session to handle subsequent operations, or I can call Session.flush(). Either one will generate the correct Hibernate exception if the version of an object has been incremented by another transaction. However, I am not certain that flushing changes actually guarantees that a transaction running on another server could not commit changes between the time that I flush and the time that I commit on the current server.

How would you handle this? Should I commit changes and begin a new transaction? Or is flushing sufficient? Or is there a common design pattern for handling this type of situation?

Thanks

Kevin

Your flush won't commit the transaction, but only ensure that you have hit the database with the data that is in the Hibernate cache.

This is a tricky scenario, but not uncommon. I've tackled this in a similar way, just as you mentioned with closing and opening, but it just didn't feel elegant.