Asp. How to use session__.net correctly in net

The source of Poplar under the Banyan Tree: Blog time: 2010-08-24 read: 3,629 times original link [favorites] Summary: ASP.net developers know that the session is very unstable in use, or not as good as cookies, this article will tell us How to use session correctly.

ASP.net in the session than the ASP in the session flexible and powerful many, but also a lot of complexity; see some asp.net developers complained that the session instability, inexplicably lost, in fact, this is one of the areas of asp.net improvement.

We know that the most important difference between the session and the cookie is that the cookie information is all stored on the client, and the session only holds an ID on the client as a service-side authentication token, and the real data is placed in the server's memory.

In a traditional web programming language (such as ASP), the expiration of the session is entirely handled in accordance with timeout, and the timeout value defaults to 20 minutes, but the problem is: There are usually a lot of users who just look at the page and then close the browser and leave. Server-side memory is also a long time to save the session data, if this user a lot of resources is undoubtedly a waste.

In ASP.net, there are several storage strategies for the session:

By default, the system uses the InProc mode, which is in-process mode. In this case, the session is stored in the memory of the ASP.net worker process mapping, and the problem is that the ASP.net worker process is often reclaimed by the system in order to maintain good average performance. We can configure automatic recycling in IIS (for example, by time cycle, or when memory usage reaches a value that is automatically recycled), the following figure is the interface for configuring application pool Recycle parameters in IIS7:

When the ASP.net worker process is reclaimed, its mapped memory is emptied and initialized so that other programs can be used, so the session disappears, which is the main reason why sesssion disappears for no reason.

Of course, the default InProc mode is also the most performance of the mode, if you can not tolerate this "instability", you can set mode to StateServer mode in web.config:

< sessionstate mode = "StateServer" stateconnectionstring = "tcpip=127.0.0.1:42424" ></sessionstate >

In this case, the session is saved in a aspnet_state.exe process other than the asp.net process, which is unaffected by the asp.net process recovery. Note, however: Aspnet_state is run as a Windows service, so make sure that the service is started on the 127.0.0.1 corresponding machine.

In addition, we must realize that although the session in the StateServer mode is much more stable, the performance relative to InProc is lossy (presumably around 15%~25%), since the session value is serialized within the system and saved to the aspnet_ The state process is mapped in memory and is deserialized when it is read.

This pattern also has the advantage that if the IP address in tcpip=127.0.0.1:42424 is specified as another server, the session can be saved on a machine other than the Web server.

Session information can even be saved to the SQL Server database:

Entering vs command line mode, enter the following command:

That is, the Aspnet_regsql-s database instance name-ssadd-u the connection user name. Note: The database server must first start the SQL Server Agent service:

When this command is run, a aspstate database is created automatically, and two tables Aspstatetempapplications and ASPStateTempSessions are created under the tempdb database.

The corresponding Web.config configuration is:

< sessionstate mode = "SQL Server" sqlConnectionString = "Data source=jimmyt61p;uid=sa;pwd=***" ></sessionstate >

Note: If you want to create the table directly in the database aspstate, just the command line, and then add a parameter-sstype p, that is:

Aspnet_regsql-s database Instance name-ssadd-sstype p-u connection user name

Similarly, SQL Server mode also has performance loss (around 25%) while saving read session data, but using SQL Server enables the persistent retention of session data.

Finally, let's look at the other two values in mode: OFF and Custom,off are equivalent to disabling the session, not to mention that custom allows the developer to define how the session is stored, which is equivalent to providing a programmable development interface (I never used it, so ...). Also can not talk about a very deep way, hehe.

In combination: InProc performance is the highest, but it may cause the session to be lost for no reason, and this mode does not apply to the Web server cluster or load balancing scenario (because there is no session synchronization between multiple servers), StateServer and SQL Server can be applied to the Web server cluster scenario, but performance is reduced, and SQL Server is the only built-in solution if you want the session to persist.

Personal experience: In general, I tend to use cookies, thereby reducing the consumption of server resources, but this also needs to find a balance, because the server-side code to get the client's cookies, it means that the cookie file must be passed through the browser to the server, also consumes network bandwidth. In addition, in some blog system, such as users write articles, if the halfway away, and then continue to write, wait until the save will find session has expired, the page to login page, hard dozen n more words but no. At this point you can consider using code to maintain the session, that is, Kirin brothers Heartbeat thought: Let Your website "heartbeat" up, or use Ajax every few minutes to save automatically. Furthermore, in terms of security, forged sessions are much more difficult and relatively safer than cookies.