The Application s State

 

The Application's State

Table 13-1 summarizes the main features of the various state objects.

Table 13-1: State Management Objects at a Glance

Object

Lifetime

Data Visibility

Location

Cache

Implements an automatic scavenging mechanism, and periodically clears less frequently used contents

Global to all sessions

Does not support Web farm or Web garden scenarios

HttpApplicationState

Created when the first request hits the Web server, and released when the application shuts down

Same as for Cache

Same as for Cache

HttpContext

Spans the entire lifetime of the individual request

Global to the objects involved with the request

Same as for Cache

HttpSessionState

Created when the user makes the first request, and lasts until the user closes the session

Global to all requests issued by the user who started the session

Configurable to work on Web farms and gardens

ViewState

Represents the calling context of each page being generated

Limited to all requests queued for the same page

Configurable to work on Web farms and gardens

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.

Note 

In this chapter, we'll review several objects involved, at various levels, with the state management. We won't discuss cookies in detail, but cookies are definitely useful for storing small amounts of information on the client. The information is sent with the request to the server and can be manipulated and re-sent through the response. The cookie is a text-based structure with simple key/value pairs, and it consumes no resources on the server. In e-commerce applications, for example, cookies are the preferred way of storing user preferences. In addition, cookies have a configurable expiration policy. The downside of cookies is their limited size (browser-dependent, but seldom greater than 8 KB) and the fact that the user can disable them.

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.

Table 13-2: HttpApplicationState Properties

Property

Description

AllKeys

Gets an array of strings containing all the keys of the items currently stored in the object.

Contents

Gets the current instance of the object. But wait! What this property returns is simply a reference to the application state object, not a clone. Provided for ASP compatibility.

Count

Gets the number of objects currently stored in the collection.

Item

Indexer property, provides read/write access to an element in the collection. The element can be specified either by name or index. Accessors of this property are implemented using Get and Set methods.

StaticObjects

Gets a collection including all instances of all objects declared in global.asax using an <object> tag with the scope attribute set to Application.

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.

Table 13-3: HttpApplicationState Methods

Method

Description

Add

Adds a new value to the collection. The value is boxed as an object.

Clear

Removes all objects from the collection.

Get

Returns the value of an item in the collection. The item can be specified either by key or index.

GetEnumerator

Returns an enumerator object to iterate through the collection.

GetKey

Gets the string key of the item stored at the specified position.

Lock

Locks writing access to the whole collection. No concurrent caller can write to the collection object until UnLock is called.

Remove

Removes the item whose key matches the specified string.

RemoveAll

Calls Clear.

RemoveAt

Removes the item at the specified position.

Set

Assigns the specified value to the item with the specified key. The method is thread-safe, and the access to the item is blocked until the writing is completed.

UnLock

Unlocks writing access to the collection.

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.

Concurrent Access to Data

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 that leads to nonoptimal use of threads. The application global state is held in memory and never trespasses the machine's boundaries. In multimachine and multiprocessor environments, the application global state is limited to the single worker process running on the individual machine or CPU. As such, it is not something really global. Finally, the duration of the data in memory is at risk because of 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, you're probably better off dropping global state in favor of database tables. At the very least, you should wrap your global data in smart proxy objects that check for the existence of data and refill if it's not there, for whatever reason. Here's a quick snapshot:

// 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; } 

 


Programming Microsoft ASP. Net 2.0 Core Reference
Programming Microsoft ASP.NET 2.0 Core Reference
ISBN: 0735621764
EAN: 2147483647
Year: 2004
Pages: 112
Authors: Dino Esposito
BUY ON AMAZON

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net