[infinispan-issues] [JBoss JIRA] (ISPN-8204) Remove should be conditional

[Pedro Ruivo (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450867#comment-13450867 ] 

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)