10

When I check JBoss logs I see a lots of those errors

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                                                                     >

Then, when I try to send a JMS message I see this 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 suspect the rollback to be a consequence of the previous error. Am I right ? what could cause the transaction to remain in an aborted state like this ?

looking around I found this post : What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . I understand that some log of transaction have been kept but this does not explains how to fix the issue I now have.

Community
  • 1
  • 1
Olivier.Roger
  • 4,241
  • 5
  • 40
  • 68

4 Answers4

3

In general, every RuntimeException that gets thrown from a managed been (something injected that is wrapped with a JBoss proxy) and that is not marked as an @ApplicationException(rollback = false) will cause the transaction to rollback.

These cases are usually very easy to see in the log files.

Timeouts on the other hand, are a bit trickier. you will see in the log file something like: "Abort of action id -3f57fd2d:e48e:4cf8de0f:bc invoked while multiple threads active within it."

Other calls will continue to run and will fail only when they try to access the database connection, receiving the "transaction is marked for rollback" exception.

Doron Manor
  • 576
  • 4
  • 5
2

I have seen similar errors on JBoss 5.1 (at least the second one which refers to a timeout)

We did not find the actual cause but it is highly likely that it is caused due to a long running transaction that gets "reaped"

The reason we came to this conclusion is that we saw this at times of high load and some operations were taking a long time to complete.

We use PostgreSQL and there were a lot of connections "waiting in transaction" which get cleared after the reaping. Check the transaction timeout in your configuration and set it to higher value to see if it alleviates the problem.

https://community.jboss.org/wiki/TransactionTimeout covers how to manage this setting.

drone.ah
  • 1,135
  • 14
  • 28
1

We were receiving a similar error and later found out that the cause had to do with how we were creating and handling our entities. We had a parent object with a list of children entities and we were creating copies of the parents and then trying to add new children to the lists. The problem though was that those child lists were marked with the lazy loading annotation:

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

which was causing hibernate to fail. To fix it we had call evict on the entity so that Hibernate would stop trying to fetch the children whenever we created copies of the parent.

((Session) entityManager.getDelegate()).evict(entity to evict)

This may not be the solution to your particular problem, but hopefully it helps someone!

Alex Schultz
  • 39
  • 6
-2

We solve the issue increasing max_prepared_transactions to 100 in postgresql.conf file.

user3838497
  • 1