Huh? How can you specify session variables to go to a single browser
window in the same browser? I am fairly sure that browser windows share
any cookies received across all of the open windows.
Client variables are tied or keyed to the CFID/CFTOKEN cookies, just as
session variables are. If your IE and Netscape browsers have different
CFID/CFTOKEN then they will have different sets of session AND client
variables.
It's the same issue if you pass around your own CFID/CFTOKEN on the url
line, and bypass the CFID/CFTOKEN cookie. Whatever the current
CFID/CFTOKEN is (no matter where it came from, cookie or URL) that is what
CF will use as a KEY to get the session and client variables.
Now, if you set your own CFID/CFTOKEN cookies, you can specify the domain
of the cookie, even down to different directories (ie, CF Applications) on
the same web site. But all your browser windows will have the same cookies
for a given cookie path.
I am pretty sure of all this, but heck, could be wrong.
At 05:18 AM 2/28/01, Gary Morin wrote:
>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
