ASP session Management in load-balanced environment

One of the biggest challenges in creating an interactive Web page is maintaining the user's state, and a site may want to remember who you are, what you clicked on before n pages, what you did last time, and what you want 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 collection and keep each user with a specific variable by matching the user's session cookie. The session variable maintains its state as long as the user remains active on the server. The default valid time for a session variable is 20 minutes, or whenever the user closes the browser, the Global.asa file runs regardless of the session_onend part.

The key to the above statement is "Stay active on the server". Each session variable is set on the network server and remains in local memory. So what if you use load balancing on a web-wide scale? (For an introduction to load balancing, see the MSDN article ' ASP and Web session Management '). For true load balancing, whenever a user who resides on a server clicks on a connection, it changes the state of the server, potentially losing their session information whenever a new page is browsed.

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 with the problem of state keeping. 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 =" & request.form("sessionid"))
ShipToZipCode = SesssionRs("ShipToZipCode")
TypeOfCustomer = SesssionRs("TypeOfCustomer")
CustomerEmail = SesssionRs("CustomerEmail")