[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