[infinispan-issues] [JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

[Dan Berindei (JIRA)]

Dan Berindei created ISPN-3918:
----------------------------------

             Summary: Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
                 Key: ISPN-3918
                 URL: https://issues.jboss.org/browse/ISPN-3918
             Project: Infinispan
          Issue Type: Bug
          Components: Distributed Cache, Locking and Concurrency
    Affects Versions: 6.0.0.Final
            Reporter: Dan Berindei
            Assignee: Dan Berindei
             Fix For: 7.0.0.Final
         Attachments: ntpiadjst.log.gz

In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.

Say \[B, A, C] are the owners of k (C just joined)
1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
2. B forwards the command to A and C
3. C writes {{k=v1}} 
4. C becomes the primary owner of k (owners are now  \[C, A])
5. A/B see the new topology before committing and throw an outdatedTopologyException
6. A retries the command, sends it to C
7. C forwards the command to A, which writes {{k=v1}}
8. C doesn't have to update the entry, returns null

If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.

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