Home arrow ASP arrow Page 2 - When Session Variables Go Bad
ASP

When Session Variables Go Bad


Are session variables a bad thing in ASP? In this article Bruce examines the pro's and con's of session variables and provides suggestions that you can apply to your own ASP apps.

Author Info:
By: Bruce Johnson
Rating: 5 stars5 stars5 stars5 stars5 stars / 46
November 28, 2002
TABLE OF CONTENTS:
  1. · When Session Variables Go Bad
  2. · The Implementation Details
  3. · Cap'n. The Resources. They Canna Take It!
  4. · Conclusion

print this article
SEARCH DEVARTICLES

When Session Variables Go Bad - The Implementation Details
(Page 2 of 4 )

The ability to even have Session variables is premised on IIS being allowed to place a cookie onto the client's system. This cookie contains a 16-character identifier that allows IIS to track the requests that are made by that client. Internally, this identifier is associated with a collection. This association allows IIS to not only implement Session variables, but also to time out the session itself (and the variables along with it).

The fact that the identifier is a cookie means that those users (and you know who you are) who don't have cookies turned on will not have their session variables stored. Just so that we're clear, not accepting cookies doesnot mean that the session variables won't exist. But every time the cookie-less user makes a page request, a new session id will be generated, along with a call to the Session_OnStart procedure. So there is, in effect, no persistence of the variables from page to page. What's worse, you're site will bombard them with requests to store a cookie on their system (one for every page that they hit). So, in the interest of a better user interface, a different approach might be called for.

The 'better' way would be to check to see if the user will even accept cookies before going too far into your web site. The technique to do this is quite simple. On one page, set a cookie on the user's browser. Then on a subsequent page, check for the presence of that cookie. If it's not there, then the user has disabled cookies, at which point you may want to warn them what they're in for.

As we've already mentioned Session variables are implemented as a collection of values. As such, there is no practical limit to the number or type of variables that can be stored. There are, however, technical reasons to limit the objects that are stored. But more on that in the next section.

Tying Up Loose Ends
"After I assign the object to the Session variable the Session variable is still 'Empty'"

"Using a connection object in my Session variable worked fine on the development server, but it randomly times out now that it's in production"

Sound familiar? Don't be surprised if it does. Again, this is a regular topic in the newsgroups. Problems assigning objects to Session variables, that is. Well, there is an explanation for the problems and, consequently, a good reason to avoid doing so blindly.

First, we need to discuss the concept of threads and how they apply to IIS. A thread in Windows is a single stream of processing capacity. Now IIS has a number of threads assigned to it (10 by default) each of which is capable of responding to requests and transmitting the resulting pages back to the user. The assignment of requests to threads is a round robin process (in other words, each thread in turn is given the request to handle), so no thread gets overworked.

Another concept that comes up if you create COM objects with Visual Basic is something called Apartment Threading or Single Threaded Apartments (STA). The distinguishing feature of an STA component is that all calls to the object (both methods and properties) must occur on the thread in which the object was originally created. Or, to put it in the words of the MSDN glossary "Each object 'lives in an apartment' (thread) for the life of the object". That means that the object has what is called 'thread affinity'. The object needs to be running in that thread before it can used by that thread.

The opposite of an STA object is a free-threaded or Multi-Threaded Apartment objects. These objects can run on any thread. In fact, they can be running on different threads simultaneously. So why can't you simply define your COM objects as free-threaded? Aside from the fact that Visual Basic 6 doesn't allow you to do this, the complexity of your component would increase exponentially. In a free-threaded component, the value of the member variables can be changed by any instance of the object running on any thread. And the change would be seen by all of the components. In other words, there is no protection of the data from other instances of the same object. Something that STA provides.

Back to the impact of STA on IIS. Let's say that you create an STA object in an ASP page and assign it to a Session variable. When the next page tries to access the variable, IIS needs to wait for the creating thread to become available. Otherwise, the object would not be available. If you're running on your development system, it is likely that there will not be more than one or two threads active at one time. So if your request had to wait for the thread on which the STA object was created, you would probably be none the wiser. However, if you install the object into a production environment that is getting hundreds of hits an hour, there is likely to be a different outcome. The site will seem sluggish and the possibility of having a component breakdown is not an uncommon occurrence.
blog comments powered by Disqus
ASP ARTICLES

- Central Scoreboard with Flash and ASP
- Calorie Counter Using WAP and ASP
- Creating PGP-Encrypted E-Mails Using ASP
- Be My Guest in ASP
- Session Replacement in ASP
- Securing ASP Data Access Credentials Using t...
- The Not So Ordinary Address Book
- Adding and Displaying Data Easily via ASP an...
- Sending Email From a Form in ASP
- Adding Member Services in ASP
- Removing Unconfirmed Members
- Trapping HTTP 500.100 - Internal Server Error
- So Many Rows, So Little Time! - Case Study
- XDO: An XML Engine Class for Classic ASP
- Credit Card Fraud Prevention Using ASP and C...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials