6:33 a.m.
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> 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> 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>
> 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