"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."

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