Hi Steve Ebersole, thanks for such elaborate answers. And I think that now I got that it is the RegionAccess that should be the representaion of the map = cache. My confusion came from the statistics methods and contains(key) directly on the Region, and also the name 'access' suggests that the purpose of this interface is rather a 'facade' than a 'storage' (at least to me as a non-native speaker).

So, to make it crystal clear, when someone builds TRANSACTIONAL access from a region, using role X, inserts an entity with id 123, and later builds READ_WRITE access using the same role X; should the request to fetch entity with id 123 return null?

IIUC such situation should not be possible (single entity is always accessed using the same access type), and if we link cache just with the access type (instead of a region), I don't have any reason to request the restriction to single access type per region anymore. I wonder if we could shape the interface in a way to express that each role will be always accessed using the same access type, but it's probably unnecessary if that's clearly stated in javadoc.

Therefore, I would not need the contents of RegionBuildingContext at the point when the Region is built if that's inconvenient for the implementation, anytime prior to building first RegionAccess would be fine.

Regarding statistics, I think the RegionObserver counting hits/misses per region is fine, and those getElementCount* methods should go to the RegionAccess aka storage. The other changes (timestamps, timeout) sound fine, I am glad that you've clarified the meanings.