ASP. NET-server-based status management Session (2)

　　Preface

In the previous article "ASP. NET. ASP. the "status-1-state management overview" in. NET indicates that HTTP is a "stateless" protocol. When you jump from a page to another page, it does not save data, however, we need to transfer data from one page to another, and share some data among many pages. In order to allow users to save status information through requests, ASP. NET provides a Session storage mechanism. These Session variables are stored by each user. In ASP, you can only temporarily store Session variables in the memory of the Web server, however, this method has proved its shortcomings in scalability and dependency.

　　Reading directory

　　I. Three Problems in ASP Session stored in the memory of Web Server

Ii. ASP. NET allows three modes to store Session variables in three different places

Iii. Advantages of storing Session variables in SQLServer Databases

4. Next we will discuss the third best storage mode.

V. Instances

　　I. Three Problems in ASP Session stored in the memory of Web Server

1: This is the easiest way to lose. process recovery and server process crash will cause your website's visitors to log out for no reason.

2: It overload the server and affects the server performance.

Session variables are generated based on each user. When they are stored in the memory of the Web server, imagine a website with tens of millions of users. Due to the huge number of users, the number of active Session variables stored on the Web server is also very large, which means that the memory of your Web server stores a large amount of Session data. If you continuously increase the load on the server, it may be saturated, causing adverse effects on the overall application performance.

3: it cannot effectively apply the Web server group

A Web server group refers to a group of network servers running in parallel. Each Web server in the server group has an image of your website, and the traffic load of your website is evenly distributed to each Web server, to achieve load balancing, and the Session variables stored in the memory of the Web server will prevent the establishment of the Web server group.

Assume that three Web servers Server1, Server2, and Server3 are connected in parallel to receive user requests. When a request Request1 is sent to the Web server group, it is determined according to the load balancing logic. Server2, all other tasks in Server 3 are not idle, but Server1 is idle to process this request. Therefore, request Request1 will be sent to Server 1 for processing. Now, imagine that in the process of processing this request, you have stored a Session variable in the memory of Server1. Now everything is fine. After a while, the same user has another request Request2, this request requires the Session variable stored in the previous request, but Server1 is used by some tasks, while Server2 and Server3 are idle. According to the load balancing principle, request2 will be sent to Server2 for processing, but how does Server2 get the Session variable of the previous request? After all, the Session variable is stored in In the memory of any associated Server1, this means that Request2 still has to wait for Server1 to be idle. This clearly results in Server2 and Server3 waste, which leads to a waste of Web Server clusters.

　　Ii. ASP. NET allows three modes to store Session variables in three different places

1: InProc

The memory of the website server is also stored in the process

2: StateServer

Worker Process

3: SQLServer

Stored in an SQL Server database

　　Iii. Advantages of storing Session variables in SQLServer Databases

1: Reliability

Because the data is actually stored in a real database, it is better than any other method, so you don't have to worry about server restart.

2: Security

The SQL Server mode is safer than the InProc mode and StateServer mode. You can configure SQL server security options to protect your data.

3: scalability

Web Server clusters can easily obtain Session variables because they are stored in an independent database.

By default, the first mode is used. The second and third modes are called "out-of-process mode" because the storage of Session variables is irrelevant to the Web site.

In web. config, you can use the <sessionState/> node to configure the state mode.

　　4. Next we will discuss the third best storage mode.

　　1: Configure SQL Server to store Session Status

You can use the command line tool called aspnet_regsql.exe to complete the configuration.

Format

Aspnet_regsql.exe-S <SQL Server IP>-U <User Name>-P <Password>-E-ssadd-sstype c-d <Database Name>

　　

In actual operation, start to run:

C: \ WINDOWS \ Microsoft. NET \ Framework \ version \ aspnet_regsql.exe-S.-U sa-P hy-ssadd-sstype c-d aspstate

 

　　

Tables and stored procedures generated in the Session status database in SQLServer

　　

 

　　2: Configure Web. config to store the Session Status

Once the SQLServer server is successfully configured to support Session state storage, You need to modify the sessionState configuration item in the Web. Config file of the ASP. NET Web application to make the Session State database take effect.

.
　

<SessionState mode = "SQLServer" sqlConnectionString = "server = .; database = aspstate; user = sa; pwd = 123 "allowCustomSqlDatabase =" true "cookieless =" false "timeout =" 20 "> </sessionState>

　　V. Instances

We create two Web forms: WebForm1.aspx and WebForm2.aspx. The first page shows a "add product to my shopping cart" button. When you click it, save a fixed product to a DataTable, then, the DataTable is stored in a Session variable to pass it in the request. The second page shows the item added from the DataTable.

We can see that the SessionID output in the third figure is consistent with the SessionID in the SQLServerSession status Storage Server database. This SessionID is used to maintain the data of each user. What do you mean? This indicates that your Session variables are actually stored in the database of the SQLServer server and output on the WebForm2.aspx page.

Running Effect