> But, you still keep making this mis-assumption that Region has to map to some concept in Infinispan. It doesn't. So please take a step back here - you'd see that in fact you have almost everything you asked for when hibernate-infinispan is asked to perform these operations...

I am making an assumption that Region maps to a shared map-like data storage. Is that too much? And I don't use the concept of synchronous/asynchronous strategies because it does not map to Infinispan well; I just observe when particular RegionAccess methods are called and act accordingly.

> We have talked ad-nauseum about how Region must be able to support multiple kinds of data. That is, a single named region must be able to host a combination of entity, collection and natural-id data. This aspect is not even up for discussion, and we've beaten it to death in prior discussions.

Agreed, I've confirmed this in my previous comment. This is solved: by default the identifiers of data in Region will contain type information, you can set up optimized variant using cache keys factory.

> Not until a provider is asked to build a RegionAccess is it asked to build something that in any way, shape or form corresponds to any under-lying cache concept - because this is the point where it needs access to the underlying "cache" it will be accessing.

Then, what does "buildRegion" mean? Since you expect it to return such an empty shell, why do we need that Region instance at all?

> You ask that this be "stateless", but then you ask that it hold state ("keeps just references to components" -> state). The provider (you) build the RegionAccess; you can build it however you want.

All instance of RegionAccess coming from the same region will keep references to the same components, therefore there's no state per RegionAccess. But this is a bit of digression, and speaks about the current implementation - but do you expect these objects to keep any state?

Regarding the wish list: I had no particular format in mind, I meant just "all data", though I've assumed something like the (Entity)CacheDataDescriptions. Something implementation could use to turn some optimizations if the data is immutable, if we store just single type and so on.

But my problem is that I don't have all this info when someone calls buildEntityRegionAccess because I don't know if someone will call that method again with different arguments in the next second. I have to either use the most generic implementation, or optimistically assume that there won't be a second call and if there is such invocation with incompatible arguments, throw an exception (or do a complicated fallback to the generic implementation).

> In general, I think it is perfectly reasonable for a provider to throw an exception if it encounters a config it does not support.

It's reasonable as the last resort, but it's much better to express the limitation what the use can/cannot do and make it impossible to mess the config. Also, I believe that getting failures during startup is less error-prone than once the user hits rare branch in his application which leads to such failure.