Just for the record, I am in favor in using session variables over
strictly the use of cookie variables.  I would think that the required
parsing and logic to read and handle the cookies in your application
would remove any benefit they would have over session variables hanging
out in memory.  I was just interested in a more technical argument to
benefits/drawbacks of using strictly cookie variables over session
variables and to see if anyone agreed with strictly the use cookie
variables instead of session variables.


Thanks for the post Jeremy.


Kevin


  _____  

From: Jeremy Brodie [mailto:[EMAIL PROTECTED]
Sent: Monday, April 05, 2004 2:49 PM
To: CF-Talk
Subject: Re: Cookies vs Session Variables


Kevin,

If your application requires a login and a password I'd strongly
recomend going the session rather than the cookie route for the
following reasons.

1) You can destroy sessions after someone ends a transaction. For
example if someone walks away for a few moments, you can destory a
session and thereby force someone to log in again. With persistant
cookies, you do not have this option.

2) Michael had mentioned the fact that users can change their
privacy/cookie settings. By using persistant cookies you force yourself
into either checking for the existance of cookies every time or by using
the request scope (and thereby moving the cookie value into RAM,
defeating the purpose of using pure persistant cookies). I'd also like
to point out that some places mandate no session or persistant cookies
-- something session variables can handle if you move CFID and CFTOKEN
into the URL. <My experaince also tells me people purge cookies
perodically... so this poor assumption.

3) Security. Sometimes, you might use a session variable to check
against values in the database -- such as a customer profile. Going the
cookie appraoch will force more stingent checks on your data than
session varibles since the data comes from the client machine -- You
will need to use the same QC techniques as you need for URL variables!

The reasons I bring up these two points is that you will need to create
additional code to compensate for the fact that persistant cookies are
remote and can be manipulated by the client. Result-- More CFIFs,
CFTRYs/CFCATCHs and so on.

4) Finally, Let's do a thought expairment to see what conventional
wisdom tells us.....

For a sturcture containing user information a persistant cookie requires
a connection with local file system and then CF needs to parse out the
information contained in the structure. Every time you call the cookie,
you need to run through the same series of steps. Using session
variables, that information is in server RAM or in a nearby database
--much closer to the center of action.

What do you think would be faster-  reading a file remotely or reading
server RAM (or nearby database)? What does Flash do (since it is a
fatter client side tehcnology -- see the Flex discussion from earlier
this week for what others think)?

Jeremy

>In the case of this argument, let's assume that cookies are enabled for
>everyone.  So we can eliminate those statements.  This is purely an
>issue of how much does it hurt performance.
>
>Kevin
>
>  _____  
>
>From: Tangorre, Michael [mailto:[EMAIL PROTECTED]
>Sent: Monday, April 05, 2004 1:48 PM
>To: CF-Talk
>Subject: RE: Cookies vs Session Variables
>
>Kaz, is this in regards to the conversation we had yesterday about
>company
>"x" choosing to use cookies over session vars because they "think" that
>session vars use too much memory?
>
>Let me start this conversation off with a quick question.... What If I
>disable cookies :-)
>
>Tell those networking guys to simmer down, no one is going to blow up a
>server with session variables or corrupt the PIX firewall...  LOL
>
>Mike
>
>
>> Is there any performance gain to only using cookie variables
>> instead of using session variables?  Is it worth the hassle?
>> Are session variables really that much of a server hog?
>>  
>> Just curious to what others think.
>>  
>> Kevin
>  _____
  _____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to