StaleObjectStateException vs OptimisticLockException

Question

A StaleObjectStateException is thrown in my application instead of OptimisticLockException (as I read, I should expect this) when an optimistic concurrency problem occurs in my application. There is no need to send code, as this is the most basic concurrency problem - the wrong version in the timestamp column.

How can I get an OptimisticLockException and not another?

Answer 1

StaleObjectStateException is thrown when using the direct sleeping API. An OptimisticLockException is thrown if you are using JPA hibernation. If this bothers you, please read: What is the difference between JPA and Hibernate?

Use the catch try block to catch the exception:

try { // your hibernate operation here } catch (OptimisticLockException e) { // do something (eg: inform user update is conflicting) } 

It is worth noting that the OptimisticLockException exception occurs because another transaction updated (hence created a new version) the object before you got a chance to do it. The user interface application usually prompts the user to rewrite / reset / merge his / her version of the object

Answer 2

In my analysis of Hibernate 3.5.2 (now a bit old), I found that they sometimes throw an OptimisticLockException , and sometimes a StaleObjectStateException . Batch operations even throw a StaleStateException , which is a superclass of StaleObjectStateException , but does not have an entity instance.

It seems to me that this is incomplete refactoring, you probably need to catch both and react the same way.