Table of Contents
Advertisement
DEVELOPING COLDFUSION 9 APPLICATIONS
Using Web Elements and External Objects
• Lock the code that accesses and modifies common data. In general, you do not have to lock code that modifies a
shared object's data, including writable properties or file contents, if multiple requests do not share the data (as
opposed to the object) . However, specific locking needs depend on the COM object's semantics, interface, and
implementation.
• All
tags in the application that use an Application scope lock share one lock. Therefore, code that accesses
cflock
a frequently used COM object inside an Application scope lock can become a bottleneck and reduce throughput if
many users request pages that use the object. In some cases, you can avoid some contention by placing code that
uses the COM object in named locks. Place the code that creates the object in an Application scope lock.
Note: You can also improve the performance of some COM objects by creating Java stubs, as described in
Complex COM Objects using Java
sharing the COM object, but the technique works with all COM objects. Also, generate Java stubs to correctly access
complex COM objects that do not properly make all their features available through the COM IDispatcher interface.
Therefore, to get the greatest performance increase and prevent possible problems, use both techniques.
Example 1: Using the FileSystem object
The following example uses the Microsoft FileSystem Scripting object in the Application scope. This code creates a
user-defined function that returns a structure that consists of the drive letters and free disk space for all hard drives on
the system.
<cfapplication name="comtest" clientmanagement="No" Sessionmanagement="yes">
<!--- Uncomment the following line if you must delete the object from the
Application scope during debugging. Then restore the comments.
This technique is faster than stopping and starting the ColdFusion server. --->
<!--- <cfset structdelete(Application, "fso")> --->
<!--- The getFixedDriveSpace user-defined function returns a structure with
the drive letters as keys and the drive's free space as data for all fixed
drives on a system. The function does not take any arguments --->
<cffunction name="getFixedDriveSpace" returnType="struct" output=True>
<!--- If the FileSystemObject does not exist in the Application scope,
create it. --->
<!--- For information on the use of initialization variables and locking in
this code, see "Locking application variables efficiently" in Chapter 15,
"Using Persistent Data and Locking" --->
<cfset fso_is_initialized = False>
<cflock scope="application" type="readonly" timeout="120">
<cfset fso_is_initialized = StructKeyExists(Application, "fso")>
</cflock>
<cfif not fso_is_initialized >
<cflock scope="Application" type="EXCLUSIVE" timeout="120">
<cfif NOT StructKeyExists(Application, "fso")>
<cfobject type="COM" action="create" class="Scripting.FileSystemObject"
name="Application.fso" server="\\localhost">
</cfif>
</cflock>
</cfif>
<!--- Get the drives collection and loop through it to populate the
proxies" on page 1178. Using a Java stub does not improve performance as much as
Last updated 8/5/2010
1181
"Accessing
Advertisement
Table of Contents
