在ASP.NET中使用线程有任何非明显的危险吗？

Question

对于这个程序员的问题,这是一个兄弟问题.

简而言之,我们正在考虑将一些一直支持用户请求的工作推送到后台"正确".如果我们走的是服务路线,这个相关的问题给了我很多想法,但是并没有真正提供任何有说服力的论据,说明为什么,我们应该这样做.

我会承认,对我来说,做道德等同的能力

WorkQueue.Push(delegate(object context) { ... });

真的很引人注目,所以如果它有点困难(而不是天生就不可行),我倾向于采用后台线程方法.

所以,我知道的后台线程问题(在AppPool的上下文中):

• 由于AppPool被回收,它们可能随时死亡
  • 解决方案:跟踪任务执行的时间,因此可以重新运行*如果需要新线程
• 所述线程池用于向传入的HTTP响应查询,所以使用它可以饿死IIS
  • 解决方案:构建我们自己的线程池,同时限制线程数.

我的问题是,如果有的话,我错过了什么？ 在ASP.NET中使用后台线程会出现什么问题？

_{*问题中的任务已经安全重新运行,所以这不是问题.
ǂ假设我们没有做任何真正愚蠢的事情,比如在后台线程中抛出异常.}

Answer 1

我个人遇到的一个危险是 CallContext。我们使用 CallContext 来设置用户身份数据，因为我们的 Web 应用程序和基于 .NET Remoting 的应用程序服务（旨在使用 CallContext 来存储呼叫特定数据）之间共享相同的代码 - 因此我们没有使用HttpContext。

我们注意到，有时，新请求最终会在 CallContext 中获得非空标识。换句话说，ASP .NET 不会在请求之间清空 CallContext 中存储的数据……因此，如果未经身份验证的用户选择的线程仍具有包含经过验证的用户身份信息的 CallContext，则他们可能会进入应用程序。