Re: [jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE
On 21 Mar 2008, at 11:59, Bela Ban wrote:
Manik Surtani wrote:
> 2) Remote (proxy) access to a given cache. Something like:
>
> Cache c = new CacheProxy(currentInstance, addressToProxyTo);
>
> so that you could query any caches (coordinators, or all caches
> in the case of BR) you care about, about their "interesting" roots
> and children.
>
> I'm guessing everything you need in c, d and f can be achieved with
> proxy access described above?
>
> So I'm now the callback hasn't changed, and still looks like:
>
>
> void handleMerge(Cache currentInstance, List<Address>
> mergedMembership, List<Address>... subpartitionMemberships);
>
> NB: CacheProxy does not exist as yet. It is something we need for
> Partitioning (JBCACHE-60), so I thought it may make sense here.
Are proxies something we could do before Data Partitioning *in case
we decide to do merging first* ?
Yes, definitely.
In what respect are those proxies different from a remote cache
loader ? Do you envisage RCLs to use proxies once proxies are in
place ?
Proxies are independent of the Cache Loader Interceptor. RCLs need to
play nice with the CL interceptor's decisions to load, etc. I can
foresee the TCPDelegatingCacheLoader, ClusteredCacheLoader, even the
DataGravitationInterceptor, for example, being reimplemented using
proxies. Would make things much cleaner and more robust.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org