Maintaining session information in ASP across a web farm?

[brickwall]

My hosting company put sites on load-balanced multiple servers. Sometimes, not always, only sometimes, sessions get dropped when the http request gets routed to a different server. The hosting company suggest that I use cookies to store session info so that in case the session gets drop, I can read the info back from the cookie. What is the best approach to do this?

Will this suffice?

1. On user login
- store data in session vars
- duplicate data in cookies
- set cookie to expire within now +30mins

2. On all other pages
- refresh cookie to expire within now +30mins

3. On glabal.asa session_onstart()
- check for cookie
- if unexpired copy data to session vars

I cannot use a database for this purpose because of other technical concerns.

Your input will be much appreciated.

[Xoc]

I think what you described will work.

As an alternative, in ASP.NET, you can use session variables across the entire web farm by either:

1) Starting a service
2) Setting up a SQL Server box

Then changing one variable in the web.config for the site.

[brickwall]

Thanks Xoc.

Iam using classic ASP, not .NET and I don't have any other control over the server because Iam on a shared hosting plan.

Follow-up related questions:

1. When a session gets dropped because the http request is routed to another server, another new session is created upon receipt of the request, right? I assume a new session is created in such case that is why I opted to put the cookie-verification code inside Session on_start() in global.asa

2. What is the correct syntax for putting expiration date/time in cookies in classic ASP and ASP 3.0?

Is this correct?
- Response.Cookies("myvar") = myvalue
Response.Cookies("myvar").Expires = #1/11/05 00:00:00 AM#

Thanks again.

[tomasz]

IMHO, it is time to look for another host, if they have off load their servers, they most likely running at critical level CPU/Memory.

[RossWal]

Brickwall, Why do you propose to use session vars on top of cookies. Why not simply go with cookies?

Ross

[CaseyRyan]

I agree, I would just use cookies and read/write the values on the pages you need to.

Problem with reading the cookies at session beginning of the session is that the session times out, it doesn't end when the customer switches servers.
Here's the scenario:
Your client is started on Server1 (Session Started).
He bounces to Server 2 (Session Started).
He then bounces back to Server 1 again (within 20 minutes? = Session Continued).

You would never know that the customer had been on the other server unless you're reading his cookies everytime. So, I would not use session at all, and just read cookies when you need them, write to them when you need to.

I'd also look into another hosting company like tomasz said.

[duckhunter]

We run our site in a web-farm as well. Our provider offers 'sticky sessions' inside the load balancer. Any well known load balancing hardware should be able to keep users sticky to the box they first landed on.

If this is not available, cookies will be your best route given it's classic ASP.