[infinispan-dev] Remote contains key instead remote get for unsafe return conditional operations?

galder at redhat.com galder at redhat.com
Wed May 19 12:10:42 EDT 2010


Hi,

Mircea and I have been discussing about https://jira.jboss.org/browse/ISPN-437 on IRC. In principle, using a flag like SKIP_REMOTE_LOOKUP to avoid remote lookups sounds like a good idea but as I said on the JIRA, I sometimes use those returns to find out whether the operation succeeded correctly, independent of the need of Hot Rod to send the previous value to the client.

Now, amongst others, I use returns of putIfAbsent, replace (2 versions), remove to find out whether the operation work correctly or not. However, although I need a return, as Mircea suggested, I don't need the actual previous value unless I need to send it back to the user. I need "something" that allows me to decide whether the operation worked fine.

If: 
- we take putIfAbsent as an example,
- client does not require previous value (this could be translated into sending SKIP_REMOTE_LOOKUP)
- we're in a distributed environment and
- key being operated is not local.

Then: I don't need to get the actual value for the key from another node. I need a remote node to tell me if the key exists because that's enough for the client to know whether the key is present or not and see if the put succeeds or not. Something to clarify is what putIfAbsent would actually return if the key had existed, particularly if the key was remote and we don't have the previous value (maybe some kind of flag/dummy value?)

As a FYI, currently putIfAbsent would not be reliable in the scenario above unless transactions were used (I have already another thread to find out why transactions are required). If no transactions are used, pIA call would not retrieve the key from another node.

replace(k, v) would require similar treatment as putIfAbsent. replace(k, old, v) and remove(k, v) would not need such flag/dummy since they return boolean values.

Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list