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

Invalid CacheStore content when using DIST_SYNC + shared CacheStore and Transactions

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

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 5.1.3.CR1, 5.1.3.FINAL
    • 5.1.2.FINAL
    • Core
    • None

      The attached file is an example to reproduce the situation:

      CM1 is started and a cache is filled up with some values. 2nd CM is now started and the same cache is filled there with values. As result I'd expect to have (in this case) 8 entries inside the cache store.
      When using JDBC cache store and looking into the logs, for some of the key added in the 2nd node (even if they are unique) he executes UPDATE queries instead of inserts...

      This only happens, when cache store is shared and transactions are enabled.

        1. XXX.java
          3 kB

            [ISPN-1908] Invalid CacheStore content when using DIST_SYNC + shared CacheStore and Transactions

            Galder Zamarreño added a comment -

            @Thomas, this is indeed a bug. What seems to happen is when DIST_SYNC and transactions are in use, if the originator should not store the data in the cache store, it skips it (which is right), but the owner of the data, which receives the prepare, is not actually calling into the cache store.

            Basically, when the prepare() is called locally, CacheStoreInterceptor.skip() returns false and so it's able to determine whether the put call should be stored or not. However, when that's executed remotely, it returns true and so the DistCacheStoreInterceptor is not able to check whether it's the owner of the key and it should store it. I'm trying to figure out a fix for this (i.e. override visitPrepareCommand in DistCacheStoreInterceptor...)

            Galder Zamarreño added a comment - @Thomas, this is indeed a bug. What seems to happen is when DIST_SYNC and transactions are in use, if the originator should not store the data in the cache store, it skips it (which is right), but the owner of the data, which receives the prepare, is not actually calling into the cache store. Basically, when the prepare() is called locally, CacheStoreInterceptor.skip() returns false and so it's able to determine whether the put call should be stored or not. However, when that's executed remotely, it returns true and so the DistCacheStoreInterceptor is not able to check whether it's the owner of the key and it should store it. I'm trying to figure out a fix for this (i.e. override visitPrepareCommand in DistCacheStoreInterceptor...)

              rh-ee-galder Galder Zamarreño
              tfromm_jira Thomas Fromm (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: