Chris Bonham opened SPR-9275 and commented

Currently there is no explicit exception handling in the cache abstraction. For example, when an external cache server is not available, the exceptions are just sent back to the calling class. I propose changing the caching abstraction to catch the exception and then invoke the underlying method.

Affects: 3.1.1

Issue Links: - #13933 Add @Cacheable implementation support for exception handling allowing the service method to be called instead of letting the provider exception to break the service ("is duplicated by") - #16165 Support of ehcache's BlockingCache

Referenced from: commits https://github.com/spring-projects/spring-framework/commit/05e96ee44817d40c7a60734bd4b8ec577d6e5194

9 votes, 14 watchers

Comment From: spring-projects-issues

Chris Beams commented

Added @Costin as a watcher.

Costin, did you consider anything like this when initially working on the caching abstraction? It does seem reasonable to at least make error behavior configurable, i.e. what to do when the cache provider is unavailable. Options could include (a) hard failure, i.e. propagate the exception, (b) log the exception and invoke the underlying method, (c) allow optional user-provided error handling strategy.

Comment From: spring-projects-issues

Adriano Andrulis commented

Hi Chris, I would be glad to see this coming trough, is it possible to volunteer my time to try and fix it? What's the procedure for such offer?

Kind regards.

Comment From: spring-projects-issues

Chris Beams commented

Hi Adriano. You're certainly welcome to take a shot at it -- thanks for offering! Read and follow the contributor guidelines to understand how to put together a pull request.

Since this isn't just a minor bug fix, but rather an improvement involving a bit of design, I would recommend that you put together as basic an implementation as possible (along with test cases) and submit the pull request early to solicit feedback. That way, if there's something about the approach that doesn't work, you don't put too much effort in before finding out.

Comment From: spring-projects-issues

Adriano Andrulis commented

Thanks Chris, I will download the source and try to make the proposed design implementation as soon as possible.

Comment From: spring-projects-issues

Bill Koch commented

Hi Chris,

I took a shot at implementing a FailSafeCache that will gracefully catch Exceptions thrown by the native cache implementation and simply logs them. Pull Request #138 has the details of my changes. Any feedback would be greatly appreciated!

Thanks!

Comment From: spring-projects-issues

Bill Koch commented

My proposed changes only help CacheManager implementations that extend the AbstractCacheManager. For those that don't, (namely the RedisCacheManager, although there very well could be others), this functionality can be added by leveraging the FailSafeCache wrapper that I use in the AbstractCacheManager. I'd be more than happy to apply this pattern to the RedisCacheManager and submit another pull request to the spring-data-redis project.

Thanks again!

Comment From: spring-projects-issues

Narendranath Krishnamurthy commented

@Chris Beams

Eager to know if this ticket still waiting for triage or fixed?

Comment From: spring-projects-issues

Daniel Faria Gomes commented

Eager to know if this ticket still waiting for triage or fixed? +1

Comment From: spring-projects-issues

Stéphane Nicoll commented

Hi everyone,

This issue has not been fixed. I like how Chris Beams described it in its original comment which seems to isolate this change in the transparent processing of cache operation (i.e. annotated methods) rather than on the CacheManager directly as PR 138 suggests. Wrapping the CacheManager may be an option but I would rather go for a strategy interface that could be configured somewhere with one or more sensible implementations of it. Any input or idea you guys might have would be more than appreciated.

Thanks!

Comment From: spring-projects-issues

Stéphane Nicoll commented

A CacheErrorHandler strategy interface has been added and allows you to handle issues for cache-related operations. Offer callbacks for put, get, evict and clear for both Spring's and JCache's caching abstraction.

The error handler can be configured using CachingConfigurer (check CachingConfigurerSupport) or using the error-handler property of the annotation-driven XML element.

A default SimpleCacheErrorHandler is provided by default that just throws back any exception as it was the case before. It is suggested to override from this class if only one or a few callbacks should be overridden.

This is going to be available in the next 4.1.0.BUILD-SNAPSHOT. Give it a try and let me know if you have comments to improve it. Thanks!

Comment From: razorree

But that CacheErrorHandler doesn't solve this issue: Add @Cacheable implementation support for exception handling allowing the service method to be called instead of letting the provider exception to break the service [SPR-9295] as underlying service is not called in case of IO (or other) Exceptions from cache.

Comment From: snicoll

Not sure what you mean. We can't ignore such error by default so if it thrown back at you, you'll get that, yes. You can provide your own implementation of the handler though that would ignore certain exceptions (and that will be treated as if the entry does not exist).