Wie fangen Sie optimisticLockexception auf Servlet -Ebene?

Question

Ich verwende JPA TopLink-Wesentential und baue REST-Web-App.

Ich habe ein Servlet, das eine Entität findet und sie löscht.

Unter dem Code, den ich dachte, ich könnte eine optimistische Ausnahme in der Servlet -Ebene aufnehmen, aber es ist nicht! Stattdessen wird Rollbackexception geworfen, und genau das heißt es in der Dokumentation:

Aber wenn ich dann das NetBean IDE -Glassfish -Protokoll sehe, wird optimisticLockexception geworfen. Es wird einfach nicht in meinem Code gefangen. (Meine Systemdruckmeldung wird nicht angezeigt, sodass ich sicher bin, dass es dort nicht hineingeht.)

Ich habe versucht, jedes Paket (natürlich einzeln) zu importieren und habe mit Catch -Klausel getestet, aber beide Zeit, es geht nicht in den Fangblock, obwohl der Protokollfehler "optimistische Ausnahme" besagt.

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

Also wo die optimisticLockexception geworfen wird ?????

@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();
            }
        }

Fehler MSG:

[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

Nicht zu 100% sicher, aber könnte es sein, dass Sie Javax.Persistence.OptimisticLockexception (Beachten Sie das Paket), aber da die ausgeworfene Ausnahme Oracle.toplink.essentials.exceptions.optimisticLockexception ist, wird es nicht erwischt? Obwohl der Name der Ausnahmeklasse derselbe ist, sind sie nicht die gleiche Klasse.

Answer 2

Ich würde vermuten, dass es in die geworfen wird em.getTransaction().commit(); Aussage.

Weil die Java Doc von Rollbackexception Wenn gesagt:

Vom Persistenzanbieter geworfen, wenn entityTransaction.commit () fehlschlägt.

Ich glaube fest daran, dass dies nicht der Code ist, den Sie wirklich verwenden (er würde aufgrund eines fehlenden) wirklich verwenden bean.setVersion(Integer.parseInt(12345);), aber ich "hoffe", dass der wahre Code das gleiche Problem hat.

Answer 3

Haben Sie versucht, EntityManager.flush () anzurufen? In Ihrem Versuch/Fangblock? Wenn JPA -Spülung ist, wenn die OptimisticLock -Ausnahme ausgelöst wird.

Außerdem müssen Sie die Transaktion nicht so begehen, wie Sie es getan haben. Sie hätten einfach txn.commit () machen können; anstelle von em.gettransaction (). commit ();.

Ich habe eine ähnliche Situation, in der ich Javax.Persistence.OptimisticLockexception fangen kann. In meinem Fall habe ich den Rest Endpunkt zu einem SSB gemacht und den Entitätsmanager injiziert. Ich rufe dann eine Methode auf einem anderen SSB auf, das ebenfalls injiziert wird und als Controller für dieses Stück Biz -Logik fungiert. Dieser Controller führt einen Flush () durch und fängt die Oolex und überarbeitet und applicationException, die der Rest -Endpunkt / SSB fängt und wiederholt. Mit diesem Muster müssen Sie auch sicherstellen, dass TransactionAttribUTetype.RequiresNew so angeben, dass jeder Wiederholung in einer neuen Transaktion auftritt, da der Olex die alte ungültig macht.