Re: [infinispan-dev] ISPN-263 and handling partitions
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)