The scope of an object determines which scripts can use an object. By default, when you create an object instance, the object has page scope. Any script command in the same ASP page can use a page-scope object; the object is released when the ASP page is sent back to the client. The recommended scope for most objects is page scope. You can change the scope of an object, however, to make it accessible from scripts on other pages. This topic explains how to work with page scope objects and how to change the scope of objects.
An object that you create by using Server.CreateObject on an ASP page exists for the duration of that page. The object is accessible to any script commands on that page, and it is released when ASP has finished processing the page. Thus an object has the scope, or lifetime, of a page.
If you have programmed in Visual Basic or VBScript, note that you cannot release an object before ASP has finished processing the page. For example, the following VBScript statement is often used to release an object by assigning the value Nothing to the object variable:
Set myObj = Nothing
If you include this statement in an ASP page, any attempt to use myObj will return an error code, as expected. Internally, however, ASP retains a reference to your object, even after you have released it. While you cannot use the object in your script, the object's resources are not released until ASP has finished processing the page. Similarly, if you release an object by creating a different object instance and assigning it to an object variable you have already used, ASP retains a reference to the original object instance. While creating many objects may not cause a problem for most scripts, it can cause problems if the objects use shared resources, such as database connections.
Because objects have page scope, do not depend on objects being released manually. For example, the following loop creates 1001 Connection objects, which would open most of the connections on even a large SQL server:
<%
For I = 0 to 1000
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "connection string"
Next
%>
In general, you should avoid creating objects inside a loop. If you must create objects in a loop, you should manually release the resources used by an object. The previous example works if the Connection object is created only once, and the physical connection to the data source is opened and closed during each loop:
<%
Set Conn = Server.CreateObject("ADODB.Connection")
For I = 0 to 1000
Conn.Open "connection string"
Conn.Close
Next
%>
A session-scope object is created for each new session in an application and released when the session ends; thus, there is one object per active session. Session scope is used for objects that are called from multiple scripts but affect one user session. You should give objects session scope only when needed. If you do use session scope, you must know the threading model of the component that provides the object because the threading model affects the performance and security context of the object. For more information, see “Advanced Information: Performance Issues” in this topic.
To give an object session scope, store the object in the ASP Session built-in object. You can use either the <OBJECT> tag in a Global.asa file or the Server.CreateObject method on an ASP page to create a session scope object instance.
In the Global.asa file, you can use the <OBJECT> tag, extended with RUNAT attribute (which must be set to Server) and the SCOPE attribute (which must be set to Session). The following example creates a session-scope instance of the Ad Rotator object:
<OBJECT RUNAT=Server SCOPE=Session ID=MyAd PROGID="MSWC.Adrotator"> </OBJECT>
Once you have stored the object in the Session object, you can access the object from any page in the application. The following statement uses the object instance created by the <OBJECT> tag in the previous example:
<%= MyAd.GetAdvertisement("addata.txt") %>
On an ASP page, you can also use the Server.CreateObject method to store an object in the Session built-in object. The following example stores an instance of the Ad Rotator object in the Session object.
<% Set Session("MyAd") = Server.CreateObject("MSWC.Adrotator") %>
To display an ad, you first retrieve the instance of the Ad Rotator object stored in the Session object, and then call the method to display an ad:
<% Set MyAd = Session("MyAd") %>
<%= MyAd.GetAdvertisement("addata.txt") %>
ASP does not instantiate an object that you declare with the <OBJECT> tag until that object is referenced by a script command from an .asp file. The Server.CreateObject method instantiates the object immediately. Thus, the <OBJECT> tag offers better performance than the Server.CreateObject method for session-scope objects.
An application-scope object is a single instance of an object that is created when the application starts. This object is shared by all client requests. Only rarely should you give an object application scope. Some utility objects, such as counters, might require application scope, but generally you should use the alternatives proposed in the following section. In addition, the threading model affects the performance and security context of the object (see “Advanced Information: Performance Issues” in this topic).
To give an object application scope, store the object in the ASP Application built-in object. You can use either the <OBJECT> tag in a Global.asa file or the Server.CreateObject method on an ASP page to create an application scope object instance.
In the Global.asa file, you can use the <OBJECT> tag, extended with RUNAT attribute (which must be set to Server) and the SCOPE attribute (which must be set to Application). On an ASP page, you can use Server.CreateObject to store an object instance in the Application built-in object. For examples of using the <OBJECT> tag and Server.CreateObject, see the previous section “Giving an Object Session Scope.”
You should give objects session or application scope only when needed. Because these objects linger until the session or application has finished running, they consume resources, such as memory or database connections, that might be better used in other ways. In addition, the threading model of a component affects the performance of objects you create from it, especially objects with session or application scope.
In many cases, a better solution than creating application or session scope objects is to use session or application scope variables that pass information to objects created at the page level. For example, you should not give an ADO Connection object session or application scope because the connection it creates remains open for a long time and because your script no longer takes advantage of ODBC connection pooling. You can, however, store an ODBC connection string in the Session or Application built-in object and access the string from a Connection object instance that you create on a page. In this way, you store frequently used information in the session or application name space but you create the object that uses the information only when needed.
You can create your own JScript object by defining a constructor function that creates and initializes the properties and methods of the new object. The object instance is created when your script uses the new operator to invoke the constructor. User-defined objects are supported in ASP scripts and work well when they have page scope. Giving a user-defined JScript object application or session scope, however, might affect the functionality of the object. In particular, if an object has session or application scope, scripts on other pages can access the object's properties but cannot call its methods.
The threading model of a component may affect the performance of your Web site. Generally, objects that are marked Both are the recommended objects to use in all ASP scripts, particularly in the Session and Application objects. Single-threaded objects are not recommended.
Because you may not always have control over the threading model of the objects you use, the following guidelines will help you get the best performance: