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:

@Override
protected <R extends Service> void createServiceBinding(ServiceInitiator<R> initiator) {
	if (initiator instanceof CacheInitiator) {
		super.createServiceBinding(XXCacheServiceInitiator.INSTANCE);
	} else {
		super.createServiceBinding(initiator);
	}
} 

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:

sr.locateServiceBinding(SessionFactoryServiceRegistryFactory.class).setService(new XXSessionFactoryServiceRegistryFactory(sr));

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