从 ASP.NET 页面运行长时间运行的存储过程（不需要返回）
我想知道如何从页面运行存储过程，并且即使页面关闭也“让它完成”。它不需要返回任何数据。
I would like to know how you would run a stored procedure from a page and just "let it finish" even if the page is closed. It doesn't need to return any data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以数据库为中心的选项是：
根据容量，您可以运行该作业的多个（名称不同）副本，同时处理列表中的项目。
（我已将此方法用于非常长时间运行的方法。这更像是一种管理类型的技巧，但它可能适合您的情况。）
A database-centric option would be:
Depending on capacity, you could have several (differently named) copies of this job running, concurrently processing items from the list.
(I've used this method for very long-running methods. It's more an admin-type trick, but it may be appropriate for your situation.)
首先准备命令，然后将其放入线程池中。只需确保线程不依赖于任何 HTTP 上下文或任何其他 http 内部对象。如果您的请求在线程之前完成；上下文可能消失了。
Prepare the command first, then queue it in the threadpool. Just make sure the thread does not depend on any HTTP Context or any other http intrinsic object. If your request finishes before the thread; the context might be gone.
请参阅异步过程执行。这是即使 ASP 进程崩溃也能保证执行的唯一方法。它还可以进行自我调整，可以处理负载峰值，请求会在资源可用时排队并进行处理。
该解决方案的要点是利用 SQL Server 激活 概念，允许您在 SQL Server 的后台线程中运行存储过程，无需客户端连接。
基于 SqlClient 异步方法或 CLR 线程池的解决方案不可靠，随着 ASP 进程的回收，调用会丢失，而且它们会在内存中建立请求队列，这些请求实际上会因内存消耗而触发进程回收。
基于表和代理作业的解决方案更好，因为它们可靠，但它们缺乏基于激活的解决方案的自调整功能。
See Asynchronous procedure execution. This is the only method that guarantees the execution even if the ASP process crashes. It also self tuning and can handle spikes of load, requests are queued up and processed as resources become available.
The gist of the solution is leveraging the SQL Server Activation concept, which allows you to run a stored procedure in a background thread in SQL Server without a client connection.
Solutions based on SqlClient asynch methods or on CLR thread pool are unreliable, the calls are lost as the ASP process is recycled, and besides they build up in-memory queues of requests that actually trigger a process recycle due to memory consumption.
Solutions based on tables and Agent jobs are better, as they are reliable, but they lack the self tuning of Activation based solutions.