[
https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin....
]
Pedro Ruivo commented on ISPN-8204:
-----------------------------------
Well, IMO the {{remove()}} should be non-conditional. It would have a simplified code path
(always successful and same value matcher) and a simplified topology change handling
(without the issues related to conditional commands) and it can respect the {{skip_load*}}
(and related) flags. Of course we would have to send the commands to the backups and
interact with persistence every time...
None of the approaches will have the advantage in all scenarios (existing vs non-existing
key). So, we can choose a scenario to optimize and go for the approach that works better
in that scenario.
Remove should be conditional
----------------------------
Key: ISPN-8204
URL:
https://issues.jboss.org/browse/ISPN-8204
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking
the command as unsuccessful, not writing the cache store and not replicating the change to
backup owners. That makes the command effectively conditional (as it checks previous
value), in the same way as {{cache.replace(k, newValue)}} is.
While I think that this is the correct behaviour, it's a breaking change for
transactions. Some transactions may become read-only and there are multiple tests in the
testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)