The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Client Variables: The Final Nail

posted under category: ColdFusion on June 16, 2011 at 1:00 am by MrNate

I have been working on a project for a while now. Really, for about 6 years, but only in the past month did I get everything written down. I call it The Final Nail for ColdFusion Client Variables. It's an eight page (printed) look at ColdFusion's client variables scope, and all the problems that come with it.

If you are looking for a reason to go through your ColdFusion app and replace you client vars, print off a copy and take it to your manager.

If you use client variables and think everything is fine, I suggest you read it and find out exactly what you have gotten yourself into.

If you are in love with client variables, well, I'm so sorry. I'd hoped we could be friends. I really am a nice guy, but we have to draw the line somewhere.

I had a ton of help, so thanks to everyone who pitched in (whether you know it or not)!

Last, this is the standing comments post for the article, so if you want to talk about it, this is the place. You can also get me on twitter, @nathanstrutz if you have any quick comments.

That's all; enjoy The Final Nail for ColdFusion Client Variables!

Too old to comment!
On Jun 16, 2011 at 1:00 AM Dawesi ( or or said:
I'm still waiting for the final nail? Is it coming, no it isn't, maybe because your article isn't about client scope, but about coding standards?!

Like every programmer rant ever, the response is 'Don't like it, then don't use it'. There are plenty of legitimate reasons to use them (personally I generally turn them off). and to be honest, again, your downsides are developer/admin configuration mistakes, not technology mistakes.

Not unlike the evaluate() debate (which was always a fundimental farse), unless you know _EVERY_ senario ever used, you'll end up making a ass out of yourself when someone presents a perfectly good use case that makes better sense. aka "No-one knows everything" and no issue has ONLY two sides in programming.

'Lazy' and 'efficient' are easily interchangable in the programming world depending on the 'perspective'.

"Client variables illustrate why people hate ColdFusion."

hahahahahahahahahaha, hate... too funny, I hear that all the time... or never! Do they work, yes. Do they work well if used correctly "yes".

"CF gets a bad rap for having a lot of terrible applications and spaghetti code. "

and more often a good wrap for the apps that are coded well??! You've obviously never participated in other programming communities. I'm yet to find a language that isn't branded this way that's been around for 2 minutes, Ruby is the latest language to be bagged for this. also.. used wordpress or joomla lately??!

That said, your article could easily be separated into two issues, and probably should be.

Just for the stir... Client Variables RULE!!

On Jun 17, 2011 at 1:00 AM Tim Cunningham (timcunningham71 who loves said:
Keep in mind, back in the day when Allaire was working on client variables, many people didn't have a way or means to connect a database to their website, so Client Variables filled a need at time. It allowed a cheap method to persist your data.

That being said it is shameful that we have let this albatross hang about so long. At the very least, Client Variables should be defaulted to "OFF", if a person really needs them they can turn them on.

On Jun 18, 2011 at 1:00 AM Sean Corfield ( said:
I'm with you on this Nathan. The first thing I do on any new server is turn client variables off. It's a ridiculous implementation and I still see so many CF devs argue for client variables over session variables "because of failover" or "because of load balancing". As you say, it's a lazy choice that just makes CFers (and CF itself) look bad.

On Jun 20, 2011 at 1:00 AM Luc (luc.reid who can't believe it's not said:
Thanks for the rant; helpful stuff.

For the sake of anyone who may not know where to find the setting, the global client variable updates flag can be turned off in CF Administrator by clicking a data store for client variables under Server Settings > Client Variables and then checking the "Disable global client variable updates" box.

On Oct 11, 2012 at 1:00 AM Adam Cameron ( said:
Nathan, you make a number of very good points here, and I've summarised what might be Adobe's action points here:

* prevent this: "At the moment this central client storage database becomes unavailable, every application in your cluster using the database will also become unavailable". Only when client variables are actually used should this matter

* "Global Request Updates on. It's on by default". Change to off by default.

* '"Purge data for clients that remain unvisited for x days" is set to 90. This means, ColdFusion will remove client variables that have not been accessed only after 90 days'. Reduce it to something similar to session timeout by default.

* "Also, this setting is global to the server." Make it app specific.

* "One last note on purging, the timeout span is in days only". Make it a timespan.

* "One deeper problem with global updates is that the changes go straight into the database on every request, and that the entire client variable scope for the user is selected back to the request on every request again."

* "I also still hear about the client variables database tables not purging, ". This is VERY common. Fix it.

* "Why, then, is it that this serialization is never done automatically for us?".

* "What I saw was a SQL statement for fetching client variables being prepared, executed, and unprepared, then again, prepare, execute, unprepare."

I've noted where there are existing bug references, but a lot of them have not been raised with Adobe. Do you not think it might be a good idea to tell *them* about these things, as well as us? If you post back the bug refs, we can all vote for them (and make sure they get followed up for CF11...)

Cheers for taking the time to write such a thorough article!


On Oct 11, 2012 at 1:00 AM Adam Cameron ( said:
Argh. Forgot to "subscribe".


On Nov 18, 2013 at 1:00 AM Brian FitzGerald (bmfitzgerald3 who dances with said:
Hey Nathan, thanks for the thoughtful bashing of client variables :) While I was aware of many of the drawbacks, I enjoyed learning some additional details as well as the history behind the technology.

I am in the process of researching some alternative approaches in order to persist complex data in a clustered environment and I'd like to learn more about the options we have as CF developers to solve the issues.

Do you have any recommended practices or resources that speak in any detail about things like sticky sessions, or other techniques to maintain the integrity of the session and application scopes across multiple boxes in a cluster? Thanks for your insight.

On Nov 18, 2013 at 1:00 AM Nathan Strutz ( said:
I should probably have a follow-up to my rant that is constructive instead of destructive. I touch on it in the article, but I'll need to summarize. For you, today, here's a quick overview.

1- Sticky sessions are your best bet. Your servers are probably hardware clustered with something like an F5 switch, there is probably a switch in the config to simply enable this. It keeps users on the same server until that server fails.

2- Use cookies for safe data. Be aware of client data mainpulation, you wouldn't want to put a User ID in there because a user could change it.

3- Use CFCache, key off existing session ID cookies. Servers can share a clustered cache, see Rob's caching architecture, and look around because he has a LOT of great info on it. CFCache serializes automatically, runs faster and removes a lot of the problems that client variables have.

On Jan 9, 2014 at 1:00 AM ACB ( who would have preferred an address at said:
This article also assumes developers have absolute control over their servers. In our case, we use client variables over sessions because of clustering/fail-over problems. But we have zero control over our servers. They are controlled by policies far above our heads. So "sticky sessions" do not work for us. I would love to know what your solution is in our case.
Too old to comment!