我有一个问题，但找不到确切的答案...
如果您有一个ASP.Net页面需要渲染的时间超过请求超时，那么这个进程会发生什么？Web服务会中止它吗？
假设我在ASP.Net页面中向响应流写入XML，并且调用我的GenerateXML方法时超时了。我的方法调用会发生什么？它会完成，但Web服务器报告超时吗？还是被中止了？
我可能可以编写一个测试来查看自己的结果，但我认为可能有更多内容。
2个回答
1
让我们澄清一下：
您的问题中至少有两个超时时间（1）会话超时（2）请求超时。最常见的情况是请求超时 - 因为客户端不想等待几分钟直到服务器恢复。通常请求的生命周期比会话短。在这种情况下，服务器以通常的方式终止请求-通过引发ThreadAbortException。即使一切正常，也会引发此异常，以终止请求处理。
当会话结束时-客户端甚至不应该知道它。只有在您进行授权时，客户端才会被重定向到登录页面。但是服务器代码可能会丢失存储在会话中的数据。
当会话结束时-客户端甚至不应该知道它。只有在您进行授权时，客户端才会被重定向到登录页面。但是服务器代码可能会丢失存储在会话中的数据。
- Dewfy
3
那么，如果我的页面请求线程（因此也包括GenerateXML方法）被ThreadAbort占用，该怎么办？如何处理这种情况是最好的方式？我正在生成并缓存XML，但如果它总是在第一次生成时超时，那么它将永远不会被缓存。 - Jeff
1@Jeff：我总是讨厌得到这样的答案，但如果你的页面渲染器需要*那么长时间，问题就在于页面渲染，而不是IIS处理会话管理的方式，所以你应该在那里进行改进... - Treb
我早就意识到了。这只意味着要更多地努力解决这个问题。我只需要认真思考页面请求的过程，以证明给自己看即可。 - Jeff
0
由于渲染过程本身并不知道会话超时的情况，我的假设是渲染完成时没有任何问题。只有当用户在返回到服务器的呈现页面上执行操作时，才会意识到超时。
我现在无法通过任何证据支持这一点，但对我来说，这是最合理的行为。其他任何行为都需要在渲染过程中进行额外的超时检查，这将消耗 CPU 时间（=金钱），但不会以任何方式提高会话安全性。
- Treb
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接