StaleObjectStateException与OptimisticLockException [英] StaleObjectStateException vs OptimisticLockException

问题描述

在我的应用程序中出现乐观并发问题时，我的应用程序中抛出StaleObjectStateException，而不是OptimisticLockException（正如我所看到的那样）。不需要发布代码，因为它是最基本的并发问题 - 时间戳列中的错误版本。

我应该如何获取OptimisticLockException，而不是另一个？ / p>

解决方案

当您使用直接的hibernate API时，会抛出StaleObjectStateException异常。如果您使用JPA风格的hibernate，则会抛出OptimisticLockException异常。如果这让您感到困惑，请阅读： JPA和Hibernate之间有什么区别？

使用try catch块来捕获异常：

  try {
 //你的hibernate操作这里
} catch（OptimisticLockException e）{
 //做某事（例如：通知用户更新冲突）
} 
 <值得注意的是，由于其他事务在您有机会进行更新（因此创建较新版本的）对象之前，会发生OptimisticLockException异常。 。在UI应用程序中，通常提示用户是否覆盖/放弃/合并他/她的对象版本
 
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?
解决方案
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

                        
这篇关于StaleObjectStateException与OptimisticLockException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！