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/cf-talk@houseoffusion.com/ ______________________________________________________________________ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists