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.

Reply via email to