ColdFusion MX: From Static to Dynamic in 10 Steps

By Barry Moore

Using <CFLOCK>

The earlier section "The Session Scope" mentioned that it's a good idea to lock shared memory scope variables. In this section, we will look at just what this means, why it should be done, and how we go about doing it.

As previously mentioned, shared memory variablesnamely those in the Session, Application, and Server scopeslive in memory on the server. They are called shared memory scope variables because several pages can, and usually do, share access to these variables at the same time. For example, we might have several user templates trying to read or set the value of an Application scope variable all at the same time. Because ColdFusion Server uses multithreading (the capability to respond to multiple requests at one time) to handle user requests (which is usually a good thing), ColdFusion Server is quite happy to let this happen.

The problem is that with many users potentially changing the value of a variable at the same time, server memory can become corrupt. In a practical sense, this means you could end up with the wrong information in your shopping cart, or this memory corruption could crash the server. To prevent memory corruption, we lock access to any shared memory scope variables whenever we set or read their values. This locking has the effect of stopping multiple threads from accessing these variables at once. In a practical sense, it makes everyone line up and access these variables one at a time in a nice, orderly fashion.

As we've already seen, we lock access to these variables using the <CFLOCK> tag. The attributes for the <CFLOCK> tag are listed in Table 8.5.

As you can see, there are two types of lock: Exclusive and ReadOnly. An Exclusive lock will prevent more than one request from entering the area of code inside the <CFLOCK> tags. This means that the locked code can only be executed one request at a time. Any other requests will line up and wait until the Exclusive lock has finished and released the lock before stepping in to access the code. Exclusive locks are generally used when setting or changing the value of a shared scope variable.

A ReadOnly lock will let multiple requests in to the locked code only if they are reading the value and not changing it. A request won't be able to write to or change a variable while another request is reading it. ReadOnly locks are usually used when you just want to retrieve the value of a shared scope variable and not actually change it.

The SCOPE attribute is used to indicate the scope of the variable you are attempting to access. There is also a NAME attribute that is used for specialist locks. The use of these two attributes is mutually exclusive; you can only use one or the other. Most of the time, the SCOPE attribute will suffice.

The required TIMEOUT attribute indicates how long we should wait to obtain a lock on the variable we are trying to use. Ten seconds is a pretty standard setting. If our request is queued up behind several other requests and cannot obtain a lock in the time specified, it will generate an error message unless the THROWONTIMEOUT attribute is set to NO, in which case processing will continue.

For more detailed information on locking, see the Macromedia ColdFusion documentation available at www.macromedia.com/support/coldfusion/documentation.html and the Macromedia knowledge base TechNote 20370, "ColdFusion Locking Best Practices," at www.macromedia.com/v1/Handlers/index.cfm?ID=20370.