asp.net - 什么会导致 ASP.NET 工作进程被回收？

Question

这是我当前的问题:

我猜测我的问题(如下所述)是由 ASP.NET 工作进程被回收引起的，根据下面的答案 - 我正在使用 InProc session 存储，并且没有看到太多的机会离开，因为对其他类型存储的限制是所有 session 对象都是可序列化的。然而，我不知道什么会让工作进程像我看到的那样频繁地被回收——据我所知，应用程序目录中的文件没有任何更改，并且 IIS 中的选项似乎暗示该进程只会每 1,740 分钟回收一次，这比实际 session 丢失的频率要低得多。所以，我现在的问题是，哪些不同的情况会导致 ASP.NET 工作进程被回收？

这是我原来的问题:

我的 ASP.NET Web 应用程序中出现了一个难以重现的问题。该应用程序有一个主 .aspx 页面，该页面已加载并初始化许多 session 变量。此页面使用 ASP.NET Ajax Sys.Net.WebRequest 类重复访问另一个 .aspx 页面，该页面使用 session 变量进行数据库查询并更新主页(主页永远不会重新访问) -要求)。

有时，在使用该页面一段时间后，会导致成功的 HTTP 请求，其中在主页中创建的 session 正确地转移到子页面，其中一个请求似乎会导致创建新的 ASP.NET session —所有 session 变量都会丢失(导致我的代码中抛出异常)，并且在动态请求的页面中报告新的 session ID。这意味着主页突然与服务器断开连接——就服务器而言，用户不再登录。

我几乎肯定这不是 session 超时 - 超时时间设置得有些荒谬，发生这种情况所需的时间是可变的，但永远不会长到足以导致 session 超时，< em>并且常量Sys.Net.WebRequests应该刷新 session 计时器。

那么，还有哪些情况会导致 HTTP 请求与 ASP.NET session 失去联系？不幸的是，当这种情况发生在我身上时，我没有嗅探网络流量，否则我会检查 ASP.NET session cookie 是否已保留。

Answer 1

一种解决方案是使用 StateServer，而不是 InProc session 管理。

很多事情都会导致 session 状态丢失:

1. 编辑 Web.Config
2. IIS 重置
3. 等等

如果 session 状态对您的应用程序很重要，则使用 SQL 状态管理或 ASP 附带的状态服务器。网络。

干杯，

RB。