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