Here's a detailed description:
Copy Code code as follows:
<sessionstate
Timeout= "Timeout in minutes"
Cookieless= "[True|false]"
Mode= "off| inproc| stateserver| SQL Server "
Stateconnectionstring= "Tcpip=server:port"
statenetworktimeout= "for network operations and state server,in seconds"
sqlconnectionstring= "Valid SqlConnection string,minus Initial Catalog"
/>
Timeout: Specifies the lifetime (in minutes) of the session after the activity ends. If the user is not activated for a specified period of time, a new session is created and the previous state is lost.
Cookieless: In the default state, the generated session ID is stored in a cookie, and later, the cookie is asp.net read in other requests to determine the session state to connect to the current user.
If some users disable cookies in the browser, we can use cookieless to enable session state for those users. When set to True, ASP. NET automatically appends the session ID to the URL and any associated URLs that exist in the requested page.
Not enabled, set to False
Enabled, set to True
This mechanism adds a processing step, because all links in the page must be overridden to contain the session ID, and the URL requested later must be parsed to extract it and obtain the actual resource URL (no session ID).
Mode: state mode.
inproc--This is a default setting. All states are saved in the memory of the same process that is running the application. This enables optimal performance, but if the application is restarted, or if the process is suspended for some reason, all session data for the associated user is lost.
stateserver--can use this setting to isolate state memory from the process running the application. It can combine the following two properties:
stateconnectionstring= "Tcpip=server:port" statenetworktimeout= "for network operations and state server,in seconds"
You can save state information to its own processes and memory by specifying the address and port of the machine. This allows the state to be isolated from the application to prevent it from failing. In the state server and in it, the ASP.net state service must be started, and the service can be started either through the Serivces console or through the following command prompt:
>net Start aspnet_state
You can also set this service to start automatically. By setting the IP address of the state server, you can designate the appropriate machine to hold the application's state information. This prevents the application server from restarting, but it does not prevent the machine from restarting. It should also be noted that putting state memory outside the application process creates a performance conflict, especially if the application is on another machine on the network. Be sure to figure out whether the conflicts caused by preserving session information are normal.
sqlserver--If you decide to keep session state at any cost, you can take advantage of this setting. This pattern saves all session state in a SQL Server database, so it can withstand any failed operations of applications, servers, and even the database server, assuming the database itself is not faulted. Setting this pattern is really about configuring the following properties of the sessionstate element:
sqlconnectionstring= "Valid SqlConnection string,minus Initial Catalog"
You must also run a script to prepare the database required to store the state. Script the InstallSqlState.sql file under the D:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 path
You do not need to run this script using SQL Server Query Analyzer. MSDE provides us with a command-line utility: osql.
>osql–s [Servername]–u [Login]–p [pwd] < InstallSqlState.sql
For maximum reliability, we can even group SQL Server. This pattern is the most powerful way to protect session state, but it is also the most expensive in terms of performance. Each request requires a roundtrip between the databases, which can severely affect the application's response. At the same time, the use of network processing can also be caused by high load of bottlenecks.
