java - 如何在web层捕获OptimisticLockException

Question

我遇到一个问题，即当 EJB 层引发 OptimisticLockException 时如何在 Web 层(.war 代码)中捕获该异常。

我们正在使用 JEE5、GlassFishV2.1 和 JPA(带有 TopLinks)和容器管理事务。但是，当由于同一实体上另一个并发用户的 trnasaction 导致脏读发生时。它会在 war 层给出 Transaction.RollBackException实际上是由 OptimisticLockException 引起的。但是我无法在 war 方面捕获 OptimisticLockException。

我在网上找到的
http://books.google.com/books?id=fVCuB_Xq3pAC&pg=PA292&dq=OptimisticLockException++Collision+Exception&hl=en&ei=0A6jTI3nN5DQccbO5MAB&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCgQ6AEwAA#v=onepage&q=OptimisticLockException%20%20Collision%20Exception&f=false

在 ejb 端使用 em.flush，然后我们可以捕获一些自定义异常并将其抛出到 war 中。但我认为 em.flush 会刷新所有数据库，这是一个昂贵的操作吗？

try{
   //some enitity
   em.flush()
  }
catch(OptimisticLockException ole){

throw ole;
}

我的意见是不要调用 em.flush，因为 90% 的情况下不会出现 OptimisticLockException，而是在 .war 中捕获 EJBException，然后重试。有更好的选择吗？

尝试{ //一些代码 } 捕获(EJBException 前){

      if (ex.getCausedByException().getCause().toString().
          indexOf("javax.transaction.RollbackException")!= -1){
               // do work
          }     
      }
   }

Answer 1

你可以做任何一个。从技术上讲，flush() 并不是一个昂贵的操作，因为它写入数据库所做的工作不再需要由提交来完成，因此没有额外的数据库访问，并且不会“刷新所有数据库”。不过，flush() 确实有一些开销，更改将计算两次，一次用于刷新，一次用于提交，一次用于提交。根据您的更改策略和托管对象的数量，这确实会产生成本。 Flush还需要将托管对象重新置于跟踪的托管状态，这也有一些成本，但与数据库访问成本相比通常较小。

请注意，在提交期间可能会发生除锁定错误之外的其他错误，因此即使您使用刷新来捕获锁定错误，您仍然需要在 war 中使用代码来处理其他失败原因，因此不要使用刷新，仅进行一般事务失败错误处理可能是最好的解决方案。如果你想对锁定错误做一些特殊的事情，你应该能够在原因链中找到异常，但是在重试操作时要小心，你锁定是有原因的，所以可能应该将错误报告给用户并让他们重试操作。