安全HttpContext.Current.Cache用法 [英] Safe HttpContext.Current.Cache Usage

问题描述

我使用的缓存在这样的Web服务方法：

I use Cache in a web service method like this :

var pblDataList = (List<blabla>)HttpContext.Current.Cache.Get("pblDataList");
            if (pblDataList == null)
            {
                var PBLData = dc.ExecuteQuery<blabla>(
    @"SELECT blabla");

                pblDataList = PBLData.ToList();

                HttpContext.Current.Cache.Add("pblDataList", pblDataList, null, DateTime.Now.Add(new TimeSpan(0, 0, 15)), Cache.NoSlidingExpiration, CacheItemPriority.Normal, null);

            }

我不知道是不是线程安全的？我的意思是该方法是由多个请求者调用，不止一个请求者可以在同一时间击中了第二条线，而缓存为空。因此，所有这些请求者将检索的数据，并添加到高速缓存。查询需要5-8秒。可以围绕这个代码周围lock语句阻止行动？ （我知道多个查询不会造成错误，但我想，以确保只运行一个查询。）

I wonder is it thread safe? I mean the method is called by multiple requesters And more then one requester may hit the second line at the same time while the cache is empty. So all of these requesters will retrieve the data and add to cache. The query takes 5-8 seconds. May a surrounding lock statement around this code prevent that action? (I know multiple queries will not cause error but i want to be sure running just one query.)

推荐答案

缓存对象线程安全的但 HttpContext.Current 将无法从后台线程。这可能会或可能不会适用于你在这里，这是一个从不明显的代码段无论是否实际使用后台线程，但如果你是现在还是在将来的某个时候决定，你应该记住这一点。

The cache object is thread-safe but HttpContext.Current will not be available from background threads. This may or may not apply to you here, it's not obvious from your code snippet whether or not you are actually using background threads, but in case you are now or decide to at some point in the future, you should keep this in mind.

如果有任何机会，你需要从后台线程访问缓存，然后使用的 HttpRuntime.Cache 来代替。

If there's any chance that you'll need to access the cache from a background thread, then use HttpRuntime.Cache instead.

此外，虽然上的缓存个别操作是线程安全的，顺序查找/存储操作显然不是原子。无论你的需求的他们是原子依赖于特定的应用程序。如果它可能是同一查询多次运行一个严重的问题，也就是说，如果它会产生更多的负荷比你的数据库可以处理，或者如果它是一个问题的请求返回在立即覆盖数据缓存，那么你可能会希望把整个代码块左右的锁。

In addition, although individual operations on the cache are thread-safe, sequential lookup/store operations are obviously not atomic. Whether or not you need them to be atomic depends on your particular application. If it could be a serious problem for the same query to run multiple times, i.e. if it would produce more load than your database is able to handle, or if it would be a problem for a request to return data that is immediately overwritten in the cache, then you would likely want to place a lock around the entire block of code.

然而，在大多数情况下，你真的要分析第一，看看是否不这其实是一个问题。大多数Web应用/服务不与高速缓存的该方面关心自己，因为它们是无状态的，并且如果高速缓存被覆盖不要紧

However, in most cases you would really want to profile first and see whether or not this is actually a problem. Most web applications/services don't concern themselves with this aspect of caching because they are stateless and it doesn't matter if the cache gets overwritten.

这篇关于安全HttpContext.Current.Cache用法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！