Arquillian TransactionMode.ROLLBACK not working as expected

support
#1

Our setup/objectives:

  • We are using wildfly 8.2.0 Final along with Arquillian setup.
  • We are writing Arquillian tests using transaction extension.
  • We want to create the data using business methods using JPA code, and not using UnitDB(XML, JSON etc).
  • We want the data created for the tests to be rolled back automatically without writing any code to manage the deletions

We found a critical issue when we were trying to create tests with the option @Transactional(TransactionMode.ROLLBACK) using the transaction extension.

It is quite common in our code to find some EJB methods marked with TransactionAttributeType.REQUIRES_NEW.
These methods may called by other EJB methods which may have other TransactionAttributeTypes.

So, Coming back to our test, If a EJB method to be tested in-turn calls another EJB method that’s marked with TransactionAttributeType.REQUIRES_NEW then the data created by this method is stored in the DB and is not rolled back at the end of the test.

It is similar to the issue described in this SO question: http://stackoverflow.com/questions/32348359/arquillian-and-transactionattributetype-requires-new

Do you have a recommendation to solve it? Or is it a known issue?

Thanks.

#2

Technically Arquillian Transaction Extension work on the outer User Transaction. By defining REQUIRES_NEW you’re telling the container to start a new transaction that is bound to the scope of the given method, so depending on the implementation this is either nested or a completely new transaction scope. At this point Arquillian is controlling another transaction, and per say the result you are seeing is expected… doh probably not wanted in all cases. :smile:

On top of my head I’m not sure how Arquillian could bypass this behavior without some deep transaction manager integration. And even if we did have that, it might not be the correct thing to do. For instance, if we avoid committing a REQUIRES_NEW transaction on a EJB sending JMS messages the message is never sent…

I think this is highly tied to how the application behaves what the correct thing to do would be.

One option could be to deploy a ejb-jar.xml that override the Transaction attributes for the REQUIRES_NEW EJB methods where applicable as part of the test Deployment on a case to case basis… ?