The Application s State

In spite of their quite unfamiliar names , the HttpApplicationState and HttpSessionState objects are state facilities totally compatible with classic Active Server Pages (ASP) intrinsic objects such as Application and Session . Ad hoc properties known as Application and Session let you use these objects in much the same way you did in ASP.

The HttpApplicationState object makes a dictionary available for storage to all request handlers invoked within an application. In classic ASP, only pages have access to the application state; this is no longer true in ASP.NET, in which all HTTP handlers and modules can store and retrieve values within the application's dictionary. The application state is accessible only within the context of the originating application. Other applications running on the system cannot access or modify the values.

An instance of the HttpApplicationState class is created the first time a client requests any resource from within a particular virtual directory. Each running application holds its own global state object. The most common way to access application state is by means of the Application property of the Page object. Application state is not shared across either a Web farm or Web garden.

Properties of the HttpApplicationState Class

The HttpApplicationState class is sealed and inherits from a class named NameObjectCollectionBase . In practice, the HttpApplicationState class is a collection of pairs, each made of a string key and an object value. Such pairs can be accessed either using the key string or the index. Internally, the base class employs a hashtable with an initial capacity of zero that is automatically increased as required. Table 13-2 lists the properties of the HttpApplicationState class.

Notice that static objects and actual state values are stored in separate collections. The exact type of the static collection is HttpStaticObjectsCollection .

Methods of the HttpApplicationState Class

The set of methods that the HttpApplicationState class features are mostly specialized versions of the typical methods of a name/value collection. As Table 13-3 shows, the most significant extension entails the locking mechanism necessary to serialize access to the state values.

Note that the GetEnumerator method is inherited from the base collection class and, as such, is oblivious to the locking mechanism of the class. If you enumerate the collection using this method, each returned value is obtained through a simple call to one of the get methods on the base NameObjectCollectionBase class. Unfortunately, that method is not aware of the locking mechanism needed on the derived HttpApplicationState class because of the concurrent access to the application state. As a result, your enumeration would not be thread-safe. A better way to enumerate the content of the collection is by using a while statement and the Get method to access an item. Alternatively, you could lock the collection before you enumerate.

State Synchronization

Notice that all operations on HttpApplicationState require some sort of synchronization to ensure that multiple threads running within an application safely access values without incurring deadlocks and access violations. The writing methods, such as Set and Remove , as well as the set accessor of the Item property implicitly apply a writing lock before proceeding. The Lock method ensures that only the current thread can modify the application state. The Lock method is provided to apply the same writing lock around portions of code that need to be protected from other threads' access.

You don't need to wrap a single call to Set , Clear , or Remove with a lock/unlock pair of statements—those methods, in fact, are already thread-safe. Using Lock in these cases will only have the effect of producing additional overhead, increasing the internal level of recursion:

// This operation is thread-safe Application["MyValue"] = 1;

Use Lock instead if you want to shield a group of instructions from concurrent writings:

// These operations execute atomically Application.Lock(); int val = (int) Application["MyValue"]; if (val < 10) Application["MyValue"] = val + 1; Application.UnLock();

Reading methods such as Get , the get accessor of Item , and even Count have an internal synchronization mechanism that, when used along with Lock , will protect them against concurrent and cross-thread readings and writings:

// The reading is protected from concurrent read/

writes

Application.Lock(); int val = (int) Application["MyValue"]; Application.UnLock();

You should always use Lock and UnLock together. However, if you omit the call to UnLock , the likelihood of incurring a deadlock is not high because the Microsoft .NET Framework automatically removes the lock when the request completes or times out, or when an unhandled error occurs. For this reason, if you handle the exception, consider using a finally block to clear the lock or expect to face some delay while ASP.NET clears the lock for you when the request ends.

Tradeoffs of Application State

Instead of writing global data to the HttpApplicationState object, you could use public members within the global.asax file. Compared to entries in the HttpApplicationState collection, a global member is preferable because it is strongly typed and does not require a hashtable access to locate the value. On the other hand, a global variable is not synchronized per se and must be manually protected. You have to use language constructs to protect access to these members—for example, the C# lock operator or, in Microsoft Visual Basic .NET, the SyncLock operator. We demonstrated global members in Chapter 12.

Memory Occupation

Whatever form you choose to store the global state of an application, some general considerations apply about the opportunity of storing data globally. For one thing, global data storage results in permanent memory occupation. Unless explicitly removed by the code, any data stored in the application global state is removed only when the application shuts down. On one hand, putting a few megabytes of data in the application's memory speeds up access; on the other hand, doing this occupies valuable memory for the entire duration of the application.

For this reason, it is extremely important that you consider using the Cache object (which is discussed further in the next chapter) whenever you need globally shared data. Unlike Application and global members, data stored in the ASP.NET Cache is subject to an automatic scavenging mechanism that ensures that data is removed when a too-high percentage of virtual memory is being consumed. In addition, the Cache object has a lot of other features that we'll explore in the next chapter. The bottom line is that the Cache object was introduced just to mitigate the problem of memory occupation and to replace the Application object.

// Retrieve data public object GetGlobalData(string entry) { object o = Application[entry]; if (o == null) { // TODO:: Reload the data from its source return Application[entry]; } return o; }