User Guide

cflock 223
These examples show situations that cause deadlocks:
The following deadlock could occur if you tried to nest an exclusive lock inside a read lock:
The following code shows this scenario:
<cflock timeout = "60" scope = "SESSION" type = "readOnly">
...............
<cflock timeout = "60" scope = "SESSION" type = "Exclusive">
.........
</cflock>
</cflock>
To avoid a deadlock, everyone who nests locks must do so in a well-specified order and name the
locks consistently. If you must lock access to the Server, Application, and Session scopes, you must
do so in this order:
1 Lock the Session scope. In the cflock tag, specify scope = "session".
2 Lock the Application scope. In the cflock tag, specify scope = "Application".
3 Lock the Server scope. In the cflock tag, specify scope = "server".
4 Unlock the Server scope.
5 Unlock the Application scope.
6 Unlock the Session scope.
Note: If you do not have to lock a scope, you can skip any pair of these lock/unlock steps. For
example, if you do not have to lock the Server scope, you can skip Steps 3 and 4. Similar rules apply
for named locks.
For more information, see the following:
• Chapter 15, “Using Persistent Data and Locking,” in Developing ColdFusion MX Applications
• Article #20370, ColdFusion Locking Best Practices, on the Macromedia website at
www.macromedia.com/support/service/
Example
<!--- This example shows how cflock can guarantee consistency of data updates
to variables in the Application, Server, and Session scopes. --->
Example deadlock with two users
User 1 User 2
Locks the session scope. Locks the Application scope.
Deadlock: Tries to lock the Application scope,
but it is already locked by User 2.
Deadlock: Tries to lock the Session scope, but it
is already locked by User 1.
Example deadlock with one user
User 1
Locks the Session scope with a read lock.
Attempts to lock the Session scope with an exclusive lock.
Deadlock: Cannot lock the Session scope with an exclusive lock because the scope is already
locked for reading.