Fyi cf officially did away with need for manual locking some time ago. The only sitation where you need to lock now is where you have potential race conditions. Some folks still like to lock anyway though.
Regards Russ Michaels >From my mobile On 1 Feb 2012 18:57, "Mike Chabot" <[email protected]> wrote: > > I would agree with what some others have written, in that an apparent > over-use of session variables is not inherently bad, unless it is > causing server instability or memory problems. Make sure the > programmer is using session variables for a specific reason, and that > he is aware of the issues that using session variables can cause. Out > of all the faults one can find when examining a Web site, using too > many session variables is fairly low on the priority list. 1000 users > on a site at a time with 250 session variables per user doesn't seem > that bad to me on the surface. Storing frequently accessed database > data in the session scope is often used as a caching optimization > technique to reduce the database bottleneck. It is a technique I use > and recommend, especially for very busy Web applications. In general, > the busier the Web application, the more you are going to want to > store in-memory to reduce the database usage, assuming your server has > sufficient RAM. Really giant Web sites, like Facebook and YouTube, > make extensive use of in-memory databases, like memcached. > <http://en.wikipedia.org/wiki/Memcached> > > One thing most developers neglect to do when using lots of session > variables is making the session code thread safe, which takes a > relatively high skill and experience level to accomplish. Unless you > see a lot of cflock tags to mitigate the possible problems, a site > with 1000 simultaneous users and 250 session variables might have > random problems that could be traced back to the use of session > variables. Threading problems can be hard to diagnose and are usually > not discovered until the code gets put into a production environment. > > If the programmer is aware of the memory usage and threading issues, > using lots of session variables is likely a minor concern, and > potentially is a good thing if he is using them as a technique to > speed up the Web application. > > You wrote "I see no scope referencing in these Vars," which I find odd > if you are referring to variables in the session scope. All the > in-memory variables should have their scope referenced when they are > used. > > -Mike Chabot > > On Tue, Jan 31, 2012 at 11:37 AM, Robert Harrison > <[email protected]> wrote: > > > > Thanks for all the input. Besides the fact that the application could > conceivably have hundreds of thousands of session Vars in memory, I'm > concerned about collision too. > > > > I see no scope referencing in these Vars and see they are all 'common > names'. I also see no routines to clear any vars after completion of an > operation is over. > > > > Oh well. > > > > Robert B. Harrison > > Director of Interactive Services > > Austin & Williams > > 125 Kennedy Drive, Suite 100 > > Hauppauge NY 11788 > > P : 631.231.6600 Ext. 119 > > F : 631.434.7022 > > http://www.austin-williams.co > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:349725 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
