One scenario you should be aware of in NBST's step
"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."
is:
Cache A and B are in view v1.
C joins and PREPARE_VIEW(v2) is sent and only reaches C, so we have {Av1, Bv1,
and Cv2}
Let's say we (k,val1) that should be migrated from A to C, because of the view
change
1. k is updated on Cv2 to val2
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!
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.
On 27 Sep 2011, at 17:22, Dan Berindei wrote:
> Following the discussions last week I've written up a wiki page
> describing the strategies for cache view management and state transfer
> that will enable asymmetric caches and manual rehashing:
> http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign
>
> The state transfer part is not very detailed, as you'll see we want to
> go with a non-blocking approach but I'm not sure we can finish that
> for 5.1 so we're keeping a blocking fallback option.
>
> Your comments are welcome, either on the list or on the wiki page.
>
> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
