Arjuna JTA transazioni annullate da una rollback inaspettatamente

Question

Quando controllo i registri JBoss vedo un sacco di quegli errori

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                  > 

Poi, quando si tenta di inviare un messaggio JMS vedo questo errore:

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 sospetto che il rollback sia una conseguenza dell'errore precedente. Ho ragione ? cosa potrebbe causare la transazione di rimanere in uno stato interrotto come questo?

guardandosi intorno ho trovato questo post: What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . Comprendo che alcuni log delle transazioni sono stati mantenuti ma questo non spiega come risolvere il problema che ora ho.

Answer 1

ho visto errori simili su JBoss 5.1 (almeno la seconda, che si riferisce ad un timeout)

Non abbiamo trovato la vera causa, ma è altamente probabile che sia dovuta a causa di una lunga operazione di esecuzione che viene "mietuto"

Il motivo per cui siamo arrivati ​​a questa conclusione è che l'abbiamo visto in momenti di carico elevato e che alcune operazioni richiedevano molto tempo per essere completate.

Usiamo PostgreSQL e c'erano molte connessioni "in attesa di transazione" che vengono cancellate dopo la raccolta. Controllare il timeout della transazione nella configurazione e impostarlo su un valore superiore per vedere se allevia il problema.

https://community.jboss.org/wiki/TransactionTimeout illustra come gestire questa impostazione.

Answer 2

In generale, ogni RuntimeException che viene generata da un stato gestito (qualcosa iniettato avvolto con un proxy JBoss) e che non è contrassegnato come @ApplicationException (rollback = false) causerà il rollback della transazione.

Questi casi sono in genere molto facili da vedere nei file di registro.

I timeout, d'altra parte, sono un po 'più complicati. nel file di registro vedrai qualcosa come: "Interruzione dell'azione id -3f57fd2d: e48e: 4cf8de0f: bc richiamato mentre più thread sono attivi all'interno di esso."

Altre chiamate continueranno a essere eseguite e avranno esito negativo solo quando tenteranno di accedere alla connessione al database, ricevendo l'eccezione "la transazione è contrassegnata per il rollback".

Answer 3

Abbiamo ricevuto un errore simile e in seguito abbiamo scoperto che la causa riguardava il modo in cui stavamo creando e gestendo le nostre entità. Avevamo un oggetto padre con un elenco di entità figli e stavamo creando copie dei genitori e poi cercando di aggiungere nuovi figli agli elenchi. Il problema però era che tali elenchi bambini sono stati segnati con i pigri carico della nota:.

@OneToMany (cascade = CascadeType.ALL, prendere = FetchType.LAZY ...

che provocava hibernate a fallire Per risolvere che avevamo chiamata sfrattare sull'entità in modo che Hibernate dovrebbe smettere di cercare di andare a prendere i bambini ogni volta che abbiamo creato le copie del genitore.

((Session) entityManager.getDelegate()). sfrattare (entità di espellere)

Questa potrebbe non essere la soluzione al tuo particolare problema, ma speriamo che aiuti qualcuno!

Answer 4

Risolviamo il problema aumentando max_prepared_transactions a 100 nel file postgresql.conf.