I agree with what Mike said. Plus, I don't think this is as simple as it
appears.
For instance, if I ...
Region<?, ?> students = clientCache.getRegion("Students");
What happens when the "Students" Region does not exist server-side?
This would require a check to determine whether the Students Region
actually existed on the server first before creating the PROXY Region on
the client. If this check were not performed and the "Students" Region did
not exist on the server, then a user would not know about this fact until
they performed a Region operation.
For example in
package ...;
import ...;
public class NativeClientApp {
public static void main(String[] args) {
ClientCache gemfireCache = new ClientCacheFactory()
.set("name", NativeClientApp.class.getSimpleName())
.set("log-level", "config")
.addPoolServer("localhost", 40404)
.create();
ClientRegionFactory<Object, Object> exampleProxyRegionFactory =
gemfireCache.createClientRegionFactory(ClientRegionShortcut.PROXY);
Region<Object, Object> exampleProxyRegion =
exampleProxyRegionFactory.create("Example");
* exampleProxyRegion.put("keyOne", "valueOne");*
assertThat(exampleProxyRegion.get("keyOne")).isEqualTo("valueOne");
}
}
Without starting a server, this program fails on the Region.put(..) (i.e.
exampleProxyRegion.put("keyOne", "valueOne");), and NOT when the Region is
created. This is unfortunate, since it does not "*fail-fast*", which could
potentially occur much later in the application lifecycle when it is least
expected!
Therefore, in certain cases, the following...
Region<?, ?> students = clientCache.getRegion("Students");
Will work when the "Students" Region does in fact exist on the server, and
in other cases will fail once an operation is performed.
Additionally, I think it would be less than clear when this Region created
by clientCache.getRegion("name") is going to the server and when it does
not, or whether it even created a Region or got another Region defined in
say client-cache.xml, which could be LOCAL.
All and all, I think overloading the API in this way is very confusing and
wrong.
$0.02
-John
On Wed, Feb 15, 2017 at 8:02 AM, Michael Stolz <mst...@pivotal.io> wrote:
> 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.
> >
>
--
-John
john.blum10101 (skype)
