On 24 Apr 2013, at 16:08, Mircea Markus <[email protected]> wrote: > > On 22 Apr 2013, at 17:43, Manik Surtani wrote: > >> On 22 Apr 2013, at 14:47, Bela Ban <[email protected]> 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.
Good point. > - 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
