使用Session.SyncRoot锁定每个会话的危险是什么？

Question

如果两个请求在ASP.NET MVC应用程序中非常接近，我有以下代码的竞争条件：

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

workload和org是EntityFramework对象。对CreateWorkload的调用将一行添加到数据库中的工作负载表中。(我们确实应该在表上使用唯一的约束来强制执行，但我现在不能这样做，因为表中有一些脏数据。)当SingleOrDefault遇到满足条件的多行时，对包含此代码的Action方法的后续调用将引发异常。

因此，为了解决这个问题，我想要lock这些代码行。我不希望每个请求都使用静态锁对象来完成，因为这会降低每个用户的站点速度。我想做的是使用Session.SyncRoot进行锁定。也就是说。

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

不过，我不是ASP.NET专家，在docs和ReSharper中出现了一些警告标志，即它可以抛出NotImplementedExceptions或null。然而，测试表明，这是很好的工作。

那么，ASP.NET专家们，使用Session.SyncRoot的风险有多大？作为另一种选择，如果Session.SyncRoot“非常危险”，我可以在会话启动时在会话集合中分配一个锁对象来做同样的事情吗？

Answer 1

只有在使用实现HttpSessionStateBase但不覆盖SyncRoot属性的自定义会话类来执行抛出NotImplementedException以外的其他操作时，这种危险才存在。HttpSessionStateWrapper类和HttpSessionState类确实实现和重写了SyncRoot方法。因此，只要您是通过HttpSessionStateWrapper或HttpSessionState类访问会话，而不是通过自定义类访问会话，就可以正常工作。