transacción Arjuna JTA rollback inesperadamente

Question

Cuando compruebo los registros de JBoss veo un montón de esos errores

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                  > 

entonces, cuando intento enviar un mensaje JMS veo este error:

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 sospecha que la reversión es una consecuencia del error anterior. ¿Estoy en lo cierto? ¿Qué podría hacer que la transacción permanezca en un estado abortado como este?

mirando alrededor Encontré este post: What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . Entiendo que se ha guardado algún registro de transacción, pero esto no explica cómo solucionar el problema que tengo ahora.

Answer 1

he visto errores similares en JBoss 5.1 (por lo menos el segundo que se refiere a un tiempo de espera)

No se encontró la causa real, pero es muy probable que es causada debido a una transacción de larga ejecución que se "cosechó"

La razón por la que llegamos a esta conclusión es que vimos esto en momentos de gran carga y algunas operaciones tardaron mucho en completarse.

Utilizamos PostgreSQL y había muchas conexiones "esperando en transacción" que se borraron después de la cosecha. Compruebe el tiempo de espera de la transacción en su configuración y configúrelo en un valor más alto para ver si alivia el problema.

https://community.jboss.org/wiki/TransactionTimeout explica cómo administrar esta configuración.

Answer 2

En general, cada RuntimeException que se lanza desde un estado gestionado (algo inyectado que se envuelve con un proxy JBoss) y que no está marcado como @ApplicationException (rollback = false) hará que la transacción se retrotraiga.

Estos casos suelen ser muy fáciles de ver en los archivos de registro.

Los tiempos de espera, por otro lado, son un poco más complicados. Verá en el archivo de registro algo así como: "Anulación de la acción id -3f57fd2d: e48e: 4cf8de0f: bc invocada mientras múltiples hilos están activos dentro de ella".

Las demás llamadas continuarán ejecutándose y solo fallarán cuando intenten acceder a la conexión de la base de datos, recibiendo la excepción "La transacción está marcada para la reversión".

Answer 3

Recibimos un error similar y luego descubrimos que la causa tenía que ver con la forma en que creábamos y manejábamos nuestras entidades. Tuvimos un objeto principal con una lista de entidades secundarias y estábamos creando copias de los padres y luego intentamos agregar nuevos hijos a las listas. El problema sin embargo es que esas listas niños fueron marcados con los perezosos anotación de carga:.

@OneToMany (cascada = CascadeType.ALL, fetch = FetchType.LAZY ...

que estaba causando a fallar hibernación Para solucionar que tuvimos que desalojar llamada en la entidad de manera que Hibernate podría dejar de intentar buscar a los niños siempre que creamos copias de los padres.

((Sesión) entityManager.getDelegate()). evict (entidad a desalojar a)

Puede que esta no sea la solución a su problema en particular, ¡pero con suerte puede ayudar a alguien!

Answer 4

Resolvemos el problema aumentando max_prepared_transactions a 100 en el archivo postgresql.conf.