ASP Sessions and Applications

The most powerful aspect of server-side scripting languages such as ASP is their almost magical ability to turn the Web – a medium originally crafted to serve one static document after another - into a platform that delivers rich, interactive experiences. These experiences come in the form of online applications that respond differently to different users in different situations.

To make this transformation possible, ASP must not only be able to produce dynamically-generated Web pages in response to requests. It must also have the ability to track information that’s specific to the users of a set of related ASP scripts (e.g. an online discussion forum), and permit those scripts to share information with each other.

In this, the fourth article in SitePoint's series on ASP, I’ll be describing the features of ASP that make the above possible: Applications and Sessions. To start, I'll take you through the steps required to create a Web Application in Microsoft Internet Information Server (IIS), and I’ll explain how applications and sessions fill the need for persistent data. I'll then introduce you to the Application and Session objects in ASP that are the center of the magic, and also explain the role of the global.asa file. Finally, I'll take you through the code of a complete example that deals with tracking the number of users on your site at any given time.

This article assumes that you’re familiar with the concepts covered in the previous articles in this series, beginning with Getting Started with ASP. If you haven't read them, and you’re approaching ASP for the first time, I would suggest at least skimming through those previous articles before you jump into this one.

Here we go!

Web Applications in IIS

A Web application is a lot like any other software application that you’d run on your computer, except that the interface is provided by a set of Web pages, and the code of the application runs mainly on the Web server from which you fetch those pages. Examples of common Web applications today include discussion forums, book stores, and custom news feeds.

From the point of view of an ASP developer, however, a Web application is just a collection of ASP files that work together to provide this kind of service. This group of ASP files is generally stored in a single directory, and possibly a number of subdirectories. The first step in taking advantage of the features that ASP provides to support the development of Web applications is to identify that 'application root directory' to IIS.

I'll assume for the moment that you have administrator-level access to the IIS server that you're using for ASP development. In this case, your first task is to define a Web application on your server. Create a directory anywhere on the server (I chose c:\MyApplication) that you'll use for the examples in this article. Open Control Panel, Administrative Tools, and Internet Information Services, then navigate to the Default Web Site. Right-click on it and select New, Virtual Directory. When prompted by the wizard, type an alias for the directory as it will appear in the URL (e.g. a virtual directory with the alias myapp will be accessible as http://localhost/myapp/ from your computer and as http://your.host.name/myapp/ from other computers on your network), and then browse to the directory you just created. For the access permissions, leave the default options (Read and Run Scripts) selected. When you've completed the wizard, the new virtual directory should appear in the tree view as shown here:

You've now defined a Web application on your server. All the ASP files contained in that directory (or its subdirectories) will be considered a part of the myapp application (or whatever you chose to call it). Before we explore further the features of ASP that take advantage of this, let's stop and examine what we need a Web application for.

The Need for Persistent Data

As we've seen in previous articles in this series, you can store values in ASP variables and display them as part of a dynamic Web page. One limitation of variables, however, is that they only exist for as long as the particular ASP script that created them runs. Once an ASP script has ended, and the last of the Web page has been sent to the requesting browser, all the variables that were created during the course of the script's execution are destroyed to free up memory, to enable later page requests to be processed.

There are many situations where it would be handy to have a variable that stayed in memory at the end of one ASP script so that the value stored within it could be picked up and used again by another script later on. In the last article, we saw how we could pass information from one page to another, either through a form submission or with a URL query string; however, these methods are not always adequate.

For instance, take the example we looked at in that article. Here we prompted the user for his or her name with an HTML form that appeared on the first page requested when they entered the site. We then passed that name on to each additional page with a query string that contained the name the user entered. Imagine the implications of putting this example to practical use on a site the size of SitePoint.com. Every single link in every single page would have to be individually coded to pass the username variable on to the next page. Plain HTML pages could not be used even when it wasn't necessary to display any dynamic data on a given page, because an HTML page would not be able to pass on the username to subsequent pages.

As you can see, when your goal is to create a variable that you can use throughout your site, passing it from one page to the next is rarely a practical solution. Fortunately, ASP Web Applications were designed with just this sort of thing in mind. You'll also recall from our last article that ASP has a number of built-in objects - Request and Response being prime examples of these. Two other objects that all ASP scripts have access to are Application and Session, and it is these special objects that let us store data that will be accessible by all ASP scripts in the current Web application.