Table of Contents
Advertisement
DEVELOPING COLDFUSION 9 APPLICATIONS
Developing CFML Applications
User 1
Locks the Session scope.
Tries to lock the Application scope, but the Application scope is
already locked by User 2.
Neither user's request can proceed, because it is waiting for the other to complete. The two are deadlocked.
Once a deadlock occurs, neither of the users can do anything to break the deadlock, because the execution of their
requests is blocked until the deadlock is resolved by a lock time-out.
You can also cause deadlocks if you nest locks of different types. An example of this is nesting an exclusive lock inside
a read-only lock of the same scope or same name.
To avoid a deadlock, lock code sections in a well-specified order, and name the locks consistently. In particular, to lock
access to the Server, Application, and Session scopes, do so in the following order:
1
Lock the Session scope. In the
Lock the Application scope. In the
2
Lock the Server scope. In the
3
4
Unlock the Server scope.
Unlock the Application scope.
5
Unlock the Session scope.
6
Note: You can skip any pair of lock and unlock steps in the preceding list if you do not need to lock a particular scope. For
example, you can omit steps 3 and 4 if you do not need to lock the Server scope.
Copying shared variables into the Request scope
You can avoid locking some shared-scope variables multiple times during a request by doing the following:
1
Copy the shared-scope variables into the Request scope in code with an exclusive lock in the Application.cfc
method or the Application.cfm page.
onRequestStart
Use the Request scope variables on your ColdFusion pages for the duration of the request.
2
Copy the variables back to the shared scope in code with an exclusive lock in the Application.cfc
3
method on the OnRequestEnd.cfm page.
With this technique the "last request wins." For example, if two requests run simultaneously, and both requests change
the values of data that was copied from the shared scope, the data from the last request to finish is saved in the shared
scope, and the data from the previous request is not saved.
Locking application variables efficiently
The need to lock application variables can reduce server performance, because all requests that use Application scope
variables must wait on a single lock. This issue is a problem even for write-once read-many variables, because you still
must ensure that the variable exists, and possibly set the value before you can read it.
You can minimize this problem by using a technique such as the following to test for the existence of application
variables and set them if they do not exist:
Use an Application scope flag variable to indicate if the variable or variables are initialized. In a read-only lock,
1
check for the existence of the flag, and assign the result to a local variable.
Outside the
bock, test the value of the local variable
2
cflock
User 2
Locks the Application scope.
Tries to lock the Session scope, but the Session scope is already locked
by User 1.
tag, specify
cflock
scope="Session"
tag, specify
cflock
scope="Application"
tag, specify
cflock
scope="Server"
Last updated 8/5/2010
.
.
.
323
onRequestEnd
Advertisement
Table of Contents
