<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 10 Jun 2011, at 13:42, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:</div><div><br></div><div>BCHM analyses whether or not to evict stuff every time an operation (put, get, replace) is run, based on the configured eviction policy (LIRS, LRU or NONE). It does so by calling evictionStrategy.execute(), which returns a Set of hash entries removed from the BCHM.</div><div><br></div><div><a href="https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/BoundedConcurrentHashMap.java#L341">https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/BoundedConcurrentHashMap.java#L341</a></div><div><br></div><div>Note that execute() actually removes entries from the BCHM, so after execute() is called, these entries are no longer in the BCHM!</div><div><br></div><div>This is set is then sent to the EvictionManager </div><div><br></div><div><a href="https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManager.java#L61">https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManager.java#L61</a></div><div><br></div><div>which in turn passivates the evicted entries:</div><div><br></div><div><a href="https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManagerImpl.java#L189">https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManagerImpl.java#L189</a></div><div><br></div><div>So we have a window where the entry is neither accessible from memory or from a cache store, since it is "in-fly".</div><div><br></div><div>My proposed fix is to:</div><div><br></div><div>1) Make sure the PassivationManager is passed in to the DataContainer, and available to any EvictionStrategy</div><div>2) EvictionStrategies ensure passivation occurs *before* removing an entry from the BCHM</div></div></blockquote>Does this cover the following scenario?</div><div>1. thread1.get determines that K needs to be passivated </div><div>2. thread2 remove(k) removes it from memory</div><div>3. thread1. passivates it to disk then removes it from memory as well (no op)</div><div>4. thread3.read(k) returns a value - wrong.</div><div><br></div><div>I think this won't happen as along as we have a lock on K for the passivate-then-delete-from-data-container operation. AFIK we don't do that ATM.</div><div><br></div><br></body></html>