I have implemented a regular cache where the elements expire after 10 minutes. Once an element is expired, data is retrieve from the backend (say a remote source) again. The new element will be put back in the cache. So far nothing new.
However, If the backend system is not available at that time I would like to still serve cached data. The problem is that through the use of cache.get() my element has expired and remove from the cache already.
My idea now is to create a secondary infinite backup cache that holds the same data as my 10 min. cache but elements never really expire. If I need to get data from the backend and the backend fails to provide data I serve my request from this infinite backup cache.
Does this sound like a decent approach or does Ehcache provide something more clever and out of the box for this kind of problem?
That sounds like it will work - but the question is really around whether you are willing to pay the memory overhead with regards to maintaining an "infinite" cache and potentially impacting the run-time performance of the "regular" 10-minute TTL cache - just for the one very-low-probability event of the backend data-source becomes unavailable.
Given that under steady state you care about Data-Liveness (hence the 10 minute TTL) - I wouldn't recommend changing it. But then TTL can be changed at runtime - so what you could do is to detect that the backend data-source is unavailable and then modify the TTL of the cache to something much larger than 10 minutes - this way cache.get at least returns all the cache-values that were in the cache, at the time you modified the TTL.
Yes it (bumping TTL programmatically) is not going to help with already expired entries, but will help with preserving existing non-expired entries (but without any increased overhead in terms of maintaining a separate cache and additional memory needed for it).