Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Session Variables
No doubt the first references you read on ASP programming recommend the use of session variables to save state information. Session variables are indeed extremely easy to use because the ASP Session object does all the work for you. For example, to save a user's e-mail address in a session variable, you might code something like:
Session.Contents("EmailAddr") = "kdlutes@delmarit.com"
And to later retrieve the email address back into a variable:
EmailAddr = Session.Contents("EmailAddr")
A new session is started when a user first requests a page from an ASP application, and the contents of a session are unique for each user. Because the Web server has no way to know when the user leaves a site, it destroys the session data only when it decides the session isn't being used anymore. The default is 20 minutes of inactivity, but this value can be changed by using a Web server configuration option or by changing the Session object's Timeout property within ASP code. Your ASP code can also explicitly destroy session information by calling the Session object's Abandon method.
As with cookies, sessions are also not an ideal solution for retaining state in Web applications. The problem comes from how the ASP Session object works. When a user first makes a request to your Web application, a unique identifier for the user is generated (SessionID), and the server asks the browser to save this identifier in a cookie. The only purpose of this SessionID cookie is so that the server can associate requests from the user with previous requests from the same user. The cookie it uses is non-persistent, and it is destroyed as soon as the user leaves your site. However, it uses the same cookie protocol as described previously, and if the user has disabled cookies on his or her browser, session variables won't work.
The session data itself isn't stored on the client computer. Instead, it is stored in the server's memory, so it presents another problem. As the number of concurrent users of your application increases, so must the available memory on the server. Additionally, if the application runs on Web servers in a load-balanced environment, sessions will work only if all requests from a single user are always routed back to the same server, which partially defeats the purpose of using load balancing in the first place.