Yep, there is no hard and fast rule. But, here's another way to look at it. If you are doing lots of writes to shared scopes that's when this becomes and issue - obviously if variables are written to once and then only ever read this is not really an issue at all. And, READONLY locks add no significant processing time (a READONLY lock is actually less a lock and more a flag that says "this cannot be executed if there is an exclusive lock active"). So, other than you having to add that code in there, there is no real downside to doing so.
Which is why so many suggest that it is good policy to always lock. That has never changed. What has changed is that in CFMX you don't *have* to lock, but you may still want to so as to ensure that your application runs as intended. --- Ben -----Original Message----- From: Andrew Tyrone [mailto:atyrone@;optonline.net] Sent: Friday, November 01, 2002 1:37 PM To: CF-Talk Subject: RE: Understanding Locking In CFMX > -----Original Message----- > From: Ben Forta [mailto:ben@;forta.com] > Sent: Friday, November 01, 2002 12:57 PM > To: CF-Talk > Subject: RE: Understanding Locking In CFMX > Which simply means that any time there can be concurrent access to > data from different threads there is a risk for a race condition. The > simplest example? If you have a dozen variables in a shared scope and > some other process were to read those during an update then there is a > risk that the thread reading the data may have 6 variables with old > values and 6 with new values. That should not trash your server, but > it may mess with your application - that is your choice. I guess that is my point -- if there is no concrete answer on when to lock, I'd lock all the time so I don't have to worry about it. > Any application or development language that allows multiple threads > to access shared data has to deal with it - operating systems do, as > do DBMSs, as do development languages. It is not a CF issue at all. I am aware of that, it just seems like the "when and where" issue of locking is even more sketchy with CFMX than it was beforehand. > What was a CF issue was possible memory corruption pre-CFMX. That's > been fixed. Race conditions? That's for you to determine if they pose > a problem for your particular application. The problem that I have with looking at an app and trying to figure out if I am going to need to lock is, I might as well lock because if I ever have to add or modify the application, I'll be wasting time going back and locking other code because new code I've written might cause a race condition with the prior code. Thanks for the additional insight! Andy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
