[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=13457851#comment-13457851 ] 

Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------

Hi Scott,

I have done as recommended.
https://github.com/99sono/wildfly/commit/dd29331a9b0270fcb0e1e3d0f9d6a8119f9ab8d7

You are essentially explaining that the java:jboss/TransactionSynchronizationRegistry is "technically"  more readily available to use than the objects that are (aliased) into the java:comp namespace. Did I understand it correctly?

I will read the instructions on the document and make the pull request.

// NOTE: I have started trying to investigate that problem with eclipselink trying to return a used connection to the connection manager, and the connection manager reporting it has no clue what connection is being returned. I have increased the logging level on "org.jboss.jca.core.tracer.Tracer" - I have the feeling that the connectionmanager.ccm.CachedConnectionManager is somehow losing the reference to the connection. Unfortunately, in a small sample application where I tried to reproduce the firing of the event, oserving the event on new transaction and so on ... everything went out perfectly. Could not make it happen. But based on the log file, I see that the flow of statements: 
{panel}
####2017-09-02 13:18:28,282 ThreadId:321 ALL   connectionmanager.ccm.CachedConnectionManager - registering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl at fdf6032, connection : org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction at 76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}

And later:
{panel}
####2017-09-02 13:18:30,655 ThreadId:321 ALL   connectionmanager.ccm.CachedConnectionManager - unregistering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl at fdf6032, connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction at 76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}
Only appear once each. And it is during this unregister that the blow up happens. So it looks as if in the in between time after the "registering" the connection manager simply lost track of the connection.
I will have to open a JIRA for this, I suppose. I want to investigate it a bit more, but I have very little time avalable to play around this.

I will let you know as soon as the pull request is sent out.

Kindest regards.

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