Uploaded image for project: 'JBoss Cache'
  1. JBoss Cache
  2. JBCACHE-806

Invalidation causes problems with otimistic data versioning and certain edge cases

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Duplicate Issue
    • Affects Version/s: 1.4.0.SP1
    • Fix Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Estimated Difficulty:
      High

      Description

      Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.

      From email conversations:

      Manik >>

      At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB. If CacheB has V2 already, the invalidation will fail. What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory. Am I correct?

      Max >>
      It wasn't the scenario I had in mind, but this one is probably also relevant.

      Manik >>
      Or is the scenario you're trying to paint more like:

      V2 put into CacheA. CacheB has V1, gets the invalidation msg, and V1 is evicted. Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache? This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.

      Max >>
      This is the scenario I had in mind yes.

        Gliffy Diagrams

          Activity

          Hide
          manik Manik Surtani added a comment -

          Solution:

          Use INV_SYNC and if a remote eviction fails with a data version mismatch on a remote node, propagate the exception back to the caller, fail any tx on the caller's side. This will create a 'network' of valid versions, even if the valid versions don't exist on the current node.

          Show
          manik Manik Surtani added a comment - Solution: Use INV_SYNC and if a remote eviction fails with a data version mismatch on a remote node, propagate the exception back to the caller, fail any tx on the caller's side. This will create a 'network' of valid versions, even if the valid versions don't exist on the current node.
          Hide
          manik Manik Surtani added a comment -

          Pls see attached test cases (now in JBoss Cache 1.4.0 branch test suite)

          This issue only seems to arise when using ASYNC invalidation. I see expected behaviour when using SYNC invalidation.

          Show
          manik Manik Surtani added a comment - Pls see attached test cases (now in JBoss Cache 1.4.0 branch test suite) This issue only seems to arise when using ASYNC invalidation. I see expected behaviour when using SYNC invalidation.
          Hide
          manik Manik Surtani added a comment -

          If this is the case, we could only recommend SYNC invalidation anyway (when using optimistic locking/data versioning) since in ASYNC mode we have no idea if a remote invalidation succeeds or not.

          Show
          manik Manik Surtani added a comment - If this is the case, we could only recommend SYNC invalidation anyway (when using optimistic locking/data versioning) since in ASYNC mode we have no idea if a remote invalidation succeeds or not.
          Hide
          manik Manik Surtani added a comment -

          Not treated as a bug.

          In the SYNC case, works as expected.

          In the ASYNC case, this would be unreliable anyway due to the async nature of the communication.

          Solution: Recommend using INVALIDATION_SYNC.

          Show
          manik Manik Surtani added a comment - Not treated as a bug. In the SYNC case, works as expected. In the ASYNC case, this would be unreliable anyway due to the async nature of the communication. Solution: Recommend using INVALIDATION_SYNC.
          Hide
          manik Manik Surtani added a comment -
          Show
          manik Manik Surtani added a comment - JBCACHE-1155

            People

            • Assignee:
              Unassigned
              Reporter:
              manik Manik Surtani
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development