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
11:34 a.m.
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
[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
3:51 p.m.
The JCAOrderedLastSynchronizationList is intended to guarnatee the ordering
in the JVM so it seems very likely it should be used. I wonder why the
wrapper is not being injected into JPA and JCA?
On 14 November 2018 at 17:34, Scott Marlow <smarlow(a)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.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
3:41 a.m.
On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson <tom.jenkinson(a)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.
Best,
S.
On 14 November 2018 at 17:34, Scott Marlow <smarlow(a)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
>
> [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
4:39 a.m.
On 15 November 2018 at 09:41, Stefano Maestri <smaestri(a)redhat.com> wrote:
On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson <tom.jenkinson(a)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!
Best,
S.
>
> On 14 November 2018 at 17:34, Scott Marlow <smarlow(a)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.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
10:01 a.m.
On 11/15/18 5:39 AM, Tom Jenkinson wrote:
On 15 November 2018 at 09:41, Stefano Maestri <smaestri(a)redhat.com
<mailto:smaestri@redhat.com>> wrote:
On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
<tom.jenkinson(a)redhat.com <mailto:tom.jenkinson@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(a)redhat.com
<mailto:smarlow@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
11:10 a.m.
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(a)redhat.com> wrote:
On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>
>
> On 15 November 2018 at 09:41, Stefano Maestri <smaestri(a)redhat.com
> <mailto:smaestri@redhat.com>> wrote:
>
>
>
> On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
> <tom.jenkinson(a)redhat.com <mailto:tom.jenkinson@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(a)redhat.com
> <mailto:smarlow@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(a)lists.jboss.org <mailto:
wildfly-dev(a)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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
11:33 a.m.
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(a)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(a)redhat.com> wrote:
>
>
> On 11/15/18 5:39 AM, Tom Jenkinson wrote:
> >
> >
> > On 15 November 2018 at 09:41, Stefano Maestri <smaestri(a)redhat.com
> > <mailto:smaestri@redhat.com>> wrote:
> >
> >
> >
> > On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
> > <tom.jenkinson(a)redhat.com <mailto:tom.jenkinson@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(a)redhat.com
> > <mailto:smarlow@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(a)lists.jboss.org <mailto:
> wildfly-dev(a)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(a)lists.jboss.org <mailto:wildfly-dev@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(a)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
12:54 p.m.
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(a)redhat.com <mailto:brian.stansberry@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(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>
>
> On 15 November 2018 at 09:41, Stefano Maestri
<smaestri(a)redhat.com <mailto:smaestri@redhat.com>
> <mailto:smaestri@redhat.com <mailto:smaestri@redhat.com>>>
wrote:
>
>
>
> On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
> <tom.jenkinson(a)redhat.com
<mailto:tom.jenkinson@redhat.com>
<mailto:tom.jenkinson@redhat.com
<mailto:tom.jenkinson@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(a)redhat.com <mailto:smarlow@redhat.com>
> <mailto:smarlow@redhat.com
<mailto:smarlow@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@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
2003
days inactive
2004
days old
7 comments
4 participants
participants (4)
-
Brian Stansberry -
Scott Marlow -
Stefano Maestri -
Tom Jenkinson