Yes. That's the way I understand it, too. So (correct me if I'm wrong), once an object is created on a thread, only that object lives on that thread until the object is released and the thread again becomes available. Since it's one thread per apartment, basically it's also saying that a maximum of one object lives (is instantiated)in any given apartment at one time.

What I'm really trying to do is understand just where static thread-local storage (for a given thread) is subject to possible corruption. For example, what if two asp pages instantiate the same object and these instances coexist on the same thread (assuming that's possible in the STA model)? Thus these objects can unpredictably mess with the same TLS at the same time. My understanding is that that STA, by definition, prevents that from happening.

>I believe it's 1 apartment to 1 thread and, while there can be multiple apartments/threads at any one time, each single apartment/thread serializes requests with its message pump. So, if your running thread ID tests in a test web app, you'll see that a request may end up with the same thread id if you run it over and over again(or it may not). However, you will not see the same thread id for multiple requests at the same time. I think that's the way it works. Here's some background info I saw posted on Apartment Model threading:
>http://www.techvanguards.com/com/concepts/multithreading.asp