Recently, when I was working on a project, some pages needed to load a lot of data, and sometimes, I clicked on the page without waiting for the page to finish loading, and then clicked on another page again
There will be a very slow state of suspended animation while loading the web page, so let's study it carefully today.
At first, I thought that this situation would occur on many websites or my computer network speed problem, but I found that this site did not have this situation, sometimes, I would get stuck when I posted, but I clicked on other pages in the tab to load quickly.
Let's take a closer look today!! The code tested first:
Homeview Code:
Controller Code:
For test code analysis, our controller has 3 methods, one is the home page, and the other two are test methods
The Test1 request blocks for 5 seconds and then returns data to the user
Test2 requests will not block and will return data directly to the user
Our homepage is two interfaces for Ajax requests, which are asynchronous requests, so there is no blocking problem.
We will find that Test1 method outputs content only after Test2 outputs content (Normally, the page will output the content returned by Test2 directly, and then wait 5 seconds to output the content returned by Test1, because js does not block)
Then, we directly access the Test1 and Test2 interfaces, we access Test1 first, and then immediately access Test2, and find that Test2 must wait until Test1 returns to complete, as shown in the figure below:
If a page request sets a reader lock, other requests that are being processed at the same time in the same session will not be able to update the session state, but at least they can be read. If a page requests a write lock for the session state, then all other pages are blocked, regardless of whether they want to read or write content. For example, if two program views are writing content in the same session at the same time, one program must wait until the other program is finished before it can be written. In AJAX programming, it is important to be aware of this happening.
Special note: Only when writing a session, Asp.net will block the request, but as long as you have visited the page where the session is written, such as the operation after logging in to the system with the session (the session is locked until it expires, of course, it is only the case that the SessionID is the same). There will be this problem.
Netizen information
As long as the website uses a session, each request will lock the session throughout its lifetime, so that requests with the same sessionid must wait to be unlocked
This means that if the website has a timed out page, it can't do anything, and you have to wait for the timed page to load.
You can't do it either, multiple ajax concurrent requests on the same page, you can't do it, message polling requests.
To sum it up:If you take a session to the request, if you do not bring a session to the request, the above situation will not occur
Solution:
Added the SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) feature to the controller controller
Note:
Required means you are requesting a exclusive lock on Session (i.e. no parallel processing of requests for the same sessionID) ReadOnly means you are requesting a non-exclusive lock on Session (i.e. your request still has to wait for requests with an exclusive lock to finish, but you can process requests with non-exclusive locks in parallel. However it is up to you to ensure that your code doesn't write to Session. It's not necessarily enforced by the framework) Required means the session mutex you requested (i.e. there is no requirement to process the same SessionID in parallel)
ReadOnly means that the session you request is a non-exclusive lock (i.e. your request still has to wait for completion, the request for an exclusive lock but you can process a request with a parallel non-exclusive lock). But you want to make sure your code doesn't write sessions. It doesn't have to be executed by the framework)
|