Арджуна JTA транзакция неожиданно откатилась

Question

Когда я проверяю логи JBoss, я вижу много таких ошибок

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                                                                     >

Затем, когда я пытаюсь отправить сообщение JMS, я вижу эту ошибку:

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

Я подозреваю, что откат является следствием предыдущей ошибки. Я прав ? что может привести к тому, что транзакция останется в прерванном состоянии, как это?

Оглядываясь вокруг, я нашел этот пост: Что вызывает Arjuna 1603 (Не удалось найти новый XAResource для использования для восстановления несериализуемого XAResource) , Я понимаю, что некоторые журналы транзакций были сохранены, но это не объясняет, как исправить проблему, с которой я столкнулся.

Answer 1

В общем, каждое RuntimeException, которое выдается из управляемого объекта (что-то внедренное, обернутое прокси-сервером JBoss) и не помеченное как @ApplicationException (rollback = false), вызывает откат транзакции.

Эти случаи обычно очень легко увидеть в лог-файлах.

Таймауты, с другой стороны, немного хитрее. вы увидите в файле журнала что-то вроде: «Прерывание действия id -3f57fd2d: e48e: 4cf8de0f: bc вызвано, когда в нем активно несколько потоков».

Другие вызовы будут продолжаться и будут прерываться только при попытке доступа к соединению с базой данных, получая исключение «транзакция помечена для отката».

Answer 2

Я видел похожие ошибки на JBoss 5.1 (по крайней мере, вторая ошибка, которая относится к тайм-ауту)

Мы не нашли фактическую причину, но весьма вероятно, что она вызвана из-за длительной транзакции, которая "пожинает"

Причина, по которой мы пришли к такому заключению, заключается в том, что мы видели это во время высокой нагрузки, и для выполнения некоторых операций требовалось много времени.

Мы используем PostgreSQL, и было много подключений, «ожидающих в транзакции», которые очищаются после получения. Проверьте тайм-аут транзакции в вашей конфигурации и установите для него более высокое значение, чтобы увидеть, облегчает ли это проблему.

https://community.jboss.org/wiki/TransactionTimeout описывает, как управлять этим параметром.

Answer 3

Мы получили аналогичную ошибку и позже выяснили, что причина была в том, как мы создавали и обрабатывали наши объекты.У нас был родительский объект со списком дочерних объектов, и мы создавали копии родителей, а затем пытались добавить новых дочерних элементов в списки.Проблема, однако, заключалась в том, что эти дочерние списки были помечены с помощью отложенной загрузки:не удалось. Чтобы исправить это, у нас был вызов evict для объекта, чтобы Hibernate прекратил попытки извлекать дочерние элементы при создании копий родительского объекта.

((Session) entityManager.getDelegate ()). evict (entityвыселить)

Возможно, это не решение вашей конкретной проблемы, но, надеюсь, это кому-нибудь поможет!

Answer 4

Мы решаем проблему увеличения max_prepared_transactions до 100 в файле postgresql.conf.