First off here is a little piece of code I got from Hal Helms that helps to
get rid of duplicate sessions
<!--- Set session cookies --->
<cfif IsDefined("Cookie.CFID") AND IsDefined("Cookie.CFTOKEN")>
<cfset cfid_local = Cookie.CFID>
<cfset cftoken_local = Cookie.CFTOKEN>
<cfcookie name="CFID" value="#cfid_local#">
<cfcookie name="CFTOKEN" value="#cftoken_local#">
</cfif>
1. I had found many oddities with 4.0, one being that when we upgraded from
4.0 to 4.0.1 it was erroring on cfapplication because there was no name.
This was a huge problem, made the website completely unusable till I went to
every place that has cfapplication. So it would not surprise me if CF did
something wierd like you described.
2. I am not sure about your second question, though it would seem logical
since the registry is not shared between the servers. Though Dave Watts
could probably answer this better than me.
Robert Everland III
Dixon Ticonderoga
Web Developer Extraordinaire
-----Original Message-----
From: Karl Simanonok [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 25, 2002 4:42 AM
To: CF-Talk
Subject: Client Variable Storage in CF 5.0 versus 4.0
I have some questions relating to how client variable storage was handled
in CF 4.0 compared to how it is handled today in CF 5.0. Some background
information may help these questions make sense by putting them in context:
Background info
===============
I am upgrading a web site (not of my design or construction) that is still
running CF 4.0, that uses three load-balanced web servers. The site owner
has been having endless problems that appear to trace to client variables
getting mixed up somehow, with the end result being that people who log in
sometimes see other people's data returned from the database instead of
their own. This results in some unpleasant calls to customer support and
probably a certain amount of lost business that we never learn about. The
CF coding is very poor (no indents, max dependencies everywhere, deeply
nested CFINCLUDEs, no variable scoping, variables renamed every time they
get passed from one place to the next, etc.) and the database is for
practical purposes almost impenetrable (it's an academic's experiment of a
denormalized style of database that is emulated on SQL Server, with no
primary keys, completely unrelated data stored in the same tables, almost a
thousand Byzantine stored procedures to maintain referential integrity,
views of views of views and so on -- but that is a separate problem). In
this environment it would be extremely difficult to isolate this problem
even if I could reproduce it, but I have never been able to observe the
problem myself, we just get two or three irate customers calling every day
about it.
Needless to say, the only sensible thing to do is to replace the awful
database with a normal one and rewrite all the kludgy CF code the way it
should have been written in the first place, and this is what I am
beginning to do. Tonight I removed one of the three web servers from load
balancing and upgraded it to CF 5.0 as an early step in the process, and
something odd happened: the client variable storage that had worked
previously in CF 4.0 didn't work any longer, even though it was set up to
work the same way as it did before in the CF Administrator. The Registry
is set up as the default location for client variable storage; however the
production database was still explicitly named as the place for client
variable storage in the CFAPPLICATION tag in Application.cfm
(CLIENTSTORAGE="ProductionDB"). Looking in ProductionDB, I noticed
something that had eluded me before: no CDATA and CGLOBAL tables! That
must mean that CF 4.0 doesn't find them in the production database and uses
the Registry default as set up in the CF Administrator. I'm guessing that
CF 5.0 is stricter and won't put up with such shenanigans, and that if the
database specified for use as client variable storage in the CFAPPLICATION
tag doesn't have those tables, CF 5.0 throws an error.
So, my questions for you experts are:
1) Is my conclusion true, did CF 4.0 default to the Registry (or the
default setup in the CF Administrator for client variable storage) if the
database specified in the CFAPPLICATION tag for client variable storage did
not contain CDATA and CGLOBAL tables?
2) Can client variables be maintained properly in a load-balanced (by
hardware, not ClusterCats) system if they are stored in the Registry of
each web server? I'm thinking that this might explain how the client
variables are getting mixed up.
Thanks for your help.
Regards,
Karl Simanonok
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
______________________________________________________________________
Why Share?
Dedicated Win 2000 Server � PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER
Instant Activation � $99/Month � Free Setup
http://www.pennyhost.com/redirect.cfm?adcode=coldfusionc
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
