[infinispan-dev] Asymmetric caches and manual rehashing design

Mircea Markus mircea.markus at jboss.com
Wed Oct 5 08:52:32 EDT 2011


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111005/5b52978c/attachment-0001.html 


More information about the infinispan-dev mailing list