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
The choices for component scope are:
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 should support the Apartment threading model. Limitations of the Free and Single threading models are discussed in Single-Threaded Components and Free-Threaded Components.
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 would retrieve 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 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 (i.e. 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.
Additional information on scope is provided in Setting Object Scope.
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 any 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 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 it application scope.
Further details on threading models are provided in Selecting a Threading Model.