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

[Radim Vansa (JIRA)]

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

Radim Vansa commented on ISPN-8204:
-----------------------------------

1) I am removing value matchers in ISPN-7590, and I speak only about changes including version history
2) What is different for conditional commands with regards to topology changes?
3) SKIP_CACHE_LOAD (if you meant that) will be respected. IGNORE_RETURN_VALUE won't prevent cache loading anyway, we need previous value for listeners and we can't know ahead if we'll need the previous value until it's too late. WSC would be executed less times (nothing changes for regular case, and we won't run it when the remove is a no-op).

I don't see any disadvantages; the only problem I see so far is how expiration listeners rely on this in dist mode.

> 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)