# TransactionAwareCacheManagerProxy, and what it does not cover

cacheManager : org.springframework.cache.transaction.TransactionAwareCacheManagerProxy

nameOf(1) -> Alice
after the identical rollback, nameOf(1) -> Alice

The put was registered as a transaction synchronisation and dropped when the
transaction rolled back instead of committing.

--- what it does not cover: beforeInvocation = true ---
inside the same transaction, after an evict declared beforeInvocation=true,
a re-read returns : Bobby

Not the stale value. The eviction was NOT deferred, and the re-read went to
the database and saw the uncommitted row. The reason is in the bytecode:
AbstractCacheInvoker.doEvict(cache, key, immediate) calls evictIfPresent()
when immediate is true and evict() when it is false, and the decorator only
registers a post-commit synchronisation in evict() - evictIfPresent()
delegates straight to the target cache. See docs/output/22-decorator-bytecode.txt.

Two gaps do remain, and they are structural rather than measurable here:
reads are never deferred, so a @Cacheable lookup inside the transaction sees
whatever the shared cache holds; and outside a transaction the proxy is a
pass-through that writes immediately.