[infinispan-issues] [JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations
[
https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-5035:
-----------------------------------
I'd assume that the code using cache.replace would look like
{code}
Foo oldFoo = cache.get("foo");
Foo newFoo = new Foo(oldFoo).addBar("bar");
boolean succeeded = cache.replace("foo", oldFoo, newFoo);
{code}
As during replication any DeltaAware command parameter is replaced by Delta, currently we
would send cache.replace("foo", zero-delta, delta-with-bar) and get false since
zero-delta does not match the object. I think that we should not produce the zero-delta
from oldFoo (only the one with delta-with-bar), and the replace should work as if Foo did
not implement DeltaAware.
Anyway, I don't think I would like to use DeltaAware for such use-case anyway. My
concern is just that the API is not consistent.
DeltaAware support for conditional operations
---------------------------------------------
Key: ISPN-5035
URL: https://issues.jboss.org/browse/ISPN-5035
Project: Infinispan
Issue Type: Feature Request
Components: Core
Reporter: Radim Vansa
Current delta-aware approach is implemented only in PutKeyValueCommand and
ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware
commands - or rather it does not allow to return any kind of value (the condition itself
can be implemented inside the delta).
One use-case when this would be required is equivalent of AtomicLong.getAndIncrement().
Currently we can implement this using
{code}
Long previous;
do {
previous = cache.get(key);
} while (cache.replace(key, previous, previous + 1);
{code}
which requires at least two RPCs. With more generic interface, such as JCache's
EntryProcessor this could be implemented using single RPC.
(so, this JIRA is basically a request to native support for EntryProcessor)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)