1

If I open a transaction, and put code that is potentially going to throw OLE in a try-catch block, will I have to restart the transaction? My answer is yes, but I can't seem to find any confirmation out there...

My code basically looks like this:

//start a hibernate transaction here
try
{
   //do things that are very likely to throw OLE
}
catch (Exception exc) 
{
   //just log it and do nothing else
}

//do something else that needs a hibernate session here (*)

So when I'm at (*), it looks like I would need to check whether or not the transaction is still active?

4

2 回答 2

1

来自：http ://docs.jboss.org/hibernate/orm/3.3/reference/en/html/transactions.html#transactions-demarcation-exceptions

如果 Session 抛出异常，包括任何 SQLException，立即回滚数据库事务，调用 Session.close() 并丢弃 Session 实例。Session 的某些方法不会使会话保持一致状态。Hibernate 抛出的任何异常都不能被视为可恢复的。通过在 finally 块中调用 close() 确保 Session 将被关闭。

并来自：http ://docs.oracle.com/javaee/6/api/javax/persistence/OptimisticLockException.html

发生乐观锁定冲突时由持久性提供程序抛出。此异常可能作为 API 调用、刷新或提交时的一部分抛出。当前事务（如果一个处于活动状态）将被标记为回滚。

所以是的，你应该关闭会话，然后再试一次。

于 2013-08-14T15:46:11.113 回答
0

这是您可以在 JPA 规范中找到的关于以下内容的摘录OptimisticLockException：

  • 将更改写入数据库时​​会完成版本检查，因此通常会在提交时抛出异常
  • 它总是导致事务被标记为回滚
  • 如果要捕获并处理异常，请调用 flush() 以强制数据库写入更早发生
  • 异常提供了一个 API 来返回导致异常的对象
  • 它通常通过刷新/重新加载过时的对象并重试事务来处理

为了完整起见，这里是规范中相关部分的副本：（
我无法提供具体链接，因为该文档在此处仅提供 .pdf 格式）。

3.4.5 乐观锁异常

当与有效的锁定模式和刷新模式设置一致时，提供程序实现可能会将写入数据库推迟到事务结束。在这种情况下，可能直到提交时间才会发生乐观锁检查，并且可能会在提交的“完成前”阶段抛出 OptimisticLockException。如果应用程序必须捕获或处理 OptimisticLockException，则应用程序应使用 flush 方法来强制发生数据库写入。这将允许应用程序捕获和处理乐观锁异常。

OptimisticLockException 提供了一个 API 来返回导致引发异常的对象。不能保证每次抛出异常时都存在对象引用，但只要持久性提供者可以提供它，就应该提供它。应用程序不能依赖此对象可用。

在某些情况下，当跨越 VM 边界时，将抛出 OptimisticLockException 并被另一个异常（例如 RemoteException）包装。可能在包装的异常中引用的实体应该实现 Serializable 以便编组不会失败。

OptimisticLockException 总是导致事务被标记为回滚。

在新的事务上下文中刷新对象或重新加载对象，然后重试事务是对 OptimisticLockException 的潜在响应。

于 2013-08-14T16:13:31.760 回答