[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