Summary about the frequent loss of sessions in ASP. NET

Summary about the frequent loss of sessions in ASP. NET

During ASP. NET development, session loss often occurs. I have read a lot of information, but I still have no idea about the specific reasons. Even Microsoft is not sure.

I have summarized the following points of attention when I have no deep understanding:

1. Try not to use frame. during development, frame programs are often lost. If there is no frame, this situation has almost never happened;

2. The name of the host server where ASP. NET programs are deployed cannot contain an underscore (_). The specific reason is unclear. After seeking for technical support from Microsoft, Microsoft engineers will inform you.

3. you can. in config, set sessionstate, set mode = "inproc" to mode = "StateServer", and enable ASP. net State Service to prevent session loss. However, some virtual hosts may not have enabled this service.

4. Use cookies to maintain the data content.
5. Use a database
Citation
Http://www.bullnet.cn/blog/index.asp
References
Http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp? Id = 10

The session mechanism is a server-side mechanism. The server uses a structure similar to a hash (or a hash) to save information.

When the program needs to create a session for a client request, the server first checks whether the client request contains a session id called the session id, if a session id is included, it indicates that a session has been created for this client before, and the server uses the session id to retrieve the session. (if the session id is not found, a new one may be created ), if the client request does not contain the session id, the client creates a session and generates a session id associated with the session. The session id value should be unique, the session id is returned to the client for saving in this response.

The cookie can be used to save the session id. In this way, the browser can automatically display the id to the server according to the Rules during the interaction. Generally, the cookie name is similar to SEEESIONID. For example, for weblogic cookies generated by web applications, JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764, whose name is JSESSIONID.

Because cookies can be artificially disabled, there must be other mechanisms so that session IDs can still be passed back to the server when cookies are disabled. A frequently used technology called URL rewriting is to directly append the session id to the end of the URL path. There are two additional methods, one is as the additional information of the URL path, the format is http ://..... /xxx; jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764
The other is appended to the URL as a query string, in the form of http: //.../xxx? Jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764
There is no difference between the two methods for users, but they are handled differently by servers during parsing, the first method also helps to distinguish the session id information from the normal program parameters.
To maintain the status throughout the interaction process, the session id must be included after the path that each client may request.

Another technique is form hidden fields. The server automatically modifies the form and adds a hidden field so that the session id can be passed back to the server when the form is submitted. For example, the following form
<Form name = "testform" action = "/xxx">
<Input type = "text">
</Form>
It will be rewritten
<Form name = "testform" action = "/xxx">
<Input type = "hidden" name = "jsessionid" value = "ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764 ">
<Input type = "text">
</Form>
This technology is rarely used now. I have used iPlanet6, the predecessor of the SunONE application server.
In fact, this technology can be simply replaced by rewriting the URL of the action application.

When talking about the session mechanism, we often hear the misunderstanding that "the session disappears as long as the browser is closed ". In fact, you can imagine the example of a membership card. Unless the customer initiates a card sales proposal for the store, the store will never easily Delete the customer's information. The same applies to sessions. Unless the program notifies the server to delete a session, the server will keep it. Generally, the program sends a command to delete the session when the user logs off. However, the browser will never notify the server that it is about to close before it closes, so the server will not have the opportunity to know that the browser has been closed, most session mechanisms use session cookies to save session IDs. When the browser is closed, the session id disappears, and the original session cannot be found when the server is connected again. If the cookie set by the server is saved to the hard disk, or the HTTP request header sent by the browser is rewritten by some means, the original session id is sent to the server, then you can still find the original session when you open the browser again.

It is precisely because closing the browser will not cause the session to be deleted, forcing the server to set an expiration time for the seesion. When the last time the session was used by the client exceeds this expiration time, the server considers that the client has stopped the activity before deleting the session to save storage space.