If performance is paramount and assuming that enough memory is available and
depending on how much client var data an app would create, why not create a
memory-resident database and use it to store client vars? You would have to
flush regularly to disk but it might help performance if that's most
important.
Oracle can pretty much do that anyway though right but could a "poor man's"
work-around be to create a RAM Disk (if you can, I haven't seen this in a
long time, can you do it on Win2k?) and copy the database data files to it.
The only advantage of this over file-system caching would be that you are
reserving RAM for that data and so it wouldn't be cleared out of cache.
At a low OS level you could programmatically create memory-mapped files but
that's would be a whole development effort in and of itself.
Another .02 cents to the pile....
Kev
-----Original Message-----
From: 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 session to session or supporting a clustered
> environment, thereby creating a tremendous amount of database traffic.
Although I agree with this point, there are several other very valid reasons
for using Session variables. Someone has already brought up the point that
restarting the service doesn't necessarily cripple the user's session if the
application is using client variables.
In addition, on the user's side of things, Client variables generally act
more like real "session" than do Session variables since Client variables
are not arbitrarily expired every so many minutes. Of course, you can set
Session variables to expire after a hours or days, but in most applications,
that would take up an untenable amount or RAM: generally, your database
server has more disk space than your Web server has RAM.
And of course, my old sounding board is that even a very careful use of
Session variables generally affects server stability in a manner that Client
variables do not. I know many people will claim that they experience no
problems with properly locked Session variables. Either we are cursed or we
just read our log files more thoroughly, because we have seen all manner of
intermittent errors and unusually application behavior stemming from Session
variables. These slowly disappear as we phase out of developing and
maintaining applications with Session variables in favor of Client
variables.
Benjamin S. Rogers
Web Developer, c4.net
Voice: (508) 240-0051
Fax: (508) 240-0057
Bob
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: April 23, 2001 1:32 PM
To: CF-Talk
Subject: 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 it's more reliable and there's no difference in
> the performance of my applications.
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
data to the Client scope, as you'll end up with quite long strings.
Session variables are more robust, certainly (when stored in a database),
but they're definitely quite a bit slower. This makes sense - otherwise, why
would we bother caching queries and output to make applications faster,
rather than just returning to the database for every data view?
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
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
