Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-3918

Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer


    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • 6.0.0.Final
    • Core, State Transfer

      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.

            Unassigned Unassigned
            dberinde@redhat.com Dan Berindei (Inactive)
            0 Vote for this issue
            3 Start watching this issue