什么是使用Session.SyncRoot每会话锁定的危险？ [英] What are the dangers of using Session.SyncRoot for locking per session?

问题描述

我有以下code的竞争条件，如果两个请求进来确实在ASP.NET MVC应用程序并拢：

I have a race condition with the following code if two requests come in really close together in an ASP.NET MVC app:

var workload = org.Workloads.SingleOrDefault(p => ...conditions...);
if (workload == null) {
    workload = org.CreateWorkload(id);
}

工作量和组织是的EntityFramework对象。到 CreateWorkload 调用数据库中添加一行到工作负载表。 （我们确实应该对表的唯一约束强制执行这一点，但我现在该表中有一些脏数据不能。的）的后续调用包含此$ C $操作方法ç抛出一个异常时，的SingleOrDefault 遇到多个行满足条件。

workload and org are EntityFramework objects. The call to CreateWorkload adds a row to a Workloads table in the database. (We really should enforce this with a UNIQUE constraint on the table, but I can't now that the table has some dirty data in it.) Subsequent calls to the Action method that contains this code throws an exception when SingleOrDefault encounters more than one row satisfying the conditions.

因此​​，要解决这个问题，我想锁定 code的这些行。我不希望它每次请求完成的，静态锁定对象，因为这会减慢下来站点为每个用户。我想要做的就是使用<一个href=\"http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28SYSTEM.WEB.HTTPSESSIONSTATEBASE.SYNCROOT%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK,VERSION=V4.0%22%29;k%28DevLang-CSHARP%29&rd=true\"相对=nofollow> Session.SyncRoot 锁定。即。

So to fix this, I want to lock these lines of code. I don't want it done per request, with static lock object because that slows the site down for every user. What I'd like to do is use Session.SyncRoot for locking. I.e.

Workload workload;
lock (Session.SyncRoot) 
{
    workload = org.Workloads.SingleOrDefault(p => ...conditions...);
    if (workload == null) {
        workload = org.CreateWorkload(id);
    }
}

我不是一个ASP.NET专家，但是，也有显示出来的文档和ReSharper的，即它可以抛出NotImplementedExceptions或为空一些警示标志。然而，测试表明，这工作得很好。

I'm not an ASP.NET expert, however, and there are some warning signs showing up in the docs and ReSharper, namely, that it can throw NotImplementedExceptions or be null. However, testing shows that this works just fine.

所以，ASP.NET专家，有什么用Session.SyncRoot这个风险？作为替代方案，如果Session.SyncRoot是真正的风险，可能我对分配会话的会话集合中锁定的对象启动做同样的事情？

So, ASP.NET experts, what are the risks of using Session.SyncRoot for this? As an alternative, if Session.SyncRoot is "really risky", could I assign a lock object in the Session collection on Session start up to do the same thing?

推荐答案

的危险只存在如果使用自定义会话类，它实现 HttpSessionStateBase ，但不会覆盖 SyncRoot上属性做多抛出一个NotImplementedException以外的东西。在 <一个href=\"http://msdn.microsoft.com/en-us/library/system.web.httpsessionstatewrapper.syncroot%28v=vs.100%29.aspx\"相对=nofollow> HttpSessionStateWrapper 类和 <一个href=\"http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.syncroot.aspx\"相对=nofollow> HttpSessionState 类都实现并重写 SyncRoot上方法。所以，只要你所访问通过 HttpSessionStateWrapper 或 HttpSessionState 类，而不是一个自定义类，这个会话会工作得很好。

The danger only exists if you use a custom session class that implements HttpSessionStateBase but doesn't override the SyncRoot property to do something other than throw a NotImplementedException. The HttpSessionStateWrapper class and the HttpSessionState class DO implement and override the SyncRoot method. So, as long as you're accessing the Session via the HttpSessionStateWrapper or HttpSessionState classes and not a custom class, this will work just fine.

这篇关于什么是使用Session.SyncRoot每会话锁定的危险？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！