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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
