ASP Lecture Series (9) Setting Object Scope
Author：Eve Cole
Update Time：2009-05-30 19:59:07
The scope of an object determines which scripts can use the object. By default, when you create an object instance, the object has page scope. Any script command within the same ASP page can use the page-scoped object; the object is released when the ASP page is sent back to the client. For most objects, the recommended scope is the page scope. You can change the scope of an object so that it can be used by scripts on other pages. This topic explains how to use page-scoped objects and how to change an object's scope.
Using page-scope objects Objects created with Server.CreateObject on an ASP page exist for the lifetime of the page. The object is accessible to any script commands for the page and is released when ASP has finished processing the page. Therefore, the object has the scope or lifetime of the page.
When programming with Visual Basic or VBScript, be careful not to release the object until ASP has finished processing the page. For example, the following statement is often used to free an object by assigning the object variable a value of Nothing:
Set myObj = Nothing
If you include this statement in an ASP page, any attempt to use myObj will return an expected error code. But internally, ASP still retains a reference to the object even after it is released. When you cannot use an object in a script, the object's resources are not released until ASP has finished processing the page. Likewise, if you release the object by creating another object instance and assigning it to an object variable that has already been used, ASP retains a reference to the original object instance. For most scripts, creating multiple objects may not cause problems, but if the objects use shared resources, such as database connections, problems may arise.
Since objects have page scope, do not rely on manually freeing objects. For example, the following loop creates 1001 Connection objects, which will be able to open most connections even to a large SQL server:
<%
For I = 0 to 1000
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "connection string"
Next
%>
In general, you should try to avoid creating objects inside a loop. If unavoidable, you should manually release resources used by the object. If the Connection object is created only once, and the physical connection to the data resource is opened and closed in each loop, then the above example will work normally:
<%
Set Conn = Server.CreateObject("ADODB.Connection")
For I = 0 to 1000
Conn.Open "connection string"
Conn.Close
Next
%>
Giving objects session scope In an application, a session-scope object is created for each new session and is released after the session ends. Therefore, there is one object for each active session. Session scope is used for objects that are called from multiple scripts, but only affect one user session. You can give an object session scope only when needed. If you do need to use session scope, you must understand the threading model of the component that provides the object, because it affects the performance and security environment 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 either use the <OBJECT> tag in the Global.asa file or use the Server.CreateObject method on the ASP page to create a session-scoped object. Domain object instance.
In the Global.asa file, you can use the ;OBJECT> tag that extends the RUNAT attribute (must be set to Sever) and the SCOPE attribute (must be set to Session). The following example creates a session-scoped instance of the Ad Rotator object:
<OBJECT RUNAT=Server SCOPE=Session ID=MyAd PROGID="MSWC.Adrotator">
</OBJECT>
Once you store an 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 objects 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 should first obtain an instance of the Ad Rotator object stored in the Session object, and then call a method to display the object:
<% Set MyAd = Session("MyAd") %>
<%= MyAd.GetAdvertisement("addata.txt") %>
ASP does not create an instance of an object declared with the <OBJECT> tag until it is referenced by a script command in an .asp file. The Server.CreateObject method immediately creates an instance of the object. Therefore, it is better to use the <OBJECT> tag than the Server.CreateObject property for session-scoped objects.
Give an object application scope
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 in rare cases do you need to give an object application scope. Some utility objects, such as counters, etc., may require application scope. But in general, you can use the alternatives suggested in the next section. Additionally, the threading model affects the performance and object safety environment (see "Advanced information: Performance issues" in this topic).
To give an object application scope and store it in the ASP Application built-in object, you can either use the <OBJECT> tag in the Global.asa file or create the application scope using the Server.CreateObject method on the ASP page object instance.
In the Global.asa file, you can use the ;OBJECT> tag that extends the RUNAT attribute (must be set to Sever) and the SCOPE attribute (must be set to Session). In ASP pages, you can use Server.CreateObject to store object instances in the Application built-in object. For an example using the <OBJECT> tag and Server.CreateObject, see the previous section, "Giving session scope to an object."
Alternatives to Session and Application Scope Give an object session or application scope only when required. Because these objects remain until the session or application ends. They consume resources such as memory or database connections that might be more useful in other ways. Additionally, a component's threading model affects the performance of the objects you create from it, especially those that have session or application scope.
In many cases, a better approach than creating application- or session-scoped objects is to use session- or application-scoped variables to pass information to objects created at the page level. For example, do not give the ADO Connection object session or application scope because the connection it creates will remain open for a long period of time while the script no longer uses ODBC connection sharing. However, you can store the ODBC connection string in the Session or Application built-in object and obtain the string from the created Connection object instance on the web page. This way you can store frequently used information in a session or application namespace, but only create objects with that information when needed.
User-defined JScript objects You can create your own JScript objects by defining a constructor that creates and initializes the properties and methods of the new object. When a script calls the constructor using the new operator, an instance of the object is created. ASP script supports user-defined objects, which function properly when they have page scope. However, if a user-defined JScript object is given application or session scope, it may affect the functionality of the object. In particular, if an object has session or application scope, scripts from other pages can obtain the object's properties but cannot call its methods.
Advanced information: Performance issues The threading model of the component may affect the performance of the Web site. Generally speaking, objects marked with Both are recommended for use in all ASP scripts, especially in the Session and Application objects. Single-threaded objects are deprecated.
Because you may not always control the threading model of the objects you use, the following guidelines can help you achieve optimal performance:
Page scope object. Objects marked Both or Apartment will give you the best performance.
Application scope object. In general, you should avoid placing objects in the Application object. If you do need to use application-scope objects, you will get the best performance from a Both-tagged object combined with FreeThreadedMarshaler. You can either use the <OBJECT> tag or use the Server.CreateObject method to store objects with the Single, Free, or Both tags in the Application object. You must use the <OBJECT> tag with apartment-threaded objects.
Session scope object. Objects marked with Both will give you the best performance. Using single-threaded or apartment-threaded objects will cause the Web server to lock the session on one thread. Free-threaded objects do not lock the session, but do not run as fast. In the Session object, you can use the <OBJECT> tag or the Server.CreateObject method to store objects.
If you have installed the SDK documentation, you will get detailed information about the threading model and the component performance it implies. (SDK documentation is not available on Windows 95 and later.)
