[infinispan-dev] ISPN-263 and handling partitions

Bela Ban bban at redhat.com
Mon Apr 22 09:17:32 EDT 2013



On 4/19/13 11:04 AM, Pedro Ruivo wrote:

> I have another suggestion that can allow all the partitions to
> process write commands.
>
> I think we can rely on the primary owners to decide which partition
> has the write permission on a key. For example, if the primary owner
> of key1 is on partition_1, then the partition_1 has the only
> partition that can update key1. All the remaining partitions only
> have read access over key1.


This is problematic, as it doesn't take primary / minority partitions 
into account. E.g if we have {A,B,C,D,E,F,G} and key1 is present on A 
(primary owner) and G (backup owner), and the cluster splits into 
{A,B,C,D} and {E,F,G}, then key1 might be on A (primary) and D (new 
backup), but also on E (new primary) and G (old backup). Both partitions 
would allow modifications to key1.

Also, if key1 was not present in the {E,F,G} partition, and some client 
created it, nothing would prevent that, as we don't know the the other 
partition's existence.

> The problem with this approach is that we have to keep the
> consistent hash before the partition occurs.


Yes, the issue is that you can *never* determine if a partition 
occurred, or if some member(s) crashed, so in the above case a hard and 
fast rule of the primary partition have at 4 or more members make sense 
for a primary partition approach.


-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


More information about the infinispan-dev mailing list