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