Reasons to move to .NET
Jimmy Nilsson
Many developers are thinking about moving to .NET, yet may not understand good reasons to do so. Never fear: In this tip, excerpted from InformIT, Jimmy Nilsson discusses one such reason -- multi threading.
Jimmy Nilsson is the author of .NET Enterprise Design with Visual Basic .NET and SQL Server 2000.
Most VB6 developers who have read about .NET, or who have played with it, have a long list of reasons why you should upgrade to Visual Basic .NET or C#. Common reasons include support for implementation inheritance, an improved versioning schema, and object constructors.
Some developers also see the support for free threading as a major improvement over the VB6 Single-Threaded Apartment (STA) multi-threading model. However, other developers warn about the dangers that free threading will add. Using free threading certainly can do some serious damage, but it also opens up new possibilities for VB developers when building COM+ components. We can use the object pooling service, for example, and the synchronization service in COM+ makes it quite easy to write thread-safe components. (If you leave out sharing objects between requests by using the object-per-request mode, you're also relieved of most of the threading issues.)
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!
To read the article from which this tip is excerpted, click over to InformIT. You have to register there, but the registration is free.
For More Information
