One of the biggest challenges session|session creating interactive Web pages is maintaining the user's state, a site that might want to remember who you are, what you clicked on before n pages, what you did last time, and what you're going to show you right now. There are many ways to implement these functions, such as query strings, submitting forms, or cookies, the most powerful of which is the ASP's session object.
Source: http://www.asptoday.com/articles/20000118.htm When the user first arrives at a site, he/she is given an HTTP cookie format SessionID (is a read-only property,
Returns the session identification number for each user. The server can then track a whole group of variables in the session set, by
Matches the user's session cookie to keep each user with a specific variable. As long as the user stays active on the server,
The session variable maintains its state. The default valid time for a session variable is 20 minutes, or whenever the user closes
Browser, the Global.asa file runs regardless of what the session_onend part is.
The key to the above statement is "Stay active on the server". Each session variable is set on the network server and remains in the
In local memory. So what if you use load balancing on a web-wide scale? (For an introduction to load balancing, see
MSDN article ' ASP and Web session Management '). For real load balancing, whenever you live on a server
When a user clicks on a connection, it changes the state of the server, potentially losing them whenever a new page is browsed
Session information.
If you find yourself writing code in such an environment-or you suspect your site is ultimately load-balanced-you have 4 ways
To solve the problem.
0 does not use session at all.
0 Use temporary cookies.
0 Purchase third party components to handle session management.
0 load-Balance only for first click in Web-wide.
This article discusses the four options and explains when and where they are most applicable.
Do not use sessions at all
Obviously, one way to bypass sessions management is to not use the sessions variable at all. But you're still stuck in
The problem of state retention. You can use the easiest way to track users without having to write to the client.
An unsafe approach is to use a browser to query a string, or to place a form in a hidden value to keep the user active.
This will allow you to give them a user ID and store the variables in a place where all Web servers can be reached. For example
I kept the variables shiptozipcode, Typeofcustomer and Customeremail. You can write this:
< form action= "/nextpage.asp" method= "POST" >
Item Number: < input type=text name= "ItemNumber" >< br >
Quantity: < input type=text name= "Quantity" >< br >
Unit cost:< input Type=text name= "UnitCost" >< br >
< input Type=hidden value= "abxxxkjr8jsdfi12kjil2h75cx45x2" name= "SessionID" >
< input type=submit value= "Post form" >
</form >
Then, on the nextpage.asp, the following work can be done:
Set Conn=server.createobject (ADODB. Connection)
Set Sessionrs = Conn.execute ("Select Shiptozipcode, Typeofcustomer, _ Customeremail from tblsession where SessionID =" &A mp Request.Form ("SessionID"))
Shiptozipcode = Sesssionrs ("Shiptozipcode")
Typeofcustomer = Sesssionrs ("Typeofcustomer")
Customeremail = Sesssionrs ("Customeremail")
This allows the three variables to remain active on each page by storing all the session information in the database. Ensure
It is important that the value of the user ID is difficult to guess. When you access the first page, the SessionID that is assigned to the user is stored as the user name. When the user
When you leave this page, consider clearing this data to effectively regenerate the ASP Session object. This can be done by hand, or with
A timed program will delete records for more than a few weeks.
Use of temporary cookies
For special, insensitive data, it is meaningful to write information directly to the client machine. For example, if my site uses only one
Variable to track the user's zip code to the user's local traffic records, then the user's zip code in the form of an HTTP cookie
There should be no harm in writing their machines. Because you can disable cookies as a browser shutdown, you can make them
The ability to mimic a session variable can also enable them to be persistent and to remember him the next time the user visits.
The value of the Request object cookie can be used by the server. Request the value of the cookie, and then bring the value in. So on top of us
example, you can do this:
Shiptozipcode = Request.Cookies ("Sessioncookie") ("Shiptozipcode")
Typeofcustomer = Request.Cookies ("Sessioncookie") ("Typeofcustomer")
Customeremail = Request.Cookies ("Sessioncookie") ("Customeremail")
You have to put these at the top of each page, but if the user sets three cookies, each page can be
Access and use these user-specific variables. You can also set three variables in a cookie, see Ken Baumbach's article
Cookie Basics with ASP, which has more information about setting variables.
This method does not apply if you think that the user may invalidate cookies on the browser. But more and more sites are asking to use
Cookies,web users are becoming more proficient. It is possible that relatively few users will invalidate cookies, but this will be done in
Before this method is considered.
Although the above methods will certainly work, they weaken the functionality of the ASP because it restricts one of the key components--session
The use of the object. To avoid this limitation caused by load balancing, one way to continue using sessions is to buy a third party
component, you can better handle sessions than IIS.
In this article, I don't want to compare the pros and cons of various third-party components. But I heard that there's a component that works pretty well, it's softartisans.
Provided, called Sa-session Pro. It uses the NT file system to store the user's information, and the entire network-wide server can
Use. Other Third-party components create the session engine to separate the network server from the session manager. This way, each time the user
Can be redirected to the same session engine and load-balanced for clicks on the server itself.
Another third-party component that can be selected is a member server for Microsoft. It is with the Microsoft Site Server, which allows a
The site deals with issues other than state maintenance. In Bill Pitzer's article ' Moving your ' Anonymous ' visitors to
Registered the status using Site Server and Membership Directory authentication ' has more
Information.
Since ASPs have become increasingly a choice for enterprise-class network applications, load balancing has become the greatest threat to the success of these applications,
There will be more and more third-party components in the marketplace. The ASP itself is a server object or ActiveX component that can handle these
Plugin's.
Load balance only when first click in Web-wide
This method, also known as front-end load balancing, is easy to describe, but may not be suitable for execution. To achieve true load balancing, each
Requests are rebalanced to the user. In most cases, however, front-end load balancing is sufficient to accommodate most of these server-maintained
Supporters.
To do this, only allow the first click in the range through the load balancer. Each additional page load keeps the user
On the same server. This is as simple as using a relative path in your code rather than an absolute path.
< Form action= "http://www.myserver.com/mypage.asp" Method=post >
