Hello all. So as you know eviction changed pretty substantially from JBC3 but the overall design still remained the same. I'm proposing a radical change to the design, which we briefly discussed in Neuchatel. Here's a recap of what has changed already since JBC3: 1. ExpirationAlgorithm and ElementSizeAlgorithm dropped, unnecessary. Leaves us with {FIFO, LRU, MRU, LFU} 2. Eviction queue design improved to O(1) for most operations on most algorithms, except LFU (O(log n)) 3. Expiration treated as a top-level construct where lifespans for entries can be provided on a per-entry basis 4. Eviction watermarks are now exclusively size-based (numElements) and not time-based. 5. MinTTL still supported. Now here is how I want to change things further: 1. Drop MRU and LFU. I don't see MRU being useful except in very specific edge cases. LRU somewhat useful but very expensive. 2. Re-introduce a time-based watermark. Brian, this is where your thoughts are most useful - how do you see this being used? In passivation? 3. Get rid of the eviction queues. Unnecessary duplication of keys. The core datastructure can be refactoreed to provide an efficient, threadsafe lookup for entries, where entries are also ordered for eviction. 4. To support 3. and make it as efficient as possible, eviction may only be an approximation. (e.g., if items 1 - 10 are added in order, and 3 need to be removed based on FIFO, we may lose 7, 9 and 10 instead of 8, 9 and 10.). How much of a concern is this? (typical tradeoff of accuracy vs efficiency) Cheers -- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

>> 1. Drop MRU and LFU. I don't see MRU being useful except in very >> specific edge cases. LRU somewhat useful but very expensive. Did you mean "LFU somewhat useful"? If so, yeah, agreed.

>> 2. Re-introduce a time-based watermark. Brian, this is where >> your thoughts are most useful - how do you see this being used? >> In passivation? Theoretically it's important for passivation, but in practice I find it makes more sense to let the web/sfsb container decide what gets passivated. So don't let AS passivation drive this. For entity caching, supporting maxAge is very important as that allows guaranteed flushing of stale data from the cache; important in use cases where other systems may update the DB making the cache invalid, but the application is willing to accept that for a certain period.

Eviction based on time-since-last-access I think is more of a convenience. It helps shield users from needing to think about # of nodes; they can just reason "if this data hasn't been used in 5 minutes, I don't need it." A nice heuristic. With the flat structure the problem of reasoning about number of nodes is a bit less, since structural nodes are gone. My gut feeling on this is that eviction based on time-since-last- access is not strictly necessary but if you take it away you'll get lots of grumbling.