Classic ASP (2.0 & 3.0) session variable issues?

Phurion

Phurion

Perch
I was reading through the KB for any gotcha's I might run into by transferring here. I noticed an article that recommended using SQL session state management, but it didn't indicate if this was related only to .NET or if classic ASP would be affected as well. One of the solutions offered was to move the domain to a Win2k server vs the Win22k3 servers the cluster is hosted on.

The portal software I use makes extensive use of session variables for it's login and new user authentication. I've also used it quite a bit in our guild application so it forces applicants to view some required pages before allowing them to access the application form.

Will I be affected, and if so, what do I need to do to have the domain moved to a Win2k server?
 
We do not offer windows 2000 anymore, and the last windows 2000 server is being migrated off ofer the weekend. Most session state be managed by application pools now, however I'd recommend using a cookie, sql, or other method fr the best state retention.
 
Unfortunately I can't recode my entire portal application (SOOP) to change the way it uses session variable.

I can look into changing my custom code, and hope it all works out.
 
SOOP doesn't have any issue at all, I know people using soop I can close tab, close browser and come back, and still logged in :D
 
Excellent! That's good to know.

I'm hoping my guild application form works with the same reliability. Let me explain what it does, and maybe you can tell me if it will work or not.

Users are required to read 3 pages before the application form will allow them to see it. The application checks for session variables set in those 3 pages. If any one of them is not set correctly, it redirects them back to the page they didn't read. Depending on how fast they read, it could take 2 to 3 minutes to get through the entire process.

Do you think the session variables will be managed in a way that this process will still work, or do I need to look at storing them in a cookie (though I really, REALLY hate cookies since so many folks disable them these days).

Thoughts? Suggestions?
 
2-3 minutes should be ok, but if it is a problem it may need to go to its own pool.

Pool problems can happen if a site has few to no hits, because after 20 minutes with no hits the pool "dies" but so long as you have hits that will be a non issue.
 
Would it help if I add in some code to touch the application pool with every page load, just something to sort of "ping" it to keep it alive?

That would be an easy enough solution. Or might that cause other problems?
 
sure, dotnetnuke does that to keep its asp.net pages alive, because asp.net cna take some time to compile, don't see why you couldn't do it on asp to keep a session alive longer.
 
You must log in or register to reply here.
Back
Top