On 26 Nov 2014, at 13:33, Sanne Grinovero <[email protected]> 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. ^ We support this and it works: https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ReplaceWithVersionConcurrencyTest.java > 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> twitter.com/galderz >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> -- >>> Radim Vansa <[email protected]> >>> JBoss DataGrid QA >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
