transakcja Arjuna JTA niespodziewanie rollbacked

Question

Kiedy sprawdzić logi JBoss Widzę dużo tych błędów

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                  > 

wtedy, gdy próbuję wysłać wiadomość JMS widzę ten błąd:

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 

í podejrzewają, że wycofanie jest konsekwencją poprzedniego błędu. Czy mam rację ? co może spowodować, że transakcja pozostanie w tak zniekształconym stanie?

rozejrzałem się Znalazłem ten wpis: What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . Rozumiem, że niektóre dzienniki transakcji zostały zachowane, ale to nie wyjaśnia, jak rozwiązać problem, który mam teraz.

Answer 1

Widziałem podobne błędy na JBoss 5.1 (przynajmniej drugi, który odnosi się do limitu czasu)

Nie znaleźliśmy rzeczywistej przyczyny, ale jest wysoce prawdopodobne, że jest to spowodowane ze względu na długi transakcji biegania który dostaje "zebrane"

Powodem, dla którego doszliśmy do tego wniosku jest to, że widzieliśmy to w czasach dużego obciążenia i niektóre operacje wymagały długiego czasu.

Używamy PostgreSQL i było wiele połączeń "czekanie w transakcji", które zostały wyczyszczone po zebraniu. Sprawdź limit czasu transakcji w swojej konfiguracji i ustaw wyższą wartość, aby sprawdzić, czy to rozwiązuje problem.

https://community.jboss.org/wiki/TransactionTimeout dotyczy sposobu zarządzania tym ustawieniem.

Answer 2

Generalnie każdy RuntimeException że zostaje wrzucony z zarządzanego been (coś wtryskiwanego że jest owinięty z prokurentem JBoss) i że nie jest oznaczony jako @ApplicationException (rollback = false) spowoduje transakcji wycofać.

Te przypadki są zwykle bardzo łatwe do zauważenia w plikach dziennika.

Limity czasu z drugiej strony są nieco trudniejsze. zobaczysz w pliku dziennika coś w stylu: "Przerwij działanie id -3f57fd2d: e48e: 4cf8de0f: bc wywoływane, gdy wiele wątków jest w nim aktywnych."

Inne połączenia będą nadal działać i zakończy się niepowodzeniem tylko wtedy, gdy próbują uzyskać dostęp do połączenia z bazą danych, otrzymując wyjątek "transakcja jest oznaczona do wycofania".

Answer 3

Otrzymaliśmy podobny błąd, a później dowiedzieliśmy się, że przyczyna miała związek z tym, w jaki sposób tworzymy i postępujemy z naszymi podmiotami. Mieliśmy obiekt nadrzędny z listą obiektów podrzędnych i tworzyliśmy kopie rodziców, a następnie próbowaliśmy dodać nowe dzieci do list. Problemem jednak było to, że wykazy te dziecko zostały oznaczone adnotacją: leniwy załadunku.

@OneToMany (kaskada = CascadeType.ALL, przynieś = FetchType.LAZY ...

który powoduje niepowodzenie hibernacji Aby rozwiązać to mieliśmy rozmowę eksmitować na jednostkę tak, że Hibernate zatrzyma próbuje sprowadzić dzieci kiedykolwiek stworzyliśmy kopie rodzica.

((Session) entityManager.getDelegate()). eksmisji (podmiot eksmitować)

To może nie być rozwiązanie konkretnego problemu, ale mam nadzieję, że pomoże komuś!

Answer 4

Rozwiązujemy problem zwiększający max_prepared_transactions do 100 w pliku postgresql.conf.