浏览器关闭后保持我的网络应用程序运行
我有一个 aspx Web 应用程序，可以更新或添加数据库中的文件。 客户端通过浏览器访问，要求之一是他们可以开始更新并能够在更新继续时关闭浏览器。 在我关闭浏览器后，它似乎运行了一会儿，但随后就停止了。 如何让 ASP.NET 应用程序保持运行？
I have a aspx web application that updates or adds files in a database. The clients access through the browser and one of the requirements is that they can start the update and be able to close the browser while the update continues. It appears to run for a little bit after I close the browser but then it stops. How can you keep the application running for asp.net?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以使用 WF (Workflow Foundation) 很好地解决这个问题。 为关闭浏览器后仍应继续存在的任务创建工作流。 工作流有自己的线程和生命周期，与 ASP.NET 分开。
That's something you could very well solve with WF (Workflow Foundation). Create a workflow for the task that should survive closing the browser. Workflows have their own threads and livecycles separate from ASP.NET.
Web应用程序将继续在应用程序池中运行，但最终会被回收。 只要用户会话运行，应用程序就应该保持活动状态，因此通过增加会话超时可以解决问题。
更好的方法是将长时间运行的任务移至服务中，但这可能需要重写您的应用程序。
The web application will keep running in the application pool, but this will be recycled eventually. As long as the users session runs the application should be kept alive, so by upping the session timeout you may fix the problem.
A better approach though would be to move the long-running task into a service instead, but that may require a rewrite of your application.
通常对于长时间运行或异步处理，您希望将请求分派给后端服务来处理。 尝试保持 Web 应用程序处于活动状态以完成处理可能会导致问题，尤其是 HTTP 和会话超时。
一种常见的模式是将请求放在消息队列中，并让后端服务在可能的情况下处理它。
Usually for long-running or asynchronous processing, you want to dispatch the request to a back-end service to handle. Trying to keep the web-app alive to finish processing can lead to problems, especially with HTTP and session timeouts.
A common pattern for this is to put the request on a message queue and let a back-end service process it when it can.
我将创建一个单独的 Windows 服务，您可以将作业从 Web 应用程序推送到该服务上，然后在用户再次登录时检查作业的状态。
Windows 服务不会绑定到 asp.net 应用程序域，因此无论您的 Web 应用程序中发生什么情况，它都会继续运行。
I would create a separate windows service that you can push jobs onto from your web application, then check the status of the job(s) when the user logs in again.
The windows service won't be tied to the asp.net app domain so it will continue to run regardless of whats happening in your web application.
我遇到过这种模式，您必须将工作与 HTTP 请求分离。 我们解决这个问题的方法是将要完成的计算抽象为要安排的事件。 因此，假设浏览器上的用户执行了一个需要在后端进行长期（相对）计算的操作，该计算将被赋予诸如“doXYZForUser”之类的名称，并给出诸如（userId，params ...）之类的参数向量和发送到工作队列。 将来的某个时间，用户再次登录，可以看到他们的工作状态。
我正在运行 Java 堆栈和 Java 消息服务 (JMS)，但原理是相同的。 来自浏览器的请求将事件排队，浏览器收到一个 ACK 消息，表示该事件已在工作队列中。 该队列由一个完全独立运行的进程管理，在 .NET 中我认为该进程被称为消息队列。 队列中出现的作业将被处理，结果可以放置在一个单独的表中，其中包含对启动该作业的用户的引用，以便他们下次登录时可以返回作业状态/结果。
I've run into this pattern and you have to decouple the work from the HTTP request. The way we've solved it is to abstract the computing to be done as an event to be scheduled. So, say a user at a browser takes an action that requires a long lived (relatively) computation on the back end, this computation is given a name like 'doXYZForUser' and given a prameter vector like (userId, params...) and sent off to the work queue. Some time in the future the user logs in again and can see what the status of their job is.
I'm running a Java stack and a Java Message Service (JMS) but the principle is the same. The request from the browser queues up an event and the browser get an ACK back saying the event is on the work queue. The queue is managed by an entirely separately running process which in .NET I believe is just called the Message Queue. The job comes up on the queue gets processed and the results can be placed in a separate table containing a reference to the user that kicked off the job, so the next time they log in job status/results can be returned.