Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
STA Problems
Apart from not having the possibility of using object pooling, just what's so bad about STA? I'm not going to go into a long description about different threading models here. Let's just use a simplified description and say that an STA thread can't be used by a second request when it's servicing a first request. It doesn't matter whether the two requests are about two different objects, or even classes. Instead, the second request is put on hold until the first request finishes. You might ask why the second request would try to use the same thread. One reason is that COM+ uses a thread-pool per server application, and the size of the STA thread-pool is approximately 10 threads multiplied by the number of CPUs. So if you only have one CPU in your server, there are only 10 threads that can service the requests of the application. When all those threads are busy with long requests, new requests have to wait. (You can increase the size of the thread pool—see Microsoft Knowledge Base article Q303071—but the basic problem is always there. It's also the case that when you don't see long requests you'll have a lot of thread-switching overhead.)
If all the threads are busy, new requests have to wait. This doesn't apply for Multi-Threaded Apartment (MTA) threads, because there's no upper limit for that thread pool. But there's one even more irritating problem when it comes to STA threads. Assume that two users' objects are sharing the same STA and all other STAs are unoccupied. The first user then starts a long operation. Even though there are many idle threads, requests from the second user have to wait.
The blocking behavior of STAs has been well known for a long time, but I think Microsoft's support engineers have recently been more eager to point out the problems of STAs at the COM+ newsgroups. They refer to Knowledge Base article Q291837, "INFO: Do Not Make Blocking Calls from an STA Component." In this article, Microsoft says that a blocking call is a call that calls a back end (such as SQL Server). So what does this mean? It basically says that you shouldn't use VB6 for writing COM+ components that talk to a database server. Oops! My guess is that 90% of the COM+ components in the world do just that—they're written in VB6 and talk to a database server (directly or indirectly).
The good news is that this problem goes away when Visual Basic .NET is used because then you write free-threaded COM+ components!