Understanding ASP.net Session State

asp.net one, session-state functionality

HTTP is a stateless protocol, so it does not automatically indicate whether a sequence of requests is from the same client or even whether a single browser instance is still actively viewing a page or site. Using the ASP.net built-in session state feature, you can use the

1. Automatic identification and classification of requests from a single browser client to a logical application session on the server.

2, the session-wide data is stored on the server for use across multiple browser requests.

3. Raises appropriate session lifetime management events that can be handled in application code (Session_OnStart, Session_OnEnd, etc.)

II. Identification of Session state

When you create a session, the server generates a separate identity for each session. The identity is represented by a 120-bit SessionID string that contains only the ASCII characters allowed in the URL. The SessionID value is generated using an algorithm that guarantees uniqueness and randomness, in which the purpose of ensuring uniqueness is to ensure that the session is not conflicting, and that the purpose of ensuring randomness is to ensure that a malicious user cannot use the new SessionID to compute the SessionID of an existing session.

Iii. how session state is stored

There are three ways to store session state

1, in-process session state mode (INPROC): When we create a new Web program by default to adopt the process of Session state mode, which is widely used in the model. In this mode, session state is stored in the local asp.net worker process, so that the in-process session-state mode may be the fastest access option available to date. But the more data stored in a session, the more memory the WEB server consumes, potentially increasing the risk of performance degradation.

2.. NET State Server Mode (StateServer): Session state is stored in a remote process (for example, in a indows NT service named Aspnet_state.exe)

3, SQL mode (SQL Server): Session state is stored in a private database table managed by SQL Server.

Both the. NET state Server and SQL schemas can be called out-of-process session modes. When data is stored, data serialization needs to be stored in the external repository, and when reading and data, the data needs to be deserialized and copied into the local session dictionary, so the request causes performance degradation of 15% (out-of-process) to 25% (SQL Server). Note that this is only a rough estimate. But in an out-of-process storage scenario, the session state survives longer and makes the application more powerful because it protects against Microsoft? Internet Information Services (IIS) and ASP.net failed. By separating session state from your application, you can also make it easier to extend existing applications into Web Farm and web Garden architectures. In addition, session state is stored in an external process, fundamentally eliminating the risk of periodic data loss due to a process cycle.

Iv. Configuration of Session state

The configuration of session state is done by setting the <sessionState> section of the Web.config file. Here are three ways to configure the session state

1. In-process mode

In-process mode is the default session-state mode. To use in-process mode, set the <sessionState> element's Mode property to Inproc.

An example of a configuration setting for an in-process pattern is shown below.

<configuration>
<system.web>
<sessionstate mode= "Inproc"
Cookieless= "false"
timeout= "20"/>
</sessionState>
</system.web>
</configuration>
2, State server mode

To use a state server, you must first ensure that the ASP.net State service runs on a remote server for session storage. This service is installed with ASP.net and Visual Studio. NET in the following locations:

Systemroot\microsoft.net\framework\versionnumber\aspnet_state.exe

Then, in the application's Web.config file, set the <sessionState> element's Mode property to StateServer. Finally, set the ConnectionString property to Tcpip=servername:portnumber.

The following is an example of a configuration setting for the state server pattern.

<configuration>
<system.web>
<sessionstate mode= "StateServer"
Stateconnectionstring= "tcpip=dataserver:42424"
Cookieless= "false"
timeout= "20"/>
</sessionState>
</system.web>
3. SQL Server Mode

To use SQL Server, first run InstallSqlState.sql or installpersistsqlstate.sql on a SQL Server computer that will store session state. All two scripts create a database named ASPState that contains several stored procedures.

The difference between two scripts is the placement of aspstatetempapplications and aspstatetempsessions tables. The InstallSqlState.sql script adds these tables to the TempDB database, which loses data when the computer restarts. Instead, the InstallPersistSqlState.sql script adds these tables to the ASPState database, which allows session data to be preserved when the computer restarts.

By default, two script files are installed in the following location:

Systemroot\microsoft.net\framework\versionnumber

Then, in the application's Web.config file, set the <sessionState> element's mode property to SQL Server. Finally, set the sqlConnectionString property to the integrated Security=sspi;data source=servername;.

An example of a configuration setting for SQL Server mode is shown below.

<configuration>
<system.web>
<sessionstate mode= "SQL Server"
sqlconnectionstring= "Integrated security=sspi;data source=dataserver;"
Cookieless= "false"
timeout= "20"/>
</sessionState>
</system.web>
</configuration>
In SQL Server mode, you can also configure session state to work in a failover cluster. A failover cluster is two or more identical redundant WEB servers that store session data in a SQL Server database on a separate computer. If a WEB server fails, another server in the cluster takes over its work, provides services for the request, and the session data is not lost.

To configure a failover cluster, set the <machinekey> element in the Web server's Web.config file to the same value.

The SQL connection string for the WEB server is then set to point to a SQL Server database that stores session data on the computer.

V. Session-State Access

You can access the session state directly through the sessions collection. For compatibility with earlier versions of ASP, access to session state can also be achieved through the Session.Contents property on the Application object.

The following example shows the two values written to the session collection on the first page and then the session collection on the second page. Note: The page code is omitted here.

The first page that writes the value to the session collection

Dim name As String = "a"
Dim id As Integer = "1"
Session ("name") = Name
Session ("id") = ID
Second page, getting values from the session collection
Dim name As String = Session ("name")
Dim id As Integer = session ("id")
' Gets the number of items in the session-state collection
Dim i As Integer = Session.count
Note that in-process mode, no real serialization and deserialization occur, so objects are stored in session state as active instances of their respective classes.

In out-of-process session mode, because serialization and deserialization are used, you need to convert the data type as appropriate.

If you perform a serialization operation on a date value, the date should be the Int64 type.

VI. Session lifetime Management Events

Session lifetime management events have two Session_OnStart events and Session_OnEnd events, which you can set in the Global.asax.vb file

1. Session_OnStart Event

When connected to a server from a single browser client, the Session_OnStart event is triggered, which marks the beginning of the session, and does not trigger the event during subsequent browsing, unless the session times out or is discarded. The Session_OnStart event is the best time to set session variables, because they are set before any pages are accessed.

Example: The following example is the Session_OnStart event code that compares the number of online statistics that are commonly used:

Sub session_start (ByVal sender as Object, ByVal e as EventArgs)
' When the event occurs, add the number of online users by 1
Application ("UserCount") = Application ("UserCount") + 1
End Sub
2. Session_OnEnd Event

The Session_OnEnd event is discarded or timed out in the session, which marks the end of the event. Note, however, that only the INPROC mode supports this event. You can specify a time-out period by Web.config the timeout property of the <sessionState> section of the file, and if the user is within the time-out period (in minutes, the default is 20 points)
Clock) does not refresh or request a Web page, the session terminates. You can use the Session_OnEnd event to do some cleanup work.

Example: The following example is the Session_OnEnd event code that compares the number of online statistics that are commonly used:

Sub Session_End (ByVal sender as Object, ByVal e as EventArgs)
Application ("UserCount") = Application ("UserCount")-1
End Sub
For specific application examples of session state, see:

ASPX "Target=_blank> Simple Forum Program