Hello, I'm in need to use the Cache method .replace( key, expectedValue, newValue ); and while debugging I got into org.infinispan.commands.write.ReplaceCommand.perform(InvocationContext) which is doing "the right think" only if ctx.isOriginLocal() . What puzzles me most is that there even is a comment pointing this out, as it was a design choice made for some purpose.. some purpose which strongly conflicts with my needs and the API contract :-/ Could anyone please explain?

thanks, Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Both old (expected) and new values are already sent to the other nodes: it's just being ignored. I'm looking into the BaseReplicatedAPITest and to make an example of a frequently used pattern on the test: cache2.withFlags(CACHE_MODE_LOCAL).put("key", "valueOld"); assert cache2.get("key").equals("valueOld"); assert cache1.get("key") == null; cache1.putIfAbsent("key", "value"); assert cache1.get("key").equals("value"); assert cache2.get("key").equals("value"); <---- ?? It seems to expect the test is performed only on the executing test (cache1) and so to override the comparison result which in this case would have a different result on cache2 because of the two caches being "out of sync" after the CACHE_MODE_LOCAL operation. I think the test should change that last line in assert cache2.get("key").equals("valueOld"); My problem is specifically with cache.replace( x,y,z) , but all of the CAS methods seem to use this pattern Agree? Sanne On 22 October 2012 13:48, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 22 Oct 2012, at 02:36, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > >> Hello, >> I'm in need to use the Cache method >> >> .replace( key, expectedValue, newValue ); >> >> and while debugging I got into >> org.infinispan.commands.write.ReplaceCommand.perform(InvocationContext) >> >> which is doing "the right think" only if ctx.isOriginLocal() . What >> puzzles me most is that there even is a comment pointing this out, as >> it was a design choice made for some purpose.. some purpose which >> strongly conflicts with my needs and the API contract :-/ >> >> Could anyone please explain? > > Could be due to the cost of retrieving the old value, of remote, for comparison. The update would need to be sent to the owner of the entry anyway, and the check could be done there (where it would be local). > >> >> thanks, >> Sanne >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev