【问题标题】:Getting HttpContext from BackgroundWorker process从 BackgroundWorker 进程中获取 HttpContext
【发布时间】:2010-08-19 15:44:58
【问题描述】:

我有一个 ASP.NET 站点,我一直在做一些重构代码的工作,试图通过创建 BackgroundWorker 并发送工作从实际的 http 请求中删除一些长时间运行的进程(大约一个小时)到那个处理。这在缩减测试中运行良好,但是当我将逻辑应用于实际代码时,我发现从后台工作程序中运行的代码访问 Session 变量时出现问题。似乎传递的 HttpContext 对象有一个空会话,如果我要求 HttpContext.Current,我会返回空。

我假设这是因为它们在不同的线程中,并且会话和 HttpContext.Current 都依赖于在同一个线程中。有什么方法可以让我从后台工作人员访问会话,还是我坚持从会话中找到我需要的所有变量并将它们放入可用的数据结构中,然后再将它们放回会话中(如果合适的话)?如果我需要这样做,这显然会使重构变得非常复杂,所以我宁愿不这样做。

感谢您的任何想法。除了 BackgroundWorker 进程(在另一个问题中向我建议)之外,我愿意接受有关如何执行此操作的其他建议。

【问题讨论】:

    标签: asp.net session backgroundworker


    【解决方案1】:

    我不确定您的所有要求,但如果您不希望将冗长的过程与单个用户的请求相关联,那么您可以使用应用程序缓存而不是会话。

    如果是这样,我会尝试将您对 Session 的使用换成:

    HttpRuntime.Cache.Set("CacheKeyName");
    HttpRuntime.Cache.Get("CacheKeyName");
    

    【讨论】:

    • 如果无法控制会话,这听起来像是一种明智的替代方法(我的方法完全是关于方法参数的)。
    【解决方案2】:

    Here 是一个 MSDN 链接,可以对此有所了解。 特别是文字是:

    如果异步操作方法调用使用 BeginMethod/EndMethod 模式公开方法的服务,则回调方法(即作为异步回调参数传递给 Begin 方法的方法)可能会在以下线程上执行:不受 ASP.NET 的控制。在这种情况下,HttpContext.Current 将为 null,并且应用程序在访问 AsyncManager 类的成员(例如参数)时可能会遇到竞争条件。为了确保您可以访问 HttpContext.Current 实例并避免竞争条件,您可以通过从回调方法调用 Sync() 来恢复 HttpContext.Current

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2014-01-01
      • 2010-09-08
      • 1970-01-01
      • 1970-01-01
      • 2020-05-08
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多