Apppool 回收和 Asp.net 带线程？
我制作了一个执行长sp的asp.net页面。 假设执行 sp 的函数名为 Func1。
我遇到过这个问题：
如果我在同一个线程中运行Func1（正常执行），应用程序池将不会自行回收，因为他将其视为忙碌/工作。
但是，如果我在另一个线程中执行 Func1 - 那么应用程序池会在此处设置的时间后回收自身：
我的问题是：为什么是这样？
如果我同步运行命令，那么应用程序处于活动状态且不符合应用程序池回收条件，这是真的吗？ 如果我在新线程中创建它，那么它是否有资格进行应用程序池回收？
这是为什么呢？线程是否不如主线程重要？
I have made an asp.net page which executes a long sp.
lets say the the function that executes the sp is called Func1.
Ive met with that problem :
If i ran Func1 in the same thread ( normal execution), the apppool won't recycle itself since he's seeing it as a busy/working.
But if I execute Func1 in another thread - so the apppool recycle's itself after the time that is set here :
My question is : why is that ?
is it true that if i run a command synchronously , so app is active and not eligible for apppool recycle ?
And if i create it in a new thread so it does eligible for apppool recycle ?
why is that ? Does the thread is less important then the main thread ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ASP.NET 维护一个用于服务请求的线程池线程列表。它知道当没有任何线程处于活动状态时，它可以回收应用程序域。
如果您在不了解 ASP.NET 的情况下创建线程或使用线程池线程，它不会检测到您的线程处于活动状态，并且可能会回收。
当它回收时，它会卸载
AppDomain，这会导致在线程上抛出ThreadAbortException。满足您的要求的正常解决方案是拥有由 Web 应用程序控制的 Windows 服务。这显然是在一个单独的过程中，因此不受网络应用程序回收的影响。然而，这是一个不平凡的练习。
快速而肮脏的解决方案是从您的 Web 应用程序中异步启动 Web 请求。然后可以返回开始操作的页面。被调用的“隐藏”页面可能会阻塞，直到 SP 完成。正如我所说，这是一个令人讨厌但简单的解决方案。
ASP.NET maintains a list of thread pool threads that it is using to service requests. It knows it can recycle the app domain when none of its threads are active.
If you create a thread or use a thread pool thread without the knowledge of ASP.NET, it will not detect that your thread is active and may recycle.
When it recycles, it unloads the
AppDomainwhich causes aThreadAbortExceptionto be thrown on your thread.The normal solution to your requirements is to have a windows service that is controlled by the web app. This is obviously in a separate process and so is not affected by the web app recycling. However, this is a non-trivial exercise.
The quick-and-dirty solution is to asynchronously start a web request from within your web app. The page that starts the operation can then return. The "hidden" page that was called can block until the SP has completed. As I said, this is a nasty-but-easy solution.