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

putForExternalRead to L1 not invalidated

    XMLWordPrintable

Details

    • Bug
    • Resolution: Obsolete
    • Major
    • None
    • 5.2.1.Final
    • Core
    • None
    • Hide

      With empty caches.
      1. Node A reads v1 from some data store, then calls cache.putForExternalRead(k,v1). A doesn't own k.
      2. Node B then calls cache.put(k,v2). B is the owner of k.
      3. Node A's copy of k is never invalidated.

      Show
      With empty caches. 1. Node A reads v1 from some data store, then calls cache.putForExternalRead(k,v1). A doesn't own k. 2. Node B then calls cache.put(k,v2). B is the owner of k. 3. Node A's copy of k is never invalidated.

    Description

      With transactional distributed caches it happens that Cache.putForExternalRead(k,v) places an entry into L1 that never gets invalidated. It seems to happen when the the owner of k doesn't have the entry. In this case the non owner puts k into his cache without having the owner registering this. Usually the owner stores all requesters in L1ManagerImpl.addRequester and sends out invalidations to the requesters. What should happen is that the entry is replicated to the owner.

      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

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: