<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2 Mar 2011, at 17:43, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">As consistency models go, Infinispan is primarily strongly consistent (with 2-phase commit between data owners), with the exception of during a rehash where because of eventual consistency (inability to get a valid response to a remote GET) forces us to wait for more responses, a quorum if you like. Not dissimilar to PAXOS [1] in some ways.</div></blockquote>We are strongly consistent even during the rehash - we make sure that the user receive's the last piece of data or no data at all (TimeouException). <br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I'm wondering whether, for the sake of performance, we should also offer a fully eventually consistent model? What I am thinking is that changes *always* occur only on the primary data owner. Single phase, no additional round trips, etc. The primary owner then asynchronously propagates changes to the other data owners. This would mean things run much faster in a stable cluster, and durability is maintained. </div></div></blockquote>Don't we already do that with "eagerLockSingleNode"?<br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> However, during rehashes when keys are moved, the notion of the primary owner may change. So to deal with this, we could use vector clocks [2] to version each entry. Vector clocks allow us to "merge" state nicely in most cases, and in the case of reads, we'd flip back to a PAXOS style quorum during a rehash to get the most "correct" version.</div></div></blockquote><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" color="#000000"><br></font></div><div>In terms of implementation, almost all of this would only affect the DistributionInterceptor and the DistributionManager, so we could easily have eventually consistent flavours of these two components. </div><div><br></div><div>Thoughts?</div></div></blockquote>+1<br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Cheers</div><div>Manik</div><div><br></div><div>[1] <a href="http://en.wikipedia.org/wiki/Paxos_algorithm">http://en.wikipedia.org/wiki/Paxos_algorithm</a></div><div>[2] <a href="http://en.wikipedia.org/wiki/Vector_clock">http://en.wikipedia.org/wiki/Vector_clock</a><br><div>
<div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org/">http://www.infinispan.org</a></div><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br></body></html>