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

L1 and early invalidation leaves inconsistent state

    XMLWordPrintable

Details

    Description

      In a distributed transactional cache with L1 enabled I can observe the following.
      Prepare cache by adding an entry with Cache.put( k, v1 ).
      1. Node B starts with adding a changed value. Cache.put( k, v2 )
      2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations.
      3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1.
      4. Node B proceeds with transaction.
      The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2.

      It seems the invalidation is either send to early or must be synchronized in some way with the transaction.

      Cache config:
      <namedCache name="entity">
      <jmxStatistics enabled="true" />
      <clustering mode="dist">
      <stateTransfer fetchInMemoryState="false" timeout="20000" />
      <async />
      <l1 enabled="true" />
      <hash numOwners="1"/>
      </clustering>
      <locking isolationLevel="READ_COMMITTED"
      lockAcquisitionTimeout="15000" useLockStriping="false" />
      <eviction maxEntries="10000" strategy="LRU" />
      <expiration maxIdle="100000" wakeUpInterval="5000"/>
      <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
      <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
      </namedCache>

      Attachments

        Issue Links

          Activity

            People

              wburns@redhat.com Will Burns
              sebastiantusk Sebastian Tusk (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: