ASP in a Nutshell, 2nd Edition

Comments/Troubleshooting

Application-level variables are, in effect, global variables for your ASP application. The use of globals in ASP applications should be viewed with as much skepticism as the use of globals in traditional standalone applications, if not with more. The most important step is to painstakingly consider its scope before implementing any object or variable with application-level scope. There are very few instances in which using these ASP global variables is necessary.

With that warning, there are a few instances in which using application-level variables or objects is useful in creating functional ASP applications. One of the most important of these is maintaining application-specific statistics for your web site. Using application-level variables that are incremented at the beginning of each user session, for example, you could maintain a count of clients that have used your application. Although such web management tools as Microsoft Site Server perform similar tasks, their statistics are file-specific, not application-specific.

Some ASP literature has suggested using application-level objects for maintaining open ActiveX Data Objects (ADO) database connections for all application users. (For more information on ADO, see Chapter 12.) This is not a good use of application-level variables, since this approach prevents ODBC from pooling connections per individual pages.^[1] However, you could use an application-level variable to maintain an application-specific connection string for that same database connection.

There is one trap that you should be aware of when considering the use of application-level variables and objects. Consider the following scenario. You have two physical directories: c:\inetpub\wwwroot\MainApp and c:\inetpub\wwwroot\MainApp\SearchApp. These directories are mapped to the virtual directories /MainApp and /SearchApp, respectively. You have, in effect, an application within an application. The first client requests a page within the c:\inetpub\wwwroot\MainApp\SearchApp physical directory. Which initialization code will be used to initialize the Application object—the code in the GLOBAL.ASA for /MainApp or the GLOBAL.ASA for /SearchApp ? In this case the /SearchApp GLOBAL.ASA is the one processed. Until a file in /MainApp that does not exist in /SearchApp is requested, the GLOBAL.ASA file for /MainApp is not processed. If the two GLOBAL.ASA files define different sets of application-level variables, you have no way of knowing within your code which Application variables were properly initialized without testing them.

Finally, note that IIS now allows you to set ASP applications up in separate memory spaces from each other and from the web server itself by simply checking an option on the Properties panel of a given virtual directory in IIS's Microsoft Management Console. This ability is an important improvement in IIS. If your ASP application is running in a separate memory space from the web server and a server object in it (or the scripting engine itself) crashes, it will not also crash the web server or your other ASP applications.

---

^[1] ODBC connection pooling provides a method by which ODBC connections can be reused by successive users. Instead of creating a new connection each time a client requests one, the server attempts to reuse an already existing connection that is no longer in use. If unused ODBC connections reside in memory after a certain period of time (configured in the MMC), they are destroyed to free memory.