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

[Dan Berindei]

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 at redhat.com> 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 at redhat.com
> > twitter.com/galderz
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20141120/3e2eb39e/attachment.html