Aspnetcore.docs: Concurrency locking by key for the repopulation callback

[marchy]

Regarding repopulating the items and the 'This can result in several threads repopulating the cached item' point in the Additional notes section above, how can you ensure that only one thread invokes the cache repopulation at once?

In the warm-up sequence of our web app we happen to hit a ton of these all at once as we are pre-warming all sorts of routes which each hit common cache-key dependencies while being pulled from the API+DB. Since EF queries are non-warmed as well these all bundle up and can memory spike to the point of taking down the server, and it's not feasible to artificially stagger/throttle the warm-up requests in our case either as to prevent the concurrency need in the first place.

Any thoughts or guidance on how we could concurrency-lock the cache repopulation by key?
This seems like something that would be useful to be done out of the box, or at least with an opt-in setting/parameter/overload

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 13f5f8f9-18dd-9c12-9ed1-fcc6b44ba7fd
• Version Independent ID: 640b4f36-5886-7b69-1c95-cfc8574a02fd
• Content: Cache in-memory in ASP.NET Core
• Content Source: aspnetcore/performance/caching/memory.md
• Product: aspnet-core
• Technology: aspnetcore-performance
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[marchy]

Seems there is a long-running unsolved issue for this already here: https://github.com/aspnet/Extensions/issues/708

Microsoft team, any updates with roadmap on this? Having a cache that calls the expensive operation we are trying to protect from simultaneously goes against the very purpose caches are built in the first place. In a typical server warm-up scenario, where you want to fire off many common requests and make sure everything is cached and ready for production-slot-swapping --> this could even take down a server due to the immediate and heavy load on its resources.

The non-official workarounds to this are sufficiently risky (ie: not reliable/thread-safe, could potentially leak memory or deadlock) that this needs to be provided by Microsoft's implementation in a way we can be sure it is safe.

[pkellner]

There should be a "Note" on the docs at a minimum to say this is "worst practice" way to use cache. My preference would be to leave it out entirely rather than put a MyCache example that is just wrong and should not be used.