IIS / .NET只允许特定的用户会话并发单一响应 [英] IIS / .Net only allows single concurrent response to given user session

问题描述

下面是我的问题：

我们有一个.NET 4.5 Web窗体应用程序。在应用程序的某些页面需要很长的时间来加载，由于在服务器端繁重的数据访问和操作。如果用户的页面加载完成前，并打开一个新的标签页关闭浏览器选项卡，在新标签应用程序的任何请求都将挂起20分钟以上，或只是超时。但是，如果他们打开一个新的隐身窗口（浏览器），或者其他浏览器，就可以立即连接。

We have a .Net 4.5 web forms application. Some pages in the application take a very long time to load due to heavy data access and manipulation on the server side. If a user closes their browser tab before the page completes loading, and opens a new tab, any requests to the application in the new tab will hang for 20 minutes or more, or just time out. However, if they open a new incognito window (Chrome) or another browser, they can connect immediately.

我相信这是因为净处理来自同一个会话的并发请求按顺序，按如下说明： ASP.NET会话状态概述

I believe this is because .Net handles concurrent requests from the same session sequentially, as explained here: ASP.NET Session State Overview

并发请求和会话状态访问ASP.NET会话状态
为每个会话排斥的，这意味着如果两个不同的用户做出
并发请求，访问每个单独的会话被授予
兼任。然而，如果两个并发请求为
相同的会话制成（通过使用相同的SessionID值），第一个请求
获得的会话信息的独占访问。第二个请求
执行第一个请求完成之后。 （第二届会议
也可以，因为第一个请求超出锁定超时可以访问，如果对信息的独占锁被释放
）。如果在@ Page指令的
的EnableSessionState值被设定为只读，用于只读会话信息
请求不导致的会话数据的
独占锁。但是，只读
的会话数据的请求仍然可能需要等待一个锁由会话数据清除读写
的要求设置。

Concurrent Requests and Session State Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

我发现，同时研究这个问题已经提到（但未经证实），当浏览器选项卡响应完成之前关闭，会被卡住，有的岗位也不会从同一会话的新请求响应，直到该组SessionTimeout周期已经过去。这是我的假设，从隐身窗口的请求被接受，因为它有一个新的会话。

Some posts I've found while researching this issue have alluded to (but not confirmed) that when the browser tab is closed before the response completes, the session gets "stuck" and will not respond to new requests from the same session until the set SessionTimeout period has elapsed. It is my hypothesis that a request from an incognito window is accepted because it has a new session.

有谁知道有什么方法来释放会话的新要求，除了等待超时？是否有某种方式来检测客户端不再侦听？我发现 Response.IsClientConnected ，这似乎是有前途的，但我不知道它是如何被使用。

Does anyone know of any way to free up the session to new requests, besides waiting for a timeout? Is there some way to detect that the client is no longer listening? I've found Response.IsClientConnected, which seems promising, but I am not sure how it would be used.

注意：这是一个包含业务逻辑的显著量的传统应用程序，和目前的条件不允许在此时的重写时间或预算。因此，建议只是让他们负载重新编写网页的速度更快不会立即可行的，虽然我承认，将真正成为最好的解决方案。的

推荐答案

本来就我自己的并发性和会话状态类似的问题。

Had a similar issue myself regarding concurrency and session state.

尝试设置ENABLESESSIONSTATE =，在你的web.config只读

Try setting enableSessionState="ReadOnly" in your web.config.

请参阅我的想法在这里：的EnableSessionState =只读 - 可能出现的副作用

See my thoughts here: EnableSessionState = ReadOnly - possible side effects?

编辑：对不起，看到你可能已经尝试过这样做。

sorry, saw that you might already have tried doing this.

这篇关于IIS / .NET只允许特定的用户会话并发单一响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！