It appears `SessionFactoryImpl` has (for a long time) assumed that there is a one-to-one mapping between second level cache region names and access strategies. This is true in a typical configuration because each region draws it's name from it's single consumer (e.g. the fully qualified class name of the entity for an EntityRegion). This ceases to be true however when the user explicitly configures multiple entities or collections to share the same cache region. What then ends up happening (from what I can tell - and from code inspection) is that everyone ends up using the access strategy for which collection or entity cache gets their first.

In HHH-10418 the problem is that with entity and collection caches sharing the same region you will get class cast exceptions when the consumer that arrives second gets the incorrect type. As that issue states this was caused by the fix for HHH-10286 which added the collection access strategies in to the map. It was I believe broken before this though (and still is), and arguably in a worse way. Two entities with different configured access strategies will end up using whichever one gets there first, in the worst case this could allow a 'read-write' entity to end up with with a 'read-only' strategy.

In a related manner, currently the CacheDataDescription is bound to the region when it's created, but nothing is done to enforce that everyone using the region is "compatible" with that description. It seems this should be corrected to either bind the CDD to the access strategy, or to enforce that those sharing a region should have 'compatible' data descriptions. At the moment it's possible to run in to problems with this where a region can be created expecting for example unversioned entities, and then abruptly see versioned entities fed to it due to this problem.

Figuring out the correct fix to this is further complicated as the SessionFactoryImplementor SPI interface contains methods that assume this 1-1 mapping that are used to allow the stats API to expose the entries within a cache.

Anyway lots of food for thought here. No reproducible test case I'm afraid... this was mostly discovered by code inspection, and seeing a weird failure in the JSR-107 provider that I couldn't initially understand.