Does laminas-cache offer any built-in stale-while-revalidate or stampede protection for concurrent cache misses?

Question

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?

Siddharth · Answer

Direct answer
No, laminas‑cache 3.x does not include a built‑in stale‑while‑revalidate or stampede‑prevention mechanism.
Why this is the case
The component treats an expired entry as a miss; once the TTL passes the item is removed and the application must regenerate it. There is no soft‑expiry flag, no automatic stale‑while‑revalidate response, and no cross‑adapter lock primitive exposed in the core API.
Verification steps

Inspect StorageInterface and CacheItemPoolInterface for methods that return a stale value or acquire a lock; none are defined in the core documentation.
Review the Redis storage adapter configuration – its set and get methods implement hard TTL only; no soft‑TTL or atomic compare‑and‑set options are exposed.
Run a controlled load test: configure a short TTL on a hot key, issue concurrent getItem calls from several threads, and observe that each thread recomputes the value, confirming a stampede.

If you need to know whether your Redis deployment supports a client‑side compare‑and‑set or Lua‑script‑based lock, verify that option; otherwise manual locking around getItem/setItem remains the recommended pattern.

Does laminas-cache offer any built-in stale-while-revalidate or stampede protection for concurrent cache misses?

1 answer

Direct answer

Why this is the case

Verification steps

Your perspective belongs here.

0 question comments