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

This gets even more interesting when we have transactions in play. E.g.: K resides on {A, B} in a cluster of {A, B, C} On C, we do: 1. tx.begin() 2. retval = C.replace(K, V, V2) 3. // do something with retval 4. tx.commit() It is one thing to set the expectation of unreliable return values for async mode as defined below, but the above would be tricky even in the case of sync mode. On line 2 we would have to start the tx on remote nodes and start processing the commands and pull back results. And on 4, the prepare logic would have to change to assume that all writes have already been executed. On the plus side, this means we have txs that will fail fast(er) if remote locks cannot be be acquired... Thoughts and comments? - Manik On 16 Apr 2009, at 14:33, Manik Surtani wrote: > 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 -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org