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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

Tom Jenkinson
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

Stefano Maestri


On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

Tom Jenkinson


On 15 November 2018 at 09:41, Stefano Maestri <[hidden email]> wrote:


On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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


On 11/15/18 5:39 AM, Tom Jenkinson wrote:

>
>
> On 15 November 2018 at 09:41, Stefano Maestri <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
>     <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>         <mailto:[hidden email]>> 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
>             [hidden email] <mailto:[hidden email]>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

Brian Stansberry
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 <[hidden email]> wrote:


On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>
>
> On 15 November 2018 at 09:41, Stefano Maestri <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
>     <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>         <mailto:[hidden email]>> 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
>             [hidden email] <mailto:[hidden email]>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

Brian Stansberry
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 <[hidden email]> 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 <[hidden email]> wrote:


On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>
>
> On 15 November 2018 at 09:41, Stefano Maestri <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
>     <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>         <mailto:[hidden email]>> 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
>             [hidden email] <mailto:[hidden email]>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
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
> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>
>
>         On 11/15/18 5:39 AM, Tom Jenkinson wrote:
>          >
>          >
>          > On 15 November 2018 at 09:41, Stefano Maestri
>         <[hidden email] <mailto:[hidden email]>
>          > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>          >
>          >
>          >
>          >     On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson
>          >     <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> 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
>         <[hidden email] <mailto:[hidden email]>
>          >         <mailto:[hidden email]
>         <mailto:[hidden email]>>> 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
>          > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>          > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>          >          
>           <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>          >
>          >
>          >         _______________________________________________
>          >         wildfly-dev mailing list
>          > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>          > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>          >         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>          >
>          >
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev