Reasons to move to .NET


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,

    Requires Free Membership to View

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

This was first published in April 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.