Как поймать OptimisticLockException на уровне сервлета?

Question

Я использую JPA toplink-essential, создавая веб-приложение REST.

У меня есть сервлет, который находит одно сущность и удаляет его.

Ниже код Я думал, что могу поймать оптимистичное исключение блокировки на уровне сервлета, но его нет! Вместо этого RollbackException выбрасывается, и вот что написано в документации:

Но тогда, когда я вижу журнал NetSE IDE GlassFish, где-то генерируется исключение optimisticLockException. Это просто не попадает в мой код. (мое сообщение для печати в системе не отображается, поэтому я уверен, что его там не будет.)

Я попытался импортировать каждый пакет (по одному в то время, конечно) и протестирован с предложением catch, но оба раза, это не входит в блок catch, хотя ошибка журнала говорит об «оптимистичном исключении».

import javax.persistence.OptimisticLockException; 
import oracle.toplink.essentials.exceptions.OptimisticLockException; 

Так где OptimisticLockException брошено ?????

@Path("delete") 
@DELETE 
@Consumes("application/json") 
public Object planDelete(String content) { 

    try { 
      EntityManager em = EmProvider.getInstance().getEntityManagerFactory().createEntityManager(); 

      EntityTransaction txn = em.getTransaction(); 
      txn.begin(); 
      jObj = new JSONObject(content); 
      MyBeany bean = em.find(123); 

      bean.setVersion(Integer.parseInt(12345)); 
      em.remove(bean); 


      //here commit!!!!! 
      em.getTransaction().commit(); 
     } 
     catch(OptimisticLockException e) { //this is not caught here :(
      System.out.pritnln("here"); 
      //EntityTransactionManager.rollback(txn); 
      return HttpStatusHandler.sendConflict(); 
     } 
     catch(RollbackException e) { 
      return HttpStatusHandler.sendConflict(); 
     } 
     catch(Exception e) { 
      return HttpStatusHandler.sendServerError(e); 
     } 
     finally { 
      if(em != null) { 
       em.close(); 
      } 
     } 

тзд Ошибка:

[TopLink Warning]: 2011.01.28 05:11:24.007--UnitOfWork(22566987) 
--Exception [TOPLINK-5006] 
(Oracle TopLink Essentials - 2.0.1 (Build b09d-fcs (12/06/2007))): 
oracle.toplink.essentials.exceptions.OptimisticLockException 

    [TopLink Warning]: 2011.02.01 08:50:15.095--UnitOfWork(681660)-- 
javax.persistence.OptimisticLockException: Exception [TOPLINK-5006] (Oracle TopLink 
Essentials - 2.0.1 (Build b09d-fcs (12/06/2007))): 
oracle.toplink.essentials.exceptions.OptimisticLockException 

Answer 1

Не 100% уверен, но это может быть, что вы ловли javax.persistence.OptimisticLockException (обратите внимание на пакет), но, как выброшенное исключение oracle.toplink.essentials.exceptions.OptimisticLockException, это не попасться ? Несмотря на то, что имя класса исключений одинаково, они не являются одним и тем же классом.

Answer 2

Я предположил бы, что она брошена в em.getTransaction().commit(); заявлении.

Поскольку java doc of RollbackExceptio п, если сказал:

Метательного поставщик сохраняемости, когда EntityTransaction.commit() терпит неудачу.

Я сильно верю, что это не код, который вы действительно использовать (не компилируется из-за отсутствующего) в строке bean.setVersion(Integer.parseInt(12345);), но я «надежда», что реальный код имеет ту же проблему.

Answer 3

Вы пробовали вызов entityManager.flush(); внутри блока try/catch? Когда JPA сбрасывается, возникает исключение OptimisticLock.

Также вам не нужно совершать транзакцию так, как вы это делали. Вы просто могли бы сделать txn.commit(); вместо em.getTransaction(). commit() ;.

У меня такая же ситуация, когда я могу поймать javax.persistence.OptimisticLockException. В моем случае я сделал конечную точку ReST SSB и ввел менеджера сущностей. Затем я вызываю метод на другой SSB, который также вводится и действует как контроллер для этой части логики бизнес-логики. Этот контроллер выполняет flush() и ловит OLEX и rethrows и ApplicationException, которые конечная точка Rest/SSB ловит и повторяет попытку. Используя этот шаблон, вам также необходимо указать TransactionAttributeType.RequiresNew, чтобы каждая сделанная вами повторная попытка выполнялась в новой транзакции, поскольку OLEX делает недействительным старый.