[hibernate-dev] Cache key containing composite ID with a many-to-one

[Steve Ebersole]

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 <gbadner at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>