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: