Re: Functions need reference to Cache

A GemFireCache will be either a ClientCache or a Cache. If Functions always execute on a member of the cluster then it this new getCache method should return Cache. But if it is possible to execution a function in a client then getCache should return GemFireCache. GemFireCache extends RegionService

Re: Functions need reference to Cache

Yeah, there's even a PR for this - but it doesn't have tests. If anyone wants to pick that up and clean it up and add tests that would be great! https://github.com/apache/geode/pull/74 -Dan On Thu, Mar 2, 2017 at 1:01 PM, John Blum wrote: > Also keep in my mind if you are given a RegionFunctio

Re: Functions need reference to Cache

Also keep in my mind if you are given a RegionFunctionContext (in cases where the *Function* is executed "on a *Region*") then you have indirect access to the cache... regionFunctionContext.getDataSet()

Re: Functions need reference to Cache

I think I even see comments in the code stating "TODO: use the cache in the FunctionContext when it becomes available". On Thu, Mar 2, 2017 at 12:30 PM, Kirk Lund wrote: > I'm looking into a deadlock involving code under > org.apache.geode.management. Related to this, I'm also looking at all of

Re: Functions need reference to Cache

I agree this would be useful, and I think it already has an open GEODE ticket: https://issues.apache.org/jira/plugins/servlet/mobile#issue/GEODE-393 On Mar 2, 2017 12:30 PM, "Kirk Lund" wrote: > I'm looking into a deadlock involving code under > org.apache.geode.management. Related to this, I'm

Re: Functions need reference to Cache

> On Mar 2, 2017, at 12:30 PM, Kirk Lund wrote: > > > In an effort to prevent deadlocks and move away from statics and > singletons, I'd like to find a good alternative to this for Functions. I > think adding this method to FunctionContext is the best solution: > > /** > * Returns a reference