我们有一个 MVC.NET 应用程序在重新启动时遇到 fatal error 。在我们的 Session_Start 事件处理程序中，我们将 session ID 添加到字典中。在 Session_End 处理程序中，我们将其删除。考虑以下请求序列:
获取主页.mvc
<应用程序重新启动>
获取 main.css
获取横幅.jpg
获取一些数据.mvc
...
由于应用程序的架构方式，如果您在应用程序在浏览器窗口中打开时进行重建，这种顺序会相当频繁地发生。除了我在生产环境中也看到它之外，这不会是非常令人担忧的。例如，它会在您编辑 web.config 时发生(尽管很少)。
重启后的请求都是由于主页中的链接或来自 JavaScript 的 AJAX 调用。
我观察到的是 .NET 并行处理前 5 个请求。每个这样的请求都会导致它触发 Session_Start 事件。不久之后，它会触发 Session_End 事件 3 次。需要明确的是，每个 Session_Start 对应于完全相同的 session 。它们都具有相同的 session ID，并且 IsNewSession 属性对于所有 session 状态对象都是 true。此外，Session_End 事件与被终止的 session 不对应。 session 与存储在 session 状态中的任何数据一起持续存在。
我需要阻止它多次触发 Session_Start，或者弄清楚如何判断 Session_End 何时并不意味着 session 已经结束。
最佳答案
这个问题的答案被证明是相当直截了当的，尽管这种行为确实令人困惑。
通常情况下，MVC 会在应用程序的 session 状态锁上同步所有对应用程序的请求(因为 MVC 的 http 模块被标记为需要 session 状态)。在我的场景中，应用程序在提供主页后重新启动。因此，当与主页相关的请求进入时，该 session ID 还没有 session 状态，并且请求并行执行。
我看到 5 个并行请求，因为我在 XP 上开发，并且 IIS 的桌面版本被限制为 5 个并发请求。由于这些请求中的任何一个都不存在 session 状态对象，因此每个请求都会创建一个新的 session 状态对象并触发 Session_Start。其中四个请求转到 MVC 操作方法。由于这些需要 session 状态，一旦请求完成，.NET 会尝试将创建的 session 状态对象与后备存储同步。
只有第一次同步才能成功。 .NET 只是丢弃三个额外的 session 状态对象并为每个对象触发 Session_End。 .NET 不会尝试将第五个 session 状态对象与后备存储同步，因为它是为异步 http 模块创建的，该模块被标记为需要只读 session 状态。
所以，修复有两个部分:
(1) 在我的 Session_Start 处理程序中，我现在检查 session 状态对象是否为只读。如果是，那我什么都不做就立即返回。 .NET 不会触发相应的 Session_End，因此我所做的任何事情都不会被正确清理。
(2) 我现在在我的字典中保留一个引用计数。每次 Session_Start 处理程序尝试添加 session ID 时，我都会增加计数，并在每次 Session_End 尝试删除 session ID 时减少它。一旦计数达到 0，我就从字典中删除 session ID。
关于asp.net - 为什么我的 ASP.NET MVC 应用程序会为单个 session 多次触发 Session_Start？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3365942/