Sometimes, when developing Web applications with ASP.NET, you encounter a problem like this. You have a small amount of data that rarely changes; you need that data again and again throughout the life of the application; and further, such data is shared among users accessing your application.

For example, you might have an online sales application that serves a limited region. Your application is aware of 50 different zip codes. For each zip code, you might associate the phone number of the sales office serving that zip code. This data might be used in various places in your application, including as a datasource for some Web server controls.

You could easily store this data in a database, such as Oracle or SQLServer. But you probably don't want to retrieve the data from the database every time you use it, even if you allow for caching on the server. I've found a better approach for such situations.

Initially, I store the data in a database. When the application starts up, I load the data into a single instance of a container, and then use that container whenever I need to access the data. This requires that you mind your Ps, your Qs, and your SIs (that is, static initializers). It also requires that you have a good understanding of how applications are started and stopped on the Microsoft IIS server, which runs the ASP.NET framework. In the rest of this article, I dive into these different topics to help you make sure your static data is well cared for.

Application Lifecycle

One big difference between an Internet application and a traditional client-side application is that, with an Internet app, each user doesn't get his own copy of the program running on the Web server. In addition, users have little control over the starting and stopping of the application. For you, as a developer of such applications, this can be a major pain in your exit ramp if you're trying to use code that relies on the application start-up, unless you know what you're doing. That's why a good understanding of the ASP.NET application lifecycle is necessary.

Note: The Web server does not run a separate copy of your application for each user accessing your web site. Bear this in mind as you read through the rest of this article, because you don't want to code global static variables as if each user has a separate copy of them. For per-user data, use session variables instead. For information on session variables, search the MSDN online help for HttpSessionState.

When you install your application on a Web server, it waits for somebody to access it. For example, suppose you're the Great Owner of the Microsoft.com Web site, and you install an application called superapp, which people access through the URL http://www.microsoft.com/superapp/default.aspx.

You went through the motions of configuring the application on the IIS server. But now it just sits there, waiting for the first user to come. When that finally happens, the IIS server goes through a bunch of rigmarole to initialize your application.

Now your application is running. And the user does his or her business (which is hopefully profiting you, or, in the very least, Bill Gates, since he needs the money). Then the user goes on her merry way. But what about the application? It's still running. Two minutes later, another user comes along to the same URL. Your application is still running, ready to serve up the Web pages.

When does it end? If the application goes idle for a certain period of time, the ASP.NET runtime will end your application for you. But if people are still connecting to the Web site, the application will still be running. Only after all is quiet will the thing finally shut down (assuming it doesn't crash, of course).

The whole process is somewhat complex (see the online help for the HttpApplication class for a list of the steps that take place; also check out Microsoft Knowledgebase article number 312607 for the whole details). But the important thing to worry about here is that when your application starts up, the ASP.NET framework creates an instance of HttpApplication for you. Or — and I'll give the details to this shortly — you can create your own class derived from HttpApplication, where you can store your global data (such as the zip code idea I mentioned earlier) inside the Global.asax file.

However, what I just said isn't the full story. You don't get just one HttpApplication. That's where it gets bizarre. The ASP.NET system actually creates multiple instances of HttpApplication (or of your derived class in Global.asax) in order to handle multiple requests. The whole idea is so that IIS and the ASP.NET system can handle high-performance Web sites that get heavy traffic.

Even though there are multiple HttpApplication instances, there's still no guarantee which of these are shared among which users. Each user accessing the site does not necessarily get his own instance of HttpApplication. In general, you don't want to make any assumptions about the individual instances of HttpApplication. And remember, even though there may be multiple HttpApplication instances, only one instance of the application itself is running on the server.