WrongClassException using Infinispan and sharing cache regions

Description

Causes a regression that makes it impossible to store data from different entities into the same cache region when using Infinispan. The simple id should really only be used when the cache region is not shared; makes the assumption that the regions are not shared.

Environment

None

Activity

Show:
Steve Ebersole
September 2, 2016, 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

Radim Vansa
September 12, 2016, 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".

Gail Badner
September 14, 2016, 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.

Gail Badner
November 23, 2016, 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.

Gail Badner
November 23, 2016, 8:26 AM

Fixed in master, 5.1, and 5.0 branches.

Assignee

Radim Vansa

Reporter

Steve Ebersole

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure