[
https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-8204:
-----------------------------------
Thing to consider is also the {{RemoveExpiredCommand}}. As clustered expiration listeners
in distributed mode rely on this being successful on primary owner, if that one does not
contain the entry (because it is expired on that node, too) the listener would not be
fired.
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, 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)