[
https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin....
]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 11:58 AM:
-----------------------------------------------------------------------
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...
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@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.
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...
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
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)