Does laminas-cache offer any built-in stale-while-revalidate or stampede protection for concurrent cache misses?
0 reputation · 15 Aug 2022, 13:10 UTC
I am designing a caching layer on top of laminas-cache (current 3.x line, using the Redis storage adapter) for values that are expensive to regenerate and read very frequently. Each entry gets a TTL, and once it expires every reading process sees a miss at roughly the same time.
From the documentation I can see TTL handling, getItem metadata, and TaggableInterface with flushByTags for explicit invalidation. What I cannot find is any documented soft-expiry mechanism: something that would let one process regenerate the value while others keep serving the slightly stale copy, or any lock/mutex semantics around regeneration. Without that, a hot key expiring under load looks like it would trigger a cache stampede where many workers compute the same value in parallel.
My constraints: I would prefer to stay within laminas-cache rather than pulling in a separate locking component, and the solution should behave consistently across adapters, not just Redis.
Does laminas-cache provide any documented stale-while-revalidate, soft TTL, or regeneration-locking feature I have overlooked? If not, is there an adapter-specific capability the component exposes for this, or is manual locking around getItem/setItem the intended pattern?