In the context of Active Server Pages, an application is the sum of all the files that can be accessed through a given virtual directory and its subdirectories. This ASP application context is the same for all clients using the application. For example, a client from Thailand who requests pages from your /SearchApp virtual directory is accessing the same "application" as a second client from Sweden who is requesting pages from the same virtual directory—regardless of which specific web page within the virtual directory each is requesting.
Just as traditional standalone applications allow you to share information throughout the application, so too do ASP applications. You can share information among all clients of a given ASP application using the Application object. This built-in object represents the ASP application itself and is the same regardless of the number or type of clients accessing the application and regardless of what part or parts of the application those clients are requesting.
The Application object is initialized by IIS the moment the first client requests any file from within the given virtual directory. It remains in the server's memory until either the web service is stopped or the application is explicitly unloaded from the web server using the Microsoft Management Console.
IIS allows you to instantiate variables and objects with application-level scope. This means that a given variable contains the same value for all clients of your application. You also can instantiate server-side objects with application-level scope that likewise contain the same values for all clients. These application-level variables and objects can be accessed and changed from the context of any user's session and from any file within the current application.
As stated earlier, the Application object's initialization occurs when the first user of your application requests any file from within the virtual directory that the ASP application encompasses. This initialization can be thought of as setting aside memory for the given ASP application. The web server instantiates and initializes the Application object for you. However, you can customize this initialization by including code in a special optional file called GLOBAL.ASA . Although I will discuss this file in greater depth in Chapter 11, it is worth presenting a brief overview here.
The GLOBAL.ASA file exists—if it exists—at the root of the physical directory mapped to by your ASP application's virtual directory. It is processed every time a new user requests a page from within the application's virtual directory. This file contains initialization code for both the user's session and the application itself. If the user is not the first user, the application-specific sections of GLOBAL.ASA are not processed. If the GLOBAL.ASA file does not exist or does not contain any code, but the user's request is the web server's first request for files within a given application, the web server still initializes the Application object. However, the web server's initialization involves only the dimensioning of memory required for the application.
The GLOBAL.ASA file provides a place for you to create variables and objects that have application-level scope. This section of the GLOBAL.ASA file represents an event procedure. The event is the OnStart event, and its event handler is executed when the application is started. It's important to note that although the GLOBAL.ASA file is processed for every user that makes a request, the Application object's OnStart event is executed for only the first user. (The OnStart and the corresponding OnEnd event procedures are covered in detail later in this chapter.)
Variables and objects with application-level scope have the same value for all users at all times during the life of the application. If one user requests a page containing code that changes an application-level variable's value, then that variable's value is changed for all users. This presents a problem: potentially, two or more users could attempt to change the value of the same application-level variable at the same time. Fortunately, ASP provides the Application object's Lock and Unlock methods to avoid conflicts in these situations. Just as you must carefully consider the ramifications of using global variables in a multithreaded application, you also must consider the ramifications of using variables with application-level scope. Use application-level variables with care.
The properties, collections, methods, and events of the ASP Application object are outlined in Application Object Summary.
Get ASP in a Nutshell, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
