An important issue when integrating your newly created server components with the ASP scripts themselves is the scope that these components will have. There are three possible levels of scope that are available in ASP. Page-level scope is where the object has a lifetime of a single page, and is only visible to that page. Session-level scope means that the object has the lifetime of an entire user session, and is visible to all pages that may be accessed during that session. Application-level scope means that the object is visible to all sessions accessing a particular application. The session and application-level scope object are created in the global.asa file, or by storing a reference to the object in an application-level or session-level variable.
A page scope object has the lifetime of a single ASP script page. The component is only visible from that single page. For components at this level, the best types of components to user are apartment-threaded and both-threaded. These components can be accessed directly, rather than by proxy. A free-threaded component is not nearly as good, since the calls must be via a proxy, and also a free threaded object cannot access the ObjectContext, which it needs to participate in the transaction. As in nearly every case, the single threaded object is bad, since all access is serialized across the application. This means that of all the users currently accessing the site, only once person can access the object at one time.
When an object is created with session scope, it will be available to all ASP script pages that are referenced during that user's session. Each session that is created in the application will also have its own instances of session-scope objects. To create a session scope object, you will add this entry to the global.asa file for the application.
<OBJECT RUNAT=Server SCOPE=Session ID=myID
PROGID="objectID"><OBJECT>
This <OBJECT> tag must be outside of any <SCRIPT> blocks in the global.asa file. The RUNAT=Server parameter indicates that this object is a server side component. The SCOPE=Session indicates that this object will have session-level scope. It will be accessible to any ASP script that is part of the application, referenced through the myID object reference.
The choice of threading models for session-level objects is a bit different. As with the page-scope object, single threaded and free threaded are bad since access to them has to be through a proxy. An apartment threaded object is OK, but when the session-scope object is being accessed, then the session is locked down. This means that no other changes to any session-level variables can be made while the object is being accessed. For a session-level object, the optimal threading model is both.
An application-scoped object is one that can be accessed by any ASP script in the application. There is also only one instance of the object for the entire application. This object is inserted in the same way as the session scoped object, using the <OBJECT> tag. There is one change that needs to be made for an application-scoped object:
<OBJECT RUNAT=Server SCOPE=Application ID=myID
PROGID="objectID"><OBJECT>
By changing the SCOPE parameter to Application, there will be one instance of this object available to all users of the application. This presents some interesting challenges when selecting a threading model for an application-scoped component. If this component is marked as using Apartment threading, then all access to this object will be serialized. That means that only one user out of all users accessing the site can use the object at any one time. All of the other users will have to wait until it is their turn. If a system is going to have very infrequent concurrent use, such as in an intranet that serves 25 people, maybe this is OK. If you are trying to run a production site that has thousands of simultaneous users, using an apartment threaded component would quickly bring the site to a grinding halt.
The best component to use is one that is marked both. A both-threaded component will be able to directly accessed through function calls, rather than having to use a slower proxy call. Most of all, the access to the component is not serialized, meaning that multiple users can access the component at one time. This will greatly enhance the scalability of the application over the user of apartment-model application scope components.