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

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

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

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