[hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level?

Steve Ebersole steve at hibernate.org
Wed Dec 12 11:15:55 EST 2018


Scott, if you take a look at the JtaPlatform impls they do in fact cache
(configurable) either the TM or UT.  I am like 90% sure I did not cache the
TSR because you told me not to (you are the one who asked for JTA
integration via TSR).

If it is no longer the case that that should not be cached, then feel free
to cache it.



On Tue, Dec 11, 2018 at 7:23 AM Scott Marlow <smarlow at redhat.com> wrote:

> Hi Gail,
>
> Yes, WFLY-11243 [1] is caching TransactionSynchronizationRegistry at the
> WildFly level, which is great for WildFly applications but other
> platforms might benefit from one of the following:
>
> A.  Reducing the number of Hibernate ORM calls to JndiService#locate
> (the TransactionSynchronizationRegistry).  In a WildFly 15 container
> managed persistence context/EntityManager, I saw that every call to
> EntityManager.find() in a new JTA transaction, required a call to
> JndiService#locate (from pulse()).  This will be worked around in
> WildFly 16, via [1], to avoid the call to JndiService#locate.
>
> B.  Or could/should we cache the TransactionSynchronizationRegistry in
> the SessionFactory?  Which is my open question still.
>
> Apologies for the bad [2] link, I'm not sure why that is now invalid,
> next time I will use a gist link.
>
> Scott
>
> On 12/10/18 6:12 PM, Gail Badner wrote:
> > Hi Scott,
> >
> > I see that the issue is resolved and your commit is merged. Is this no
> > longer an issue?
> >
> > Thanks,
> > Gail
> >
> > On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     Hi,
> >
> >     I started working on a WildFly change WFLY-11243 [1] to cache the
> >     TransactionSynchronizationRegistry inside of the WildFly JtaPlatform
> >     instance.  The purpose of caching the
> >     TransactionSynchronizationRegistry
> >     is to avoid repeated JndiService.locate() calls, like during entity
> >     manager creation time [2] and other uses as well.
> >
> >     My question is whether the idea of caching the
> >     TransactionSynchronizationRegistry instance is already handled at the
> >     session factory level?  If not, would that make sense?
> >
> >     [3] is the WildFly pr to cache the TransactionSynchronizationRegistry
> >     instance, to avoid repeatedly looking it up (since it rarely ever
> >     changes).  If there is a way to instead have the
> >     TransactionSynchronizationRegistry cached at the SF level, that
> >     might be
> >     better.
> >
> >     Scott
> >
> >     [1] https://issues.jboss.org/browse/WFLY-11243
> >     [2] https://paste.fedoraproject.org/paste/kXHq27RpSSs8GS8v0S8Dog
> >     [3] https://github.com/wildfly/wildfly/pull/11784
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list