So what is User state maintenance?
Author: Green Apple studios This article hits: 277
This article is compiled manuscripts, the original source: http://www.asptoday.com/articles/19990820.htm
If you are not careful, very similar situations will occur on the Web application. As a result, developers need to pay special attention to scalability and fault-tolerant issues and should be able to adapt to future development when designing applications. Maintaining user status is an integral part of application scalability and fault tolerance, and the decisions you make at the site design stage are critical to the future success of your site.
Some types of state are not maintained, and a Web application cannot exist. For example, an online shopping application must keep in mind the backlog of user orders, and when users are moving one page at a site, they must add items to their shopping baskets. HTTP, the connection between a client and a server running on all Web applications is a stateless protocol. Each page that the user requests is handled independently. So the Web application must have something, some place to remember the user's information.
From the moment the user arrives at a certain page, by the time he leaves the page, the Active Server page uses the Session object that allows the user to interact with the Web site (or automatically abandons the session after "lease time"). You just have to assign a value:
Session ("NumItems") = 3
Response.Write Session ("NumItems")
I believe that the session object is a fool in some ways because it allows all kinds of bloated programming--when developers want to create variables, and no data type restrictions. This makes it hard to find bugs, and even worse if there are a lot of people working on a project together. On the one hand is to assist and support bloated programming, on the other hand the session object also has a problem-scalability and fault tolerance.
Typically, the way to measure a Web application is to use a series of Robin DNS to maintain applications on multiple Web servers, or to use a load-balanced router to allocate requests from the client to one of the Web servers. However, once a user starts an ASP session with a Web server, all subsequent requests are returned to the Web server, which means that if the server is shut down, the user loses their session and the performance problem arises if the server is overloaded. There is a workaround: Do not use the Session object.
There are other ways to maintain user status. You can store them on the client with an implied structure or form, but I think you need a secure HTTP or risk exposing the user's information to the outside world. After all, you are moving more than necessary data between the client and the server.
You can move the session data away from the application itself and drive it from different servers. Just as the database is responsible for keeping the data, you need another type of server to manage the Dynamic data. You can have many Web servers driven from a Dynamic Data server and a replica of a Dynamic data server used in fault tolerance. Perhaps this wonderful dynamic Data server can be executed on the site server with an Membership Server and an ActiveX User Object (AUO). An introduction to AUO can refer to Active User Objects & the Membership Directory.
Before you use AUO for session data, you must already have a Membership server configured with AUO and assigned to a Web site. Once these are ready, further configuration of the Membership Directory and AUO is required.
Configure AUO
The hardest part of using AUO for session state is to configure it-not really difficult, but to do a little extra work before you start using it. By creating a class and a property to define what the state information looks like, you need to set the storage place for the class's example. The steps are:
Define the attributes of the session state that you want.
Creates or selects a class for session state data.
Creates a container for dynamic data.
Configure a second AUO supply.
It is meaningful to consider a property as a member of a class in an object-oriented domain. You must associate a data type with each attribute, for example, the shopping basket class that maintains the number of items contained in the shopping basket as the numeric property. Add all attributes to the Membership Server's schedule with the site server's MMC.
Once you have defined all the attributes, you associate them with a class-an example of a class as an object-each object can have its own property value. If you already have a class to represent the session state, you can add attributes to it. Otherwise you will need to use the Membership Directory Manager to create a new class to represent the session state. In our example, a class called Sessionstateclass is used.
Now you need to create a second AUO provider that contains secondary data for the main AUO provider. It can be an ODBC-compliant database, a different directory service, or another container in the Membership Directory. In this example, the secondary data is session state information, stored in a container in the Membership Directory.
So, in the membership root directory, create a container that holds the dynamic session information and name it ou=sessionstatedata. The second AUO supply uses the Sessionstatedata container to store the data. Create a second AUO supply with sessionstate with MMC. It should have the following properties:
ADS Path:computername:ldapport/o=yourdirectory/ou=sessionstatedata
Schema Path:computername:ldapport/o=yourdirectory/ou=admin/cn=schema/cn=sessionstateclass
Now you can use AUO to store session information. Although this may seem a bit complicated, all you have to do is create and sample an object that exists in the Membership Directory: Define a class that has attributes (or components) that represent the session state of the user. Each user will get an example (or object) of this class. So now we let AUO start working.
Set AUO Session state
Author: Green Apple studios This article hits: 277
Now that the second AUO is ready to store dynamic data, you now need to set a value for the property. First, you contract an object to the user who requested the Web page:
Set objuser = Server.CreateObject ("Membership.UserObjects")
You can access any static property simply by referencing it. So, to display the public name you want to do this:
Response.Write "Your Login:" + objuser.cn
To set up dynamic information, you must ensure that the object actually exists. Because it's a dynamic object, you can't automatically assume it exists.
If not IsArray (objuser ("sessionstate"). objectclass) Then
objuser ("sessionstate"). objectclass =
Array ("sessionstate", "DynamicObject")
End If
Then set an existing time value. When this time is over, the object terminates and disappears. SetInfo must be invoked before any other properties of the AUO Session object are set.
objuser ("sessionstate"). Entryttl = 900 ' specified in seconds
objuser ("sessionstate"). SetInfo
Finally, you can set the value. Here I set a property that is defined as NumItems. Note that this attribute must exist in the plan and that the assigned value must conform to the data type in the plan.
objuser ("sessionstate"). NumItems = 3
objuser ("sessionstate"). SetInfo
You can try using a non-existent attribute, or assigning a value of the wrong type, to see the error message you get.
Access AUO Session state
I left the simplest example to the end. Accessing the value of a property is the same as accessing any second AUO provider information. Specifies the user object, the second AUO supplier name, and the property name.
Response.Write objuser ("sessionstate"). NumItems
Leave your desk, wait for the end of the object, and then come back and refresh the page to verify that the object is really dynamic. If the object has been terminated, nothing can be displayed.
The difference between session and AUO objects
You may have noticed that you have to define and copy them before using the AUO property, which I think is the greatest advantage relative to the session object. It forces each developer to do more design beforehand, creating a central area of a variable declaration for projects that multiple people develop together, which is much more useful than having session variables spread across ASP files.
There is also a lot of possibility of data processing. You can use ADSI to access groups that store session state, and then perform various display processing on groups of users and their properties, such as who buys, what they cancel, what time of day they buy, and so on.
Conclusion
So don't be the victim of your success--Build your ASP application to make it scalable and fault tolerant. A key aspect of scalability and fault tolerance is the policy of maintaining user session state information. If you are using a site server, an ActiveX user object is a good way to maintain user state information.
