ASP.NET 线程敏捷性——如何克服？

Question

众所周知，ASP.NET 表现出所谓的“线程敏捷性”。简而言之，这意味着可以使用多个线程来满足单个请求，但一次不能使用多个线程。这是一种优化，意味着等待异步 I/O 的线程可能会返回到池中并用于服务其他请求。

但是，ASP.NET 在移动请求时不会迁移所有与线程相关的数据。 Microsoft 要么忘记这样做，要么认为只有编写 ASP.NET 的人自己才应该使用线程本地存储(通过 ThreadStatic 属性变得容易)。

根据快速谷歌搜索，在我看来，避免该问题的唯一方法是依赖 HttpContext。如果 ASP.NET 决定在请求中切换线程，上下文确实会迁移，因此这可以解决该问题。但它却带来了一个全新的令人头疼的问题:它将您的应用程序逻辑与 HttpContext 联系在一起，从而与 Web 上下文联系在一起。这在所有情况下都是 Not Acceptable (事实上，我想说在大多数情况下这是 Not Acceptable )。此外，由于 HttpContext 是密封的并且具有内部构造函数，因此您无法模拟或 stub 它，因此您的逻辑也变得不可测试。

根据this (old) blog post ，CallContext 不起作用，鉴于调用上下文在概念上恰好是一个逻辑线程，这非常令人恼火!

是否有一种简单的方法可以可靠地实现“每逻辑线程”隔离，该隔离可以在 ASP.NET 上下文以及其他上下文中工作？

如果没有，有人知道有一个轻量级的第三方框架可以解决这个问题吗？是StructureMap ASP.NET 迁移线程时行为是否正确？

我想要一个一般性的答案，但以防万一有人想知道，我正在查看的具体用例是在 SharePoint 上下文中使用 Entity Framework 。不幸的是，我们暂时只能使用 SP-2010 和 EF 3.5。 EF 基本上要求使用与最初读取数据相同的上下文来保存数据 - 否则您必须自己跟踪更改。我想介绍一个“当前模型”的概念。第一次在处理每个 HTTP 请求时调用模型时，应将其实例化，然后在请求期间应使用同一模型实例。但是，如果在计时器作业的上下文中执行，依赖于“Model.Current”的代码也应该可以工作。我对计时器作业代码在完成模型时显式处置模型感到满意(我想在 SharePoint Web 上下文中将任务交给 HttpApplication.EndRequest 的处理程序)。

可能有理由不这样做，这也很有趣，但无论如何我真的很感激学习一种在 ASP.NET 上下文中实现“逻辑线程隔离”的方法，如这会非常有用。

Answer 1

有一篇与该问题相关的好帖子:Implicit Async Context ("AsyncLocal") 。

如果我一切都正确，逻辑 CallContext 即 CallContext.LogicalGetData 和 CallContext.LogicalSetData 使您能够正确迁移不可变数据，因为您生活在过去的世界.NET 4.5。这种不可变限制是一个坚果，但仍然......还有很长的路要走。