This feature calls for a mechanism to avoid issues around concurrent access to a JPA EM if a transaction times out. Currently EM cleanup happens in AC callbacks - if those callbacks happen on the application thread there is no issue but if they happen on the reaper thread then it is possible for the EM to be manipulated whilst the application is still using it.

The linked forum thread came up with 4 proposals to handle the problem:

1. Reaper marks transaction as set rollback only: this solution has potentially insurmountable issues (eg JVM1 -> JVM2, JVM1 crashes, txn never gets commit/rollback called on it). In addition it would need to be configurable - some users want the reaper to do the timely rollback;
2. WildFly wraps the TM/TSR and coordinates the running of all Synchronization callbacks. This solution is complex and does the AS have sufficient knowledge to coordinate callbacks correctly. Option 4 below is similar but the decision about what to do and when to do it is left in the hands of the relevant callbacks where the knowlege resides;
3. Start a discussion on the JPA expert group to get certain thread unsafe Synchronization JPA callbacks used by EE container/Persistence providers changed. This is an option for the future;
4. Trigger callbacks when the transaction is disassociated from a thread. For example, detaching any loaded entities and closing the EM can be done when all relevant callbacks, namely the afterCompletion callback (triggered on the reaper thread) and the txn disassociated callback (triggered on the application thread) have been seen.

This JIRA will implement option 4.