Support CacheErrorHandler in TransactionAwareCacheDecorator - #37289
Open
harrisleesh wants to merge 1 commit into
Open
harrisleesh wants to merge 1 commit into
harrisleesh wants to merge 1 commit into
Conversation
A CacheErrorHandler configured via CachingConfigurer only applies within intercepted cache invocations. With transaction-aware caching, put, evict and clear operations are deferred to the after-commit phase and run outside the intercepted invocation, so failures of the deferred operations bypass the configured error handler and propagate to the caller of the transaction commit. In particular, this prevents suppressing cache backend outages via LoggingCacheErrorHandler. TransactionAwareCacheDecorator now optionally accepts a CacheErrorHandler to invoke for put, evict and clear failures in the after-commit phase. AbstractTransactionSupportingCacheManager exposes a corresponding errorHandler property, applied when decorating caches for transaction awareness. Without an error handler, failures are propagated as before. Closes spring-projectsgh-28554 Signed-off-by: seonghun lee <harrisleesh@gmail.com>
spring-projects-issues
added
the
status: waiting-for-triage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
CacheErrorHandlerconfigured viaCachingConfigureronly applies within intercepted cache invocations. With transaction-aware caching,put/evict/clearare deferred to the after-commit phase and run outside the intercepted invocation, so failures of the deferred operations bypass the configured error handler and propagate to the caller of the transaction commit — as reported in gh-28554, this prevents suppressing cache backend outages (e.g. Redis timeouts) viaLoggingCacheErrorHandler.This PR follows the direction of the reporter's earlier attempt and completes the wiring question left open there:
TransactionAwareCacheDecoratorgains an optionalCacheErrorHandlerconstructor argument, invoked forput/evict/clearfailures in the after-commit phase. Without a handler, failures propagate exactly as before — no behavior change for existing usage.AbstractTransactionSupportingCacheManagerexposes a matchingerrorHandlerproperty, applied indecorateCache(..), so cache manager implementations that extend it (e.g.RedisCacheManager) and integration layers (e.g. Boot's auto-configuration) can propagate the interception-level handler to the decorator.Tests cover handler invocation for all three deferred operations and pin the existing propagation behavior when no handler is configured.
Closes gh-28554