That may be the case (who the hell am I to argue) but in talking with at least one person on the CF development team he's specifically stated that forcing the developer to lock was one of the biggest mistakes they ever made.
Yes, it COULD have been done on the server - but it wasn't. The idea at the time, or so I was told, was that a human could optimize locking better (grouping multiple statements into a single lock for example) - of course the problem was that most people can't. To have the server do the locking you're getting into a performance hit (especially with the way structured scopes were handled). I can say however that I've also worked on several high load applications that tanked repeatedly... until locking was addressed (I'm working on one now in fact). Nothing else was touched. We both know that certain things have to be in place to have problems with locking... a framed site, for example, may be more susceptible to issue in the session scope, a site which keeps session data in the application scope will be more susceptible than a site that only maintains read-only vars in the application scope and so forth. So while it's definitely not true that EVERY application would crash without locking (sorry for the definitive statement) it's definitely true that many, many of them did. The concept that you "must always lock" definitely emerged from this - only to be invalidated completely (even as a rule of thumb) with the MX release. The way I like to put it is: You may or may not choose to lock... but if you choose not to you better damn well know why. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Matt Liotta > Sent: Thursday, December 04, 2003 12:50 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Basic CFC Design Question > > > In any case problems at this level could cost you the reliability of > > the > > server. This is where the "lock everything, all the time" mindset > > comes > > from: if you didn't (in pre-MX) your application would simply not be > > stable > > under load. > > > > You had no choice but to lock - not doing so would result in twitchy > > server > > death. > > > Not true as I stated over and over during the pre-CFMX timeframe. I > worked on many high load CF applications that were able to make use of > shared memory scopes without using locks including one that was > featured as an Allaire case study. It wasn't that I had some magic luck > that things worked as the did, the applications were designed > specifically such that even without locks there would never be an > instance where corruption of shared memory could occur. > > Remember, that if always locking everything was a rule that was really > true, there would be no need for developers to apply locks in the first > place since such a simple rule could be handled by the server. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.MontaraSoftware.com > (888) 408-0900 x901 > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
