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.
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… ?