Lemme splain.
>From the docs...
"Application and Session variables are in-memory variables, therefore, using
them can increase the total amount of memory used by the server"
When you use the setclientcookies param in cfapplication (I beleive the
default is yes anyway) what this does is store the users cfid and cftoken in
a cookie on thier machine. The actual session variables are in your servers
memory and the cfid and cftoken are pointers to the space in your servers
memory where these variables exist for this user. This of course is why you
must lock your sesssion variables because there is a lot of grey matter
floating around and you want to make sure you are using the right part. But
I digress. The reason you must set cflocation's addtoken attribute to yes
is that it passes cfid and cftoken (the pointers) with the request. Now
someone might argue that that is not necessary because cfapplication is
always looking for that cookie anyway. However, not passing this token can
give you some funky ass results (as steve puts it).
When I first started developing CF I was a session variable junky, but here
are some reasons never to use them. First of all, they are stored in
memory. This is bad. Your server's memory has enough to deal with without
having to keep track of session variables. What if the server burps while
you are in the middle of someone's session? That is, lets say some task
whether server related or application related spikes the ram. Your session
variables are wiped out and you go hungry a bow bow bow. Second, what do you
do with paranoid web users that do not have cookies enabled? Or worse with
a user that had thier paranoid friend set up thier browser? The latter has
no idea how to enable thier cookies, the former thinks you can look through
thier bedroom windows and is lost as a user. Now lets say you want to
maintain state over several visits. Like someone comes to you website and
you remember thier preferences. Now lets imagine this website is hosted on
a shared server at some half-witted Hosting company. Something goes wrong
on the server so thier solution is to reboot the machine. Guess what
happens to your pointers and in memory variables? That's right, you go
hungry. The problem with session variables is that you ultimately give up
state management control.
On the other hand, client variables can be stored both in the database and
in the cookie. Now wherein if you do not store them in the database you
still may have token problems if a server is rebooted. That is the cfid and
cftoken for someone's browser may change. However, a ram spike is not going
to kill your session. The safest way to maintain state is with client
variables stored in the database. It makes handling stuff like wddx a
breeze, you don't give up state management, and if next thing you know ole
jed's a millionaire, clustering is transparent.
Sean Renet
----- Original Message -----
From: "Clint Tillerson" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Friday, February 23, 2001 6:29 AM
Subject: Re: cflocation, addtoken = yes||no
> I'm using session variables and NOT client variables. So, yes, I am
> maintaining state with cookies. But how do these cookies interact
> with cflocation. My understanding is cookies are not passed with a
> cflocation, so how does cf know my cfid and cftoken immediately
> following a cflocation if cookies are not passed and addtoken=No?
> Is it simply because I am the only user at the time?
>
> (BTW, this is a corporate Intranet site with few users. I'm using CF
> 4.01, hoping to go to 4.5 soon.)
>
> Actually, this raises another question. I understand for clustering,
> you need to use client variables. But for a low profile site such as
> this, I don't feel that will ever be a need. Is clustering the ONLY
> reason there is a preference to client variables over session
> variables. I always use session management and never use client
> managment. I'm wondering if I need to re-think this. What are the
> advantages/disadvantages?
>
> This concept has alluded me for some time.
>
> All of your comments are greatly appreciated. This listserv is a
> great resource!!
>
> clint
>
>
>
>
>
> On 22 Feb 2001, at 18:06, Ken Beard wrote:
>
> > probably the reason you are still seeing everything work is that you
> > are maintaining state with cookies.
> >
> > At 01:57 PM 2/22/01 -0500, you wrote:
> > >Does the "addtoken" attributue of <cflocation> refer only to their
> > >display in the URL? i.e., Will your site perform the same regardless
> > >how you set this attribute? If you set addtoken = No, are they still
> > >passed? In development, this seems to be true, but I'm worried
> > >whether sessions will be lost or confused in production with multiple
> > >users. If it doesn't matter whether you set it Yes or No, why would
> > >anyone ever set addtoken = yes?
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
