3 Replies Latest reply on Nov 22, 2010 11:25 AM by manik

    Data inconsistency across nodes with transactions

    gupabhi

      I have a cache in replication mode across 2 nodes (A and B).

       

      Node A has transactions enabled with useEagerLocking="true". Node B does not have transactions enabled.

      Here are the operations I perform -

       

      "keyX" already exists in the cache, visible from both nodes.

       

      1. NODE A :  tx.being()

      2. NODE A :  remove("keyX")

      3. NODE B : remove ("keyX")

          (at this time node B waits to acquire the lock)

      4. NODE A :  tx.rollback()

      5. NODE B: (successfully completed operation 3)

       

      6. NODE B:  get("keyX")

         ==> This returns a value! "keyX" is not actually removed !

      7. NODE A:  get("keyX")

         ==> This returns a value! "keyX" is not actually removed !

       

      This seems incorrect. At 5. when the node B returns successfully from the remove, it should have actually removed the entry from the cache. Please confirm you believe this is an issue too and I'll be glad to open a jira.

       

       

      Thanks,

      Abhi    

        • 1. Re: Data inconsistency across nodes with transactions
          manik

          This is an invalid config.  If some nodes use transactions, all nodes must have transactions enabled.

          • 2. Re: Data inconsistency across nodes with transactions
            gupabhi

            Thanks for the reply Manik.

             

            A couple of points about this -

             

            1. Even when I configure transactions in cache B and run the above steps, 'keyX' does not get removed. Note that I do not actually begin any transaction in Node B. This is a valid use-case where depending on the user operation a node may or may not want to start a tx.

            Also, puts/gets etc seem to work just fine with the above configuration. I've just noticed the problem with 'remove'.

             

            2. I would actually think that it should be a valid use-case that some nodes support tx and others do not. I understand that this is not supported today but do you think it should be in the future?

             

            3. If this is an invalid config, it would be nice if it fails on startup of the 2nd cache. I have seen Infinispan fail-fast in a number of instances where config is invalid.

             

            Thanks,

            Abhi

            • 3. Re: Data inconsistency across nodes with transactions
              manik

              If it still fails, do you have a unit test to replicate this behaviour?