ASP. NET 3.5 core programming learning notes (32): httpapplicationstate

ASP. NET provides four levels of state management tools: applications, sessions, pages, and requests. Each layer has dedicated container objects.

Application Status

The following table summarizes the main functions of each State object:

Although the names of the httpapplicationstate and httpsessionstate objects are different from those of the ASP internal object application and session, their functions are completely consistent in terms of status.

The httpapplicationstate object provides a dictionary-based storage object for all request handlers in the application. All HTTP processing programs and modules can store and retrieve values in the application dictionary. The application status is only visible in the context of the current application. Other applications in the same system cannot access or change the value.

When the client asks the salt concentration for resources in a virtual directory for the first time, the instance of the httpapplicationstate class will be created. Each running application holds its own full State object. The most common way to access the application state is through the Application attribute of the page object. Application status cannot be shared in Web farm and web garden.

Attributes of the httpapplicationstate class

The httpapplicationstate class is closed and inherits from the nameobjectcollectionbase class. For ease of use, the httpapplicationstate class is designed as a set of key/value pairs. The middle key is string type and the value is object type. Internally, the base class uses hashtable, the initial capacity is 0, and is automatically increased as needed.

The following table lists the attributes of the httpapplicationstate class:

Note that the static object and the actual status value are stored in different sets. The type of the static set is httpstaticobjectscollection.

Methods of the httpapplicationstate class

The methods of the httpapplicationstate class are mostly specialized versions of common key/value sets. As shown in the following table, its significant extension involves a locking mechanism designed to cope with continuous access to status values:

Note that the getenumerator method inherits from a collection class, but this class does not implement the locking mechanism. If you use this method to enumerate the set, the returned value is obtained by calling the get method of nameobjectcollectionbase. Therefore, this enumeration process is not thread-safe. The better way to enumerate the set content is to access each item through the while statement and get method. In addition, we can manually lock the set before performing enumeration.

Status Synchronization

All operations on httpapplicationstate require some synchronization measures to ensure that multiple threads running in the same application can safely access the values in the set without causing deadlocks and access conflicts. The Set accessors of the write methods (such as set and remove) and item attributes implicitly apply the write lock before performing the operation. The lock method ensures that only the current thread can change the application status.

We do not need to use the lock/unlock method to wrap a single set, clear, or remove. These methods are thread-safe. However, if you want to block Multiple commands that cannot be written concurrently, you must use the lock method explicitly.

// Lock
Application. Lock ();
Int val = (INT) application ["myvalue"];
If (Val <10)
Application ["myvalue"] = Val + 1;
Application. Unlock ();

We should use lock and unlock in pairs. However, if unlock is omitted, the possibility of deadlock is not high. Because. NET Framework automatically removes the lock when the request ends, times out, or an unhandled exception occurs. Therefore, to handle this exception, consider using finally blocks to clear the lock.

Balance of Application Status

If you do not use the httpapplicationstate object, you can add public members to the Global. asax file. Compared with data items in the httpapplicationstate set, global members have some advantages, because global members are strongly-typed and do not need hashtable to locate a value. On the other hand, the global variables themselves do not have the synchronization function and must be manually protected. We have to use lock to protect access to these members.

Memory usage

When storing global data, you should pay attention to some basic items no matter how you choose to store the global state of the application.

Global data storage will cause persistent memory usage. If you do not explicitly remove it using code, the data stored in the global state of the application will be removed only after the application is closed. Therefore, it is necessary to use a cache object to share data globally. Data stored in ASP. Net cache is automatically cleared to ensure that the data is automatically cleared when the usage of the virtual memory is high.

Concurrent Data Access

Due to the locking mechanism, there are still many problems to be solved to store global data. Locking the application status can easily become a performance bottleneck. The global state of the application is stored in the memory, without exceeding the boundaries of the computer. In a multi-computer and multi-processor environment, the global state of an application is limited to the worker processes running on a computer or a CPU. Therefore, it is not a real "Global ". In addition, because the process is terminated (in simple terms, ASP. NET processes are recycled), the data in the memory is also affected. If you want to use the application status function in the Web farm or web garden environment, you 'd better store the Global Status in the database table, at least global data should be encapsulated in a "smart" proxy object. This object is used to check the existence of data. If data is lost for some reason, the object must be refilled. As follows:

Public object getglobaldata (string entry)
{
Object o = application [entry];
// Check whether the data exists
If (O = NULL)
{
// Obtain data again
......
// Return data
Return application [entry];
}
Return O;
}