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

[Nuno Godinho de Matos (JIRA)]

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

Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 12:14 PM:
-----------------------------------------------------------------------

Hi,

As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from-master

This branch is called:
WFLY-8954-from-master

I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. 
And see where I might be bale to override functionality to what you suggest.


The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.

https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc


Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
                    .doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}

I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper at edacee0 \r\n timeToRunJndiLookup:  0  ms"}}
{panel}

The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect.

Let us see how the fishing goes.

Many thanks.


was (Author: nuno.godinhomatos):
Hi,

As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from-master

This branch is called:
WFLY-8954-from-master

I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. 
And see where I might be bale to override functionality to what you suggest.


The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.

https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc


Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
                    .doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}

I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper at edacee0 "}}
{panel}

Hopefully these jndi lookups within the container are fast.
I have noticed that the MBean server in wildfly, when I clean queus on active MQ is significantly slower than on weblogic. So I am a bit afraid of expensive calls to get resources...
The rest call is taking me 22 ms, on average ... the timing here is too expensive.


Let us see how the fishing goes.

Many thanks.

> 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)