Add caching: the Spring cache abstraction, keys, eviction timing and the self-invocation trap

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.
This commit is contained in:
2026-09-12 05:19:22 +00:00
parent 7e1676c763
commit 66208bcd97
76 changed files with 3710 additions and 0 deletions
+14
View File
@@ -0,0 +1,14 @@
# What SimpleKeyGenerator actually puts in the map
cache "shapes" after three calls with 0, 1 and 2 arguments:
cache "shapes":
key abc [String] -> one:abc
key SimpleKey [abc, 7] [SimpleKey] -> two:abc:7
key SimpleKey [] [SimpleKey] -> zero
Zero arguments -> the SimpleKey.EMPTY constant, printed as []
One argument -> that argument itself, unwrapped
Two or more -> a SimpleKey holding all of them
The method name and the declaring class appear nowhere in the key.