John,
The proposed solution is actually try to solve the situation you mentioned
-- create a proxy Region failed silently on a client when region does not
reside on the server.
Region<?, ?> students = clientCache.getRegion("Students");
The getRegion will check on the server side and it should fail with
RegionDestroyedException if a region is not reside on a server.
As to Mike's concern. Shall we throw UnsupportedOperationException for
region operation on PROXY? Based on current finding, it seems
invalidateRegion and destroyRegion on PROXY most likely are not used by
users.
Regards,
Eric
On Wed, Feb 15, 2017 at 8:31 AM, Michael William Dodge <mdo...@pivotal.io>
wrote:
> I agree with Mike that whatever changes in behavior are made to the Java
> client library should also be made in the C++ and C# libraries.
>
> Sarge
>
> > On 15 Feb, 2017, at 08:02, 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.
> >>
>
>
