Re: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper

On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson <tom.jenkinson(a)redhat.com&gt; wrote: > The JCAOrderedLastSynchronizationList is intended to guarnatee the > ordering in the JVM so it seems very likely it should be used. > +1 > I wonder why the wrapper is not being injected into JPA and JCA? > I don't see any reason in fact. And I don't remember any issues or discussion specific to this.

Best, S. > > On 14 November 2018 at 17:34, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > >> Hi, >> >> I made a local change to JCAOrderedLastSynchronizationList, to have the >> JPA container (TransactionUtil$SessionSynchronization) >> afterCompletion() >> always be run after Hibernate afterCompletion() but before the JCA >> afterCompletion(). As I am implementing EntityManager caching [1] and >> want to ensure that the EntityManager instances are only returned to the >> cache after the EntityManager is expected to be available for reuse. >> >> In my debugging, I noticed that the JCAOrderedLastSynchronizationList >> only has the Hibernate synchronizations being added but not the JCA or >> JPA container synchronizations. [2] shows that the JCA + JPA >> Synchronizations are registered via >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> >> and Hibernate ORM Synchronization is registered via the >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegi >> stryWrapper >> >> Should >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> >> be changed to use JCAOrderedLastSynchronizationList as well, so that >> IronJacamar (JCA) Synchronizations are run in the correct order? >> >> Should we change the JPA subsystem/container to also ensure that >> Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry >> instead of the >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? >> >> >> >> Is there a WildFly service that represents the >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> >> lifecycle? The JPA persistence unit service (or global JPA service) >> should depend on that service, so that applications undeploy if the TSR >> is stopped. >> >> [3] is also related to the the [1] effort and would be impacted by the >> above mentioned changes. >> >> Scott >> >> [1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233 >> >> [2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA >> >> [3] Ensure that Hibernate uses direct reference to TSR for better >> performance https://issues.jboss.org/browse/WFLY-11243 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev