User Guide

366 Chapter 15: Using Persistent Data and Locking
Considering lock granularity
When you design your locking strategy, consider whether you should have multiple locks
containing small amounts of code or few locks with larger blocks of code. There is no simple rule
for making such a decision, and you might do performance testing with different options to help
make your decision. However, you must consider the following issues:
• If the code block is larger, ColdFusion will spend more time inside the block, which might
increase the number of times an application waits for the lock to released.
• Each lock requires processor time. The more locks you have, the more processor time is spent
on locking code.
Nesting locks and avoiding deadlocks
Inconsistent nesting of
cflock tags and inconsistent naming of locks can cause deadlocks
(blocked code). If you are nesting locks, you must consistently nest
cflock tags in the same order
and use consistent lock scopes (or names).
A deadlock is a state in which no request can execute the locked section of the page. All requests to
the protected section of the page are blocked until there is a time-out. The following table shows
one scenario that would cause a deadlock:
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.
In order to avoid a deadlock, lock code sections in a well-specified order, and name the locks
consistently. In particular, if you need to lock access to the Server, Application, and Session
scopes, you must do so in the following 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: 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.
User 1 User 2
Locks the Session scope. Locks the Application scope.
Tries to lock the Application scope, but the
Application scope is already locked by User 2.
Tries to lock the Session scope, but the Session
scope is already locked by User 1.