[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-8954: ------------------------------------ Just to summarize what you posted above, on WildFly, after clicking on the web page to to trigger event B, we first see the CDI observers event getting hit. Then, org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeChangesIntoParent() is reached. Then the second JTA transaction is reached (for the second call to org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeChangesIntoParent()). [https://javaee.groups.io/g/jpa-spec/message/8] may also be relevant to this discussion. For issues like this, it may be better to start with a discussion on [https://developer.jboss.org/en/wildfly?view=discussion], as it is not yet clear exactly as to what the root issue is and it may of helped to have more input from others. At this point, since we are still not yet understanding the exact root cause and solution, it might be okay to keep the discussion going here for now, until it is a little more focused on the root issue. Having said that, some possible outcomes (or paths forward) might be: # Arrange for EclipseLink afterCompletion to run before to CDI EJB observers, so that the EclipseLink second level cache is cleared. # Or determine that the application is assuming too much about which occurs first, the CDI EJB observers or the EclipseLink clearing of the second level cache. I'm not yet personally on this path but would like to consider that this may be the outcome, from the point of view of the involved standards (Java EE, CDI, JPA, JTA). I already have looked in the latest EclipseLink source and see that it is not using the TransactionSynchronizationRegistry to register its Synchronization. We need to verify whether the CDI EJB observers on WildFly, are using TransactionSynchronizationRegistry (perhaps setting a breakpoint in org.jboss.weld.event.TransactionalObserverNotifier.notifyTransactionObservers and see if TransactionSynchronizationRegistry is being used.) Perhaps the code is elsewhere that needs to be checked, I'm not 100% sure yet. I wonder if [https://github.com/wildfly/wildfly/tree/master/testsuite/compat/src/test/...] could be updated to recreate the same issue (EclipseLink second level cache updating and CDI observer events). Thank you for discussing this issue, definitely an interesting one! Regards, Scott -- This message was sent by Atlassian JIRA (v7.2.3#72005)