"State programming framework" solution based on SessionState in ASP. NET Applications

 

In an ASP. NET-based Web application, SessionState is usually used to save the status information based on a client. However, this method of programming simply using SessionState has many limitations, such as Session Item, for example, there is no valid one. To effectively manage the client status and improve application development efficiency, our development framework system has a corresponding State programming framework many years ago. Recently, I began to upgrade and redesign it to share the implementation principles and outline design with you. I hope to inspire you. At the same time, I hope you will receive some good suggestions and comments to enrich our framework. At the same time, I wrote a simple simulation program to implement this design idea. If you are interested, you can download the simulation program here.

Directory
I. Limitations of SessionState-based programming
Ii. Use the status backup storage mechanism to solve the Web Server Memory pressure
Iii. Recovery of backup storage status items"
Iv. Definitions of status item backup policies
5. Use the code generation mechanism to help you operate the status in a strong type.

SessionState is not familiar to ASP. NET developers. We can use it to store client-based status information. From the programming point of view, we can set and obtain Session items through the method. However, this programming method based solely on dictionary indexing has many limitations:

• . The value of SessionState is a System. for Object type objects, we need to use the obtained data. The Session Item Key is a manually specified string. If the Key value is not effectively allocated, when setting a Session Item, it can easily cause confusion throughout the entire state. When obtaining a Session Item, the Key value you specified may not match the pre-specified one.
• . By default (InProc Session mode), SessionState is stored in the server memory. If too many or too large Session items are resident in the memory, the server will inevitably experience memory pressure. In fact, all Session items based on the client are not required during the entire Session period. Many Session items are only used in a few Web pages. However, we cannot manually delete the Session Item from the SessionState through the program, because we cannot determine that the Session Item is no longer needed at that moment, because it is often dependent on the UI interaction behavior. If too many low-frequency Session Items exist, and they are not small, the server memory is occupied too much, causing performance degradation.
• . Such performance losses include: the serialization, deserialization, and serialization of Session items are transmitted over the network of the Web Server and State Server or SQL Server, and data access (save and extract) to the State Server or SQL Server).

In fact, our State framework is based on SessionState, but it can solve the three problems mentioned above:

• You can provide a structured definition for all the used status items (such as status attribute names and data types) through configuration, and make it possible to use this structured configuration. This is similar to the configuration and strong type programming methods in ASP. NET;
• The status (Backing Storing) mechanism is provided to move large objects that are not frequently used from the SessionState to the corresponding backup storage (such as files and databases), so as to relieve the server memory pressure;
• Provides methods to achieve optimal configuration based on the specific runtime environment. The backup policy mainly includes two aspects: one is what status items need to be backed up for storage, and the other is how to back up storage. Factors that determine the status items of the backup storage include the time-out period since the last access (the possibility of the Status item being used again is determined by the usage frequency ); minimum number of bytes required for objects to be stored in the backup mode (it is meaningless to store small objects in the backup mode ); and the scope of the Status item (the scope of many status items is limited to a relevant Web page, or based on a certain base address. The specific backup storage method is determined by the configured "backup storage". For example, in my example, the file-based storage method is used, you can write database-based backup storage.

The state backup mechanism is the core of the entire State programming framework. Scan all status items ,. Then, they are stored in the corresponding physical storage media with the help of the specified. Finally, the corresponding status will ease the memory pressure on the Web Server. In addition to backing up the serialized State object, the back-up storage is also responsible for extracting State data from the corresponding storage media.

In this way, each request will automatically trigger the backup storage based on this session. The event we registered is HttpApplication. For the sake of performance, when the event PostRequestHandlerExecute is triggered, it is not always the check of the backup status item. Instead, you can set one. Only when the interval is exceeded will the real region check status be back-up for storage. The backup storage of the Status item is followed by the check of the backup object.

We use a specific example to further describe the backup storage process. As shown in the figure on the left (click to see the big picture), three state items are maintained in the SessionState of the IIS Process of Web Server: Foo, Bar, and Baz. After the Web Server receives and executes an HTTP request from the browser, it finds that the status item Baz value in this case, the same as its Key for serialization and backup storage. Finally, remove the Baz from SessionState.

If the Web application is deployed in the Web Farm mode and adopts the or session mode, when synchronizing data to Sate Server or SQL Server, the large object Baz is missing in SessionState, the performance will also be improved as serialization, network transmission, and data access are missing.

, They are still. In this case, the corresponding status values are extracted from the storage media in the form of byte arrays through the backup storage we specify, and then deserialized and placed into the SessionState again, I personally turn this mechanism into "".

Before further explaining the mechanism, we need to understand the premise that the framework is always maintained, including the status items, (SessionState or BackingStore), and related information. This list is placed in SessionState.

The sequence diagram shown on the right (click to see the big picture) shows the processing process of the state backup mechanism when our program obtains a certain state item: when receiving a request from a status item, obtain the current runtime information of the Status item based on the Key value. If the runtime information shows that it still exists in SessionState (Location = Session), it is returned directly from SessionState and its runtime information is updated (last accessed time ).

If the status item has been stored in the back storage (Location = BackingStore), the corresponding backup storage is used to extract the corresponding values from the storage medium in the form of byte arrays. After the deserialization is completed, save it to SessionState again and update the runtime information (last access time and current location: BackingStore-> Session ). Finally, return the specific status object after deserialization.

Determining whether a status item in SessionState should be stored in backup depends on the following three aspects. Status items that meet both conditions 1 and 2, or 2 and 3 will be stored in backup storage.

• The interval from the last access event to the current time for this status item exceeds the set timeout time limit;
• The total number of bytes of the Status item exceeds the minimum limit for backup storage;
• Whether the URL of the current request exceeds the range of the specified status.

However, our State reserve policy applies to a large granularity :. The structure of the Status group and the backup policies applied to it are defined through configuration. The following XML shows the general structure of the configuration.

    ?

In the preceding XML snippet, we define two (UserName and Position) and two (Profile and Product ). The two status groups contain their respective status items and corresponding backup policies. And and respectively indicate the time-out period, the lowest value after serialization, And the range used.

Since all statuses and data types (which can be pre-defined by the system or custom types) can be expressed in XML format, then we can reflect them in the form of code through the code generation mechanism. You can use CodeDOM + Cutom Tool [refer to my article "from data to code" (previous and next)], or directly use the T4 template. [Refer to my article "Creating a code generator is simple: how to generate code through the T4 template?" (Part 1 and part 2)]. For example, you can generate a type that inherits from the Page, such as PageBase, and add attributes such as the next State. (The following code only has the general structure of the code and omitted the specific implementation)

   PageBase : Page

 {

      ExtendedRootStateNode State { get; }

 }

   ExtendedRootStateNode : RootStateNode

 {

       UserName { get; set; }

       Position { get; set; }

      ProfileGroupStateNode Profile { get;  set; }

      ProductGroupStateNode Product { get;  set; }       

 }

   ProfileGroupStateNode : GroupStateNode

 {

       Age { get; set; }

      Gender Gender { get; set; }

       Address { get; set; }

 }

   ProductGroupStateNode : GroupStateNode

 {

       ProductId { get; set; }

       ProductName { get; set; }

 }

If you want all your Web pages to inherit from this PageBase, you can obtain or set each status item in the following way.

Source: http://www.cnblogs.com/artech/archive/2010/10/31/State_Management.html