Entries not committed w/ DistLockingInterceptor and L1 caching disabled. ------------------------------------------------------------------------ Key: ISPN-962 URL: https://issues.jboss.org/browse/ISPN-962 Project: Infinispan Issue Type: Bug Components: Distributed Cache, Locking and Concurrency Affects Versions: 4.2.0.Final Reporter: Shane Johnson Assignee: Manik Surtani 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira