[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=13453551#comment-13453551 ] 

Pedro Ruivo commented on ISPN-8204:
-----------------------------------

There are many changes in semantic. {{IRV}} flag with non-condition removal will create a {{RemoveCommand}} with {{LoadType}} {{DONT_LOAD}}:
* the context entry isn't mark as read (skips WriteSkew check)
* the value isn't loaded from cache loader if it doesn't exists in {{DataContainer}}
* if the entry doesn't exists in context, it won't be loaded from remote node
* it doesn't create a {{SuccessfulResponse}} (doesn't send the return value)
* in a transaction, it doesn't perform the remote get.

My point is that we lose all the {{IRV}} behavior, and that isn't good IMO. If we go we this changes, we can remove the flag (it is only used in {{put(k,v)}} and create a {{set(k,v)}} method. At least, it can remove a couple of if-branches in the code...

Also, I would like to know what others think about it. If I'm the only one thinking this way, there is no point in waste time to discuss it :)

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