In spite of its quite unfamiliar name, the HttpApplicationState object is an ASP.NET state facility totally compatible with a popular ASP intrinsic object like Application. An ad hoc property just named "Application" lets you use this object in much the way you did with Application in ASP. An instance of the HttpApplicationState class is created the first time a client requests any resource from within a particular virtual folder. Each running application holds its own global state object. Application state is not shared across a web farm or a web garden.
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 object contains a few collections of values and allows you to add and remove items. 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 class also provides the Lock method to apply the same writing lock around portions of code that need to be protected. You don’t need to wrap a call to Set, Clear, or Remove with a lock/unlock pair of statements—those methods, in fact, are already threadsafe. Using Lock in these cases will only have the effect of producing a little overhead—use it instead if you need to read data and want to protect against concurrent writings. Reading methods such as Get, the get accessor of Item, and even Count, have an internal synchronization mechanism that, used along with Lock, will protect them against concurrent and cross-thread readings.
Application.Lock(); Application["MyValue"] = (int) Application["MyValue "] + 1; Application.UnLock();
You should always use Lock and UnLock together. However, if you fail to call UnLock, the likelihood of really causing a deadlock is not high because the .NET Framework automatically removes the lock when the request completes, times out, or when an unhandled error occurs.
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.
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. Holding data in memory speeds access up, but too much memory occupied may result in an unacceptable overhead for the web server.
Storing data globally is also problematic because of locking. Synchronization is necessary to ensure that concurrent thread access doesn't cause inconsistencies in the data. But locking the application state can easily become a performance hit leading to nonoptimal use of threads. The application global state is held in memory and never trespasses the machine's boundaries. Finally, the duration of the data in memory is at risk due to possible failures in the process or, more simply, because of the ASP.NET process recycling. If you're going to use the application state feature and plan to deploy the application in a web farm or web garden scenario, then you're probably better off dropping global state in favor of database tables.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Magazine and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
