[infinispan-dev] Replace command not checking previous value

[Sanne Grinovero]

Hi all,
I have discussed this with Manik (having had the opportunity to talk live
with him); we agreed the test is wrong and the key owner should be
responsible to perform the equality checks, propagating the decision
to eventual peers.

https://issues.jboss.org/browse/ISPN-2435

Sanne

On 22 October 2012 13:57, Sanne Grinovero <sanne at infinispan.org> wrote:
> 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 at jboss.org> wrote:
>>
>> On 22 Oct 2012, at 02:36, Sanne Grinovero <sanne at infinispan.org> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>>
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev