问题
A StaleObjectStateException is being thrown in my app instead of OptimisticLockException (as I read I should expect this one) when optimistic concurrency problem occurs in my app. No need to post code, as it's the most basic concurrency problem - wrong version in a timestamp column.
How am I supposed to get OptimisticLockException, not the other one?
回答1:
StaleObjectStateException is thrown when you use straight hibernate API. OptimisticLockException is thrown if you used JPA style hibernate. If this confuses you please read: What's the difference between JPA and Hibernate?
Use try catch block to catch the exception:
try {
// your hibernate operation here
} catch (OptimisticLockException e) {
// do something (eg: inform user update is conflicting)
}
It's worth noting OptimisticLockException occur due to other transaction has updated (hence created newer version of) the object before you got chance to do so. In a UI application it is common to prompt the user whether to overwrite / discard / merge his/her version of the object
回答2:
As of my analysis of Hibernate 3.5.2 (now bit old), I found they sometimes throw OptimisticLockException and sometimes StaleObjectStateException. Batch operations even throw StaleStateException, which is a superclass of StaleObjectStateException, but don't have the entity instance.
It seems to me as an unfinished refactoring, you probably need to catch both and react to both the same way.
来源：https://stackoverflow.com/questions/18176932/staleobjectstateexception-vs-optimisticlockexception