GEODE-1887 <https://issues.apache.org/jira/browse/GEODE-1887> was filed to make sure that the user experience while using Geode is similar to RDBMS and other data products out there. While reviewing the pull request <https://github.com/apache/geode/pull/390> I realized that we need to make other operations propagate to the server as well. These include: - invalidateRegion() - destroyRegion() - getSnapshotService() - getEntry() - keySet() - values() - isDestroyed() - containsValueForKey() - containsKey() - containsValue() - entrySet()
Also, rather than have a user "create" a PROXY region, which is just a handle to a server side region, I would like to propose that clientCache.getRegion("name") actually creates and returns a PROXY region even if one was not created earlier/through cache.xml. So, in summary, the workflow on the client would be: ClientCacheFactory cacheFactory = new ClientCacheFactory(); cacheFactory.addPoolLocator("localhost", 10334); ClientCache clientCache = cacheFactory.create(); Region students = clientCache.getRegion("students"); students.put("student1", "foo"); assert students.size() == 1; If a client wants to have a near cache, they can still "create" a CACHING_PROXY region. For a CACHING_PROXY, I propose that we leave the default implementation unchanged, i.e. all operations work locally on the client (except CRUD operations that are always propagated to the server). In the case where the client wishes to perform operations on the server, I propose that we introduce a new method: /** * @return */ Region<K, V> serverView(); so that all operations on the returned view (Region) are performed on the server. In the longer term, we should break up Region into two interfaces, one that has methods that only work on the client (like registerInterest and serverView()) and other for the server. Thanks! Swapnil.