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

L1 inconsistency in tx caches when backup owner replies to remote get

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • Critical
    • 6.0.0.Final
    • 6.0.0.Alpha2
    • None

    Description

      Consider the following scenario

      node1: performs a remote get
node2 (backup owner): receives and replies to the remote get with v1
node1: receives the repli and store in L1_ key => v1
node2 (backup owner): commits a new value (v2) for the key (i.e. processes a commit command)
node3 (primary owner): sends the invalidation (but not for node1 because it hasn't received the remote get yet) and commits a new value (v2) for the key (i.e. processes a commit command) 
node3 (primary owner): replies to the remote get with v2
node1: ignores the reply because it used the node2 reply

      conclustion: node1 keeps the old value stored in L1.

      Possible solutions described here:
      L1 consistency for transactional caches

      Could also be interesting:
      Staggered get question
      and
      ISPN-825

      Attachments

        Issue Links

          blocks

          Bug - A problem that impairs or prevents the functions of the product. ISPN-3320 DistL1WriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKey fails randomly

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is duplicated by

          Bug - A problem that impairs or prevents the functions of the product. ISPN-3648 Inconsistent L1 in tx distributed cache

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed
          is related to

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) ISPN-3684 Improve L1 consitency with backup owners

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • To Do

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) ISPN-825 Consider staggering remote get requests when using DIST

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. ISPN-3617 Inconsistent L1 in non-tx distributed cache

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Activity

            People

              wburns@redhat.com Will Burns
              pruivo@redhat.com Pedro Ruivo
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: