User State Maintenance

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.


does not maintain certain types of state, 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 a 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 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 transfer the session data 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.