Terracotta Discussion Forums

I have a read-mostly application web application, and on top of that it is not absolutely critical that a read gets the very latest version if something has just changed.

What I want to do is, have a reasonably long TTL (e.g. 15 minutes to an hour), so that a popular resource will be in the cache most of the time when a GET request comes in. I also want to have the following rule: once an item has been put in the cache, I never want a GET to block for that item, even if it has expired (ignore evictions due to cache size, clearly these have to block). What I want to happen conceptually is something like: 1) HTTP GET request comes in for a web page; 2) servlet asks cache for an item; 3) cache notices item's TTL has expired, makes a mental note to refresh item; 4) cache returns stale item to the caller. At a different time or at least in a different thread so that the web page rendering is not slowed down: 5) cache gets the item from its "system of record" and puts it back in so it's no longer stale.

It seems like the SelfPopulatingCache can get me some of the way there, but as far as I can tell it will always block in step 3) in order to go get the item from its system of record. I'm not averse to writing some code to customize things, but I'm hopeful that there is a built-in recipe for doing this in Ehcache. If so, can someone point me somewhere or explain how I can achieve it? If not, maybe a hint about how I can write some subclasses or use cache events or some other way to accomplish my goal.

Here is one approach.
Use eventual consistency - This could be most useful with read only applications where occasional reads of state data is acceptable as long as you get the most recent version eventually. It would also never block for a GET.
Now comes the question of how do you update your cache entries without blocking on the GET. SelfPopulating cache is not an option as this would block. What you could do is have another Terracotta client "Refresh" the caches periodically and eventually (you could use open source Quartz module to achieve the periodic calls). These "refresh" calls could in turn query from your DB. This way your client would never be blocked.
Hope this helps.

Eventual consistency is what I want. When you refer to "another Terracotta client" that will do the refreshing, do you mean just a class that I write? I assume this means that there is no built-in mechanism for doing this in Ehcache?

I need to be careful because I want the cache to block for non-existent data, to avoid the "thundering herd", which is where the BlockingCache comes in. Is there any built-in cache that blocks for cache misses, but not for stale data? I will start poking around in the code to see where I could subclass and override to achieve my goal, but if there's already something that does it or comes close then that would be great.

When I meant another Terracotta client, I meant your custom application code that is also connected to TSA that would "refresh" the caches based on your requirements (instead of specifying TTI or TTL based approaches).

What you are asking is a custom business requirement - that can be easily achieved by writing a simple custom wrapper over Ehcache. Good luck with your implementation.

OK thanks for the responses. I'm not convinced it's a *simple* custom wrapper for someone unfamiliar with the ins and outs of Ehcache or writing caches in general, because of the issues around locking and concurrency. It seems like it would be easy to make a version that seemed like it worked, and then failed under some circumstances. But, I think it would be a useful "cache construct" in a lot of situations, so I will find some time to give it a try.

I've written a subclass of SelfPopulatingCache that achieves my goal (block for missing data, serve stale data immediately, background refresh). Is there an appropriate place where I can post the code? I would not mind some feedback on it, or at least it may help someone else who wants to achieve the same goal.