Using the Application Scope to improve COM performance

The Java call to create a new COM object instance can take substantial time. As a result, creating COM objects in ColdFusion MX can be substantially slower than in ColdFusion 5. For example, on some systems, creating a Microsoft Word application object could take over one second using ColdFusion MX, while on the same system, the overhead of creating the Word object might be about 200 milliseconds.

Therefore, in ColdFusion MX, you can improve COM performance substantially if you can share a single COM object in the Application scope among all pages.

Use this technique only if the following are true:

The COM object does not need to be created for every request or session. (For session-specific objects, consider using the technique described in this section with the Session scope in place of the Application scope.)
The COM object is designed for sharing.

Because the object can be accessed from multiple pages and sessions simultaneously, you must also consider the following threading and locking issues:

For best performance, the object should be multithreaded. Otherwise, only one request can access the object at a time.
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 the data (as opposed to the object) is not shared by multiple requests. However, specific locking needs depend on the COM object's semantics, interface, and implementation.
All cflock tags in the application that use an Application scope lock share one lock. Therefore, code that accesses 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. You might be able to avoid some contention by putting code that uses the COM object in named locks; you must put 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 Accessing Complex COM Objects using Java proxies. Using a Java stub does not improve performance as much as sharing the COM object, but the technique works with all COM objects. Also, you must 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.

This section includes the following examples:

View comments in LiveDocs