Re: [infinispan-dev] API behaviour when using DIST

Some of the API methods' return values may not be as expected when using DIST. Just wanted to run this by you guys to see what you thought. Specifically, what I am referring to is methods like put(), putIfAbsent(), and the 2 versions of remove() and replace(). Now when these are executed in any other cache mode (LOCAL, REPL, INVAL) return values are as expected from their java.util.Map contracts. However with DIST, there are 2 separate ways this could go. 1. The key in question is mapped to the local cache on which the method is invoked. This case behaves normally as well as per the Map contract. 2. The key in question is *not* mapped to the local cache. E.g., K is mapped to nodes A and B, and on C we do C.remove(). I can stick with the map contract if each of these methods first does a remote lookup of the key and stores this in L1 (or even in the invocation context and then throw it away if there is no L1) but this is unnecessarily wasteful IMO. The other approach is to realise the command pertains to a key for which the local cache is not the owner, and replicate the call to the remote nodes. What happens next is also a matter of tuning: we could a) replicate + ignore responses. Then the retval to these methods are indeterminate, and probably unusable. b) replicate + wait for response. This will adhere to the Map contract, albeit at a cost. Probably not possible if we use DIST_ASYNC. c) L1: we could either "correct" the L1 cache with the change, or remove the key forcing another lookup for the next time around. What do people think? Maybe offer all strategies? Or will this then become configuration hell? :) Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev