EJBTransactionRolledbackException der gelegentlich Auftritt, auf @Asynchronen Funktion

Ich bin mit Java 1.6.0_23 und Glassfish 3.1.1. Ich habe zwei Singleton-EJBs. Man ist mit dem TimerService Feuer das @ - Timeout-Funktion. Während der @Timeout, @Asynchrone Funktion aufgerufen, in der anderen Singleton-EJB. Es funktioniert 95% der Zeit ohne Fehler. Aber die anderen 5% der Zeit, wenn die @Asynchrone Funktion aufgerufen wird, bekomme ich die folgende Fehlermeldung mit keine Beweise, dass Sie sogar angefangen, die @Asynchrone Funktion. Keine andere Fehlerinformationen werden protokolliert.

Irgendwelche Ideen?

PS: ich habe versucht, die Erhöhung der maximalen Anzahl von EJBs in Glassfish von 32 auf 64. Keine änderung.

java.util.gleichzeitige.ExecutionException: javax.ejb.EJBTransactionRolledbackException 
bei com.Sonne.ejb.Container.EjbAsyncTask.call(EjbAsyncTask.java:132) ~[ejb-container.jar:3.1.1] 
bei java.util.gleichzeitige.FutureTask$Sync.innerRun(FutureTask.java:303) ~[na:1.6.0_23] 
bei java.util.gleichzeitige.FutureTask.run(FutureTask.java:138) ~[na:1.6.0_23] 
bei java.util.gleichzeitige.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_23] 
bei java.util.gleichzeitige.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_23] 
bei java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_23] 
Verursacht durch: javax.ejb.EJBTransactionRolledbackException: null 
bei com.Sonne.ejb.Container.BaseContainer.mapLocal3xException(BaseContainer.java:2305) ~[ejb-container.jar:3.1.1] 
bei com.Sonne.ejb.Container.BaseContainer.postInvoke(BaseContainer.java:2088) ~[ejb-container.jar:3.1.1] 
bei com.Sonne.ejb.Container.EjbAsyncTask.call(EjbAsyncTask.java:114) ~[ejb-container.jar:3.1.1] 
... 5 gemeinsame frames ausgelassen 
Verursacht durch: javax.ejb.TransactionRolledbackLocalException: Client-Transaktion abgebrochen 
bei com.Sonne.ejb.Container.BaseContainer.useClientTx(BaseContainer.java:4699) ~[ejb-container.jar:3.1.1] 
bei com.Sonne.ejb.Container.BaseContainer.preInvokeTx(BaseContainer.java:4577) ~[ejb-container.jar:3.1.1] 
bei com.Sonne.ejb.Container.BaseContainer.preInvoke(BaseContainer.java:1910) ~[ejb-container.jar:3.1.1] 
bei com.Sonne.ejb.Container.EjbAsyncTask.call(EjbAsyncTask.java:99) ~[ejb-container.jar:3.1.1] 
... 5 gemeinsame frames ausgelassen

InformationsquelleAutor mauman | 2011-09-08

  1. 1

    Müssen Sie sich nach anderen Fehlern, die passiert ist, bevor dieser eine (vielleicht verschluckt Ausnahmen, da Sie sagte, es gibt keine anderen Fehler). EJBTransactionRolledbackException tritt auf, wenn die aktuelle trx markiert wurden, für die ein rollback, und du bist immer noch Dinge tun, auf die DB.

    Ich doppelt überprüft. Die ich finden konnte, keine anderen Ausnahmen in meinen logs. Jeder catch() ein logging-Anweisung zu. Auch diese EJBTransactionRolledbackException Ausnahme erscheint unverzüglich zu erfolgen (4 Millisekunden tops) nach dem Aufruf der @Asynchrone Funktion in der 2. EJB und nicht zu warten, für jede Datenbank-Verbindung.
    ist es möglich, halten Sie einen Verweis auf den entitymanager? es ist wichtig, um es container-managed durch Injektion.
    Ich bin in der Tat je nach der Injektion: PersistenceContext(unitName = "myPersistenceUnit") private EntityManager em; ... und niemals über eine factory zum erstellen der entitymanager, oder etwas ähnliches.
    sorry, kann nicht vorschlagen, nichts mehr mit der zur Verfügung gestellten Informationen. Ich habe gesehen, diese Ausnahme, unter solchen Umständen, z.B. bei einer em war wiederverwendet in einem nicht-jee-konforme Art und Weise. Sie könnte einfach der Umgang mit einem container bug. 🙁
    Ganz sicher, es ist ein server-defekt-hier: auch wenn es wahrscheinlich verursacht durch etwas anderes, eine fehlerhafte Transaktion irgendwie ist verbunden, um einige http-thread. Überprüfen Sie Ihre Protokolle: es werden wahrscheinlich immer wieder passieren, auf die gleiche http-worker-thread. Wenn Sie die Größe der http-thread-pool, es wird wieder aufgebaut werden und das problem wird Weg sein (bis es wieder kommt). Habe das in ein paar Situationen (aber es war immer einer vorhergehenden Ursache.

    InformationsquelleAutor alvi

  2. 1

    Passiert mir auch.
    Scheint, das problem ist nicht ein coding problem, aber die server-Ressourcen.

    Ich erhöhte die http-thread-pool Größe
    Es war max 5 für mich und ich habe ihn an 10

    Scheint das problem behoben.

    Auch einige Hinweise auf diesen Fehler hier:
    http://pcjuzeren.blogspot.co.il/2008/12/clients-transaction-aborted.html

    InformationsquelleAutor Ronen Morecki

Schreibe einen Kommentar