Pete Freitag Pete Freitag

The client variables debacle

Updated on November 14, 2023
By Pete Freitag

Nathan Strutz recently said that client variables are no good to use. From reading his entire post, he isn't saying that the concept is flawed, just the current implementation. He even suggests how they may could be improved. I blogged about the overhead caused by client variables back in 2003, the problem was that even if you check disable global client variable updates ColdFusion was still hitting the DB server on every page request. This was in ColdFusion 6.1, I haven't retested for 7.0 yet.

Nathan also points out that All options are server-wide, it would be cool to have different options for each application. Don't forget that there are some options for client variables in the cfapplication tag such as the clientmanagement attribute that lets you turn it on and off, clientstorage attribute lets you specify which datasource to use (must be enabled for client storage in admin first), or registry, or cookie, and setclientcookies can be enabled or disabled on an application basis. See the docs for the cfapplication tag. So you can create a database for each application to use, then for each db you can set the purge time, and disable global client variable updates. Am I missing something here?

Nathan also suggests that we need more options for client storage, how about using files or a proprietary client variable server (aka state server). I agree more options are better, but I'm curious to know what advantages a proprietary client variable server would have, why not just fix how CF uses a database server?

If your going to use them, decouple them

I applaud Nathan for bringing this up again, he raises some good points. While I wouldn't go as far to say we should never use them, I would be take care as to how you use them, and I highly recommend de-coupling them from your application logic. So create a CFC that uses client variables inside to manage state, and if you want to change to session, or your own db implementation you can change how it all works without effecting your entire code base.

client variables cfml coldfusion

The client variables debacle was first published on July 08, 2005.

If you like reading about client, variables, cfml, or coldfusion then you might also like:

FuseGuard Web App Firewall for ColdFusion

The FuseGuard Web Application Firewall for ColdFusion & CFML is a high performance, customizable engine that blocks various attacks against your ColdFusion applications.

The weekly newsletter for the CFML Community


Thanks for the post. You're right, I was a little strong on the 'All options' thing. Another thought I had would be per variable options, keep this variable in memory or retrieve it from the DB for each request, etc. Perhaps too fine-grained for most people, but it would be really helpful a lot of the time.
by Nathan Strutz on 07/08/2005 at 2:50:37 PM UTC
I also think that there is a lack of clarity over Nathan's mention of "all options are server-wide", and as you point out there are several application-specific options already there.

ColdFusion 6.1 has a client variable hotfix rollup which actually contains several fixes including the one for hitting the database even if "Disable Global Updates" switch was checked.

From the technote at the following bug fix is documented: "59915 - Client variables were incorrectly updated even when they were not changed, and Disable global client variable updates was checked in the ColdFusion Administrator"

These fixes are also in CFMX 7 by default.
by Steven Erat on 07/08/2005 at 2:53:22 PM UTC
Steven, thanks for clarifying the status of the disable global updates bug.

Nathan - the per variable settings would be cool, but could perhaps create more overhead and performance issues?
by Pete Freitag on 07/08/2005 at 3:05:04 PM UTC
Do you have any examples of how to de-couple the session management with cfc's? I am a little confused on how this all might work. I understand why this should be done, but I am just a unsure how it is done.
by Jason on 07/18/2005 at 11:59:48 PM UTC

Basically the idea would be, if you normally refer to a variable as session.userid, instead create a cfc with a method getUserID(), then cfreturn session.userid.

This allows you to change this to client, cookie, etc at another time.
by Pete Freitag on 07/19/2005 at 4:31:20 PM UTC
What about using something like memcached as a storage mechanism or replacement for client variables ? There's a java api for it even.
by Hallow on 11/03/2005 at 12:38:25 PM UTC