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