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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)redhat.com > <mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev