All of your component design decisions are interrelated. Your component's function will impact what scope script writers will give it, which, in turn, will impact your selection of a threading model. The guidelines below represent two possible ways you can approach making these decisions:
These guidelines are not hard-and-fast rules, but are design recommendations to help you develop high-performance components faster.
You should give the majority of your components page-level scope. Most components that you develop around a set of business rules (business objects) should be given page scope. If the components are going to participate in transactions, they should be registered with the Microsoft® Transaction Server (MTS) explorer. Any components that you give page-level scope to should support either the Apartment or Both threading model.
You should consider using session scope if you want a component to manage an aspect of an ASP application that spans multiple scripts, but relates to a particular user. For example, if you know the application design requires multiple ASP scripts to access a database, you should create a single database access component and give it session scope. The database access component retrieves the required record set, and shares the data between all scripts in the session.
Be very cautious about giving a component application scope. Some general utility components, such as a counter component, could require application scope, but there are very few situations where a component will require application scope. You should store the data required by the component at the application level and give it session or page scope. Components with application scope should be developed with the Both threading model and should aggregate the FreeThreadedMarshaler. You should not give application scope to transactional components (those registered with MTS explorer).
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 Both model. There are serious performance limitations with the Single and Free models. For a detailed explanation see the following:
and
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 on free threaded marshaler objects, see In-process Server Threading Issues and CoCreateFreeThreadedMarshaler in the COM section of the Platform SDK.
The only disadvantage of building components using the Both model is that it does not allow for serialization of calls to the component. This means that your component will need to guarantee thread safety. Building in thread safety may slow down your development time, but will allow your component to be more suitable for use in 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 MyObj was an apartment-threaded object, the script would generate an error.
MyObj = Server.CreateObject("MyObj")
Set Application("Myapp") = MyObj
If you place an Apartment-threaded component in an application with the <OBJECT> tag, it will not generate an error. However, it 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 which rely on Windows NT® security.