>Testing multi-threading with IIS, I called an ASP page that generated a MTDLL com object from two systems simultaneously and each generated a unique thread id, which is correct. However if I bring up one system and then wait for a sufficient time and then bring up another system, both systems will share the same thread ID.

I don't understand your scenario. It doesn't matter if you wait or don't wait - apartments are built when a thread enters it and typically this apartment will always be the same if you have one request at a time. If two requests come in simultaneously or while another is processing a new thread will be created for that apartment to be processed in. You get the same thread ID because IIS will recycle threads. On an ASP page ASP creates an apartment, loads the COM object into then unloads it at the end of a page and IIS tears down the apartment. The thread comes out of a thread pool that IIS provides.

>This is what is called "blocking". Each system has to wait for the other system on the thread to finish processing before they can begin processing their request.

IIS assigns the thread and Apartment model threading requires that a thread an object uses is always the same as the thread that actually created the object. Hence the Single Threaded Apartment that VB and VFP use.

If the thread pool fills IIS will create multiple apartments on the same thread in which case blocking does occur. However, this is unlikely if you use page level ASP components that create then unlaod the object within the page.


+++ Rick ---