[infinispan-dev] Asymmetric caches and manual rehashing design

Bela Ban bban at redhat.com
Thu Sep 29 03:03:31 EDT 2011


Yes, I think a merge needs to be treated as a special case, in which we 
might have to compute the owner(s) for *every* key in a cache. Or we 
take a deterministic decision, as you mentioned, and only do this for 
the non-primary partition.

On 9/28/11 3:01 PM, Dan Berindei wrote:
> Hi Bela
>
> After writing my reply I realized there is a small problem with my argument:
>
>>
>> In order to do it deterministically we need to have a common "last
>> good consistent hash" for the last rebalance that finished
>> successfully, and each node must determine if it should push a key or
>> not based on that last good CH.
>>
>
> If there was a merge, the nodes in each partition have different ideas
> of what their old view was, so it's not possible to have a common
> "last good CH" for the entire cluster unless we pick the coordinator's
> view as the "winner" and discard everything in the loser partition.
>
> We will have instead a last good CH for each partition, and each node
> will determine whether to push a key or not based on the CH of its
> partition and the CH of the united cluster.
>
> Cheers
> Dan

-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat


More information about the infinispan-dev mailing list