Top ASP 101 Stories Getting Scripts to Run on a Schedule The Top 10 ASP Links @ Microsoft.com What is Adovbs.inc and Why Do I Need It? QUICK TIP: ASP Code-Based Security Show All Tips >>  ASP 101 Updates

The Session Object
The Session object is an intrinsic ASP object designed to maintain state on a user-by-user basis. Each user is assigned his own Session object. Because each user has his own Session object, each user's unique data can be saved. Figure 11.4 graphically shows that each user is assigned his own Session.

It is helpful to think of the Session object as a warehouse. When each new user arrives at the site, she receives her own warehouse. Throughout the site, any ASP page can deposit or retrieve information into a user's warehouse. Such a collection of user-specific information can prove useful.

For example, many of today's eCommerce sites have a shopping cart system, where, as you browse through the site, if you see an item you want to purchase, you can simply click it to add it to your shopping cart. When you are ready to "check out," you visit a page that summarizes your purchases, presents a total charge, and asks for your billing and shipping information. The shopping cart is your personal warehouse, holding the information on your specific items.

When a visitor reaches your site, his "personal warehouse" is, technically, a new instance of the Session object. This object is created specifically for this particular user, serving as a vault of user-specific information. A user's Session object instance is often referred to simply as the user's Session.

Because each user is assigned his own Session, each instance needs to be uniquely identifiable. A numeric ID, referred to as the SessionID, is used to identify that a particular Session belongs to a particular user. To list the SessionID for a user's Session, you can use the following syntax:

The SessionID is a numeric value, uniquely identifying each Session from other another. The following line of code would display, to each visitor, his or her unique SessionID:

Figure 11.5 shows the output of the preceding line of code.

The SessionID is stored in two locations: the Web server and the client. Each Session that is managed by the Web server contains its own SessionID. This SessionID is also stored on the client's computer, in the form of a cookie. Because the SessionID is saved on both the client and the Web server, the Web server can establish what Sessions belong to what clients.

Imagine that you have an ASP page that contains the following simple line of code:

The preceding line would display Your name is, followed by the value in the session variable Name. What, exactly, happens when a user visits this page? Because each visitor can have a different value for the session variable Name, how is the correct value selected? Recall from yesterday's lesson that each time a Web page is requested from the Web server, a number of HTTP headers are sent. One of the HTTP headers is the Cookie header, which contains all the cookies on the client's computer that were created by the Web site. If session variables are being used on your Web site, one of these cookies contains the SessionID associated with a particular Session on the Web server. This cookie is matched up with the correct Session, and the Name variable is displayed.

Using cookies to associate a particular client with a particular Session has its drawbacks. What happens if the user has set up his browser to not accept cookies? If this is the case, this user cannot have his own "personal warehouse," and state will not be persisted for this user. Although the majority of Web surfers today have cookies enabled, there is no guarantee that all your visitors accept cookies. There is, however, a way to use session variables with users who do not accept cookies. This workaround is discussed later today in the section "Session Variables Without Cookies."

Because each user's Session is created and stored in the Web server's memory, it is important to have this memory freed up when the visitor is no longer at your site. Due to the client-server model, you cannot determine when someone leaves your site. However, you can keep track of the last time a specific user accessed your site. If a specific user has not accessed your site for a particular amount of time, her Session is freed from the Web server's memory. The amount of time that passes before a user's Session is freed is referred to as the session timeout.

You can set the session timeout by using the Timeout property of the Session object. You can assign the Timeout property a numeric value, representing the number of minutes before a user's Session times out and destroys itself. For example, if you want to set the session timeout to 5 minutes, use the following line of code:

If you want to destroy the user's Session explicitly, before the session timeout occurs, use the Abandon method. Some personalized sites have a LogOut button available that, when clicked, removes any saved information, such as cookies and session variables. The LogOut button, when clicked, should display a LogOut message and call the Session object's Abandon method. Listing 11.6 shows the code for LogOut.asp, which simply displays a short message informing the user that she has been logged out and destroys the user's Session through a call to Session.Abandon.

Listing 11.6 - Using Session.Abandon to Destroy the User's Session Object

1:  <%@ Language=VBScript %>
2:  <% Option Explicit %>
3:  <%
4:      'Destroy the user's session
5:      Session.Abandon
6:  %>
7:
8:  <HTML>
9:  <BODY>
10:   You have been logged out.  Your Session variables have
11:   been destroyed!
12: </BODY>
13: </HTML>

Because each user has her own instance of a Session object, the memory requirements on your Web server increase as the number of concurrent users on your Web site increases. Therefore, it helps to free the memory associated with a user's Session as soon as possible. Listing 11.6 demonstrates how to remove a user's Session object by using the Abandon method of the Session object (line 5).

When each new user visits your site, he is given a "personal warehouse," into which your ASP pages can store and retrieve user-specific information. The Session object acts as the warehouse itself. Each warehouse contains its own unique, numeric ID, called the SessionID. After a warehouse has not been accessed for a set length of time, the warehouse is demolished, freeing up real estate for another warehouse. This length of time is the session timeout and can be accessed via the Timeout property of the Session object. Finally, use the Abandon method if you need to explicitly destroy a Session prematurely.

Now that you've examined the role of the Session object, it's time to discuss how to write and read the variables stored inside the Session object. These session variables are responsible for saving the user's information, thereby maintaining state across the Web application. The next section, "Using Session Variables," discusses the intricacies of session variables.