Douglas
* This is the only valid reason I currently accept for using session
variables.
The original reason I started using Session variables in preference to
client variables was for when the user was running multiple browsers
sessions at a time. The session variables would be scoped just for the local
browser, but Client variables would be common to all browsers, this could
lead to problems.
Is this a valid point? Or is there a simple work around for using client
variables?
Cheers
Gary
-----Original Message-----
From: Douglas Smith [mailto:[EMAIL PROTECTED]]
Sent: 27 February 2001 00:14
To: Fusebox
Subject: RE: cflocation, addtoken = yes||no
At 05:09 PM 2/25/01, Gary Morin wrote:
>Would you say using databased client variables is safer then using session
>variables even if your database is Access ( low volume sites). Secondly how
>does it impact performance having to constantly update and query a
>database.
To Access or not, that is the question. That's a good question that can
only be answered with testing. The real problem with Access is not Access
but the Jet Engine behind it.
But if you have a choice, don't. If you don't have a choice.....to make
Access more stable, don't use the ODBC connection, use the OLE-DB
connection. Check out the SQL directory in your Office 2000 Professional
disk. It's a desk top version of SQL server called MSDE that's really easy
to install and manage.
For me, the biggest reason to use client variables instead of session
variables is that you don't have to lock them. Do you currently lock your
session variables? Do you know what this means? It means every time you
set or reference them, you need to put a <CFLOCK> around the statement,
even something as simple as this:
<CFLOCK timeout="10" type="READONLY" scope="SESSION">
<CFSET Temp=Session.MyApp>
</CFLOCK>
You *really* need to do this if you want to have stability with session
variables. It's a royal pain in the arse. Yes, you can turn on automatic
read locks for variables on your CF admin, but it's *server wide* and
affects all your web sites (breaks your old code), and slows down
processing.
Now, add the fact that client vars don't need to be locked (a considerable
benefit during development) to the other memory stability benefits already
mentioned, plus the inherent clustering capabilities of client vars, and
one must ask "why would one *ever* use session variables?".
The answer is: if you want to cache arrays, queries or structures for
speed. Client vars can't handle these types without converting to WDDX,
which results in a considerable loss of speed. This is the only valid
reason I currently accept for using session variables.
================================================
Douglas M. Smith - Application Architect
TeraTech - Tools for Programmers(tm)
[EMAIL PROTECTED]
================================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
