[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

Scott Marlow smarlow at redhat.com
Thu Nov 15 13:54:43 EST 2018


Hi Brian,

Thanks, I am late to finding the same (verified that 
4fafb7d1387efe924be3ebf2f1b8923ef2be188a worked correctly), just cross 
linked the jiras :)

Scott
On 11/15/18 12:33 PM, Brian Stansberry wrote:
> Sorry, ContextTransactionSynchronizationRegistry is not usable in the 
> way WFLY-11166 contemplated. LocalTransactionContextService wires the 
> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper 
> into the builder object that's meant to drive the 
> org.wildfly.transaction.client stuff but it turns out that object is 
> just discarded, and ContextTransactionSynchronizationRegistry doesn't 
> use it.
> 
> I'll work up a revert commit.
> 
> On Thu, Nov 15, 2018 at 11:10 AM Brian Stansberry 
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> 
>     I suspect this is a bug I introduced in WFLY-11166, which was not
>     meant to change any behavior but perhaps did. I'm having a look.
> 
>     On Thu, Nov 15, 2018 at 10:02 AM Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
> 
> 
> 
>         On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>          >
>          >
>          > On 15 November 2018 at 09:41, Stefano Maestri
>         <smaestri at redhat.com <mailto:smaestri at redhat.com>
>          > <mailto:smaestri at redhat.com <mailto:smaestri at redhat.com>>> wrote:
>          >
>          >
>          >
>          >     On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
>          >     <tom.jenkinson at redhat.com
>         <mailto:tom.jenkinson at redhat.com>
>         <mailto:tom.jenkinson at redhat.com
>         <mailto:tom.jenkinson at redhat.com>>> 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.
>          >
>          >
>          > Hi Scott, I suggest to open a WFLY issue with the details and
>         any
>          > reproducer you can provide - thanks!
> 
>         https://issues.jboss.org/browse/WFLY-11360 asks the question:
> 
>         "
>         Apparently we are doing a JNDI lookup of
>         "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM
>         integration, which means we are using the
>         org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper
> 
>         for Hibernate ORM. Should we also be using the
>         org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper
> 
>         class in other WildFly call sites, instead of
>         org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry?
>         "
> 
>         Responses in the jira are welcome :)
> 
>         Scott
> 
>          >
>          >
>          >     Best,
>          >     S.
>          >
>          >
>          >
>          >         On 14 November 2018 at 17:34, Scott Marlow
>         <smarlow at redhat.com <mailto:smarlow at redhat.com>
>          >         <mailto:smarlow at redhat.com
>         <mailto:smarlow at redhat.com>>> 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.TransactionSynchronizationRegistryWrapper
>          >
>          >             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
>          >             <https://issues.jboss.org/browse/WFLY-11233>
>          >
>          >             [2]
>          > https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA
>          >           
>           <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
>          >             <https://issues.jboss.org/browse/WFLY-11243>
>          >             _______________________________________________
>          >             wildfly-dev mailing list
>          > wildfly-dev at lists.jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>
>         <mailto:wildfly-dev at lists.jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>>
>          > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>          >           
>           <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>          >
>          >
>          >         _______________________________________________
>          >         wildfly-dev mailing list
>          > wildfly-dev at lists.jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>
>         <mailto:wildfly-dev at lists.jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>>
>          > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>          >         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>          >
>          >
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
>     -- 
>     Brian Stansberry
>     Manager, Senior Principal Software Engineer
>     Red Hat
> 
> 
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat


More information about the wildfly-dev mailing list