Как поймать OptimisticLockException в веб-слое

Question

У меня есть одна проблема, которая заключается в том, как уловить исключение OptimisticLockException в веб-слое (.war-код), когда оно создается слоем EJB.

Мы используем JEE5, GlassFishV2.1 и JPA (с TopLinks) и управляемые контейнером транзакции. Но когда грязное чтение происходит из-за trnasaction другого одновременного пользователя на том же объекте. Он дает Transaction.RollBackException на военном уровне который фактически вызван OptimisticLockException. Но я не могу поймать 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

, что применение em.flush на стороне EJB, а затем мы можем поймать и бросить некоторые пользовательские исключения к войне. но я думаю, что em.flush обновит всю базу данных, это дорогостоящая операция или нет?

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

throw ole; 
} 

Мое мнение не называть em.flush в 90% случаев не будет OptimisticLockException и поймать EJBException в .WAR, а затем повторить его. Есть ли лучший вариант?

попробовать { // некоторый код } улов (EJBException ех) {

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

Answer 1

Вы могли бы сделать что-либо. flush() не является технически дорогостоящей операцией, так как работа, которую он делает в письменной форме в базу данных, больше не должна выполняться фиксацией, поэтому нет дополнительного доступа к базе данных и не «обновляет всю базу данных». flush() имеет некоторые накладные расходы, но изменения будут вычисляться дважды, один раз для флеша и один раз для фиксации, vs один раз с фиксацией. В зависимости от политики изменений и количества управляемых объектов у этого есть стоимость. Flush также должен вернуть управляемые объекты в отслеживаемое управляемое состояние, которое также имеет некоторую стоимость, но, как правило, незначительно по сравнению с стоимостью доступа к базе данных.

Обратите внимание, что во время фиксации могут возникать другие ошибки, кроме ошибки блокировки, поэтому, даже если вы используете флеш, чтобы поймать ошибку блокировки, вам по-прежнему нужен код в вашей войне для обработки других причин сбоя, поэтому не используйте флеш , и просто отсутствие общей обработки ошибок обработки ошибок может быть лучшим решением. Если вы хотите сделать что-то особенное для ошибки блокировки, вы должны быть в состоянии найти исключение в цепочке по цепочке, но будьте осторожны, просто повторите операцию, вы блокируете по какой-либо причине, поэтому, вероятно, сообщите об ошибке и попросите их повторить их работу.