Session Management

Article
06/24/2011

Microsoft Corporation
October 2003

Applies to
    Microsoft® ASP.NET
    Microsoft Visual Studio® .NET
    Java Server Pages

Summary: Learn how JSP and ASP.NET maintain a user's session state across pages, and the advantages of using ASP.NET over JSP. (16 printed pages)

Introduction
Session Management in JSP
Conversion with JLCA
Persisting the Session with ASP.NET
Summary

Introduction

HTTP, the underlying transport of the Web, is a memory-less protocol. Every time a client requests an application, HTTP has no idea of the caller's identity—it simply forwards the request to the Web server. To allow for a level of continuity in a Web-based application, you must use the technologies discussed in this article, which allow both JSP and Microsoft® ASP.NET applications to retain state in between client requests.

Both JSP and ASP.NET use the concept of sessions and Session objects to store data unique to a particular client while that client is connected to a Web application. For example, when a user logs on to a Web application, her login name, password, and other pertinent information might be stored in a Session variable and maintained during her visit to the site so that it can be accessed when needed. When a session begins, the requesting browser is given unique piece of information, or "ticket," that is presented by the browser on subsequent visits to identify the user. The Web application can then, for example, customize the settings for that user when she visits, since it can find her personal preferences using the information stored in the Session object referenced by the ticket.

In this article, we will start by examining how Session objects are used in JSP on the CodeNotes Web site. We will then convert a portion of CodeNotes to ASP.NET using the Java Language Conversion Assistant (JLCA), to demonstrate how the JLCA handles session calls. Finally, we will look at how a similar application can be written in ASP.NET to take advantage of additional features such as persisting session information to a database.

Session Management in JSP

In Java, the Session object is an instance of javax.servlet.http.HttpSession. The Session object provides a stateful context across multiple page requests from the same client during a conversation with the server. In other words, once a user has connected to the Web site, the Session object will be available to all of the servlets and JSPs that the user accesses until the session is closed due to timeout or error. You can access the HttpSession object for a servlet using the following code:

Listing 1. Accessing the HttpSession

//Inside doGet() or doPost()
HttpSession session = req.getSession();

In JSP, Session objects are used just as they are in servlets, except that you do not need the initialization code. For example, to store attributes in a Session object, you would use code like this:

Listing 2. Using the session variable in JSP

<%session.setAttribute("number", new Float(42.5));%>

This creates a key in the session variable named number, and assigns to it a value of "42.5." To retrieve information from a session, we simply use the getAttribute function, like this:

Listing 3. Retrieving information from a session

<td>Number: <%=
   session.getAttribute("number") %></td>

Attributes

The most commonly used feature of the Session object is the attribute storage. Remember that attributes are attached to several support objects and are the means for storing Web state in a particular scope. Session attributes are commonly used to store user values (such as name and authentication) and other information that needs to be shared between pages. For example, you could easily store an e-commerce shopping cart JavaBean in a session attribute. When the user selects the first product, a new shopping cart bean would be created and stored in the Session object. Any shopping page would have access to the cart, regardless of how the user navigates between pages. The code on the shopping page might look like Listing 4.

Listing 4. Using attributes

//Create new attribute if shopping cart does not exist
//Assumes ShoppingCartBean object has been imported
HttpSession session = req.getSession();

if (session.getAttribute("Cart") == null) {
   ShoppingCartBean cart = new ShoppingCartBean();
} else {
   ShoppingCartBean cart = (ShoppingBeanCart)session.getAttribute("Cart");
}

/**Next, add new product to cart.
Assumes ItemBean is a valid object and has been imported **/

ItemBean newItem = new ItemBean("Hat", 1, 23.34, "UPC343212");
cart.addItem(newItem);

/**Then, add or update the session attribute.
Remember that attribute names ARE case-sensitive.**/

session.setAttribute("Cart", cart);

CodeNotes Example

