[infinispan-dev] ISPN-263 and handling partitions

[Bela Ban]

Yes, that's what we decided to do a long time ago... see policy based 
merge approach in the mailing lists.

But the point of *this* discussion is not data reconciliation after a 
merge, but how to *avoid* that reconciliation by making conflicting 
minority partitions read only, such that a merge always transfers data 
from the primary partition to the minority partitions.

This is not as easy as it sounds though; Dan mentioned the case where 
the primary partition is not the owner of a given key K. In this case, 
we cannot simply swipe the minority partition. Even worse, if K is 
created and modified in the primary partition, we have to reconcile K's 
value between the primary and minority partitions...

Again, this could be dealt with by simply creating a new value for K in 
the primary partition, when K is accessed, and overwriting K's value 
from the minority partition on a merge.
Not nice, but the effect is the same as if all current owners of K 
crashed at the same time, and a partition could be seen as a *mass 
crash* of some sorts... :-)

On 4/19/13 12:42 PM, Pedro Ruivo wrote:
> After think a bit about it, we can conclude that the behaviour when we
> have partition totally depends on the application.
>
> So, why not create an generic interface (like, execute(Operation, Key,
> isPrimaryPartition)) that is invoked when a partition occurs?
>
> Maybe I'm losing the focus of the first email, but this way the
> application can choose what it is better for it. For example, if the
> application does not care about consistency, it can allow all partitions
> to read and write. On other hand, if the application is more restrict,
> it can allow only one partition to read and write and the others
> partitions reject all the operations.



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