[infinispan-dev] Eviction in Infinispan

Manik Surtani manik at jboss.org
Tue Mar 24 11:45:20 EDT 2009


On 24 Mar 2009, at 15:02, Brian Stansberry wrote:

<SNIP />

>>> 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.

Yes, LFU.

>>> 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.

Right.  I have this in the form of lifespans, which can be set either  
cache-wide or per-entry.

> 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.

I've found a way to introduce it easily enough with minimal impact/ 
cost.  It would sit alongside lifespan, as a maxIdle time.

>
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090324/ac22c91c/attachment-0001.html 


More information about the infinispan-dev mailing list