The CodeNotes Web site uses the Session object to keep track of user information during a user's visit to the site. This allows it, among other things, to display a message at the top of each page with the user's name, and customize how article text appears on the site depending on the user's preferences.

The file content_loginMain.jsp contains the form that the user will be presented with when logging into the site.

Listing 5. CodeNotes loginForm

<form name="loginForm" method="POST"
   action="<%=Links.linkToProcessLogin()%>">
   <INPUT TYPE="HIDDEN" NAME="<%=Parameters.REFERRER%>"
      VALUE="<%=referrer%>"/>
   <table>
      <TR>
         <TD COLSPAN="2" class="bodycopyblack"><%=userMessage%></TD>
      </TR>
      <TR>
         <TD class="bodycopyblack">Email:</TD>
         <TD class="bodycopyblack">
            <INPUT TYPE="TEXT" SIZE="30" NAME="<%=Parameters.USERNAME%>"
               value="<%=(username!=null?username:"")%>">
         </TD>
      </TR>
      <TR>
         <TD class="bodycopyblack">Password:</TD>
         <TD class="bodycopyblack">
            <INPUT TYPE="PASSWORD" NAME="<%=Parameters.PASSWORD%>">
         </TD>
      </TR>
      <TR>
         <TD></td>
         <TD class="bodycopyblack">
            <INPUT TYPE="SUBMIT" VALUE="Log In" class="button">
         </TD>
      </TR>
   </TABLE>
</form>

