"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.
Comments