NEW: How to use session correctly in ASP.

The original link under the Banyan Tree Yang over
Source: http://yjmyzz.cnblogs.com

The session in ASP. NET is much more flexible and powerful than the session in ASP, and it's also a lot more complicated. See some ASP. NET developers complain that the session is unstable and somehow lost, in fact, this is one of the areas of ASP.

We know that the biggest difference between a session and a cookie is that the cookie information is stored on the client side, and the session simply stores an ID on the client as a token that is validated with the server, and the real data is in the memory of the server.

In traditional Web programming languages (such as ASP), the expiration of the session is strictly handled according to timeout, the timeout value is 20 minutes by default, but the problem is: There are usually a lot of users just look at the Web page, and then close the browser to leave, in this case, Server-side memory also holds the session data for a long time, if the user is a lot of, it is a waste of resources.

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 recycled by the system in order to maintain good average performance. We can configure automatic recycling in IIS (such as recycling by time period, or automatically when memory usage reaches a value), such as the interface for configuring application pool reclamation parameters for IIS7

When an ASP. NET worker process is recycled, its mapped memory is emptied and initialized so that other programs can be used, so the session disappears as well, which is the main reason why the sesssion disappears for nothing.

Of course, the default InProc mode is also the most performance mode, if you cannot 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 stored in a Aspnet_state.exe process outside the ASP. NET process, which is not affected by the ASP.

Note, however, that Aspnet_state is running 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 will be much more stable, the performance is lossy relative to InProc (around 15%~25%), since the session value is serialized inside the system and saved to the aspnet_ The state process is mapped in memory and is deserialized when read.

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

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

Enter the VS command-line mode and enter the following command:

That is, the Aspnet_regsql-s DB instance name-ssadd-u the connection user name

Note: The database server must start the SQL Server Agent service first

Once this command is run, a aspstate database is created automatically, and two tables are created under the tempdb database aspstatetempapplications and ASPStateTempSessions

The corresponding Web. config configuration is:

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

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

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

In the same SQL Server mode, when the session data is saved, the relative InProc mode also has a performance loss (around 25%), but SQL Server can be used to persist the session data.

Finally look at the other two values in mode: OFF and custom

Off is equivalent to disabling the session, it's not much to say

Custom allows developers to define how the session is stored, which is equivalent to providing a programmable development interface (I never used it, so ...) Can not talk about a very deep road, hehe)

To combine:

InProc has the highest performance, but it may cause the session to be lost for no reason, and this mode cannot be applied to a Web server cluster or load Balancing scenario (because session synchronization cannot be achieved between multiple servers). StateServer and SQL Server can be applied to the Web server cluster scenario, but performance is reduced, and if you want the session to persist, SQL Server is the only built-in scenario.

Finally, some personal experience:

In general, I tend to use cookies to reduce the consumption of server resources, but this also requires a balance, because the client's cookie in the service-side code means that the cookie file must be passed to the server via the browser, which also consumes the network bandwidth.

In addition: In some blog systems, such as users write articles, if you leave the next, and then continue to write, until the save will find that the session has expired, the page jumped to the login page, hard hit n more words but no! At this point, you can consider using code to maintain the session, that is, the Unicorn Brothers Heartbeat thought: Let Your site "heartbeat", or use Ajax every few minutes automatically saved

Furthermore: from a security perspective, it is more difficult and safer to forge a session than a cookie.

Yang over the Bodhi tree
Source: http://yjmyzz.cnblogs.com
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

NEW: How to use session correctly in ASP.