I have strong fears that if we make these wholesale changes to existing APIs we're going to end up breaking lots of existing code.
For instance, if we make destroyRegion propagate when it never did before, we may end up destroying a server side region in production that wasn't expected. I will advocate for being more explicit about operations that are going to be performed on the server. The other fear I have is that if we make all of these server side operations available to the Java client but not to the C++ and C# clients we will once again be making our C++ and C# users feel orphaned. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Wed, Feb 15, 2017 at 9:44 AM, Swapnil Bawaskar <sbawas...@pivotal.io> wrote: > 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. >
