[jboss-jira] [JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427414#comment-13427414 ] 

Scott Marlow commented on WFLY-8954:
------------------------------------

>From the output that you have gathered, it appears to me that you have identified an ordering difference between what your application sees on WebLogic versus what you are seeing on WildFly.  

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/java/org/jboss/as/test/compat/jpa/eclipselink] 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


> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
>                 Key: WFLY-8954
>                 URL: https://issues.jboss.org/browse/WFLY-8954
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.Final
>            Reporter: Nuno Godinho de Matos
>            Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)