This form asks the user to enter a login name and a password, and then submits that information to the ProcessLogin servlet (which we'll discuss in a moment). Notice how the username field persists data by storing the entered value in a variable called username, but that no validation is done on this particular page. The validation, as well as the addition of the user's information to the Session object, is done in the ProcessLogin servlet (which is in the file ProcessLoginAction.java).

ProcessLogin

We could easily have added the username and password to the Session object from within the JSP, but the CodeNotes Web site is somewhat complicated in that it uses Java Struts as a model for its structure. Therefore, when the form is submitted, the information entered by the user is first passed to the linksToProcessLogin() method in the Links class, which determines which servlet to use for processing login information. This class determines that the appropriate action is ProcessLogin, which, maps to ProcessLoginAction.java. (This can be determined from the struts-config.xml file.)

ProcessLoginAction.java is shown in Listing 6 below (many import statements from the beginning of the file have been removed for brevity).

Listing 6. ProcessLoginAction.java

public class ProcessLoginAction
extends LoginAction
{
   public ActionForward doAction(ActionMapping mapping,
   ActionForm form, 
   BreadCrumbTrail breadCrumbTrail,
   EventLog eventLog, User user,
   HttpServletRequest request,
   HttpServletResponse response)
   {
      ActionForward forward=null;

      UserManager userManager=Context.getContext().getUserManager();

      String username=
         ((String) request.getParameter(Parameters.USERNAME));
      String password=
         ((String) request.getParameter(Parameters.PASSWORD));
      String redirect=
         ((String) request.getParameter(Parameters.REFERRER));

      if ( (username==null) || (username.equals(""))
         ||(password==null) || (password.equals(""))
         )
      {
         String userMessage =
            "Please enter both a username and password.";
         request.setAttribute(Attributes.USER_MESSAGE,userMessage);
         forward = mapping.findForward(ActionForwardConstants.LOGIN_MAIN);
      } else
      {
         try
         {
            User registeredUser=
               userManager.authorizeUser(username,password);
            // get session
            HttpSession session = request.getSession(true);

            session.setAttribute(Attributes.USER,registeredUser);
            if ( redirect==null || redirect.equals("") )
            {
               redirect=Links.linkToHomeMain();
            }
            forward=new ActionForward(redirect);
            forward.setRedirect(true);
         } catch ( AuthorizationException ae )
         {
            String userMessage =
               "Invalid username/password combination. Please try again.";
               request.setAttribute(Attributes.USER_MESSAGE,userMessage);
               forward =
                  mapping.findForward(ActionForwardConstants.LOGIN_MAIN);
         }
      }
      return forward;
   } // doAction
}

This servlet has three tasks:

Ensure that both a username and password have been typed in the correct fields, and return to the login page with an error message if they have not.
Verify that the user is a registered user with the userManager.authorizeUser() method. The case of a non-existent user is handled by an AuthorizationException.
If the user exists, a User object is added to the current session with the line:
```
session.setAttribute(Attributes.USER,registeredUser);
```

This session will be maintained as long as the user is logged into the site. Through it, user information and preferences can be accessed when needed by other pages within the CodeNotes domain.

After these tasks are complete, and the user has been authorized and added to the session, the servlet forwards the browser to the appropriate page on the site (or the main page, by default).

Using the session

As mentioned previously, once user information is available in a Session object, it is accessed from various parts of the CodeNotes Web site. One example of this is the "login panel" that displays at the top of each page.

In the file loginPanel.jsp (which is inserted into each page as part of the template for the CodeNotes Web site), the user's information is retrieved from the Session object by using the code in Listing 7.

Listing 7. Retrieving user information from the session

<% User user=(User) session.getAttribute(Attributes.USER); %>

The user's display name is then displayed in the login panel as a link, by using the code in Listing 8.

Listing 8. Displaying user information retrieved from the session

<td class="smallcopyblack" nowrap valign="top">
   You are currently logged in as:
   <a HREF="<%=Links.linkToUserDisplay()%>">
      <%=user.getDisplayName()%>
   </a>&nbsp;&nbsp;<br>

In the next section of this article, we'll look at how the JLCA converts session-related Java/JSP code to ASP.NET.

Conversion with JLCA

The JLCA does a simple, direct conversion of session-related code, and there is very little you will need to do manually in order to get it working after a conversion. For the example in this section, we will use a modified version of the CodeNotes Web site's content_loginMain.jsp and loginPanel.jsp to demonstrate how data can be added and extracted from the Session object in JSP, and how this code is converted to ASP.NET. The major modification is that we have removed most of the Struts code to simplify the example, although there are a few other minor changes that were necessary in order to have this application work independently of the full CodeNotes site. Download the JLCA Demo.

Original JSP

The JSP version of this application is similar to what you saw in the last section. content_loginMain.jsp is a simple form that asks for a username and password. We have removed its reliance on a servlet to validate the form and forward to the appropriate location, and have instead added the code in Listing 9 to the JSP itself.

Listing 9. Java code in content_loginMain.jsp

<% String username=((String) request.getParameter("username"));
   String password=((String) request.getParameter("password"));
   String redirect=((String) request.getParameter("referrer"));

   if ( (username==null) || (username.equals(""))
      ||(password==null) || (password.equals(""))
      )
   {
      String userMessage = "Please enter both a username and password.";
      request.setAttribute("userMessage",userMessage);
   } else
   {
      session.setAttribute("username",username);
      session.setAttribute("password",password);
      session.setAttribute("redirect",redirect);
      response.sendRedirect("loginPanel.jsp"); 
   }
%>

Note that we also change the<form>element so that its action attribute points to the current page (action="content_loginMain.jsp"). That way, the code in Listing 9 will execute when the Submit button is clicked, and forward (or stay) when appropriate. Note also that we are not performing any validation, or even authorization, in this example. We simply allow any username and password combination.

In Listing 9, if both a user name and password have been entered, we add the user name, password, and redirect (not actually needed in this modified version) to the Session object, and then forward the user directly to loginPanel.jsp. loginPanel.jsp, shown in Listing 10 , obtains the user name, password, and redirect from the Session object and uses the user name on the page.

Listing 10. loginPanel.jsp

<%@ page import="com.codenotes.web.Links,
   com.codenotes.web.Parameters,
   com.codenotes.web.Attributes"
%>

<%
   String userDisplayName = (String) session.getAttribute("username");
%> 

<table border="0" cellspacing="0" cellpadding="0" height="32">
   <tr> 
      <%
         if (userDisplayName == "" || userDisplayName == null)
         {
      %>
      <td class="smallcopyblack" nowrap valign="top" align="right">
         <img src="/images/ballbullet.gif" width="11" height="15">
      </td>
      <td class="smallcopyblack" nowrap valign="top">Log in to get your
         personalized&nbsp;&nbsp;<br> 
         settings. New user? <a href="<%=Links.linkToRegister()%>"
         class="smallcopyblack">Click here.</a>
      </td>

      <%
      } else
      { 
      %>
      <td class="smallcopyblack" nowrap valign="top" align="right">
         <img src="/images/ballbullet.gif" width="11" height="15"></td>
      <td class="smallcopyblack" nowrap valign="top">You are currently
         logged in as: <a HREF="<%=Links.linkToUserDisplay()%>">
         <%=userDisplayName%></a>&nbsp;&nbsp;<br>
         Edit your profile? <a HREF="<%=Links.linkToUserDisplay()%>">
         Click here.</a></td>

      <%
      }
      %>
   </tr>
</table>

You'll also notice that if you navigate directly to loginPanel.jsp (without going through content_loginMain.jsp), you will get a different page (one that does not use the variables obtained from the session).

Let's look at what happens when we convert this application to ASP.NET using the JLCA.

ASP.NET Conversion

Conversion, in this case, is a relatively simple process. Simply run the Java Language Conversion Assistant wizard from Microsoft Visual Studio® .NET, and convert the Web project as normal. Make sure that the uncompiled classes (.java files) are in the directories with the compiled classes if you want them to be converted into C# and added to the ASP.NET application.

After conversion, you will need to make several manual modifications in order for the application to work correctly.

Set content_loginMain.aspx as the start page by right-clicking it and then clicking Set As Start Page.
In Links.cs (located in WEB-INF\com\codenotes\web\), you will find three instances of the URLEncoder.encode() method that were not converted by the JLCA. You need to manually replace these lines so that they use the .NET HttpUtility.UrlEncode() method instead. For example, a line that looks like this:
```
sb.Append(Parameters.REFERRER).Append("=").Append(URLEncoder.encode(ref
errerURL));
```
should be modified so that it looks like this:
```
sb.Append(Parameters.REFERRER).Append("=").Append(HttpUtility.UrlEncode
```

(referrerURL));

