In order to avoid concurrent modifications of the same managed entity, one can use a "version" field, by annotating an integer or timestamp field with the @Version annotation defined by JSR-220.

When about to merge/update such a versioned entity, the entity manager is supposed to check this version field in order to establish if the state of this entity is the last persisted one.
If it is not, a specific exception should be raised to let the caller (i.e. application developer) know that the operation could not be performed due to stale object state (a recoverable case: simply ask the user to re-edit the entity with the last persisted state...).

When using a Hibernate session, you get a StaleObjectStateException in such cases.
In my understanding, I was going to get an OptimisticLockException with a JPA entity manager.

However, when used in J2SE, the EM requires the use of an EntityTransaction.
And, unfortunately, its commit() method is not contractually allowed to throw OptimisticLockException (while the documentation for this exception states that it can be thrown while committing).

How is the caller supposed to determine the fact that the commit failed because of a concurrent modification ?
(Note: Hibernate's JPA implementation conforms to the specification and does not throw OptimisticLockException but a RollbackException whose cause is an StaleObjectStateException)

open a case, I think it makes sense for me to wrap the SOSE into an OLE as the cause of the RollbackException

In the mean time you can flush() manually before your commit, you'll get the OLE

I am getting a similar problem.

Hibernate is not throwing the StaleObjectStateException when I am attcahing the object to the session but it is throwing it when it flushes the session.

I am calling flush() manually to force Hibernate to throw the exception which is working fine but if there is a subsequent flush with in the same session it rethrows the same exception.

Is this the expected behaviour?

The work around I found for this problem is either evict the entity or set the flush mode to NEVER in the handler for StaleObjectStateException.

Shouldnt Hibernate evict the object before throwing the StaleObjectStateException?

where does the subsequent flush comes from? your code?

you should not swallow the exception or mark the transaction as setRollbackOnly()

Regarding the first issue, I fixed it
http://opensource.atlassian.com/projects/hibernate/browse/EJB-248

I am doing a manual flush immediately after attaching the object to the session to force the OLE. But then I want to reshow the form to the user displaying the error message and as part of this process the code might execute queries which inturn might call flush (hence the subsequent flush) and Hibernate is rethrowing the same exception hence I am forced to evict the object.

after an exception, you must discard the session and start again.
In your case using FLushMode.MANUAL might help

Discarding the session is not an easy option because we use open session in view filter and we may get lazy instantiation exceptions with the entities loaded in the discarded session.

I might try setting the flush mode to manual.