Hooray, another interesting thread on CF best practices!

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.

Bob

-----Original Message-----
From: Michael Smith [mailto:[EMAIL PROTECTED]]
Sent: April 10, 2001 2:53 PM
To: CF-Community
Subject: Re: session.session_id


Kristin
Wow! Thanks for replying to this question in such detail. I didn't know so
many famous CF authors were on this
list! :-)

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 varialbes in maintain info across page
requests for one user. For me the "no
locking required" benefit outweights 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.

- Michael Smith, TeraTech, Inc http://www.teratech.com/

Kristin Aileen Motlagh wrote:

> [snip]

> Also, to Michael Smith's comment:

>
> "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..."
>
> 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?
>
> -Kristin
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/cf-community@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to