I agree that empirical testing is the way to go, but I disagree with your "must lock memory variables" rule. There are many applications that can avoid the use of cflock even in pre-MX days. IMHO, adding additional overhead when none is needed is foolish.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Dave Watts [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 23, 2002 4:28 PM > To: CF-Talk > Subject: RE: WHYYYYY!!!!!! > > > > Just curious, do pre-MX versions of CF require > > > scope-level locking (as opposed to named locks) > > > for safe access to session variables? > > > > No they don't require it. In fact scope locking only > > came in as a cool new feature with CF4.5 . Logically > > both will do the job, although as Jason pointed out > > on the other thread, scope-locking, while convenient, > > seems like overkill. Why lock down the entire scope > > just for one variable? > > One has to be very careful with the application of logic to solve these > sorts of problems, because very often one might not have the necessary > facts > to justify initial assertions. You're right that logically, both should be > sufficient, but there's a reason that Allaire introduced the SCOPE > attribute. Remember, they introduced memory variables before they realized > they introduced a CFLOCK tag at all, and on the second version of CF with > this tag, they introduced the SCOPE attribute, so there's no reason to > assume that they did the job right the first time when it comes to locking > memory variables. > > Also, with these memory variables, the scope itself is a variable, which > might cause problems if the entire scope isn't locked. Now, personally, I > just don't know enough about the internals of CF 5 (or any version of CF) > to > say whether it's safe to use the NAME attribute instead of the SCOPE > attribute. What I do know is that if you don't lock memory variables in CF > 5 > or earlier, your server will typically crash under load, and if you > consistently lock memory variables with the SCOPE attribute, your server > won't crash under load. So, there's lots of leeway there for the NAME > attribute stuff to work well, or not work well. But I know that I can't > apply logic to solve this problem, since I just don't know enough about > the > internals of the CF server. The only way to solve the problem is > empirically > - try it under load and see. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > phone: 202-797-5496 > fax: 202-797-5444 > > ::::::::::::: dream :: design :: develop ::::::::::::: > MXDC 02 :: Join us at this all day conference for > designers & developers to learn tips, tricks, best > practices and more for the entire Macromedia MX suite. > > September 28, 2002 :: http://www.mxdc02.com/ > (Register today, seats are limited!) > :::::::::::::::::::::::::::::::::::::::::::::::::::::: > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm 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
