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/753e36edf5137296d28b2a07ce...