Change the Import statement at the top of content_loginMain.aspx to:
```
<%@ Import Namespace="com.codenotes.web" %>
```
The JLCA does not automatically change the extensions on hyperlinked pages. This means that if you have a link to a JSP in your original code, that link will remain to a JSP in the converted code. For this reason, you need to change the redirect statement (Line 24 of content_loginMain.aspx) to the following:
```
Response.Redirect("loginPanel.aspx");
```
In order for the images to show up correctly in the ASP.NET version of the application, you need to change all image references so that they start with "image/" instead of "/image", due to a difference in the way .NET applications understand directory structures. You will need to make three changes in content_loginMain.aspx, and two in loginPanel.aspx.
If you want to be able to view content_loginMain.aspx in Design mode, you will need to change line 69 so that it does not have quotes-within-quotes (which are allowed in JSP, but not in ASP.NET). For example, the following line works fine in ASP.NET:
```
<TD class="bodycopyblack">
<INPUT TYPE="TEXT" SIZE="30" NAME="username" value="<%=username%>">
</TD>
```

As you may have noticed, there was no need to make any change to any of the code that dealt with the Session object. Typically, session code will convert perfectly and accurately from JSP to ASP.NET, and you will not have to worry about making any manual modifications in order for it to work.

Persisting the Session with ASP.NET

Sessions in ASP.NET applications work much the same as they do in JSP. In order for the Web server to differentiate incoming requests, it must give the requesting browser a unique piece of information (a ticket) that is presented on subsequent visits. The Web server uses this ticket to retrieve session information from a durable storage area.

