<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">One scenario you should be aware of in NBST's step<div>"<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(91, 91, 91); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; ">When a node receives a get/put for a key and the command targets are not up to date, it will just reject the command and the requestor will have to retry it on the new owner.</span>"</div><div>is:</div><div><br></div><div>Cache A and B are in view v1. </div><div>C joins and PREPARE_VIEW(v2) is sent and only reaches C, so we have {Av1, Bv1, and Cv2}</div><div>Let's say we (k,val1) that should be migrated from A to C, because of the view change</div><div>1. k is updated on Cv2 to val2</div><div>2. k is then read on Bv1 which fetches it from Av1. Av1 sees that the request was made within the same view, it accepts it and returns (k,val1) to the caller. Inconsistency!</div><div><br></div><div>In order to solve this 1 must make sure that the previous owner (i.e. A) must be aware of v2 *before* accepting a change.</div><div><br></div><div><div><div>On 27 Sep 2011, at 17:22, Dan Berindei wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Following the discussions last week I've written up a wiki page<br>describing the strategies for cache view management and state transfer<br>that will enable asymmetric caches and manual rehashing:<br><a href="http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign">http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign</a><br><br>The state transfer part is not very detailed, as you'll see we want to<br>go with a non-blocking approach but I'm not sure we can finish that<br>for 5.1 so we're keeping a blocking fallback option.<br><br>Your comments are welcome, either on the list or on the wiki page.<br><br>Dan<br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></div></blockquote></div><br></div></body></html>