This all sounds soooo familar. But I was not able to find the Jira. Seems to be there was a reason that we don't disassemble the id, though that reason escapes me atm. That does seem like the logical thing to do. Regardless of why I think we may have decided not to, it would still be interesting to see if you could make that work
On Wed, Dec 4, 2019 at 1:40 PM Gail Badner <gbad...@redhat.com> wrote: > When an entity is cached with a composite ID containing a many-to-one > association, the cache key will contain the many-to-one associated entity. > If the associated entity is not enhanced, then it could be an uninitialized > proxy. > > I've created a test case [1] that illustrates this using Infinispan. The > test case is for 5.1 branch, since hibernate-infinispan is still included > in that branch. The same would happen for master as well. > > Aside from the obvious issue with increased memory requirements to store an > entity, there are other problems as well. > > What I've found so far is that caching a key with an uninitialized entity > proxy can cause some big problems: > > 1) A lookup will never find this key unless the lookup is done with a cache > key containing the same entity proxy instance. > > 2) Calling EntityManager#find with a composite ID containing a detached > uninitialized entity proxy will result in a LazyInitializationException. > This does not happen with second-level cache disabled. > > 3) Calling EntityManager#find with a composite ID containing a managed > uninitialized entity proxy will result in the proxy being initialized. This > does not happen with second-level cache disabled. > > I have not looked into what happens when the associated entity is enhanced > and uninitialized (i.e., enhancement-as-proxy). > > IIUC, disassembling the ID that gets stored in the cache key would be far > more efficient, and would avoid these issues. We would only want to do this > when a composite ID contains an association. This would require changes in > some SPIs though, to account for the disassembled ID type. > > I've been discussing necessary changes with Scott to cache a > disassembled ID. Before we get too far down this road, I'd like to get some > feedback. > > In the first place, should an entity instance be stored in a cache key? > > Is disassembling primary keys that contain an association the appropriate > way to go? If so, I'll continue with a POC for doing this. > > Thanks, > Gail > > [1] > > https://github.com/gbadner/hibernate-core/blob/753e36edf5137296d28b2a07cee3daffc16c6d1e/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysWithEagerEntityFactoryTest.java > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev