Cache keys no longer include the entity type
Description
Activity

Former user June 7, 2016 at 10:38 PM
Backported to 5.1 and 5.0 branches as well.

Former user June 7, 2016 at 10:38 PM
Reopening to add 5.0.10 and 5.1.1 as fix versions.
Steve Ebersole June 2, 2016 at 12:27 AM
The "graceful" aspect is a follow on in my opinion. It would require us tracking whether a region name is re-used as we are building the SF. It's doable, just more involved.
In the meantime I just added an option to specify the CacheKeysFactory
impl to use. As hibernate-infinispan is the only one using this atm, that is the only place the setting has any effect currently.

Karl von Randow June 1, 2016 at 7:30 PM
Confirming that I experienced this issue using Infinispan as my 2LC. I have subsequently given up sharing cache regions and I'm much happier and, I believe, taking advantage of the way that it's intended to be used. So this issue is no longer relevant to me. The idea of gracefully disabling the optimisation, if I understand the intention above, sounds like a good solution though.

Sanne Grinovero June 1, 2016 at 5:23 PM
And yes this choice is pushed to the Cache implementor code, as only they know if the underlying storage for two caches is separated or not. This is actually the very point for which the KeyFactory implementation is left to the implementor.
Details
Details
Assignee
Reporter

Cache keys no longer include the entity type (cf. Hibernate 4) so you can no longer use the same cache region for multiple entity types.
This isn't mentioned in the migration documentation, however this seems like a major change (and related to my issue reusing collection regions in HHH-10286). Perhaps this could be mentioned in the migration documentation?