CacheAccess sounds fine...
{quote>

I ended up calling it org.hibernate.cache.spi.access.StorageAccess for the time being. I had changed that before your reply. The idea being that this represents access to the underlying cache storage. CacheAccess is fine for me too; we can change it later if we all think it makes more sense.

it has a feeling of the cache being something external to ORM. I rather think about cache as totally owned component, despite that the implementation uses different project. While you repeat that everything should be expressed from Hibernate side (and I agree to that), Hibernate and Cache does not have a peer relationship.

I am not following what you mean by "Hibernate and Cache does not have a peer relationship". What do you mean by that?

I will say however that I do not think it always makes sense to think of caching as a "totally owned component" in terms of thinking Hibernate owns it. To me whoever builds something, owns it. In general Hibernate does not finely control how the provider should build Caches, etc. Nor should it. Ok, you can argue that, e.g., hibernate-infinispan is doing this and is Hibernate... sure. But, for example, when Hibernate is used in WildFly, WildFly configures those caches for Hibernate to use - Hibernate does not own it, WildFly does.

Ad cache per region vs. cache per region access: cache per Region has an implementation problem with

@Cache(region="a.b.c",usage=TRANSACTIONAL)
public class Person

and I am a bit afraid of cache per RegionAccess (in that case you couldn't set max cache size for multiple entities together - this is possible in the current codebase). So I would prefer being able to store multiple roles with the same access type in single cache (and being smart about CacheKeysFactory), while having separate caches "a.b.c#TX" and "a.b.c#NSRW".

Additionally, I ran into another oddity regarding query-result and update-timestamps caches. Some of this I mentioned earlier when I said that I do not think it makes sense conceptually to mix entity, collection and natural-id storage with query-result and update-timestamps storage in the same "region". And in fact update-timestamps storage is more properly modeled related to the RegionFactory than a specific Region.

Its as if "region name" means a different thing when we discuss entity, collection and natural-id caching versus query-result caching.

For the case of entity, collection and natural-id Region could be interpreted as either:

1. cache per region
2. cache per "cacheable"

(here I use "cache" as in underlying provider cache object)

In either case, region-name indicates the config (interceptors, replication, etc) to use[1] - in (1) it is applied to the single cache instance, whereas in (2) the config is applied to a cache created for each "cacheable". Also, it is important to keep in mind that in (1) cache keys still need to incorporate the "cacheable" name if other "cacheable"s of the same type are also associated with this region (to properly segment the data from each cacheable); but in the case of (2) it is always safe to drop the "cacheable" name there.

Each approach has pros and cons; it is really ultimately a provider choice.

In the case of query-result caching, I think the provider should be safe to interpret Region as either:

1. cache per region
2. one cache per RegionFactory for all query-result caching

Additionally, query-result (and update-timestamps) caching storage is accessed directly, without "access" protection (as is done for entity, collection and natural-id caching).

Also too, here the notion of a Region becomes very different. Where for entity, collection and natural-id I'd actually

I have an idea for a tweak to the design to better account for these, but it represents a conceptual change that I wanted to get y'alls thoughts on. Basically I'd introduce the notion of a "Cache"

I bring up this discussion in context of your "mixed access" discussion because I think you could actually support that if you chose the "each entity Region gets its own Cache" path - since Cache seems to be lowest place you can deal with the idea of "access". Or you could just disallow that, which I am ok with providers deciding to do (we should just be clear about this in the documentation). What you propose also seems very reasonable thing for a provider to do.

As far as applying maxEntries, etc across a Region with multiple access types defined your proposal also does not handle that because it is creating separate caches (while having separate caches "a.b.c#TX" and "a.b.c#NSRW").

Personally I do not see the difficulty in supporting multiple access types against a single cache, but I have not dug into the details of implementing a provider nearly as much as you have.

[1] This is my proposal, that the region name ought to be part of a fallback resolution for the cache config to use - specifically to come to an agreement on that between the providers. It makes for a better Hibernate user experience and I'd love if we could all agree to a fallback sequence of (highest precedence to lowest):

1. "cacheable" name (Person, Animal)
2. region-name ("a.b.c")
3. cacheable type ("hibernate-entity", "hibernate-collection", "hibernate-natural-id", "hibernate-query-results")