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.
Next: Cap'n. The Resources. They Canna Take It! >>
More ASP Articles
More By Bruce Johnson
