ASP. NET 3.5 core programming learning notes (33): Overview of httpsessionstate

The httpsessionstate class provides a dictionary-based model for storing session Status values. Only requests in the same session context (that is, multiple page requests sent by the same user) can access the session status. There are many ways to store and publish session statuses, including in the Web farm and web garden environments. However, by default, the session status is held by the ASP. NET working thread.

The session state scalability model provides two solutions:

1. Local customization of ASP. NET's existing session state mechanism (for example, creating an oracle session provider or creating a module that can control ID generation ).

2. You can replace the standard HTTP module with other custom HTTP modules.

The first solution is easier to implement, but the customizable functions are limited. The encoding in the second solution is complex, but it provides better flexibility.

Session status HTTP Module

The session state is a set that is exposed by the session attribute of the page class and its type is httpsessionstate. This class is closed and implements the icollection and ienumerable interfaces. Instances of this type are created at the start of each request that supports the session. The data filled in this set will be read from the specified media in the form of key/value pairs, and will be appended to the request context. The session attribute of page is only mapped to the session attribute of the httpcontext class.

The HTTP module manages session state storage and retrieval through some special providers. The ASP. NET module that establishes session status for each user connected to the application. It is an HTTP module called sessionstatemodule. The sessionstatemodule object implements the ihttpmodule interface and provides session status services for ASP. NET applications.

However, as an HTTP module, sessionstatemodule uses relatively simple programming interfaces (the ihttpmodule interface only uses the init and dispose methods) to execute many very complex tasks, in addition, many of these operations will seriously affect the attributes and functions of Web applications. The session Status Module is called when an httpapplication object that processes a given request is created. This module is responsible for generating or obtaining a unique session ID string, this allows you to store and retrieve status data through the status provider (such as the memory of the SQL Server or Web Server.

Status Client Manager

When the session Status HTTP module is called, it reads the settings in the <sessionstate> section of the web. config file and determines the "status Client Manager" selected by the current application ". The status client manager is a component that stores/retrieves the data of the current active session. The sessionstatemodule component queries the status Client Manager process to obtain the key/value pairs for a given session.

ASP. NET has four session state processing methods. Session statuses can be stored in the asp.networking thread and maintained in an external (or even remote) process called aspnet_state.exe, which can be managed through SQL Server or other database tables. The last method is to store session data in custom components. The following table summarizes various solutions:

The sessionstatemode Enumeration type contains options available for the status client provider. Inproc options provide the fastest access speed, but remember that the more data stored in sessions, the larger the memory usage of the Web server, which may cause performance bottlenecks. If you plan to adopt an out-of-process solution, consider the impact of the serialization and deserialization processes.

The session Status Module determines the status provider based on the settings read by the <sessionstate> section of the web. config file. Then, it instantiates and initializes the State provider of the application. Each provider can execute initialization. Different types of providers may have different procedures.

All status providers expose methods for communicating with the main program. The entire architecture is shown in:

All actual State provider objects are inherited from one base class: sessionstatestoreproviderbase class.

Create an httpsessionstate object

The status module obtains the session Status and attaches it to each request context running in the current session. The session status is available only after the httpapplication. acquirerequeststate event is triggered. After the httpapplication. releaserequeststate event is triggered, the data is discarded and cannot be recovered. This means that when the session_end event is subsequently triggered, all statuses have disappeared.

When the httpapplication. acquirerequeststate event is triggered, the session module creates an httpsessionstate object for the request. In this case, the httpsessionstae object obtains a session ID and a session dictionary. The session dictionary is actually a set of State values that can be accessed through the session attribute of the page.

When a new session is initiated, the data dictionary is an empty object. If this module processes requests from existing sessions, the session Status provider of the current activity deserializes the data and fills in the data dictionary. When the request ends, if the page requests to modify the content of the current dictionary, it will execute the serialization process and send the data to the status provider. The entire process is shown in:

Synchronization of session Status access

When the session attribute is called on a web page, it actually accesses a copy of the data, which is located in the local memory. What happens if other pages (in the same session) attempt to access the session status concurrently? In this case, the current request may eventually obtain inconsistent data, or the data is not up-to-date.

To avoid this situation, the session Status Module locks the Read and Write methods so that requests to access status data are queued for execution. The page accessed by writing data to the session state will keep the write method locked in the current session until the current request ends. By setting the enablesessionstate attribute of the @ page command to true, the page will get the write access permission for the session status. Pages that only have access permission to the session State (for example, the enablesessionstate attribute is readonly) will keep the read method locked in the current session until the current request ends.

If the reader lock is set for the page request, other concurrent running requests cannot update the session status, but read is allowed. If the page request sets writer lock for the session Status, other pages will be locked, whether read or write.

Concurrent access to session status is not common in practice. This may happen if a page has multiple frames, or if the user opens two copies of the same page or multiple pages of the same application. In addition, if you use an HTTP handler that enables a session to serve an embedded Resource (image or CSS file), it may also happen. By default, concurrent access is not allowed. However, it is a good programming habit to explicitly declare the usage mode of the page to the session Status (read/write, read-only, or not used. Therefore, you only need to set the enablesessionstate attribute of the @ page command.

Attributes of the httpsessionstae class

The httpsessionstate class is defined in the system. Web. sessionstate namespace. This is a generic collection class that implements the icollection interface. The following table lists the attributes of the httpsessionstate class:

For synchronization, the httpsessionstate class becomes a special collection class. As mentioned above, the synchronization mechanism is implemented in the sessionstatemodule component, which ensures that only one thread can access the session Status at the same time. However, because httpsessionstate implements the icollection interface, it includes the implementation of issynchronized and syncroot. It should be noted that issynchronized and syncroot are unique attributes of the synchronization set and are irrelevant to the session synchronization discussed earlier. Technically speaking, httpsessionstate itself does not support synchronization, but the session state accessed through it is synchronized.

Methods of the httpsessionstate class

The following table lists the methods of the httpsessionstate class:

When the process of terminating the current request is run, the session Status Module checks the internal status and determines whether the user has issued a command to cancel the session. If this flag is set (the abandon method is called), all response cookies will be removed and the process of terminating the session will be started. But that does not mean that the session_end event will be triggered.

First, the session_end event is triggered only when the session mode is inproc. Second, if the session dictionary is empty and no actual session status data exists in the application, this event will not be triggered. In other words, if the session is closed or abandon is called, and at least one request has been completed, session_end will be triggered.