Currently, it seems that wildfly ignores Synchronization s registered for a transaction which is marked for rollback.
See also WFLY-8542, JCAOrderedLastSynchronizationList, line 70

This causes problems when integrating with Spring, in the scenario where

• An EJB transaction is started
• The EJB calls some Spring code, which uses Spring transaction handling
• A Synchronization is registered via Spring means (Spring's TransactionSynchronizationManager.registerSynchronization() )
• The transaction is marked for rollback by Spring (e.g. by a Spring transaction proxy)

In this case Spring will pass "it's" Synchronization to Widfly/JTA at the demarcation between the JTA and the spring transaction. As at this time the transaction is already marked for rollback, all Synchronization s registerd in the spring transaction will be discarded, leading to possibly missing clean up as afterCompletion() is not called for these.
(See JtaTransactionManager for the Spring part)

Spring handles an exception thrown from registration gracefully / correctly by immediately executing the afterComplection() (see JtaTransactionManager ), but Spring does not expect a "silent fail".

This problem is probably harmless for many projects / scenarios, as typically Synchronization s do work only for the commit. In our case this problem bit us pretty hard, as we were relying on cleanup logic to be executed for rollbacks (as well as commits).
The current "silent fail" behavior also makes this sort of problem very hard to find and analyze.