Hi Chris, I've created a ticket: https://issues.apache.org/jira/browse/TAP5-2754
If I understand it correctly, the getSession() call just returns the associated session of the org.hibernate.jpa.HibernateEntityManager which Session extends since 5.2, see https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc#hibernate-entitymanager-merged-into-hibernate-core As the "session" in the session.getSession() call is still the injected per-thread scoped one, the Session should just be original/not shadow-propertied one, not a new one. Cheers, Ben On Sun, Jun 11, 2023 at 3:19 AM Christopher Dodunski (Tapestry) < chrisfromtapes...@christopher.net.nz> wrote: > Hi Ben, > > Thank you for your investigative efforts, even though you weren't yet > able to pinpoint the exact cause. And thank you, you and Vangel, for > sharing that workaround. > > Occasionally, this HibernateCrudServiceDAO method works as expected. > Most times not. This seeming randomness fits with your explanation of > the 'shadow Session' being generated at runtime... perhaps something is > prematurely getting garbage collected? > > For now, I'll switch to session.getSession() as suggested. I guess this > returns an actual Hibernate session, bypassing Tapestry's per-thread > (scope) logic in between. > > Should this issue be recorded as a potential bug so that it eventually > gets fixed? > > Kind regards, > > Chris. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
