Arjuna JTA Transaktion rollbacked unerwartet

Question

Wenn ich überprüfen JBoss logs Ich sehe viele dieser Fehler

2012-03-29 12:01:27,358 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 32, 30, 1--53e2af7c:eff6:4ec11bf7:2e1da4-53e2af7c:eff6:4ec11bf7:2e263d                 > 
2012-03-29 12:01:27,398 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 31, 29, 1--53e2af7c:d397:4e8c1b0e:25b6d-53e2af7c:d397:4e8c1b0e:29d09                  > 

Dann, wenn ich versuche, eine JMS-Nachricht diesem Fehler Ich sehe zu senden:

2012-03-29 12:02:43,778 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.opcerror] [com.arjuna.ats.internal.jta.resources.arjunacore.opcerror] XAResourceRecord.commit_one_phase caught: java.lang.IllegalMonitorStateException 
2012-03-29 12:02:43,778 WARN @ [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'queue/request' - trying to recover. Cause: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state 

I vermute, dass der Rollback eine Konsequenz des vorherigen Fehlers ist. Habe ich recht ? Was könnte dazu führen, dass die Transaktion in einem abgebrochenen Zustand bleibt?

schaut sich um Ich fand diesen Beitrag: What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . Ich verstehe, dass ein Protokoll der Transaktion geführt wurde, aber das erklärt nicht, wie ich das Problem beheben kann, das ich jetzt habe.

Answer 1

Ich habe ähnliche Fehler auf JBoss 5.1 (zumindest die zweite, die zu einem Timeout bezeichnet)

Wir haben nicht die eigentliche Ursache gesehen, aber es ist sehr wahrscheinlich, dass es aufgrund einer langen Lauf Transaktion verursacht wird das wird "geerntet"

Der Grund, warum wir zu dieser Schlussfolgerung kamen, ist, dass wir dies in Zeiten hoher Last gesehen haben und einige Operationen lange brauchen.

Wir verwenden PostgreSQL und es gab viele Verbindungen "warten in der Transaktion", die nach dem Ernten gelöscht werden. Überprüfen Sie das Transaktionszeitlimit in Ihrer Konfiguration und legen Sie einen höheren Wert fest, um festzustellen, ob das Problem dadurch behoben wird.

https://community.jboss.org/wiki/TransactionTimeout behandelt, wie diese Einstellung verwaltet wird.

Answer 2

Im Allgemeinen wird jede RuntimeException, die von einem verwalteten Server ausgelöst wird (etwas injiziert, das mit einem JBoss-Proxy umschlossen ist) und nicht als @ApplicationException (rollback = false) markiert ist, einen Rollback der Transaktion auslösen.

Diese Fälle sind normalerweise sehr einfach in den Protokolldateien zu sehen.

Timeouts auf der anderen Seite sind ein bisschen schwieriger. Sie sehen in der Protokolldatei etwas wie: "Abbruch der Aktions-ID -3f57fd2d: e48e: 4cf8de0f: bc wird aufgerufen, während mehrere Threads darin aktiv sind."

Andere Aufrufe werden weiterhin ausgeführt und schlagen nur fehl, wenn sie versuchen, auf die Datenbankverbindung zuzugreifen und die Ausnahme "Transaktion ist für Rollback markiert" erhalten.

Answer 3

Wir erhielten einen ähnlichen Fehler und fanden später heraus, dass die Ursache damit zu tun hatte, wie wir unsere Entitäten erstellten und handhabten. Wir hatten ein übergeordnetes Objekt mit einer Liste von untergeordneten Entitäten, und wir erstellten Kopien der übergeordneten Elemente und versuchten dann, neue untergeordnete Elemente zu den Listen hinzuzufügen. Das Problem war jedoch, dass diese Kind Listen mit der faulen Laden Annotation markiert wurden.

@OneToMany (Kaskade = CascadeType.ALL, holt = FetchType.LAZY ...

, die nicht verursacht wurde Hibernate zu beheben es hatten wir Anruf evict auf der Einheit, so dass Hibernate, die Kinder zu holen versuchen würde aufhören, wenn wir Kopien der Eltern erstellt.

((Session) entityManager.getDelegate()). evict (entity gewaltsam zu vertreiben)

Dies ist möglicherweise nicht die Lösung für Ihr spezielles Problem, aber hoffentlich hilft es jemandem!

Answer 4

Wir lösen das Problem max_prepared_transactions auf 100 in postgresql.conf-Datei erhöhen.