SOS!!! ARJUNA016083: Can't register synchronization because the transaction is in aborted state

[Sergey Chernolyas]

Hi!

I faced with the exception. Why it occurs? How I can fix it?

I am working on project hibernate ogm for Apache Ignite. If one test failed ... all next tests failed too with the exception. I tried ways that I found by Google.

My narayana version is 5.4.0.Final

My hibernate.properties:

hibernate.ogm.datastore.provider=org.hibernate.ogm.datastore.ignite.impl.IgniteDatastoreProvider
hibernate.show_sql=true
hibernate.ogm.ignite.configuration_class_name=org.hibernate.ogm.datastore.ignite.utils.IgniteTestConfigurationBuilder

// narayana properties
com.arjuna.ats.jta.jtaTMImplementation=com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple
com.arjuna.ats.jta.jtaUTImplementation=com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple
com.arjuna.ats.jta.allowMultipleLastResources=true

Please .... HELP TO US! it is blocks progress of new release preparation.

[Ondrej Chaloupka]

Hi,

there is really not much information from what you provided which could help to understand your issue.

Nevertheless I have two points. But they are both just blind bets.

• the error message ARJUNA016083: Can't register synchronization because the transaction is in aborted state referes to the fact shown in the error message -  there is an active transaction in aborted state. From my testing experience I think the prior test (the failed one) does not clear it's 'environment' propertly. If there is an active transaction and test fails the transaction has to be finished (probably rolled-back). You should use some after test case handler to check the state and rollback.

@After

public void clear() {

  try {

     userTransaction.rollback();

  } catch (Exception ignore) {

  }

}

or check the status first, in way like

if(userTransaction.getStatus() != Status.STATUS_NO_TRANSACTION)

  userTransaction.rollback();

• using com.arjuna.ats.jta.allowMultipleLastResources=true is pretty not safe. It signalizes there are troubles in setup of the test if you need to use this.

Kind regards,

Ondra

[Thomas Jenkinson]

I would further add it may be because your main thread has made slow progress, the transaction has timed out, the transaction has been aborted by the reaper and then your main thread has become unstuck or started to make further progress which results in a sync being (attempted to be) enlisted after TX has already timed out.

[AnupKumar Dey]

The best way around this issue is to actually use XA resources.

The next way around this issue is to remove the transaction altogether.  Setting "com.arjuna.ats.jta.allowMultipleLastResources" to "true" and then enlisting multiple 1pc resources into the transaction essentially cripples the transaction semantics anyway so removing the transaction altogether is not a big step beyond this.  Assuming that's true and assuming you're using container-managed transactions then you can just use the NOT_SUPPORTED transaction attribute.

[Sergey Chernolyas]

A lot of thanks for fast answer!