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

[Sanne Grinovero]

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 at gmail.com> 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 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
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev