Dan Berindei created ISPN-11116: ----------------------------------- Summary: Invalidation commands should not load the previous value from the store Key: ISPN-11116 URL: https://issues.redhat.com/browse/ISPN-11116 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 10.1.0.Final, 10.0.1.Final, 9.4.17.Final, 9.3.6.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 11.0.0.Final, 10.1.1.Final {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it. But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}. However, we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store. Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores. Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores. -- This message was sent by Atlassian Jira (v7.13.8#713008)