It is important to understand the nesting process of CFLOCKtags while you are using them in your application. If you nest tags inconsistently, serious problems could occur that could cause your server to hang or crash. These problems are sometimes referred to as deadlocks. It is far better to avoid nesting if at all possible. When nesting your CFLOCKtags, bear in mind that many users can be attempting to access CFLOCKtags of the same name scope at the same time. For example, in one template a user could be accessing an exclusively locked block of code with the name #application. application name#, while in another template a different user could be accessing a different exclusively locked block of code by the same name. Because these two locks share the same name, the user who accesses their lock first will have an exclusive lock on it while the second user will have to wait. This is fine and how locking is intended to work.
But what if you have code being accessed by User A in one template and code being accessed by User B in a second template? In the following block of code you have a lock on the application scope followed by a nested lock on the server scope.
In the second block of code that follows, you have the opposite. If User A accesses the first template and locks the session scope at the same time that User B accesses the second template and locks the server scope, then what happens next? Neither user can con tinue with his or her block of code because in each case someone else has exclusively locked the next block of code.
Therefore, locking must be done in a consistent manner throughout your application. You should always lock the variable scopes in the same order. For example, lock session scopes first, then application, and then server scopes. But do not lock in this order: application, session, and server. At times it can be difficult to do this, so it is strongly advised to avoid nested CFLOCK tags if at all possible. Also, if you use a CFINCLUOE tag inside a CFLOCK tag, you must be especially careful about what locking occurs in the included template.
The following code provides an example of code that appears to be impossible to lock appropriately. In the CFQUERY tag, you have references to both session and application variables. You also reference a session variable in the SQL as well. You cannot very well nest a CFLOCK tag within the first CFQUERY tag, as this is not proper ColdFusion coding and will produce an error. So how do you lock these variables?
The following code provides the solution. Instead of trying to nest locks within the CFQUERY tag, which would be illegal anyway, the variable App 1; cat; on. DB is set to a non-persistent variable that does not need to be locked. Then in the CFQUERY tag, you only need to lock the session scope and reference the non-persistent variable DB, as opposed to also locking the application scope.
CFLOCK in ColdFusion 4.5
In ColdFusion 4.5, you have the option to automatically control variable locking through the ColdFusion Administrator. Using the Variable Locking page of the ColdFusion Administrator (which is discussed in Chapter 35, “ColdFu~ion Administration”),
you can define automatic behavior for servef,-application and session variables. For each of these three types of variables.you have three choices:
• No automatic checking or locking: All locking must be done with the CFLOCK tag as outlined above.
• Full checking: Any attempt to read. or write the specified type of variable outside a CFlOCK “tag Will cause an error.
• Automatic read locking: Any attempt to write the specified type of variable outside a (FLOCK tag will cause an error.
In addition, you can force all requests from the same session to occur sequentially, waiting for previous requests to finish, in order to prevent multiple requests from the same session to simultaneously access session variables. To enforce this policy, select the Single Threaded Sessions option on the Variable Locking page of the ColdFusion Administrator.
Using FLOCK in other Situations
You can also use (FLOCK in the following situations:
• When working with file updates (“File Management”)
• When invoking a CFX ( “Building Custom Tags”)