JBCACHE-880 discussion ...

[genman]

I came with a new Eviction strategy. The idea is to allow users to "put" an expiration time into a Node, and the cache will then evict the node at that time.

I went ahead and commited the changes already, but I'm not 100% pleased yet.

The things that I am not happy with are:

1. I used "Long(timestamp)" as the expiration time. It would make more sense ot have expiration indicated with a java.util.Date instead, except Date is a (little) heavier and not constant.
2. Most of the time, users want to use a relative time, e.g. 10 seconds or 10 days.
3. Expiration is indicated with a String field "expiration". (Although it's configurable, I don't see why people would want to change this.) Getting this string constant out results in code that looks kind of crappy.

Ideally, it would be better to have an API, such as:

Node.setTimeToLive(int amount, TimeUnit unit);

If this were Ruby, I'd add this method to the object at runtime. :-)

Anyway, perhaps this belongs in a Util class or a static method on some existing class? Thoughts?

[manik]

Is this not a very specific use case though? Is this generic enough to be included in the distro, or should this be a customisation? I say we see how many votes it gets. Let's talk about it as a feature on the user forum and invite people to vote on the JIRA task.

How would your impl (if you've already checked it in, could you please revert this for now?) work with existing eviction policies? Can we, for example, have a LRU policy running alongside a policy that clears up expired nodes?

[genman]

It's actually pretty common to want to cache values with a per node TTL.

Here are some references ...

http://ehcache.sourceforge.net/javadoc/net/sf/ehcache/Element.html#setTimeToIdle(int)
http://forums.tangosol.com/thread.jspa?threadID=1041&tstart=75
http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/web/filter/ExpiresRefreshPolicy.html

I'm actually surprised this isn't supplied as a base expiration policy.

I actually registered on the Tangosol to get this Javadoc:

com.tangosol.net
Interface NamedCache

put

Object put(Object oKey,
 Object oValue,
 long cMillis)

 Associates the specified value with the specified key in this cache and allows to specify an expiry for the cache entry.

And you want to vote on it?

[manik]

And there actually has been a thread on the user forum about this too, although I still think usage only makes sense for pretty specific cases.

About your implementation - how does this work with existing eviction policies? Also, why the use of an 'expiration' element, vs. a more explicit attribute on Node - Node.setTTL() or something?

And what are the semantics of this - millis since last accessed, millis since created, or expiry at a specific time? Perhaps this is best in the form of a pluggable policy too?

[genman]

And there actually has been a thread on the user forum about this too, although I still think usage only makes sense for pretty specific cases.

Web caching, session caching. JMS messages have expiration times. Almost every "business" object has some sort of lifespan or lifecycle.

Actually, I need it for my own specific application, and I don't see any better way. What's currently done is there's a timer that wakes up and scans a list of cached values and removes any ones past its expiration time.

Although it is fairly easy to implement as a plug-in, there's a lot of value of having it integrated and tested with the JBossCache product.

About your implementation - how does this work with existing eviction policies? Also, why the use of an 'expiration' element, vs. a more explicit attribute on Node - Node.setTTL() or something?

Adding an additional node element would require changing the interface for a fairly specific use case. It also increases the memory footprint of the Node.

And since this expiration value might need to be stored in a cache loader or replicated, it would also require changes to those areas.

setTTL() ultimately would likely have to call a series of interceptors, requiring more changes in TreeCache and everywhere ... I suppose it could simply translate into a "put()".

And what are the semantics of this - millis since last accessed, millis since created, or expiry at a specific time? Perhaps this is best in the form of a pluggable policy too?

Specific time is easier. TTL would be okay. But the question of replication comes up.

Perhaps I'm confusing eviction with removal? The specific time would be most useful as an indication for node removal, not for passivation.

Perhaps there should be a RemovalPolicy rather than EvictionPolicy?

Anyway, I'd appreciate you looking at the test cases.