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
