This will prevent concurrency when caching the redirects, but won't fully solve the issue, as the requests will "queue" up and re-fill the cache as soon as the previous lock is released. Given the right conditions (time to warm the cache, and amount of requests per second) won't this smoothen out the database load by spreading it over a longer time span (potentially of making some requests time out)?

Shouldn't we acquire the lock only if it's not already acquired by another request, in which case we should just wait until the lock is release and proceed without re-warming the cache?

@giannello Thanks for your review! I’ve made changes now to force write cache for redirects as previously it was deferred write at shutdown. And also added an extra check after lock is acquired so subsequent requests will not re-fill the cache.

I’m not sure about proceed without re-warming the cache as it could have some side effects. Let’s wait for @brusch suggestions.

The patch works as long as there's no cache write lock set during the first request that should write the item to the cache. If there's a write lock, the item doesn't get into the cache, so the 2nd (or any of the other requests) will not get the contents out of the cache, so we're in the same situation.

Related to: #4573

Let's wait with this PR until we have an answer to #4573 then we can decide if this is the right approach to solve the issue.