Just some additional interesting information on shared variable scopes: the reason you do not need to lock them (unless you are attempting to prevent a race condition) is that their underlying Java implementations use java.util.Hashtables. Hashtables are synchronized so that two threads cannot modify the same instance of a Hashtable concurrently. So Tony, you are right that Macromedia engineers did the right thing here, otherwise there would be a lot more cflocking going on. For instance, if they had used a HashMap, all access/modification would have to be locked (to prevent actual exceptions as opposed to just unexpected behavior), which would make for a lot more code with no advantages.
Another thing to note is that synchronization at such a low level is very fast and efficient; faster than using cflocks. Christian On Thursday, February 6, 2003, at 10:19 AM, Tony Weeg wrote: > cool. > > that makes sense...and from what I understand, it makes > perfect sense, that macromedia planned around that, and > did some homework for us. > > thanks! > > ...tony > > Tony Weeg > Senior Web Developer > UnCertified Advanced ColdFusion Developer > Information System Design > Navtrak, Inc. > Mobile workforce monitoring, mapping & reporting > www.navtrak.net > 410.548.2337 > > -----Original Message----- > From: Stephen Moretti [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 06, 2003 10:19 AM > To: CF-Talk > Subject: Re: yet another locking ? > > >> >> I definitely understand a race condition. what I don't >> understand is this: If a race condition could occur, even >> 1 time out of 1 hundred thousand iterations, isnt that enough >> to lock it? I could imagine, if I had a shopping cart system, >> that I would EVER want someone to know what my CC info >> was, however, if a race condition is even somewhat a potentiality >> then even the smallest chance of occurrence is too much of a risk >> >> wouldn't you agree? >> > Yes, but then every use of a shared scope variable isn't necessarily > going > to generate a race condition. > > Simply checking for an application scope variable and setting it to a > default value will not cause a race condition, because the value will > always > be the same. Only if you're reading and then incrementing that > application > scope variable will you get a race condition. > > In your example of a shopping cart, locking was required in CF5 and > lower > because of other issues with session variables. Using session > variables > in > a CFMX application you are unlikely to get a race condition, unless > you're > using frames in the design of your site. > > You don't get a race condition if you're only reading a variable and > not > updating, so you don't need a lock. > > Stephen > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
