This statement in version 4.1's documentation doesn't seem to be implemented....



Code that encodes the identifier exists in the CacheKey constructor & I've traced it's use through to the Session etc. As near as I can tell the tenantId is used to encode the key's, but then when it comes time to decode in SessionFactoryImpl > CacheImpl. New CacheKey's constructed are done so with the tenantId is null.

The comment on line 1489 reads:


So if the tenantId is indeed used to encode cache keys & then not used later to acess cached objects, how can CacheImpl in SessionFactoryImpl be functioning at all with keys that wouldn't match?

Is it really disabled as it seems or am I not understanding the code?

I understand it is not easy to get the tenantId in that section of code,
I imagine you'd have to use the CurrentTenantIdentifierResolver which is a contract I'm not able to implement in the context of my applications design.

What I was thinking of doing to get it working (if it isn't) was to extend the Cache interface creating methods that include a tenantId argument, the one place sure to have the correct tenantId would have to be the calling code. Then I'd have to override public Cache getCache(); in order to substitute my own CacheImpl that makes use of the extra tenantId argument in the creation of CacheKey.
Is this an appropriate solution?

I'd also of course then need to hunt around and figure out where to put my SessionFactoryImpl subclass, since hibernates architecture is still new to me.

Can anyone offer some insight or guidance on the topic > how to insure the statement made in the dev guide 16.3.3. Caching, is true.

I ran across the same issue. I was storing elements in a cache with a tenantId, but I found out that when evicting those elements the CacheImpl builds a CacheKey without a tenantId, so the hash of the key at evicting will never match the hash of the key that was used at storing.

Because I suspect I won't be the only one who struggled with this, here's my way around the issue:
I extended CacheImpl with a version that adds the correct tenantId to the CacheKey and because I was building the SessionFactory programatically I was able to replace the right services so that my CacheImpl was used in the SessionFactory.

Classes I build:
XXCacheImpl - as described above, builds CacheKey with tenantId
XXCacheServiceInitiator - implements SessionFactoryServiceInitiator<CacheImplementor>, creates XXCacheImpl
XXSessionFactoryServiceRegistryFactory - implements SessionFactoryServiceRegistryFactory, the buildServiceRegistry returns XXSessionFactoryServiceRegistryImpl
XXSessionFactoryServiceRegistryImpl - extends SessionFactoryServiceRegistryImpl but overrides createServiceBinding with the following implementation:

I build the SessionFactory with a SessionFactory builder and a StandardServiceRegistryImpl. To add my own SessionFactoryServiceRegistryFactory to the StandardServiceRegistryImpl I call the next line before building the SessionFactory itself:

This approach is able to evict elements from the cache for a specific tenant.