asp.net configuration session state Session implementation code
- 2020-05-17 05:15:16
- OfStack
Here's how:
timeout: specifies the lifetime (in minutes) of the session after the activity ends. If the user is not activated within a specified period of time, a new session is created and the previous state is lost.
cookieless: by default, the generated session ID is stored in an cookie. Later, this cookie is read by ASP.NET in other requests to determine the session state and connect to the current user.
If some users have disabled cookie in their browser, we can use cookieless to enable session state for those users. When set to true, ASP.NET automatically appends the session ID to URL and any associated URL that exists on the requested page.
Not enabled, set to false
Enabled, set to true
This mechanism adds a processing step, because all the links in the page must be rewritten to include the session ID, and the requested URL must be parsed to extract it and get the actual resource URL (no session ID).
mode: state mode.
InProc -- this is a default setting. All state is stored in the memory of the same process that is running the application. This optimizes performance, but if the application is restarted or the process is suspended for some reason, all session data for the user concerned will be lost.
StateServer - you can use this setting to separate the state store from the process in which the application is running. It can combine the following two properties:
stateConnectionString="tcpip=server:port" stateNetworkTimeout="for network operations with State Server,in seconds"
State information can be saved to its own processes and memory by specifying the address and port of the machine. This isolates the state from the application and prevents it from failing. In the status server and its context, the ASP.NET status service must be started, which can be started either through the Serivces console or through the following command prompt:
> net start aspnet_state
You can also set the service to start automatically. By setting up the IP address of the status server, you can specify 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 is also important to note that placing the state store outside the application process can cause performance conflicts, especially if the application is on another machine in the network. Be sure to find out if it is normal to have conflicts with session information.
SQLServer -- you can take advantage of this setting if you decide to preserve session state at all costs. This mode can store all session state in the SQL Server database, so it can withstand any failed operation by the application, the server, or even the database server (assuming the database itself is fault-free). To set this mode is to configure the following properties of the sessionState element:
sqlConnectionString="valid SqlConnection string,minus Initial Catalog"
You must also run a script to prepare the database needed to store the state. The script is in installsqlstate.sql file under path D:\WINDOWS\ Microsoft.NET \Framework\ v1.1.4322
Running this script does not require the use of SQL Server 2000 Query Analyzer (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 round trip between the databases, which can seriously affect the application's ability to respond. At the same time, the use of network processing will also cause bottleneck problems due to high load.
<sessionState
timeout="timeout in minutes"
cookieless="[true|false]"
mode="Off|InProc|StateServer|SQLServer"
stateConnectionString="tcpip=server:port"
stateNetworkTimeout="for network operations with 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 within a specified period of time, a new session is created and the previous state is lost.
cookieless: by default, the generated session ID is stored in an cookie. Later, this cookie is read by ASP.NET in other requests to determine the session state and connect to the current user.
If some users have disabled cookie in their browser, we can use cookieless to enable session state for those users. When set to true, ASP.NET automatically appends the session ID to URL and any associated URL that exists on the requested page.
Not enabled, set to false
Enabled, set to true
This mechanism adds a processing step, because all the links in the page must be rewritten to include the session ID, and the requested URL must be parsed to extract it and get the actual resource URL (no session ID).
mode: state mode.
InProc -- this is a default setting. All state is stored in the memory of the same process that is running the application. This optimizes performance, but if the application is restarted or the process is suspended for some reason, all session data for the user concerned will be lost.
StateServer - you can use this setting to separate the state store from the process in which the application is running. It can combine the following two properties:
stateConnectionString="tcpip=server:port" stateNetworkTimeout="for network operations with State Server,in seconds"
State information can be saved to its own processes and memory by specifying the address and port of the machine. This isolates the state from the application and prevents it from failing. In the status server and its context, the ASP.NET status service must be started, which can be started either through the Serivces console or through the following command prompt:
> net start aspnet_state
You can also set the service to start automatically. By setting up the IP address of the status server, you can specify 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 is also important to note that placing the state store outside the application process can cause performance conflicts, especially if the application is on another machine in the network. Be sure to find out if it is normal to have conflicts with session information.
SQLServer -- you can take advantage of this setting if you decide to preserve session state at all costs. This mode can store all session state in the SQL Server database, so it can withstand any failed operation by the application, the server, or even the database server (assuming the database itself is fault-free). To set this mode is to configure the following properties of the sessionState element:
sqlConnectionString="valid SqlConnection string,minus Initial Catalog"
You must also run a script to prepare the database needed to store the state. The script is in installsqlstate.sql file under path D:\WINDOWS\ Microsoft.NET \Framework\ v1.1.4322
Running this script does not require the use of SQL Server 2000 Query Analyzer (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 round trip between the databases, which can seriously affect the application's ability to respond. At the same time, the use of network processing will also cause bottleneck problems due to high load.