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:
<% Response.Write "Your SessionID is " & Session.SessionID %>
Figure 11.5 shows the output of the preceding line of code.
The SessionID is guaranteed to be unique for each separate session as long as the Web
server is running. However, if the Web server is restarted, new SessionIDs might be duplicates
of older SessionIDs. For this reason, it is unwise to use the SessionID as a unique
identifier in a database. Week 3 will discuss databases in detail.
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
Imagine that you have an ASP page that contains the following simple line of code:
<% Response.Write "Your name is " & Session("Name") %>
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.
IIS 5.0 is scheduled to have the default session timeout to 10 minutes. However, with
Windows 2000 Release Candidate 2, the default session timeout is still at 20 minutes.
With IIS 4.0, the default session timeout is, and has always been, 20 minutes.
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:
'The Session object is set to timeout in five minutes!
Session.Timeout = 5
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 %>
4: 'Destroy the user's session
10: You have been logged out. Your Session variables have
11: been destroyed!
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.