[jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE

[Manik Surtani]

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 at jboss.org