ColdFusion MX: Best practices for locking shared scope variables

Macromedia ColdFusion MX offers several enhancements in the way shared scope variables are managed internally in memory. This TechNote details updated best practices for locking shared scope variables.

Best practices for locking shared scope variables remain fundamentally unchanged from previous recommendations, however, there are subtle differences in best practices for locking in ColdFusion MX, due to enhancements in the underlying architecture. In previous versions of ColdFusion, if you did not lock shared scope variables, it caused corrupt blocks of application memory, resulting in server instability or crashes. This is no longer the case with ColdFusion MX and higher. The Java data structures that are used to store shared scope variables are designed to be thread safe. With ColdFusion MX, if you do not lock shared scope variables, it will no longer cause server instability or crashes. Please note, however, there are other potential pitfalls that you may encounter if you do not lock your shared scope variables, as documented below.

The cflock tag has not changed in ColdFusion MX, and the recommendation to use this tag to lock shared scope variables remains the same. Although it is no longer necessary to worry about your server crashing, it is still important to avoidrace conditions in your application code.Race condition is a term that is not specific to ColdFusion programming, but refers to a common issue that needs to be taken into consideration when programming in any multithreaded environment. Simply put, a race condition occurs anytime two threads (in this case, page requests) try to write to the same data at the same time. The following is an example:

If two requests to the page that includes this code are made at the same time, it is possible that in the time between the right-hand side read of the session.cartTotal, and the left-hand-side write for the second page request to execute and modify session.cartTotal. The result is corrupt data. Developers should always ensure that they mitigate or prevent corrupt data when writing application code. Using the cflock tag in this case will prevent the race condition:

This example uses cflock with the scope attribute as previously specified in the Best Practices document. It is now acceptable to use the cflock tag with thename attribute instead:

Both examples are equally effective in preventing the race condition. When using the cflock tag with thename attribute, it is important to ensure that you always use the same value when reading and writing to the same shared scope variable. It is often simpler to continue using thescope attribute to avoid making mistakes in your naming, which could result in a race condition. Using thename attribute is useful when you want a high level of granularity in your locking.

Note that you should never ever use different names for locks on code that accesses the same data. For more information, read the documentation chapters, "Using Persistent Data and Locking" and ""Locking code with cflock" in Developing ColdFusion MX Applications with CFML," both part of the ColdFusion MX documentation.

• ColdFusion Locking Best Practices
• ColdFusion MX LiveDocs (Online ColdFusion MX documentation)