Choosing the Scope of a Component in IIS

There are different choices of scope for a component. Before creating a component for use in an IIS application, select the scope based on the behavior of the scope. For information about threading models, see Selecting a Threading Model for Components in IIS. For information about how to set the scope of a component that is to be used in an ASP page, see Setting the Scope of an Object in ASP Applications.

The choices for component scope are as follows:

• Page

• Session

• Application

Page Scope

Most components that you develop around a set of business rules should be given page-level scope. In general, components that you give page-level scope to should support either the Apartment threading model or both the Apartment and Free threading models. If a component is going to participate in transactions, it should be registered with the Component Services Manager. Components that you register with Component Services Manager should support the Apartment threading model. Limitations of the Free and Single threading models are discussed in Single-Threaded Components and Free-Threaded Components.

Session Scope

You should consider using session scope if you want a component to provide functionality that spans multiple asp files. When you give a component session scope, any calls to a particular instance of the component will be treated as a group. For example, if you know the application design requires multiple .asp files to access a database, you may choose to create a single database access component and give it session scope. The database access component, in this case, retrieves the required record set and shares the data between all scripts in the session.

If you create an instance of a COM component with ASP, the COM component inherits the security context of the ASP file that created it. When IIS destroys the component instance, it uses the security context of the ASP file in most instances. There is at least one case, however, where this does not occur. If the COM component has been given session scope using the following line of code:

Session("mysesscomp") = Server.CreateObject("MyComps.Comp1"))

and the session times out before the component is destroyed, IIS tries to destroy the component by using its own security context (LocalSystem) rather than the context of the client that accessed the ASP file. If the component has accessed secured resources that it has not released, this scenario can have side effects throughout the system.

Application Scope

Be very cautious about giving a component application scope. Some general utility components, such as a Page 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 the component itself session or page scope. Components with application scope should support both the Free and Apartment threading models (marked as ThreadingModel = Both in the registry) and should aggregate the FreeThreadedMarshaler. You should not give application scope to components you have registered with Component Services Manager.

When you create an instance of a component, you determine its scope. For example, the following script snippet creates an instance of MyComponents.Comp1 and sets its scope to Application.

Set Myinstance = Server.CreateObject("MyComponents.Comp1") 
Application("AppObject") = Myinstance 

If you are both the developer of the component and the developer of the .asp file that creates the component instance you can make sure that you are assigning scope appropriately. If, on the other hand, you are developing a component that will be used by other script writers, you will not have direct control over the scope. Script writers can place the component in applications, sessions, or pages. So, in designing the component, you should be aware of the implications that scope has on performance and threading. The following table summarizes these implications.

	Both (+Free-Threaded Marshaler)	Single	Free	Apartment
Application <OBJECT> tag objects	Access is direct. Object runs in current user security context. Accesses are not serialized.	Access through proxy via GIP. Object runs in SYSTEM context. Accesses are serialized. Cannot access ObjectContext.	Access through proxy via GIP. Object runs in SYSTEM context. Accesses are not serialized. Cannot access ObjectContext.	Access through proxy via GIP. Object runs in SYSTEM context. Accesses are serialized. Cannot access ObjectContext.
Application Properties (that is, Application ("obj") = )	Access is direct. Object runs in current user security context. Accesses are not serialized.	Access through proxy via GIP. Object runs in SYSTEM context. Accesses are serialized. Cannot access ObjectContext.	Access through proxy. Object runs in SYSTEM context. Accesses are not serialized. Cannot access ObjectContext	Assignment is not allowed; an error will be generated.
Session Objects (Created with either <OBJECT> or Server.CreateObject	Access is direct. Object runs in current user security context.	Access through proxy. Object runs in SYSTEM context. Cannot access ObjectContext. Session is locked down to a single thread.	Access through proxy. Object runs in SYSTEM context. Cannot access ObjectContext. Session is locked down to a single thread.	Access is direct. Object runs in current user security context. Session is locked down to a single thread.
Page Objects	Access is direct. Object runs in current user security context.	Access through proxy. Object runs in SYSTEM context. Cannot access ObjectContext.	Access through proxy. Object runs in SYSTEM context. Cannot access ObjectContext.	Access is direct. Object runs in current user security context.

An object instance can be created either with the Server.CreateObject command or with the <OBJECT> tag. For a majority of components, the most appropriate way for you to create an object instance is to use the <OBJECT> tag in the ASP script that requires the functionality offered by your component. Notice, however, that there are implications for components that you give application scope. If you use the Server.CreateObject method to create an instance of your component, you will not be able to assign application scope.