Steve Ebersole I see that this concept still keeps 1:N relationship between Region and RegionAccess. Infinispan can't implement that (but throwing exception on second build*RegionAccess with different access type). While it's possible to mix "user model data access from the same region" (and I agree that this may be useful when setting memory contraints), it is not possible to mix different access types. Therefore, the Region will not be actually initialized until first request for RegionAccess.

As for support data, the RegionFactory will decide the configuration based on the region name, but then the API will allow to attempt to access this region both for queries and for timestamps, which does not make much sense.

I welcome removing some methods from the Region (though I am not sure how exactly should statistics work here), but regarding the API, it's not a step forward. The API that I would appreciate would specify (region name, access type, list of entities and/or collections) when creating the region and let the region happily live ever after. Separation between Region and RegionAccess is moot if Region does not have any methods, and RegionAccess is stateless (keeps just references to components), so it can be safely shared.