从BackgroundWorker进程获取HttpContext
我有一个 ASP.NET 站点，我一直在做一些重构代码的工作，尝试通过创建一个 BackgroundWorker 并将工作发送给它来从实际的 http 请求中删除一些长时间运行的进程（大约一个小时）过程。这在缩减测试中运行良好，但是当我将逻辑应用到实际代码时，我发现从后台工作程序中运行的代码访问会话变量时出现问题。似乎传递的 HttpContext 对象有一个 null 会话，如果我请求 HttpContext.Current 我会得到 null 返回。
我假设这是因为它们位于不同的线程中，并且会话和 HttpContext.Current 都依赖于同一线程中。有什么方法可以从后台工作人员访问会话，或者我是否坚持从会话中查找所需的所有变量并将它们放入可用的数据结构中，然后将它们放回到会话中（如果合适）？如果我需要这样做，它显然会使重构变得非常复杂，所以我宁愿不这样做。
感谢您的任何想法。除了 BackgroundWorker 进程（在另一个问题中向我建议）之外，我愿意接受有关如何执行此操作的其他建议。
I have an ASP.NET site and I've been doing some work refactoring code to try to remove some long running processes (in the order of an hour) from the actual http Request by creating a BackgroundWorker and sending the work off to that to process. This was running fine on cutdown tests but when I applied the logic to the real code I found problems accessing Session variables from the code running in the Background Worker. It seems that the HttpContext object that was passed has a null session and if I ask for HttpContext.Current I get null back.
I'm assuming that this is because they are in a different thread and that the session and HttpContext.Current are both reliant on being in the same thread. Is there any way I can get access to the Session from the background worker or am I stuck with finding all the variables I need from session and putting them in an usable data structure and then putting them back in session (if appropriate) afterwards? It obviously complicates the refactor massively if I need to do this so I'd rather not.
Thanks for any thoughts you might have. I'm open to other suggestions on how I might do this other than BackgroundWorker processes (which were suggested to me in another question).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不确定您的所有要求，但如果您不希望将长流程与单个用户的请求相关联，那么您可能可以使用应用程序缓存而不是会话。
如果是这样，我会尝试将您对 Session 的使用替换为：
I'm not sure of all of your requirements, but you may be able to get away with using the Application Cache instead of the Session if you're not looking for the long process to be tied to an individual user's request.
If so, I would try swapping out your use of Session to:
这里是一个 MSDN 链接，其中提供了一些信息对此请注意。
特别是文本：
如果异步操作方法调用使用 BeginMethod/EndMethod 模式公开方法的服务，则回调方法（即作为异步回调参数传递给 Begin 方法的方法）可能会执行不受 ASP.NET 控制的线程。在这种情况下，HttpContext.Current 将为 null，并且应用程序在访问 AsyncManager 类的成员（例如参数）时可能会遇到竞争条件。为了确保您有权访问 HttpContext.Current 实例并避免竞争条件，您可以通过从回调方法调用 Sync() 来恢复 HttpContext.Current。
Here's an MSDN link that sheds some light on this.
The text in particular is :
If an asynchronous action method calls a service that exposes methods by using the BeginMethod/EndMethod pattern, the callback method (that is, the method that is passed as the asynchronous callback parameter to the Begin method) might execute on a thread that is not under the control of ASP.NET. In that case, HttpContext.Current will be null, and the application might experience race conditions when it accesses members of the AsyncManager class such as Parameters. To make sure that you have access to the HttpContext.Current instance and to avoid the race condition, you can restore HttpContext.Current by calling Sync() from the callback method.