Accessing Session from ASP.NET

As discussed in the previous section, most session access code converts directly. However, that holds true only if you are working in JSP and/or ASP.NET pages. .NET does not have a direct equivalent to a servlet class, so if you need to access the session from a helper class, you have to use other means for accessing it. Fortunately, this amounts to adding a single line of code to your class:

Listing 11. Accessing Session from a normal class

System.Web.SessionState.HttpSessionState
mySession = System.Web.HttpContext.Current.Session;

Provided that your class is incorporated correctly into your Web application, you can use this code to create a reference to the existing session and add and retrieve objects as if you were working out of an ASP.NET page.

Where Session Information Is Stored

In traditional ASP, session information was stored in the same process as the ASP runtime. This process is usually the host process of IISINETINFO.EXE. There are two major problems with storing session information in this location. First, if the Web server (IIS) crashes, you lose all the information you have stored. Second, storing a session in such a manner presents challenges for Web farm scenarios, where multiple machines must share session data. Each computer in the farm has its own process, and therefore its own memory area for session data.

ASP.NET is considerably more versatile than its predecessor, and allows you to store session information in one of three locations:

Inside the ASP.NET runtime process (aspnet_wp.exe). This is the default option and is the best choice from a performance perspective but suffers from the same problem as ASP session storage: if the Web server crashes you will lose all information.
Inside a dedicated Windows Service. A Windows Service is a durable process that usually starts when the computer boots and can survive logins and logouts (in fact, IIS itself runs as a Windows Service). This technique is slower than the first option, because the ASP.NET runtime must retrieve session information from the external Service, rather than from its own process. However, this option is more durable, as session information persists even if the Web server crashes or is restarted.
Inside a Microsoft® SQL Server™ database. This option is the most durable of the three. Although the second option protects against Web server crashes, session information is still lost if the entire machine crashes. Because this third option logs Session to a database (as opposed to the computer's memory), it will survive even a machine reboot. From a performance perspective, this option is by far the slowest.

Options two and three are noteworthy because they can be used to share session information in Web farm situations across multiple machines.

Storing Session in Different Locations

In ASP.NET, session data, which is accessed through the Session object, is usually stored on the Web server. As such, session data persists as the user browses through multiple pages. Session in ASP.NET is configured by the <sessionState> element, which you'll find in the web.config file in any ASP.NET project.

Listing 12. Session configuration

<sessionState mode="InProc"
   stateConnectionString="tcpip=127.0.0.1:42424"
   sqlConnectionString="data source=localhost;
      user id=sa;password="
   cookieless="false" timeout="20"/>

The most important attribute in Listing 12 is mode, which can be set to InProc, StateServer, or SQLServer. This attribute determines exactly where session data is stored. These three settings, which will be illustrated in the following examples, will correspond to the three session storage options we listed at the beginning of this section.

The timeout setting in Listing 12 determines the period of time during which ASP.NET maintains an individual session (by default, twenty minutes). Recall that session data is specific to a browser instance. If the user remains idle for a period of time equal to the timeout attribute, then ASP.NET will invalidate their session information and remove it from wherever it is being stored. Listing 12 also depicts the cookieless attribute, which will be examined in the next example.

Storing session data in-process

By default, ASP.NET stores session information inside its runtime process. The shortcoming of this setting is that session data does not survive a Web server restart. To illustrate this problem, create a new project in Visual Studio .NET named SessionDemo, and then add the following code to the projects global.asax file.

Listing 13. Storing session in Session_Start

Sub Session_Start(...)
   'Fires when the session is started
   Response.Write("Session started<p>")
   Session("StartTime") = DateTime.Now.TimeOfDay.ToString()
End Sub

As explained in Chapter 4, global.asax is the ASP.NET equivalent of the global.asa file that you used in ASP—it houses code that is accessible to all pages within the application. In addition, this file houses methods such as Application_Start and Session_Start that are triggered when the ASP.NET application starts and when an individual session starts, respectively. Thus, the code in Listing 13 stores the time at which the client accessed the application into the session variable StartTime.

Next, add the following code to the projects Page_Load() event, which prints out the contents of the StartTime variable.

Listing 14. SessionDemo application

Private Sub Page_Load(...)
   'Put user code to initialize the page here
   Response.Write("Session stored at: ")
   Response.Write(Session("StartTime"))
End Sub

Run the application by pressing F5, and the browser will output something similar to Listing 15.

Listing 15. SessionDemo output

Session startedSession stored at: 15:26:55.7489696

Press the browser's Refresh button, and the first line in the output will disappear because Listing 13 executes only on new client instances. The point of this exercise is that when session information is stored in process, it does not survive a Web server shutdown. If you type iisreset at a command prompt to restart IIS, and then try to access the application again, the time it reports will change. In other words, ASP.NET did not persist the StartTime variable when the Web server was restarted.

Storing session inside the Windows Service

It is possible to store session information apart from the ASP.NET runtime inside a Windows Service named aspnet_state. To enable this option you must first modify the project's web.config file as follows:

Listing 16. Storing session out of process

<sessionState mode="StateServer" 
  stateConnectionString="tcpip=127.0.0.1:42424" />

Next, you must start the ASP Windows Service, which will store session data. There are two ways to accomplish this. First, you can go to the command prompt and type net start aspnet_state. Second, you can go to Control Panel/Administrative Tools/Computer Management, click Services and Applications, and then click Services.

Right-click ASP.NET State Service, and then click Start. This service must be started manually (look under the Startup Type heading). If you plan to use this session storage option, then you can configure the service to start automatically when the OS boots, by right-clicking ASP.NET State Service, clicking Properties, and then changing Startup Type from "Manual" to "Automatic."

As a result of these settings, session information will be stored inside the Windows Service (aspnet_state.exe), as opposed to the ASP.NET runtime itself. Thus, Session will persist even on a Web server restart. Run the application again by pressing F5, and as expected, the application will report the time the session started by printing out the StartTime variable. Restart IIS by typing iisreset at the command prompt, click the browsers Refresh button, and you will observe the effects of storing Session out of process: the reported time will remain the same, indicating that session information persisted through the restart.

The stateConnectionString attribute

Look at Listing 12 and you will see an attribute called stateConnectionString. This attribute specifies the TCP/IP address where the ASP.NET Service is located. Those familiar with TCP/IP will recognize that the address in Listing 12 (127.0.0.1) is a special TCP/IP value that informs ASP.NET that the Service is located on the current machine. With this setting, it is possible to direct ASP.NET to a Windows Service on another machine, a capability that is useful in Web farm scenarios. For example, all machines in the farm could specify the same address and thus store (and share) Session on a dedicated computer.

Storing session in SQL Server

Your last option when storing session information in ASP.NET is to store it in a Microsoft SQL Server database (version 7 or greater required). Employing this option is straightforward, but requires more administrative steps than the first two options.

In order to store ASP.NET session information inside SQL Server you must:

Have SQL Server version 7 or 2000 installed.
Execute the following script using SQL Server's Query Analyzer, which creates the database that ASP.NET uses to store Session:
```
%winroot%\Microsoft.NET\Framework<em>versionNum\InstallSqlState.sql
```
Modify the web.config file appropriately (where the connectionString attribute denotes the connection string that should be used to open the database):
```
<sessionState mode="SQLServer" sqlConnectionString=
"data source=127.0.0.1;user id=sa;password=" />
```

Storing Session inside SQL Server is the most durable option, as information persists even if the machine crashes. This is the slowest option of the three, however, because session data must be accessed from disk rather than directly from memory, a process thousands of times slower. Note that as with the Windows Service option, you can point ASP.NET to a Session store on a different machine, which is also appropriate in Web farm settings.

References to COM Objects

A common technique in traditional ASP was to use Session variables to store references to COM objects so that they can be used at a later time:

Listing 17. Storing a COM object reference

Set Session("MyObject") = CreateObject("WhatProc.WhatProc")

If you intend to employ this technique in ASP.NET, then you must ** store all session information in process (the default option). Attempting to store it in either the Windows Service or SQL Server results in an error similar to the following:

The type System.__ComObject in Assembly mscorlib...is not marked as
  serializable.

In addition, if you wish to store Session references to regular .NET classes, then they must be serializable.

Our demonstrations up to this point have concentrated on where session information is stored rather than how the link is maintained between pages. In this example, we concern ourselves with how ASP.NET identifies incoming clients. Recall that by default, ASP.NET uses a cookie—a small amount of information that is embedded into the client's browser and used on subsequent requests. You can disable ASP.NET's use of cookies by modifying the projects web.config, in order to enable its cookieless option:

Listing 18. ASP.NET's cookieless feature

<sessionState
   mode="InProc"
   cookieless="true"
   ... rest of config
/>

Modify SessionDemo's (from Listing 13) web.config file according to Listing 18, run the application by pressing F5, and it will function as it did in the previous example—the application will report the time the session started. Take a close look at the URL, however, and you will notice something strikingly different:

https://localhost/SessionD/(cadssl45tpxh4sbdhauu30ri)/WebForm1.aspx

As you can see, ASP.NET embeds the SessionID (the ticket) into the URL itself, a process sometimes referred to as cookie munging. You may wonder what occurs if users bookmark this cryptic URL so that they can return to it at a later time. Remember that if the user is idle, session information will persist for a period of time equal to the timeout attribute. If the user returns to the page after this prescribed amount of time, the SessionID in URL will be invalid, at which point ASP.NET will create a new session for the user.

In addition to disabling cookies in ASP.NET, you can also embed your own cookie information into the client's browser by using the Framework's HttpCookie class. In our analogy, this would be equivalent to writing information on the customer's ticket, which we would then scrutinize upon the next visit. For more on cookies in ASP.NET, see the Cookie article.

Summary

As you have probably determined, both JSP and ASP.NET have very similar mechanisms for setting and getting variables from a user's session with a Web application. Both of them use a Session object that can be directly accessed from scripts (JSP or ASPX files) and from servlets/codebehind (Java or .NET classes). In both cases, session information is stored on a per-user basis.

The main advantage that ASP.NET has over JSP is that it offers advanced session control features for persisting critical session information across server reboots. By default, session information in ASP.NET is store inside its runtime process. Options in the <sessionState> configuration element, however, allow developers to store Session in more durable locations: a Windows Service or SQL Server database. Session information stored in either of these two locations persists even if the Web server crashes and is applicable in Web farm scenarios where numerous machines must share Session.

Session Management

Contents

Introduction

Session Management in JSP

Attributes

CodeNotes Example

ProcessLogin

Using the session

Conversion with JLCA

Original JSP

ASP.NET Conversion

Persisting the Session with ASP.NET

Accessing Session from ASP.NET

Where Session Information Is Stored

Storing Session in Different Locations

Storing session data in-process

Storing session inside the Windows Service

The stateConnectionString attribute

Storing session in SQL Server

References to COM Objects

Summary

Additional resources

Session Management

Contents

Introduction

Session Management in JSP

Attributes

CodeNotes Example

Login form

ProcessLogin

Using the session

Conversion with JLCA

Original JSP

ASP.NET Conversion

Persisting the Session with ASP.NET

Accessing Session from ASP.NET

Where Session Information Is Stored

Storing Session in Different Locations

Storing session data in-process

Storing session inside the Windows Service

The stateConnectionString attribute

Storing session in SQL Server

References to COM Objects

Cookie Configuration in ASP.NET

Summary

Additional resources