Consider storing a Task<> in cache tag

[rynowak]

We're wondering if the concurrency behavior of #CacheTag is quite right.

Since we store the computed content in a StringBuilder - on cache miss, every thread to reach that block needs to recompute the content. If the content takes a long time to compute, it could mean a lot of extra DB calls or just general processing.

It seems beneficial to have the cache store Task<> so that we can quickly address the 'miss' and have other threads aside from the one computing the data wait on the task.

[rynowak]

/cc @scanham

[sebastienros]

We do that in Orchard by locking on the cache key (String.Interned), and talking with Ryan Task is better in that case. Something else we do and might be worth considering is to continue to serve stale data if one thread is already processing the new value, which means only return the Task if there is no current value. This could be an option on the cache entry to opt-out this behavior.

Edit:
How we configure the stale data is by providing an option called Grace Time which is the delay after the cache expires that the stale data can be served. If 0 then you never serve stale data. If you set 10 seconds for instance then you can potentially get served some stale data (while one thread is processing the new value) 10 seconds after the expiration time.

[scanham]

Thanks for reporting this @rynowak! 👍

I really like that @sebastienros. That's a model I've used for caching layers in the past and would love to see it here too. I would want this behavior for every instance in which I'm using the CacheTag on my current project.