Re: [infinispan-dev] Fix or document? Concurrent replaceWithVersion w/ same value might all return true - ISPN-4972

It depends on the side-effects that replacing something with the same value has: listeners, cachestores, state transfer, etc. In general I'd say: no that's not what I want.

Tristan On 26/11/14 16:43, Sanne Grinovero wrote: > On 26 November 2014 at 14:17, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >> Sanne, it will work as long as the previous value is not the same as >> the new value. >> >> If multiple threads read value 5 with version 5, and all of them want >> to replace it with value 6, only one of them will succeed. > Ok I see I might be confusing value and versions. I hope :) > >> But if multiple threads read value 5 with version 5, and want to >> replace it with value *5*, all of them might succeed. > This paragraph is confusing me more. What "value" are you referring to > at the third "5"? Is it even legal to replace an entry with a new > value but not incrementing its version?

> > Thanks! > Sanne > >> Indeed, it's not atomic, but a basic counter will work. And it's all >> we can do with the actual core cache API (unless we want to go back to >> including the HotRod version in the value). >> >> Cheers >> Dan >> >> >> On Wed, Nov 26, 2014 at 2:33 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >>> That's not Atomic. How can I implement a counter on this? >>> >>> Say the current version is 5, I read it, and then issue a "replace 5 >>> with 6" command. >>> If I send a couple of such commands in parallel I need a guarantee >>> that only one succeeds, so that the other one can retry and get the >>> counter up to 7. >>> >>> Over Hot Rod I have no locking so I have no alternatives other than >>> atomic replacement commands, that's not unlikely to happen: that's a >>> critical showstopper for users. >>> >>> Sanne >>> >>> >>> On 20 November 2014 at 16:35, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >>>> I guess you could say this is a regression, this wouldn't have been possible >>>> when the version was part of the value :) >>>> >>>> But I agree an application is very unlikely call replaceWithVersion with the >>>> same value as before, so +1 to document it for now and implement >>>> replaceWithVersion/replaceWithPredicate in the embedded cache for 8.0. >>>> >>>> Cheers >>>> Dan >>>> >>>> >>>> On Thu, Nov 13, 2014 at 3:08 PM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: >>>>> I agree with Galder, fixing it is not worth the cost. >>>>> >>>>> Actually, there are often bugs that I'd call rather 'quirks', not >>>>> honoring the ConcurrentMap contract (recently we have discussed with Dan >>>>> [1] and [2]) which are quite complex to fix. Another one that's >>>>> considered not a bug is that a read does not have transactional semantics. >>>>> Galder, where will you document that? I think that special page in >>>>> documentation should accumulate such cases, linked to JIRAs for case >>>>> that eventually we'll resolve them (with that glorious MVCC). And of >>>>> course, link from javadoc to this document (though I am not sure whether >>>>> we can correctly keep that in sync with latest release. Could we have a >>>>> redirection from http://infinispan.org/docs/latest to >>>>> http://infinispan.org/docs/7.0.x/ ? >>>>> >>>>> Radim >>>>> >>>>> [1] https://issues.jboss.org/browse/ISPN-3918 >>>>> [2] https://issues.jboss.org/browse/ISPN-4286 >>>>> >>>>> On 11/13/2014 01:51 PM, Galder Zamarreño wrote: >>>>>> Hi all, >>>>>> >>>>>> Re: https://issues.jboss.org/browse/ISPN-4972 >>>>>> >>>>>> Embedded cache provides atomicity of a replace() call passing in the >>>>>> previous value. This limitation might be lifted when we adopt Java 8 and we >>>>>> can pass in a lambda or similar, which can be executed right when the value >>>>>> is compared now, and if it returns true it’s applied. The lambda could >>>>>> compare both value and metadata for example. >>>>>> >>>>>> Anyway, given the current status, I’m considering whether it’s worth >>>>>> fixing this particular issue. Fixing the issue would require adding some >>>>>> kind of locking in the Hot Rod server so that the version retrieval, >>>>>> comparison and replace call, can all happen atomically. >>>>>> >>>>>> This is not ideal, and on top of that, as Radim said, the chances of >>>>>> this happening in real life are limited, or more precisely it’s effects are >>>>>> minimal. In other words, if two concurrent threads call replace with the >>>>>> same value, the end result is that the new value would be stored, but as a >>>>>> result of the code, both replaces would return true which is not strictly >>>>>> right. >>>>>> >>>>>> I’d rather document this than add unnecessary locking in the Hot Rod >>>>>> server where it deals with the versioned replace call. >>>>>> >>>>>> Thoughts? >>>>>> -- >>>>>> Galder Zamarreño >>>>>> galder(a)redhat.com >>>>>> twitter.com/galderz >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> infinispan-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>>> -- >>>>> Radim Vansa <rvansa(a)redhat.com&gt; >>>>> JBoss DataGrid QA >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev