The basis for implementing session Status in ASP. NET

The basis for implementing session Status in ASP. NET

Dino esposito
Wintellect

September 2003

Applicable:
Microsoft ASP. NET

Summary: Discusses how to implement the session state function in ASP. NET 1.1 and how to manage Web ApplicationsProgramTo optimize session Status management. (This article contains links to English sites .)

Directory

Introduction
ASP. NET session status overview
Synchronous Access session Status
Comparison status provider
Status serialization and deserialization
Session Lifecycle
Cookieless session
Summary

Introduction

In a stateless environment such as a web application, understanding the concept of session state has no practical significance. However, effective State management is a required feature for most web applications. Microsoft ASP. NET and many other server-side programming environments provide an abstraction layer that allows applications to store persistent data based on each user and each application.

Note that the session Status of a Web application is the data cached and retrieved by the application in different requests. A session indicates all requests sent by the user during connection with the site. The session status is a collection of persistent data that the user generates and uses during the session. The status of each session is independent from each other and does not exist at the end of the user session.

The session status does not correspond to any logical entity that constitutes the HTTP protocol and specifications. A session is an abstract layer built by a server development environment (such as traditional ASP and ASP. NET. The way ASP. Net displays the session Status and the internal implementation of the session status depend on the basic structure of the platform. Therefore, the traditional ASP and ASP. NET achieve the session state in a completely different way. It is expected that the next version of ASP. NET will be further improved and enhanced.

This article discusses how to implement session state in ASP. NET 1.1 and how to optimize session state management in Managed Web applications.

ASP. NET session status overview

The session status is not part of the HTTP infrastructure. That is to say, there should be a structure component that binds the session status with each incoming request. Acceptable Runtime Environment (traditional ASP or ASP. NET)SessionAnd use it to indicate the data blocks stored on the server. To be resolved successfullySessionObject call. The runtime environment must add the session status to the call context of the request being processed. This operation varies by platform, but it is a basic operation for stateful Web applications.

In traditional ASP, the session status isASP. dllThe library contains free-threaded COM objects. (Are you curious about this? In fact, the CLSID of this object is the D97A6DA0-A865-11cf-83AF-00A0C90C2BD8 .) This object stores data organized by name/value pairs. The "name" Placeholder represents the keyword used to retrieve information, and the "value" Placeholder represents the content stored in the session state. Name/value pairs are grouped by session ID. In this way, each user can see only the name/value pairs he/she has created.

In ASP. NET, session State programming interfaces are almost the same as traditional ASP interfaces. However, their basic implementations are completely different. The former has more flexibility, scalability, and stronger programming functions than the latter. Before studying ASP. NET session Status, let's briefly review some structure functions of ASP. NET session infrastructure.

In ASP. NET, any incoming HTTP request must be transmitted through the HTTP module pipeline. Each module can filter and modify a large amount of information carried by the request. The information associated with each request is called the call context.HttpcontextObject. We should not regard the request context as another container of status information, although it providesItemsA collection is just a data container.HttpcontextObjects are different from all other State objects (for example,Session,ApplicationAndCache), Because its limited lifecycle exceeds the time required to process the request. After a request passes a series of registered HTTP modulesHttpcontextThe object will contain the reference of the State object. When the request can be processed, the associated call context is bound to a specific session (SessionAnd global state object (ApplicationAndCache).

The HTTP module is responsible for setting the session Status of each userSessionstatemodule. The structure of this module is based onIhttpmoduleInterface design, which provides a large number of services related to session status for ASP. NET applications. This includes generating session IDs, cookieless session management, retrieving session data from external State providers, and binding data to the request's call context.

The HTTP module does not store session data internally. The session status is always stored in an external component named "status provider. The status provider completely encapsulates session status data and passesIstateclientmanagerInterface Method to communicate with other parts. The HTTP module calls the method on this interface to read and save the session status. ASP. NET 1.1 supports three different state providers, as shown in table 1.

Table 1: Status client provider

Providers	Description
Inproc	Session value in the ASP. NET auxiliary process (in Microsoft Windows Server 2003Aspnet_wp.exeOrW3wp.exe. This is the default option.
StateServer	Session values are serialized and stored in separate processes (Aspnet_state.exe. This process can also run on other computers.
Sqlserver	Session values are serialized and stored in Microsoft SQL Server tables. SQL Server instances can be run locally or remotely.

The session Status HTTP module will<Sessionstate>Partially read the currently selected status provider.

<Sessionstate mode = "inproc | StateServer | sqlserver/>
 

AccordingModeThe value of the feature. The session status is retrieved from different processes through different steps and stored in different processes. By default, session status is stored in the local ASP. NET auxiliary process. In special cases, it is stored in ASP. NETCacheObjects in the dedicated slot (cannot be accessed by programming ). The session status can also be stored outside or even in remote processes (for example, in the Windows NT service named aspnet_state.exe ). The third option is to store the session status in a dedicated database table managed by SQL Server 2000.

The HTTP module deserializes session values at the beginning of the request to make them dictionary objects. Then, the program will be passed through the class (for example,HttpcontextAndPage) Display PropertiesSessionTo access the dictionary (actuallyHttpsessionstateType object ). The binding between the session status value and the visible Session Object of the developer continues until the end of the request. If the request is successfully completed, all status values will be serialized back to the status provider and can be used for other requests.

Figure 1 illustrates the communication between the requested ASP. NET page and the session value. TheCodeBothPageClassSessionThe property is related. The programming method is almost the same as that of traditional ASP.

Figure 1: session Status architecture in ASP. NET 1.1

The physical value of the session status is locked within the time required to complete the request. The lock is managed internally by the HTTP module and used to synchronize Access to the session status.

The session Status Module instantiates the application status provider and initializes the application using the information read from the Web. config file. Next, each provider will continue its own initialization operations. The initialization operations vary depending on the type of the provider. For example, the SQL Server Status manager opens a connection to a given database, and the out-of-Process Manager checks the specified TCP port. On the other hand,InprocStatus Manager stores references to callback functions. This operation is performed when an element is deleted from the cache and is used to triggerSession_onendEvent.

Synchronous Access session Status

When the web pageSessionWhat happens when attributes are called in a simple and intuitive way? Many operations are performed in the background, as shown in the following tedious code:

 
Int sitecount = convert. toint32 (session ["counter"]);
 

The above Code actually accesses a copy of the session value created by the HTTP module in the local memory and reads data from a specific status provider (see figure 1. What if other pages attempt to access the session Status synchronously? In this case, the current request may stop Processing Inconsistent data or outdated data. To avoid this situation, the session Status Module locks the reader/writer and queues access to the Status values. Pages with write permission on the session status will keep the writer lock for the session until the request is terminated.

By adding@ PageCommandEnablesessionstateThe property is set to true. You can request the write permission for the session status on the page. (This is the default setting ). However, the page can also have read-only permissions on the session status, for example, whenEnablesessionstateProperty is setReadonly. In this case, the module will lock the reader of the session until the request on the page ends. The result is read concurrently.

If a reader is locked for a page request, other requests simultaneously processed in the same session cannot update the session status, but can at least be read. That is to say, if a read-only request is being processed, the waiting read-only request has a higher priority than the request requiring full access. If a page request sets a writer lock for the session status, all other pages will be blocked, whether or not they want to read or write content. For example, if two frameworks trySessionThe content to be written. One framework can only be written after the other framework is complete.

Comparison status provider

By default, ASP. NET applications store session states in the memory of the secondary process, especiallyCacheObjects. SelectedInprocThe session status is stored inCacheObjects. This slot is marked as a dedicated slot and cannot be accessed by programming. In other words, if you enumerate all items in the ASP. NET data cache, no objects similar to the given session state will be returned.CacheThe object provides two types of slots: dedicated slots and public slots. Programmers can add and process public slots, but dedicated slots can only be added by the system (especiallySystem. WebClass defined in the component.

The status of each active session occupies a dedicated slot in the cache. The slot name is based on the session ID. Its value isSessionstateitemDoes not declare an instance of the class.InprocThe status provider obtains the session ID and retrieves the corresponding elements in the cache. ThenSessionstateitemObject content InputHttpsessionstateDictionary object, which is passed by the applicationSessionAttribute. Please note that there is an error in ASP. NET 1.0 that causesCacheThe special slot of objects can be enumerated by programming. If you run the following code in ASP. NET 1.0, You can enumerate the items that correspond to the objects in the current active session status.

Foreach (dictionaryentry ELEM in cache) {response. Write (ELEM. Key + ":" + ELEM. value. tostring ());}
 

This error has been fixed in ASP. NET 1.1. When you enumerate cached content, no system slots are listed.

So far,InprocIt may be the fastest access option. But remember, the more data stored in sessions, the more memory the Web server consumes, which may increase the risk of performance reduction. If you plan to use any out-of-Process Solutions, consider the possible impact of serialization and deserialization. The out-of-process solution uses the Windows NT Service (aspnet_state.exe) or SQL Server table to store session values. Therefore, the session state is retained outside the ASP. NET auxiliary process, and an additional code layer is required for serialization and deserialization between the session state and the actual storage media. This operation occurs as long as the request is processed and must be optimized to the maximum extent subsequently.

Because the session data needs to be copied from the external repository to the local session dictionary, the request performance is reduced by 15% (out-of-process) to 25% (SQL Server ). Please note that although this is only a rough estimate, it should be close to the minimum impact, and the maximum impact will be much higher than this. In fact, this estimation does not fully consider the complexity of the type actually saved in the session state.

In the out-of-process storage solution, session status remains for a long time, making the application more powerful, because it can prevent Microsoft Internet Information Service (IIS) and ASP. NET failure. By separating session states from applications, you can also easily extend existing applications to the Web farm and web garden architectures. In addition, session states are stored in external processes, which fundamentally eliminates the risk of periodic data loss caused by process loops.

The following describes how to use the Windows NT Service. As mentioned above, the NT Service is a process named aspnet_state.exe, usually located in the C: \ winnt \ Microsoft. NET \ framework \ v1.1.4322 folder.

The actual directory depends on the version of Microsoft. NET Framework that you actually run. Before using a status server, ensure that the service is ready and running on a local or remote computer used as a session storage device. Status service is an integral part of ASP. NET and is installed with it. Therefore, you do not need to run other installers. By default, the status service is not running and needs to be started manually. The ASP. NET application immediately tries to establish a connection with the server after it is loaded. Therefore, the service must be ready and running; otherwise, an HTTP exception is thrown. The Service Properties dialog box is displayed.

Figure 2: ASP. NET status server Properties dialog box

ASP. NET applications need to specify the TCP/IP address of the computer where the session Status Service is located. You must enter the following settings in the web. config file of the application.

 
<Configuration> <system. Web> <sessionstate mode = "StateServer" stateconnectionstring = "TCPIP = expoware: 42424"/> </system. Web> </configuration>
 

StateconnectionstringFeatures include the IP address of the computer and the port used for data exchange. The default computer address is 127.0.0.1 (local host) and the default port is 42424. You can also specify the computer by name. For code, the use of local or remote computers is completely transparent. Note that the name cannot contain non-ASCII characters and the port number is mandatory.

If you use the out-of-process session storage, the session status will still exist and be available for future use, regardless of the situation of the ASP. NET auxiliary process. If the service is interrupted, the data is retained and automatically retrieved when the service is restored. However, if the status Provider Service stops or fails, data will be lost. UseSqlserverInstead of usingStateServerMode.

 
<Configuration> <system. web> <sessionstate mode = "sqlserver" sqlconnectionstring = "Server = 127.0.0.1; uid = <user ID>; Pwd = <password>;"/> </system. web> </configuration>
 

You can useSqlconnectionstringFeature specifies the connection string. Note that the feature string must contain the user ID, password, and server name. It cannot contain tags such as database and initial catalog, because this information is a fixed name by default. The user ID and password can be replaced with the integrated security settings.

How to Create a database? ASP. NET provides two pairs of scripts to configure the database environment. The first script is namedInstallsqlstate. SQLAndUninstallsqlstate. SQLIn the same folder as the session Status NT Service. They are created with the nameAspstateDatabase and several stored procedures. However, the data is stored in the temporary storage area of SQL Server.TempdbDatabase. This means that session data will be lost if you restart the SQL server computer.

To address this limitation, use the second pair of scripts. The second pair of scripts is namedInstallpersistsqlstate. SQLAndUninstallpersistsqlstate. SQL. In this case, the aspstate database is created, but data tables are created in the same database, and these data tables are also persistent. When SQL server support is installed for a session, a job is created to delete expired sessions in the session status database. Job nameAspstate_job_deleteexpiredsessionsAnd keep running. Note that to make the job run properly, you need to run the SQLServerAgent service.

No matter which mode you select, the encoding method for session state operations will not change. You can alwaysSessionAttribute to read and write values as usual. All behavioral differences are processed at the lower abstraction layer. Status serialization may be the most important difference between session modes.

Status serialization and deserialization

When in-process mode is used, objects are stored in the session status as active instances of their respective classes. If real serialization and deserialization are not performed, it means that you canSessionStore any objects you have created (including non-serializable objects and COM objects), and their access overhead is not too high. If you select an out-of-Process status provider, it is another situation.

In the out-of-process architecture, session values are copied from the local storage medium (external appdomain database) to the memory of the appdomain Processing request. This task needs to be completed using the serialization/deserialization layer, and represents a major cost of the off-process state provider. The main impact of this situation on code is that serializable objects can only be stored in the session dictionary.

According to the involved data types, ASP. NET uses two methods for data serialization and deserialization. For basic types, ASP. NET uses an optimized internal serialization program. For other types (including objects and user-defined classes), ASP. NET uses the. NET binary formatting program. Basic types includeString,Date and Time,Boolean Value,Bytes,CharacterAnd all numeric types. For these types, the serialization program created by using the volume itself is faster than using the common default. net binary formatting program.

The optimized serialization program is not publicly released or provided in document form. It is only a binary Reader/writer and uses a simple but effective storage architecture. Use this serialization ProgramBinarywriterClass writes a byte to indicate the type, and then writes a byte to indicate the value of the type. When reading serialized bytes, the class first extracts one byte, detects the data type to be read, and thenBinaryreaderClass callsReadxxxMethod.

Note that the values of Boolean and numeric types are well known, but not for strings. On the Basic data stream, a string always carries a fixed-length prefix (write 7-bit integer code at a time). Based on this fact, the reader determines the correct size of the string. The date value is saved by writing only the total number of tags that constitute the date. Therefore, to serialize a session, the date must be of the int64 type.

You can useBinaryformatterClass to perform serialization operations on more complex objects (and custom objects. All non-basic types are identified using the same type ID and stored in the same data stream as the basic type. In short, serialization operations may cause a 15% to 25% reduction in performance. However, note that this is a rough estimate based on the assumption that the basic type is used. The more complex the use type, the higher the overhead.

If you do not use a large number of basic types, it is difficult to achieve effective session data storage. Therefore, at least theoretically, it is better to use three session slots to save three different string attributes of an object than to serialize the entire object. But what if the object to be serialized contains 100 attributes? Do you want to use 100 slots or only one slot? In many cases, a better way is to convert complex types into multiple simple types. This method is based on the type converter. A type converter is a lightweight serialization program that returns key type attributes in the form of a string set. A type converter is an external class that uses features to bind with the base class. The Type writers decide which attributes to save and how to save them. The type converter is also helpful for viewstate storage. It represents a more effective session storage method than binary formatting programs.

Session Lifecycle

For ASP. NET session management, it is important that the lifecycle of the session state object starts only when the first item is added to the memory dictionary. The ASP. NET session starts only after the following code snippet is executed.

 
Session ["myslot"] = "some data ";
 

SessionA dictionary usually containsObjectType. to read data backward, You need to convert the returned value to a more specific type.

 
String data = (string) session ["myslot"];
 

When the page saves dataSessionLoad the valueHttpsessionstateClass. When the request is processed, the dictionary content is loaded into the status provider. If the session status is empty because data is not put into a dictionary programmatically, the data is not serialized to the storage media. More importantly, the session status is not in ASP. NETCacheCreate a slot in SQL Server or NT Status Service to track the current session. This is for performance reasons, but it will have an important impact on the way session IDs are processed: a new session ID will be generated for each request until some data is stored in the session dictionary.

When you need to connect the session status to the request being processed, the HTTP module will retrieve the session ID (if it is not a startup request) and search for it in the configured status provider. If no data is returned, the HTTP module generates a new session ID for the request. This can be easily tested on the following page:

 
<% @ Page Language = "C #" trace = "true" %>  
 
Whenever you click this button and return to the page, a new session ID is generated and tracking information is recorded.
 

 
 

 
Figure 3: a new session ID is generated for each request in an application that does not store data in the session dictionary.
 

 
Session_onstartWhat is the event situation? Will this event be triggered for each request? If the application definesSession_onstartThe session status is always saved, even if the session status is empty. Therefore, for all requests after the first request, the session ID is always a constant. Use only when necessarySession_onstartProcessing Program.
 

 
If a session times out or is abandoned, its session ID will not change the next time you access a stateless application. After the design, even if the session status expires, the session ID can continue until the browser session ends. That is to say, as long as the browser instance is the same, the same session ID is always used to represent multiple sessions.
 

Session_onendThe event indicates the end of the session and is used to execute all the cleanup Code required to terminate the session. Note that onlyInprocThis event is supported only when session data is stored in the ASP. NET auxiliary process. ForSession_onendThe session state must exist first, which means that some data must be stored in the session state and at least one request must be completed.
 

 
In inproc mode, a variable expiration time policy is assigned to the session Status added to the cache as a project. The variable expiration time indicates that if a project is not used for a certain period of time, it will be deleted. The expiration time of any request processed during this period will be reset. The time interval of the session state item is set to session timeout. The technology used to reset the expiration time of the session state is very simple and intuitive: The session HTTP module only reads ASP. NETCacheSession status items stored in. If you know ASP. NETCacheThe internal structure of the object. This module calculates the variable expiration time to reset the variable expiration time. Therefore, when the cache project expires, the session has timed out.
 

 
Expired items are automatically deleted from the cache. As part of the project's expiration time policy, the status session module also represents a delete callback function. The cache will automatically call the delete function. Deleting the function will then triggerSession_onendEvent. If an application executes session management through an out-of-process component, the end event will never be triggered.
 
Cookieless session
 
Each active ASP. NET session is identified by a 120-bit string consisting of only characters allowed by the URL. Session ID is generated using the random number generator (RNG) to encrypt the provider. The service provider returns a sequence containing 15 randomly generated numbers (15 bytes X 8-bit = 120 bits ). The random number array is mapped to a valid URL character and returned as a string.
 

The session ID string is sent to the browser and then returned to the server application in either of the following two ways: using cookies (just like in traditional ASP) or modified URLs. By default, the session Status Module creates an HTTP cookie on the client, but you can use the modified URL embedded in the session ID string (especially for browsers that do not support cookies ). The method depends on the configuration settings stored in the web. config file of the application. To configure session settings, you can use<Sessionstate>Section andCookielessFeatures.
 

 
<Sessionstate cookieless = "True | false"/>
 
 
By default, cookieless is set to false, indicating that the cookie is used. In fact, cookies are only a text file on the client's hard disk. In ASP. NETHttpcookieClass. Generally, a cookie contains the name, value set, and expiration time. When the cookieless feature is set to false, the session Status Module actually createsASP. net_sessionidAnd store the session ID in the cookie. The following pseudocode shows the cookie creation process:
 

 
Httpcookie sessioncookie; sessioncookie = new httpcookie ("ASP. net_sessionid", sessionid); sessioncookie. Path = "/";
 
 
The expiration time of session cookies is very short, and the expiration time is updated after each request is successful. CookieExpiresThe expiration time of the cookie on the client. If the session cookie is not explicitly set,ExpiresThe default attribute isDatetime. minvalueThe minimum time unit allowed by. NET Framework.
 

To disable session cookies, set cookieless to true in the configuration file, as shown below:
 

 
<Configuration> <system. Web> <sessionstate cookieless = "true"/> </system. Web> </configuration>
 
 
Assume that you request the page at the following URL:
 

 
Http://www.contoso.com/sample.aspx
 
 
The actual content displayed in the address bar of the browser varies, and the session ID is included as follows:
 

 
Http://www.contoso.com/(5yl213455mrvws1uz5mmaau45)/sample. aspx
 
 
When the HTTP module of the session status is instantiated, this module checks the value of cookieless features. If it is true, the request is redirected (HTTP 302) to the modified virtual URL that contains the session ID (before the Page name. When the request is processed again, the request contains the session ID. If a request starts a new session, the HTTP module generates a new session ID and redirects the request. If the request is sent back, the session ID already exists because the relative URL is used for returning the request.
 

 
The disadvantage of cookieless session is that if an absolute URL is called, the session status will be lost. When using cookies, you can clear the address bar, go to another application, return to the previous application, and retrieve the same session value. If you disable session cookies, session data is lost. For example, the following code interrupts the session:
 

 
<A runat = "server" href = "/code/page. aspx"> click </a>
 
If you need to use an absolute URL, use some tips to manually add the session ID to the URL. You canHttpresponseClass callApplyapppathmodifierMethod.
 

 
<A runat = "server" href = <% = response. applyapppathmodifier ("/code/page. aspx") %> click </a>
 
 
ApplyapppathmodifierThe method uses a string that represents the URL and returns the absolute URL of the embedded session information. For example, this technique is particularly useful when you need to redirect from an HTTP page to an HTTPS page.
 
Summary
 
The session status was initially introduced by the traditional ASP, which is a dictionary-based API that enables developers to store custom data during a session. In ASP. NET, session Status supports the following two main functions: cookieless session ID storage and transmission, and the status provider for actual session data storage. To implement these two new functions, ASP. NET uses the HTTP module to control the binding between the session Status and the request context being processed.
 

 
In traditional ASP, session Status refers to Cookie usage. This is no longer the case in ASP. NET because the cookieless architecture can be used. With the strength of the HTTP module, you can break down the request URL to include the session ID and redirect it. Next, the HTTP module extracts the session ID from the URL and uses it to retrieve the status of any storage.
 

 
The physical status of a session can be stored in three locations: In-process memory, out-of-process memory, and SQL Server table. Data must be serialized/deserialized before it can be used by applications. The HTTP module copies the session value from the provider to the memory of the application at the beginning of the request. After the request is complete, the modified status will return to the provider. This data communication will adversely affect the performance to varying degrees, but it will greatly enhance the reliability and stability, and make it easier to support the Web farm and web garden architecture.
 
Author Profile
 
Dino espositoHe is a training instructor and consultant from Rome, Italy. As a member of the wintellect team, Dino specializes in ASP. NET and ADO. net, mainly engaged in teaching and consulting work in Europe and the United States. In addition, Dino manages wintellect's ADO. Net Courseware and writes the "cutting edge" column for msdn magazine.Article.