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

[Bela Ban]

Okay, that makes sense

Manik Surtani wrote:
>
> 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
>
>
>
>
>
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat