JBoss Cache
  1. JBoss Cache
  2. JBCACHE-806

Invalidation causes problems with otimistic data versioning and certain edge cases

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Duplicate Issue
    • Affects Version/s: 1.4.0.SP1
    • Fix Version/s: None
    • Component/s: Replication
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Estimated Difficulty:
      High
    • Similar Issues:
      Show 10 results 

      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.

        Activity

        Hide
        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 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 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 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 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 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 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 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 Surtani
        added a comment -
        Show
        Manik Surtani
        added a comment - JBCACHE-1155

          People

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

            Dates

            • Created:
              Updated:
              Resolved: