In my applications, I have always used the session scope for handy things
like storing the currently logged in
user, so I can just do: user.isLoggedIn() ... user.hasRole(admin), things
like that. It's great!
Here at my current gig, though, they have a clustered server configuration so
client variables are pretty rubbish as they can only hold simple values.
If that is all you need it for, then perhaps use it, but I would restricr
usage to COOKIE storage, registry should be avoided at all cost, and
database storage can really put a lot of extra load on the database and
delays on
We just switched away from client variables, and now use only session
variables. We got an enormous increase in performance. The database guys were
complaining about the performance impace from all the reads -- let alone the
writes -- due to storing variables in the database.
Recall that CFMX
The short answer is that there can be need for both depending on the situation.
With CFMX Enterprise, you can leverage J2EE Sessions, that will allow you to duplicate sessions across a cluster.
Sessions have the advantage of being able to store complex data types, and don't involve a call to a
CommerceBlocks V2.1 and LoRCAT from
http://www.ProductivityEnhancement.com
The ColdFusion MX Bible is in bookstores now!
- Original Message -
From: Calvin Ward [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 9:59 AM
Subject: RE: SESSION vs. CLIENT
Phil has led you astray a little here and I will correct him.
That's why I said it was from memory and I may be wrong g
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
By default, this is incorrect. The CFID and CFTOKEN cookies
are persistent, and have a ridiculously long time until they
expire. If you want the connection to the session to be
destroyed when the browser is closed, you need to write the
cookies yourself without specifying an expiration
By default, this is incorrect. The CFID and CFTOKEN cookies
are persistent, and have a ridiculously long time until they
expire. If you want the connection to the session to be
destroyed when the browser is closed, you need to write the
cookies yourself without specifying an
It must tie it to the SessionTimeout in the CFAdmin and CFAPPLICATION
then
Maybe some testing is required g
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: 28 January 2004 12:14
To: CF-Talk
Subject: RE: Session vs. Client Management
By default
It must tie it to the SessionTimeout in the CFAdmin and
CFAPPLICATION then
If by it you mean the duration of the cookies, no, by default they last a
very long time.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
[Todays Threads]
[This
I have been archiving Dave's posts since 11/18/1999.This is number 5,000.
Cary Gordon
The Cherry Hill Company
At 12:54 PM 1/28/2004 -0500, you wrote:
It must tie it to the SessionTimeout in the CFAdmin and
CFAPPLICATION then
If by it you mean the duration of the cookies, no, by default they
January 2004 11:41 PM
To: CF-Talk
Subject: RE: Session vs. Client Management
Phil has led you astray a little here and I will correct him.
That's why I said it was from memory and I may be wrong g
_
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
Street
South Melbourne, Victoria, 3205
Phone: 03 9686 0485-Fax: 03 9699 7976
_
From: Philip Arnold [mailto:[EMAIL PROTECTED]
Sent: Thursday, 29 January 2004 1:41 AM
To: CF-Talk
Subject: RE: Session vs. Client Management
By default, this is incorrect. The CFID and CFTOKEN cookies
Actually that is not true Phil, I made a statement about this
a few weeks ago.
Under Internet Explorer, the cookies are not copied across.
Internet explorer uses instances of windows and shares the
data/settings of the windows control panel-Internet Options.
Anytime you open a new
2004 12:35 PM
To: CF-Talk
Subject: RE: Session vs. Client Management
The funny thing about this is, we don't use Session management that
often, so I'm used to using Client variables
If I open a browser, create some client variables - then Ctrl+N a new
window, the client variables are copied across
This is from memroy, so some of it might be a little off
If a cfapplication has session, but not client management
enabled (and is using client cookies), then is there any
difference in the cookie that CF uses?Expiration date,
for instance.
The CFID and CFTOKEN variables are ALWAYS on the
- Original Message -
From: Philip Arnold [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 7:46 PM
Subject: RE: Session vs. Client Management
This is from memroy, so some of it might be a little off
If a cfapplication has session, but not client
Jim,
Phil has led you astray a little here and I will correct him.
CFID CFToken are used to identify which variables belong to that client,
which is held in memory and controlled by the cookie. If the cookie has
expiration then closing the browser will assign new values for CFID
CFToken.
Jim,
The purge clients that remain unvisited has been around in Coldfusion since
4.0 that I can recall. I can't recall the earlier versions as my memory
can't go past 1998 on this fact
Regards
Andrew Scott
Technical Consultant
NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne,
The CFID and CFTOKEN variables are ALWAYS on the session
level, so as soon as you close the browser, they go
By default, this is incorrect. The CFID and CFTOKEN cookies are persistent,
and have a ridiculously long time until they expire. If you want the
connection to the session to be
Sandy Clark and Michael Smith wrote an article about how to avoid locking in
your code by the automatic conversion of client and session scopes to
request scope.
http://www.cfug-md.org/Articles/RequestVariables.cfm
CF_REQUEST is a custom tag that converts Session or Client scoped
variables to
Btw, I am also working on converting CF_Request to a CFC for MX.
Sandy Clark
-Original Message-
From: Doug Fentiman [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 5:36 PM
To: CF-Talk
Subject: Re: Session vs. Client
Sandy Clark and Michael Smith wrote an article about how
I suppose that depends on what you are putting in them ;)
~Simon
Simon Horwith
Macromedia Certified Instructor
Certified ColdFusion Developer
Fig Leaf Software
1400 16th St NW, # 500
Washington DC 20036
202.797.6570 (direct line)
www.figleaf.com
-Original Message-
From: Andy Ewings
I recon you're correct! Session vars are stored in memory, Client vars are
stored in any number of different locations (registry, client cookies, ODBC
datasource).
Jeff Garza
Web Developer/Webmaster
Spectrum Astro, Inc.
480.892.8200
[EMAIL PROTECTED]
http://www.spectrumastro.com
hi
the general opinion is that client vars are more efficient than session
variable, as long as the administrator is configured to store client
variables in a database, otherwise it stores client variables in the
registry which is less efficient that using session vars.
so in a way you're both
.
-Original Message-
From: Simon Horwith [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:05
To: CF-Talk
Subject: RE: Session VS Client
I suppose that depends on what you are putting in them ;)
~Simon
Simon Horwith
Macromedia Certified Instructor
Certified ColdFusion Developer
Fig Leaf
in a DB.
not as fast as memory in *theory*, but in practice it's more reliable and
there's no difference in the performance of my applications.
-Original Message-
From: Garza, Jeff [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 9:04 AM
To: CF-Talk
Subject: RE: Session VS Client
I
: RE: Session VS Client
Wouldn't haver thought it makes a difference. You either have to put them
in a db or the registrywhich is a db in itself!
--
Andrew Ewings
Project Manager
Thoughtbubble Ltd
http://www.thoughtbubble.net
the general opinion is that client vars are more efficient
than session variable, as long as the administrator is configured
to store client variables in a database, otherwise it stores client
variables in the registry which is less efficient that using session
vars.
Either you've got
the registry is *not* designed to be a database in that sense.
-Original Message-
From: Andy Ewings [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 9:11 AM
To: CF-Talk
Subject: RE: Session VS Client
Wouldn't haver thought it makes a difference. You either have to put them
Message-
From: Mark Smyth [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:12
To: CF-Talk
Subject: RE: Session VS Client
hi
the general opinion is that client vars are more efficient than session
variable, as long as the administrator is configured to store client
variables in a database
, distribute, or
retain this message. Please notify us on +44 (0)207 387 8890.
-Original Message-
From: Dylan Bromby [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:20
To: CF-Talk
Subject: RE: Session VS Client
personally, i think the registry is a less-than-desirable place to store
client
on +44 (0)207 387 8890.
-Original Message-
From: Simon Horwith [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:30
To: CF-Talk
Subject: RE: Session VS Client
i don't think I'd classify the windows registry as a database. Yes, it
stores data, but so do text files...I wouldn't refer
:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:31
To: CF-Talk
Subject: RE: Session VS Client
the general opinion is that client vars are more efficient
than session variable, as long as the administrator is configured
to store client variables in a database, otherwise it stores client
variables
hi
They appears to be differing opinions to this? I have heard many people
recommend the use of client variables over session variables, regardless of
whether they are hosted in a clustered envoironment.
Are there specific times when session variables are better to use than
client variables,
Client variables are stored in:
The Registry (not recommended)
A Datasource
as cookies
Therefore, they use 0 RAM, zilch, nada, nothing.
Session variables are stored in RAM. Since any amount of RAM is bigger
than no amount of RAM, I would say that session
Andy Ewings wrote:
I disagree. The registry has replaced .ini files. The registry is a
perfect repositry to store data for your app like DSN'S etc as ini files
used to.
The key word here is store.
Yes it replaces .ini files but that doesn't mean that it is suited for
multiple and
-Talk
Subject: RE: Session VS Client
I disagree. The registry has replaced .ini files. The registry is a
perfect repositry to store data for your app like DSN'S etc as ini files
used to.
--
Andrew Ewings
Project Manager
are not authorised to disclose, copy, distribute, or
retain this message. Please notify us on +44 (0)207 387 8890.
-Original Message-
From: Mark Smyth [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:57
To: CF-Talk
Subject: re: session vs client
hi
They appears to be differing opinions
, you are not authorised to disclose, copy, distribute, or
retain this message. Please notify us on +44 (0)207 387 8890.
-Original Message-
From: Mark Smyth [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:12
To: CF-Talk
Subject: RE: Session VS Client
hi
the general opinion
the problem with session vars is if CF server restarts itself
(which can, sometimes, be a good thing) you lose the session.
i use client vars exclusively over session vars now (and cookies
too) and store them in a DB. not as fast as memory in *theory*,
but in practice it's more reliable
(0)207 387 8890.
-Original Message-
From: Simon Horwith [mailto:[EMAIL PROTECTED]]
Sent: 23 April 2001 17:30
To: CF-Talk
Subject: RE: Session VS Client
i don't think I'd classify the windows registry as a database. Yes, it
stores data, but so do text files...I wouldn't refer to a text
Wouldn't haver thought it makes a difference. You either have
to put them in a db or the registrywhich is a db in itself!
Calling the registry a database is technically accurate in the same way that
you might call an LDAP server a database, but it's conversationally
inaccurate. Typically,
Can you explain why storing Client vars in the registry is less
efficient than storing session vars in RAM?
Storing Client variables in anything but cookies is less efficient than
storing session variables in RAM. It's simply faster to get something out of
the memory owned by a process than it
Message-
From: Jeffry Houser [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 4:09 PM
To: CF-Talk
Subject: Re: Session VS Client
Client variables are stored in:
The Registry (not recommended)
A Datasource
as cookies
Therefore, they use 0 RAM, zilch, nada
Maybe there's no difference in the performance of your applications, but
I've often seen the move from session to client variables (usually in
preparation for clustering) slow down applications significantly. If you
store enough data in the Session scope, it's not practical to just move that
: Andy Ewings [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, April 23, 2001 9:50 AM
Subject: RE: Session VS Client
Client variables are probably a better choice if you think you're going
to
cluster your application on multiple servers, but on a single server,
session variables
PROTECTED]]
Sent: Monday, April 23, 2001 9:49 AM
To: CF-Talk
Subject: RE: Session VS Client
I disagree. The registry has replaced .ini files. The registry is a
perfect repositry to store data for your app like DSN'S etc as ini files
used
-Original Message-
From: Mark Smyth [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 12:57 PM
To: CF-Talk
Subject: re: session vs client
hi
They appears to be differing opinions to this? I have heard many people
recommend the use of client variables over session variables, regardless
, without a need for
storing information from session to session or supporting a clustered
environment, thereby creating a tremendous amount of database traffic.
Bob
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: April 23, 2001 1:32 PM
To: CF-Talk
Subject: RE: Session VS
Session variables are more robust, certainly (when stored in a
database),
but they're definitely quite a bit slower.
I didn't know session vars were stored in a DB, I thought they were only
stored in memory.
I think Dave slipped up here. :) Client variables are generally more robust
and
:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 4:09 PM
To: CF-Talk
Subject: Re: Session VS Client
Client variables are stored in:
The Registry (not recommended)
A Datasource
as cookies
Therefore, they use 0 RAM, zilch, nada, nothing.
Session variables are stored
(sessions vs. client) since i have 1GB to use.
ironically, it's CFPOP that causes CF to restart itself...don't even get me
started on that :).
-Original Message-
From: Bob Silverberg [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 11:18 AM
To: CF-Talk
Subject: RE: Session VS Client
I
: RE: Session VS Client
the problem with session vars is if CF server restarts itself
(which can, sometimes, be a good thing) you lose the session.
i use client vars exclusively over session vars now (and cookies
too) and store them in a DB. not as fast as memory in *theory*,
but in practice
:hmm: I did not know that. Does anyone know for a fact? I thought
CFID / CFTOKEN were typically stored as cookies? Although, I know
the values are doubled in the session scope along with a few others.\
Well, since they're used as a matching key, they have to be stored somewhere
other than
Session variables are more robust, certainly (when stored in a
database), but they're definitely quite a bit slower.
I didn't know session vars were stored in a DB, I thought they were
only stored in memory.
You're right, of course. I'm a bit woozy today. Sorry about that. I meant
that
: Benjamin S. Rogers [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 3:36 PM
To: CF-Talk
Subject: RE: Session VS Client
As Dave points out, most people are aware of how important query caching
is,
but many of those same people use client variables, without a need for
storing information from
57 matches
Mail list logo
