Session and Client Variable Management

May 21, 2001

There was an interesting exchange recently from the CF-Community list on session variables:

Michael Smith, TeraTech, Inc.: "If you don't have any structures or queries in the session vars, it would be best to convert to client vars (stored in database rather than registry) as these don't need locks at all ..."

In response, Kristin Aileen Motlagh [author of Mastering ColdFusion 4.5] commented, "Sessions and client management have two different purposes. Session management is meant for a short period of time, and does not need data source setup. Client variables are meant to persist over multiple sessions. It is funny because when session variables first came out ... everyone was saying ... stop using client variables!! But I think you need to judge based upon your purpose and application what is best. Do you use them interchangeably?"

Michael Smith responded, "... I know the default timeout for client vars is usually set to be 10 days or something long, but as I understand it, they do exactly the same as session variables in maintain info across page requests for one user. For me, the 'no locking required' benefit outweighs the having to set up a database to store them in (which the CF Admin does for you when you create a client var datasource).

"To deal with the long time out, I usually store the date/time of the last page access in a client var and if the difference between it and current time gets greater than the timeout I want then I CFLOCATION the page to the login screen."

Bob Silverberg added: "I've spent a lot of time agonizing over the client vs. session variables debate (well, not really agonizing, more like thinking about it while I'm in the shower), and here are my thoughts.

"Unless I need the variables to persist from session to session, or I need to implement in a clustered environment, I always use session variables. Why, you ask? This is based on one of my prime objectives, which is to minimize calls to the database. Why continually read the same value from a database, when you can store it in RAM which is much, much faster? I believe that you should only go to the database for data that you either don't already have, or that is stale. You'll hear many people extol the virtues of query caching, but I'll bet that many of those same people use client variables extensively.

"I didn't realize until recently the sheer amount of database activity that client variables generate. Did you know that, if you have client variables turned on, CF will generate two select statements for every single page hit? And, if you don't turn off global client variable updates (which are turned on by default), you also generate an INSERT/UPDATE statement for every page, even if you aren't accessing any client variables on that page. To me that's a whole lot of unnecessary database calls.

"The one big argument in favour of client variables, IMHO, is that you cannot use session variables in a clustered environment. So, if you think that you might have to run in a clustered environment in the future, you'll probably save yourself a lot of time by using client variables from the get-go.

"I think that the 'no locking required' argument should be questioned - not dismissed, but questioned. If the argument is based on the desire to avoid writing a few (or even many) extra lines of code, I think it is questionable. Writing code is what we do, and if the best solution requires 10% more code, well, so be it. If the argument is based on performance, I'd be very surprised if the cost of the locks exceeds the cost of all of those database calls.

"I'd be interested in hearing from anyone who has any performance measures of locking vs. client variable db access, as well as other arguments for/against session/client variables."

Michael Smith responded again: "On a high volume site, you might get better performance from session rather than client variables, but on most CF sites the important things are how fast it can be coded and if the site is stable. A lot of people's code I have seen does not lock session variables correctly. And this is the cause of much CF instability and server crashes. So on this point alone, I would recommend the average CFer to use client variables over session. For me a best practice is what the average coder can do correctly 100% of the time, rather than what is the fastest possible code every time. :-)

"For an example of session locking craziness - some folks try to copy the session scope inside CFLOCKs then use the copy without locks. Unfortunately, if you use StructCopy to do this. any structures in your session scope will only have the pointers copied, and when you access the copy it will really access the session var itself! However the copy will fool the CF admin's strict lock checking for CFLOCK making you think your site is lock safe when really it isn't. ... (The 4.5.1 duplicate() function was created to get around this issue.)

"The performance with client variables in SQL server is fine for most sites. You can improve things by adding clustered indexes for the client storage tables. CDATA has one index on CFID and APP (called 'id1'), cluster it; for CGLOBAL, cluster index "id2" which is on CFID. You can also improve it by using a dedicated SQL server with lots of RAM for just the client vars database if you have a clustered high volume site."

Fusion Authority thanks Michael Smith of Teratech, Inc. for sharing this exchange with us.

Copy This Article's Url To Clipboard

Add Comments