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

Observing non-final values on backup owner

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • None
    • Core

      Regardless of storing command invocations, reading value on backup owner in non-tx cache can always lead to publishing value that should not ever been in the cache:

      1. initial value is A
      2. T1 calls replace A -> B, backup stores this value, primary is delayed
      3. T2 reads value B
      4. T3 puts C, currently blocked at primary
      5. topology change, both T1 and T3 have to retry
      6. T3 retries and updates both primary and backup
      7. T1 retries and returns false, because the current value is C, not A

      Therefore, B should have never been stored in the cache but it was observed there.

      Recording the operation T1 on primary cannot help, because we would be in a similar situation if primary crashed and we had two backups - the backup that becomes primary might not have received the operation at all.

              rvansa1@redhat.com Radim Vansa (Inactive)
              rvansa1@redhat.com Radim Vansa (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: