Re: [infinispan-dev] ISPN-263 and handling partitions

On 22 Apr 2013, at 17:43, Manik Surtani wrote: > On 22 Apr 2013, at 14:47, Bela Ban <bban(a)redhat.com&gt; wrote: > >> >> >> On 4/19/13 11:51 AM, Sanne Grinovero wrote: >>> TBH I'm not understanding which problem this thread is about :) >>> >>> Surely network partitions are a problem, but there are many forms of >>> "partition", and many different opinions of what an "acceptable" >>> behaviour is that the grid should implement, which largely depend on >>> assumptions the client application is making. >> >> >> This thread is not about providing different application data merge >> policies, which is also something that needs to be done, but more likely >> in the context of eventual consistency in Infinispan. This thread is >> about a *primary partition* approach which says that only members in a >> primary partition are allowed to make progress, and others aren't. >> >> 'No progress' needs to be defined, but so far I think we've agreed on a >> notion of read-only members, which do provide access to data, but don't >> allow modifications. One could also think about not even allowing reads >> as the data might be stale. Perhaps this is configurable. > > +1 > >> The idea is that if only a primary partition can make progress, and only >> *one* primary partitions exists in the system at any time, then we can >> simply overwrite the data of minority partitions with data from the >> primary partition on a merge. >> >> So a primary partition approach is not about how to merge (possibly >> conflicting) data after a cluster split heals, but about how to >> *prevent* conflicting data in the first place. >> >> If you think about this in CAP terminology, we sacrifice availability in >> favor of consistency. > > Precisely. This would still follow the strongly consistent model. I don't think consistency is preserved in at least the following situations: - the read-only partition has more than numOwner members. Reads in the active partition would miss data. Also the conditional operation, that rely on existing data, perform incorrectly.

- data is deleted in the active partition but copies are kept in the read-only partition. The 2nd problem can be solved with tombstones. The first problem cannot be solved and we can only target an eventual consistent cluster. That should be made very clear to the users. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev