I am attempting to use a VB Object in an IIS/ASP environment.

I have read (in a book and as a footnote in MSDN) that VB Objects are
only Single Threaded (Apartment Threaded at best).  The preferred
threading to use is 'Both Threading'.

What kind of actual, real-world problems can this cause for me.
Significant delays?  Errors over a certain threshold of users?  Does
anyone know?

If I put the object into the session this forces the entire session to
be apartment threaded.  How much will this magnify the problems I am
already going to see from using the object?

--Roy

Mostly correct.

Your options for threading models are:

Single (not recommended)
Apartment (recommended for components that have page scope)
Free (not recommended)
Both (recommended for all components)

The reasons for the "not recommended" ones vary...and I won't discuss them as
it doesn't really matter anyway (just don't use them).  ;)

As far as it goes...aparment model is fine for page-scoped components (though
it does lock the session to a single thread for the duration of that
component's existence).  The both model is far faster, but much more complex to
create (and not possible with a VB COM DLL).

Mostly, you'll get delays.  The delays will increase depending on server load
(the amount of people actually accessing the application/page containing these
components).  If you use anything but page scope (for instance, setting a
Session("") variable equal to an appartment threaded component), you'll get
larger delays as the session would be locked to a single thread until the
Session("") variable were destroyed.  If you try using an apartment component
in an Application scope...you're asking for a crawling site.  ;)

If you create an apartment object on a page, the session is only locked to a
single thread as long as the component is instanciated (until it's set to
nothing).  If you set it into a Session variable (as opposed to local page
variables), you lock the session to a single thread for as long as this object
exists...regardless of how many pages the user visits while it's active.
Basically, the higher you go with an object (page, session, application, etc)
the slower the response becomes...and the more users, the slower (more
responses in the que).

However, the good news is that you can usually work around these problems.  For
instance, at the beginning of some of my ASP applications, I use
Application_OnStart and Application_OnEnd (along with some .asp update pages
for dynamic changes) to store values from the a database into arrays.  I then
store the arrays within the Application object and extract them as neccessary
in the Session events or separate pages.  The programming is a bit more
complex, however, you end up with a *much* faster system, even if you add the
utility functions into "include" files and call them when neccessary.

Overall, if used carefully, you should still be able to use the aparment
objects and still have a reasonably fast site...  The key is extracting
information you need from the components and storing them in other
ways...usually session or application variables.  If you need a user name from
a User component, create the component and load it with its values, extract the
values you need, and add them to variables as needed.

set user = new CUser
if user.Load(lngID) then
  Session("User.ID") = user.ID
end if
set user = nothing

Response.Write Session("User.ID")

(of course, multiple uses of a session variable should be pulled into a local
variable...but...that's another subject)...

Hope this helps a bit!

-Curtis Spendlove
-Solstice Software