On 26 November 2014 at 14:17, Dan Berindei <[email protected]> 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 <[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. >> >> 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 > > _______________________________________________ > 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
