单元线程对象的生存周期
对于VB程序员的好消息是：由于ASP线程池是建立在STA基础之上的，所以在IIS应用中并没有太大的局限性。一个ASP页和由它创建的VB对象通常都是在同一个线程中运行。这样，就可以避免COM Proxy/Stub的开销。
重要的是要记住，VB对象表现出线程亲和力。这意味着VB对象只能由创建它的线程进行访问。当你在单个HTTP请求范围内创建和释放对象时，并没有问题。但是如果你试图通过把它分配给一个ASP Session变量而在多个请求中抓住一个VB对象不放，那么就会将客户牢牢拴在ASP线程池中的某个特定辅助线程中上。
看这个例子，它突出强调了ASP设计人员在创建他们的框架时必须认真考虑的问题。假设来自客户的一个请求创建了一个对象，并把它分配给ASP Session变量。该对象是在ASP线程池中的一个STA线程上创建的，不妨假设是线程17。如果来自同一个客户的下一个请求由线程8来处理，将会出现什么情况呢？这是就会出现麻烦，因为线程8不能访问线程17创建的单元线程对象。为了能够访问该对象，客户请求必须从线程8切换到线程17。
ASP设计人员做出的抉择是：一旦为一个客户会话分配了单元线程对象，ASP-RunTime就会在会话期间通过同一个STA辅助线程来发送每一个请求。这是不幸的。因为ASP线程池管理在池中第一个线程可用的情况下才会得到最佳的工作效果。
ASP线程池管理模型可以分配池中的任何线程来为进入的ASP请求服务。但是，当你把VB对象分配给ASP Session变量时，ASP必须定位(可能阻塞)创建该对象的那个线程。虽然ASP-RunTime可以把相同线程的所有后继请求都串行化，但是这种情况不允许一个应用发挥它在性能和并发方面的潜能。甚至在还有若干个空闲STA辅助线程时，客户也可能阻塞另一个客户的请求！
要避免这一切，重要的一点是VB对象应该只在页的范围内使用。
来自Ted Pattison的《Programming Distributed Application with Visual Basic 6.0》
