对于来自客户端的给定HTTP请求,ASP.NET HttpApplication的BeginRequest和EndRequest是否始终出现在完全相同的线程上?
我问的原因是我看到一些非常奇怪的行为,其中ThreadStatic变量在IHttpModule的Init方法中不为null。
我将此ThreadStatic变量设置为BeginRequest上的值,并在EndRequest上将其设置为null。
但是,我的IHttpModule Init方法应该在BeginRequest / EndRequest期间之外调用,所以我可以想到这个ThreadStatic变量在调用我的Init方法时会有一个值,如果EndRequest发生在另一个线程上而不是BeginRequest,因此当ASP .NET尝试使用同一个线程创建一个新的HttpApplication实例时,该值仍然不会为空...
我在集成模式下运行IIS 7.
答案 0 :(得分:3)
对于来自客户端的给定HTTP请求,ASP .NET HttpApplication的BeginRequest和EndRequest是否始终出现在完全相同的线程上?
没有。有一些选项可以在请求中执行异步操作,从而导致请求的结束在另一个线程上处理。这不是正常情况。
请参阅@Page
指令的Async属性:http://msdn.microsoft.com/en-us/library/ydy4x04a.aspx
有关使用异步页面的介绍,请参阅此MSDN杂志文章:“Asynchronous Pages in ASP.NET 2.0”。
答案 1 :(得分:1)
有趣的是我之前犯过这个错误,所以我应该知道更好......但是唉。
ThreadStatic成员需要是STATIC。如果它不是......它真的应该抛出编译器错误。
答案 2 :(得分:0)
不,按照Richard's answer。
顺便说一下,你应该通过HttpContext.Current.Items
在HTTP模块之间“共享”变量。对于[ThreadStatic]
,由于ASP.NET中的线程敏捷性,不保证您的代码将在同一个线程上启动和完成。所以,ThreadStatic
在ASP.NET中并不是一个好主意。
值得一提的是,EndRequest
将始终使用相同的HttpContext
执行。
这似乎是使用[ThreadStatic]和HttpContext的权威帖子 http://piers7.blogspot.co.nz/2005/11/threadstatic-callcontext-and_02.html
Scott Hanselman也发表了关于这个主题的文章: Jon Skeet也有一个很好的答案:
CallContext vs ThreadStatic