WrongClassException using Infinispan and sharing cache regions
Activity
Former user November 23, 2016 at 8:26 AM
Fixed in master, 5.1, and 5.0 branches.
Former user November 23, 2016 at 8:03 AM
Two short names have been added for hibernate.cache.keys_factory: default and simple. These only apply to Infinispan.
OldCacheKeyImplementation and OldNaturalCacheKey have been un-deprecated and renamed to CacheKeyImplementation and NaturalCacheKey.
Former user September 14, 2016 at 9:22 PM
, I plan to release 5.0.11/5.1.2 by the end of the week. Do you think this can be fixed by then? If not, please move this to 5.0.12/5.1.3.
Radim Vansa September 12, 2016 at 8:23 AM
I think that configuration-based autodetection of shared/non-shared would not work 100%, given the numerous ways you can configure it, in embedded use or in WildFly... "Experimental" way = during initialization, putting key unique to given node into the cache and failing with explanatory message if such key is already there could work in many cases, though if the cache has eviction enabled and the caches are not started at the same moment, it could be already evicted... (regrettably it's not possible to mark entry as non-evictable). But given that if this detects the key already there, the cache really is shared, it could hint user.
We would have to think about the key uniqueness a bit, too, since I can imagine users persisting the cache (incl. this key - though persistence can be avoided, it would not detect WFLY-6596 case if we just marked it as non-persistable). However if the app is just redeployed, so the 2LC is starting with a cache already containing the entities, we don't want to fail this check.
To configure Hibernate correctly, I believe that setting `hibernate.cache.keys_factory` to `DefaultCacheKeysFactory` (eh, maybe with a better name given that it's non-default) should be sufficient (as long as that works). We could also introduce short-cut names because the `org.hibernate.cache.internal` should not be exposed when it's already "internal".
Steve Ebersole September 2, 2016 at 3:14 PM
I wanted to get your thoughts on this and the direction I am thinking of for a solution... Basically I propose we determine whether the region is shared. If not we could use a simple tuple key (rootEntityName,id). I realize we'd still have the object creation overhead, but it would at least work correctly.
Relatedly, I'd like to see a way for a user to say which key factory to use. Even if it is a simple boolean that says "hibernate-infinispan can use simplified cache keys, or it cannot".
You are most likely going to be needing this in 5.0 and 5.1. https://issues.jboss.org/browse/WFLY-6596
Causes a regression that makes it impossible to store data from different entities into the same cache region when using Infinispan. The simple
idshould really only be used when the cache region is not shared; makes the assumption that the regions are not shared.