7.8 State Management and Scalability

ASP.NET overcomes all major limitations of ASP when it comes to managing session states. As you are aware from ASP development, a session state is nothing but a named variable that is cached at the server for the duration of the web user's session. As the user navigates through the web application, the session state retains its value as long as the session is not expired.

ASP session-state management can be summarized as follows:

• The session starts, and the web application assigns a unique key to the user.

• This key is stored in an HTTP cookie. Along each subsequent request, the client browser sends the unique key back to the server.

• The server looks up the states stored for this particular key and processes the request accordingly.

Although this has worked fine for all these years, we've found out that there were a number of limitations to live with or work around. The biggest limitation is that the session state is process-dependent, which is impossible to implement in a web farm environment without custom session management.

7.8.1 ASP.NET Session-State Management

ASP.NET improves on ASP session-state management by giving you the option to move to an out-of-process model. By having all web servers in the farm pointing to a common server that hosts the out-of-process state manager, the web client can be redirected around the farm without losing the session states.

By using an out-of-process model, we no longer have the problem of losing session states when the IIS process is cycled. This means that if the web server application crashed for whatever reason and restarted within the session timeout duration, the web clients could still have all their session states intact. Of course, if the out-of-process state manager crashed, that is a whole different issue. This leads to the next improvement of ASP.NETthe ability to persist session state to a database.

The idea of persisting session state to a database is not new. Many of us have implemented this as the workaround for dealing with web farm configuration. However, ASP.NET makes it easier.

Similar to all other configurations in ASP.NET, session management is done through the use of the web.config files. There are two levels of configuration: machine and application. Machine-level configuration associates with the machine.config file stored in WinNT\Microsoft.NET\ Framework\<version>\CONFIG\machine.config, while the application-level configuration uses the web.config file in the application root directory. The application-level configuration overrides the machine-level configuration.

The following code is a portion of the web.config file dealing with session-state management:^[11]

^[11] The content of this file is case-sensitive.

<configuration>
  <system.web>
    <sessionState
      mode="InProc"
      cookieless="false"
      timeout="20" />
  </system.web>
</configuration>

Table 7-2 lists the properties of the SessionState class.

7.8.1.1 Out-of-process session-state management

When you set the session-state mode to run on a remote server (mode=StateServer), you must prepare the remote server to run the state management service automatically.

ASP.NET SDK includes an NT service call ASP.NET State Service to be used for out-of-process session-state management. Before setting your web.config files to use the out-of-process mode, you will have to start the ASP State service by going to the NT Services Management Console and start the service. You might want to change the startup type to automatic so that this service will start automatically at subsequent reboots.

7.8.1.2 SQL Server session-state management

To use this mode, the SQL Server machine has to be prepared. ASP.NET SDK includes a SQL script to create the ASP State database, which is where all session states are stored. Find this SQL script (InstallSqlState.sql) at %SystemRoot%\Microsoft.NET\Framework\BUILDNUMBER\. To apply the script to your SQL Server, use the SQL Server command-line tool osql.exe or SQL Query Analyzer. We use the latter because it allows us to inspect the script to get a better understanding of how this mode of session management is implemented. You will have to stop and restart SQL Server because the script alters the master to run the ASPState_Startup helper procedure at SQL startup time.

7.8.1.3 Cookieless session-state management

In ASP development, it is a usual practice to impose the requirement that the clients' web browsers be set up to accept cookies so that we can use session state the way it is meant to be used. However, when this requirement is not in place, especially for business-to-consumer (B2C) kinds of applications, the developers have to package the session ID along with the URL as a variable in the query string or as a form field and manage the session states manually.

With ASP.NET, as you can see from the sessionstate section of the configuration file, all you do is flip the setting of cookieless to true, and everything is automatically done for you. Session state can be used as if nothing has changed.

To setup and experiment with these session-state configuration, we've created two fictitious asp.net pages: login.aspx and main.aspx. The main page redirects the user to the login page if the user has not logged in. The login page redirects the user to the main page when the user is authenticated. When the user logs in, session variable UserName will be populated.

The following is the source for the simplified login page:

<HTML>

<script language="VB" runat="server">
Sub cmdLogin_Click(ByVal sender As System.Object, _
                   ByVal e As System.EventArgs)
  ' more processing here
  Session("UserName") = txtUID.Text
  Response.Redirect("Main.aspx")
End Sub
</script>

<body>
<form id="Form1" method="post" runat="server">
<table>
  <tr>
    <td>User ID</td>
    <td><asp:TextBox id="txtUID" 
                     runat="server"></asp:TextBox></td>
    </tr>
  <tr>
    <td>Password</td>
    <td><asp:TextBox id="txtPWD" 
                     textmode="password" 
                     runat="server">
                     </asp:TextBox></td>
    </tr>
  <tr>
    <td></td>
    <td><asp:Button id="cmdLogin" 
                    runat="server" 
                    Text="Login" 
                    onclick="cmdLogin_Click">
                    </asp:Button></td>
    </tr>
</table>
</form>
</body>
</HTML>

The skeleton for the main page is as follows:

<HTML>

<script language="VB" runat="server">
Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
  If (Session("UserName") <> "") Then
    labelData.Text = "Welcome back, " + Session("UserName")
  Else
    Response.Redirect("Login.aspx")
  End If
End Sub
</script>

<body>
<form id="Form1" method="post" runat="server">
  <asp:Label id="labelData" runat="server"></asp:Label>
</form>
</body>
</HTML>

In the first scenario, we will use session-state mode InProc. Because the IIS process handles the session state, if we simulate a web server restart by issuing the command iisreset and trying to refresh the main page, it will redirect us to the login page.

In the second scenario, we change the session-state mode to StateServer and start the ASP.NET Session State Service (i.e., the command line net start aspnet_state). Note that here we are running the Session State Service on the same machine as the web server even though we can have this service running on a separate server for more reliability. This time around, the session state persists through the resetting of the web server. Of course, if we restart the ASP.NET Session State Service itself, the main page will still redirect us to the login page.

Now that we've seen in-process and out-of-process session-state management, the last scenario we try will be to have session state persisted to a database. This is as simple as setting the mode and the sqlConnectionString attributes of the sessionState node in the web.config file. Of course, we ran InstallSqlState.sql on the SQL server to generate theschema and supporting stored procedures needed by ASP.NET to persist state into the database. The result is similar to the previous trials, however. Because the session data are stored in tempdb, they are cleared when the SQL server is restarted. As a side note, remember to have SQL Server Agent start automatically so that the cleanup session-state job can be run correctly.

7.8.2 Performance Versus Scalability and Reliability

As we've said, ASP.NET introduces an out-of-process model of session-state management, which enables more scalable solutions, but not without a cost. Out-of-process communication performs much worse than in-process communication, not to mention persisting the session states to a database. You should weigh the benefits of each of the different modes of state managements to find the one that is most suitable for your application. Table 7-3 summarizes the different modes and their trade-offs.