asmhatre
66208bcd97
A Spring Boot 4.1.1 module whose test suite is the evidence for the article: 19 tests producing 22 transcripts under docs/output/, plus 12 documentation chapters. Findings the build pins: - @EnableCaching has no exposeProxy attribute; the widely-copied @EnableCaching(exposeProxy = true) does not compile. - Two methods sharing a cache name and an argument type share a key space, and one silently serves the other's answers. - beforeInvocation = true is NOT deferred by TransactionAwareCacheManagerProxy on 7.0.9 - doEvict picks evictIfPresent, which the decorator does not intercept. - Four of five invalid declarations start a clean context and throw at the first call. - Caffeine on the classpath silently displaces the simple provider.
23 lines
804 B
Plaintext
23 lines
804 B
Plaintext
# A rollback does not roll the cache back
|
|
|
|
cacheManager : org.springframework.cache.concurrent.ConcurrentMapCacheManager
|
|
|
|
nameOf(1) -> Alice
|
|
|
|
An outer @Transactional method calls the @CachePut update, which succeeds,
|
|
and then fails on the next step. The transaction rolls back.
|
|
|
|
what the cache serves : Alice Cooper
|
|
what the database has : Alice
|
|
|
|
The cache is now holding a name that no transaction ever committed. Nothing
|
|
will correct it until the entry expires or something evicts it.
|
|
|
|
--- the same shape with @CacheEvict ---
|
|
nameOf(2) -> Bob
|
|
after the rollback, nameOf(2) -> Bob
|
|
database loads: 2 <- the entry was evicted, so this one reloaded
|
|
|
|
An eviction that fires too early is self-healing: the next read goes to the
|
|
database and re-populates correctly. A @CachePut that fires too early is not.
|