Selecting a Threading Model for Components in IIS

IIS 6.0

Whether your component is used over the Internet or an intranet, it will need to respond to simultaneous calls. The way your component responds to simultaneous calls is largely determined by your choice of threading model. This choice will have significant implications on the component's responsiveness, particularly in large volume Internet scenarios.

You can use the Both threading model for all types of ASP components.

All Both-threaded components should use the COM Library function CoCreateFreeThreadedMarshaler to create a free-threaded marshaler object. If you aggregate the free-threaded marshaler object, you can make calls between threads without any marshaling or thread switches. For more information about free-threaded marshaler objects, see the COM and ActiveX? Object Services section of.

If you build a Both-threaded component that does not aggregate the free-threaded marshaler object, you will only be able to dynamically assign the component application scope if the AspTrackThreadingModel configuration property is set to 1 (True). By default, this property is set to 0 (False) in order to improve performance and prevent ASP from completing the response before the component is destroyed.

For example, if the component MyComponents.Comp1 supports the Both threading model, but does not create a free-threaded marshaler object, the following code will generate a run-time error unless AspTrackThreadingModel is set to 1 (True).

Set Application("Obj1") = Server.CreateObject("MyComponents.Comp1") 

Dynamically assigning MyComponents.Comp1 to session scope will severely impede performance for the duration of the session. Likewise, assigning this component to either application or session scope with the <OBJECT> tag would also have a negative impact on performance.

The only disadvantage of building components using the Both model is that serialization of calls to the component are not allowed. This means that your component will need to guarantee thread safety. Building in thread safety may slow down your development time, but will make your component more suitable for use with session or application scope.

You can use the Apartment model for components with page or session scope. However, when you create Apartment model components in a session, the session is locked down to a single thread. This slows access time.

You should not use the Apartment threading model for components that you plan to give application scope. Creating an instance of an Apartment model object with Server.CreateObject will generate an error. For example, if, in the following script,


is Apartment-threaded, the script would generate an error.

Set Application("Myapp") = Server.CreateObject ("MyComponents.Comp2") 

If you place an Apartment-threaded component in an application with the <OBJECT> tag, it will not generate an error. However, this will cause access to be slow.

In addition, if you develop a component with the Apartment model and give it application scope, it will run in the System security context, rather than the context of the current user, thereby making it unacceptable for scenarios that rely on Windows? security.

Although it is possible for you to use any of the four threading models, it is recommended that you develop your components with either the Apartment or the Both model. There are serious performance limitations with the Single and Free models.

This threading model is not recommended for components to be called by ASP pages. Single-threaded objects are not suited for applications that need to accommodate a large volume of users simultaneously. Using these objects can result in a deadlock when multiple users try to access the object simultaneously. All calls to Single-threaded objects are serialized through one thread, the COM Main thread. Calls to these objects from other threads are marshaled to this thread. Only one thread at a time can enter a set of Single-threaded objects, and it must be the same thread each time.

Additionally, Single-threaded objects work in the context of the System account and have all permissions associated with the System account. In most cases, this is not desirable for Web sites.

If you are developing with Visual Basic? your component will be single-threaded unless you specifically set it to Apartment on the General Project Properties page.

Building Free-threaded components is not recommended; if possible, you should use the Both model instead. One disadvantage of Free-threaded components is that you must register them with the Component Services Manager in order to access the COM+ ObjectContext object, whereas all Both- or Apartment-threaded components can immediately access the COM+ ObjectContext object. This means that Free-threaded components that you have not registered with Component Services Manager can only access the ASP built-in objects through the ScriptingContext object. This method of accessing the built-in objects is considered less suitable for ASP components than using the COM+ ObjectContext object.

Another disadvantage with Free-threaded components is that, like Single-threaded components, they run in the System context, rather than in the context of the logged-on user. As a result, the Free-threaded model is not acceptable for scenarios that rely on Windows? security to control access to objects.

The Active Template Library (ATL) provides a very easy way to declare that your component supports both Apartment and Free threading models (the Both threading model). You can use the ATL Object Wizard in Visual C++? 5.0 to set the threading model support on the Attributes tab of the properties page. For more information about ATL, see the Visual Studio? SDK and the Additional Resources section.