[infinispan-issues] [JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-3422:
------------------------------------

These are the changes I made:
    * Replace the ignorePreviousValue flag with a ValueMatchingPolicy enum.
    * Set the matching policy to MATCH_EXPECTED_OR_NEW when retrying a
      putIfAbsent(k, value).
    * replace(k, expected, newValue) and remove(k, expected) will also be
      retried with MATCH_EXPECTED_OR_NEW.
    * Check the primary owner's response and update the status of the command.
      Only successful commands should be retried if the topology changes.

Regular put(k, value) still won't be atomic, because we don't keep the previous value around. Same as regular put(k, value), replace(k, newValue) and remove(k) won't be atomic.
                
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
>                 Key: ISPN-3422
>                 URL: https://issues.jboss.org/browse/ISPN-3422
>             Project: Infinispan
>          Issue Type: Bug
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>            Priority: Critical
>              Labels: 620, nbst
>             Fix For: 6.1.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira