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

Entries not committed w/ DistLockingInterceptor and L1 caching disabled.

XMLWordPrintable

      If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.

      The problem is in the commitEntry method.

      boolean doCommit = true;
      if (!dm.isLocal(entry.getKey())) {
      if (configuration.isL1CacheEnabled())

      { dm.transformForL1(entry); }

      else

      { doCommit = false; }

      }
      if (doCommit)
      entry.commit(dataContainer);
      else
      entry.rollback();

      For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.

      We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.

      To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.

            wburns@redhat.com Will Burns
            shane_dev_jira Shane Johnson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: