It may not be correctly worded, but the following has always helped me understand the extreme views on the topic:
In the world of CF there have two (major) reasons to lock shared scopes. 1) The first reason was simply to protect the Server. In earlier versions of CF the internal data structures used to store shared scopes were themselves not thread safe. This meant that (internally) a read and a write could occur at the same time - when this happens it's like two bullets hitting in midair. You don't know what could happen: memory corruption, one or both threads crash, or nothing. 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. However in CFMX the internal data structures used ARE thread-safe. There is no way (well, so we're told) that JUST poor locking can take down the server. 2) The second reason is to protect the application (specifically the data of the application). We lock here because multiple threads can access the same data at the same time - but we get the choice. As developer's we have to determine for each application which aspects require this protection or not. The key is to remember that nothing you do here will cause the server to die (although template errors can come hot 'n' heavy). This seems to have led to a backlash with some people saying "No locking is needed in MX ever!" which is wrong. It's wrong because you still need to understand that CF is a multithreaded platform and why locking exists. Basically reason one simply doesn't exist in CFMX - only in earlier versions. What Ray and Brian are talking about now is the heart of that second reason - and honestly it seems to have very little to do with CF specifically. These exact kind of questions need to be answered in the same exact ways for any multithreaded application (.NET, JSP, PHP, whatever) including most databases. All that differs is the nitty-gritty implementation of the locking and how much the application engine does for you. On the web things like sessions, frames, multiple submits, orphaned requests and so forth are important to the discussion - but again, not in any way specific to CF. I'm not sure if this helped or hurt... but that's the way I think about it. Jim Davis ---------------------------------------------------------- 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]
