Before you read this article look at your calendar. That's right: it's December already! Where did 2001 go so fast?

The first year of the new millennium was definitely not one of those "ho-hum-nothing-much-happened" years. It was a busy, exciting, turbulent, and tragic year for most of us. Here's hoping that 2002 will be just as busy and exciting but without so much turbulence and tragedy. Happy holidays to you and your loved ones!

Partial Retraction
I don't have any questions to address this month, but I'd like to offer a slight retraction (actually, just a word of caution) of last month's article in which I talked about sparing yourself some of the hassles of locking every reference to shared variables (those in the Server, Application, or Session scopes) by copying them into and out of the Request scope.

This subject is covered in the Advanced ColdFusion class and is offered as an acceptable and even recommended alternative (I hesitate to use the phrase "best practice"). However, after talking with several other trainers and developers and doing some actual testing, I'd like to caution you about using this method of handling shared variables and suggest that you not use it in most cases.

While it certainly makes writing applications easier by not having to lock every single reference to a shared variable, and while it may make logical sense that it would improve your application's performance to have only two locks (one in Applic-ation.cfm and one in OnRequestEnd .cfm) for each page rather than opening and closing many locks, this turns out not to be the case. While many applications will perform just fine by copying shared variables into the Request scope, any application that stores a significant amount of data in those scopes will see a dramatic performance loss.

The bottleneck actually comes while making a copy of the data using the Duplicate function. The larger the amount of data, the longer it will take to copy it to/from the Request scope. Checking or creating locks doesn't take a considerable amount of time nor does it create significant amounts of server load. Copying data from one scope to another for every single user on every single page, however, will create performance problems as the data grows.

Another potentially problematic issue with copying data out of shared variables into the Request scope (which is a local variable) is memory management. Suppose you have a query result stored in the Application scope and you're using the duplicate function to copy it to the Request scope for each user. Well, you've just made a separate copy of that query for each user on your site. If it was a large query and you have many users, you could potentially run out of RAM on your server.

With these problems in mind, I would bet the next revision of the Advance ColdFusion class will not include this method as an example of how to use the Request scope to avoid having to lock every reference to shared variables.

Therefore, if your application doesn't get a large amount of traffic and only stores simple data elements (Session.LoggedIn = 1, etc.) in the shared variable scopes, you may still want to consider copying the data to the Request scope as suggested last month. However, if you're storing queries, arrays, lists, or other structures in these scopes, you'll be better off writing explicit locks around each variable reference.

I look forward to hearing from you in 2002! Please send your questions about ColdFusion (CFML, CF Server, or CF Studio) to AskCFDJ@sys-con.com. And please visit our archive site at www.NetsiteDynamics.com/AskCFDJ.