I’ve started a SourceForge project: http://sourceforge.net/projects/ehcache-zen/

@VA, @Robert, @oby1, @Lee, and others, please check it out and let me know on the forums there your feedback.

We have exactly the same problem – retrieve stale data from ehcache. Please post your code, it will be really helpful to all facing the same problem.

Regards,
VA

Hi oby1,

Yes, I opened a thread in the forums and there was some discussion on it: http://sourceforge.net/forum/forum.php?thread_id=3334621&forum_id=322278

I have been working on a different project since posting this but will be getting back to this in a few weeks. At that time, I plan to subclass SelfPopulatingCache and do the following:

1) Configure the cache to be “eternal” but configure the TTL and TTI according to how I actually want the expiration to work.

2) Override “public Element get(final Object key) throws LockTimeoutException” to implement a custom expiry check that ignores “eternal” but does evaluate the TTL and TTI. If the requested element should be expired, will call factory.createEntry(key), but if that throws an exception, will return any existing element rather than empty the cache and return null.

3) Create a new method “public Element refresh(Object key, boolean quiet) throws CacheException” method to allow refreshing objects individually from an asynchronous background thread.

I will post the code once it’s complete.

Regards,
Brian

I am trying to implement a cache that will continue to return stale objects if it is unable to obtain a newer version. (I.e., something old is better than nothing.) This seems to me like it might be a commonly required pattern, and I’m curious if anyone has come up with a solution using ehcache.

I want to use the SelfPopulatingCache to avoid having the client API dealing with the task of putting elements into the cache. But most importantly, elements would never be evicted from the cache for being stale unless a newer replacement element can be obtained first. Obviously, elements could still be evicted for size constraints, but in my application, the cache will be sized to avoid this.

I am currently considering using the SelfPopulatingCache code as a starting point to make my own subclass of BlockingCache that implements the desired behavior. During get(), it would check if the retrieved element was expired and if so invoke CacheEntryFactory.createEntry(key) to obtain a new entry. But if that call fails, it would still return the expired element. Most importantly, though, I need to figure out how to prevent the backing cache from removing the element when I call super.get(key), so that it is available to subsequent calls as well. Unfortunately, there seems to be no good extension point to make this change.

What I am currently leveraging is the “eternal” attribute in cache configuration, for an unintended purpose. Luckily it is unnecessary if the TTL and TTI parameters are set to 0. So I am setting my caches to eternal=true and configuring the TTL and TTI to set the timeouts I actually desire. Then in my custom subclass of BlockingCache, the backing cache will never remove an element, and I am writing an isExpired(Element) method based on element.isExpired() and to use instead of it. In this method, I will ignore the eternal setting but still evaluate the other expiry rules.

I’m a little concerned about how to properly handle threading issues, as I see that Cache synchronizes on element before calling element.isExpired().

It also seems unfortunate that there isn’t just a configuration flag on Cache to specify whether objects are expired on get() or not. Since the get() caller always has the ability to perform element.isExpired() and cache.remove(key) if needed, it seems like just a simple configuration flag to turn off eviction during get() would allow many more flexible usage patterns to be created.

Anyhow, I’d love to get thoughts or suggestions from others who have tackled this.

> Furthermore, the construct caches are not designed for extension:
> we wanted to make an asynchronously updating cache (which would
> return expired values while the real value was updated),

…and found the same limitation with extensibility. This seems to me like it might be a commonly required pattern, and I’m curious if anyone has come up with a solution using ehcache. I also want to use the SelfPopulatingCache to avoid client API coupling to the task of putting elements. But most importantly, elements would never be evicted from the cache for reasons of staleness unless a newer replacement element could be obtained first. Obviously, elements could still be evicted for reasons of space constraint, but in my application, the cache will be sized to avoid this.

I am currently considering using the SelfPopulatingCache code as a starting point to make my own subclass of BlockingCache that implements the desired behavior. During get(), it would check if the retrieved element was expired and if so invoke the CacheEntryFactory.createEntry(key) to obtain a new entry. But if that call fails, it would still return the expired element. Most importantly, thought, I need to figure out how to prevent the backing cache from removing the element when I call super.get(key), so that it is available to subsequent calls as well. Unfortunately, there seems to be no good extension point to make this change.

What I am currently leveraging is the “eternal” attribute in cache configuration, for an unintended purpose. Luckily it is unnecessary if the TTL and TTI parameters set to 0. So I am setting my caches to eternal=true and configuring the TTL and TTI as I actually desire. Then in my custom subclass of BlockingCache, the backing cache will never remove an element, and I am writing a isExpired(Element) method based on and to use instead of element.isExpired(). In this method, I will ignore the eternal setting but still evaluate the other expiry rules.

I’m a little concerned about threading issues, as I see that Cache synchronizes on element before calling element.isExpired(). It also seems unfortunate that there isn’t just a configuration flag on Cache to specify whether objects are expired on get() or not. Since the get() caller always has the ability to perform element.isExpired() and cache.remove(key) if needed, it seems like just a simple configuration flag like this would allow much more flexible usage patterns to be created.

Anyhow, I’d love to get thoughts or suggestions from others.

I am debugging through the hibernate source and I see that hibernate tries to cache objects every time on retrieval. Also once the objects are put into the cache they are no longer replaced. All this is fine. But I do not see the objects being retrieved from the cache at any point (neither before the hydration not after that).

Any pointers?