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
