One more important thing to keep in mind. Session variables don't work in a
"non-sticky" clustered environment where you hit a different server on every request.
If you want to implement session variables on a cluster, the cluster must be setup in
"sticky" mode (meaning that you hit a random server the first time, but maintain tied
to that server for the life of the session).
Kevin
>>> [EMAIL PROTECTED] 08/07/01 12:37PM >>>
thanks for all the info and help
See if I can do a sum here.
Session Vars are faster(memery vs db), but do use up server RAM. less
overall overhead but you have to use <CFLOCK> every time a session var is
referenced to help avoid corruption of data(which itself can then cause a
performance drop). But can handle complex data types better(?)
Client Vars are a little slower(db request), but don't use up server RAM.
Can have a lot more overhead, specially if dealing with Structures or
Arrays. Don't have to use <CFLOCK> when referencing. Data is a lot more
secure. But have to write procedures to clean up db.
Again thanks for all the help. I think I understand a lot more and hope the
individual that started this thread also did.
-----Original Message-----
From: Tyson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 11:52 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Additionally, if you convert complex data structures into WDDX, that
will work well if your client vars are being stored in a datasource.
However, if you're using cookies as you means of storing client
variables, you'll need to be careful. Each cookie has a limit of 4kb in
size. If you start dealing with complex nested data structures in WDDX,
it's very easy to bump over 4kb in size with a WDDX packet.
-Tyson
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 1:31 PM
To: CF-Talk
Subject: RE: I don't understand session locking :(
> Changing from session to client
>
> Are there any limitations on client vars, other than db size?
> Could structures and arrays be a problem?
Yes. If you want to store structures, arrays or queries in the Client
scope,
you'll have to convert them to strings; you can easily do this with
WDDX.
However, there will be a lot more overhead in doing this - the Client
scope
is inherently more "expensive" to use. So, if you've got an application
which uses Session variables all over the place, you might have problems
if
you simply switch to Client variables. You'd have to go through the
application and decide what you can do without when storing persistent
data.
> Looking at the table, cdata, the client vars are all dumped
> into one field, can this be changed?
No. You're free to build your own alternative state management
mechanism,
though; this is what we all used to do before Client and Session
variables
anyway - you'd design the appropriate relational database structure, and
store your data in there, and simply retrieve it on each page request
using
a regular SQL statement.
> and is there a way to automatically delete them when a user
> leaves your site with out logging out?
Not really, since you don't know when someone leaves your site. All you
know
is that it's been a certain period of time since their last page
request.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
