so i take it the answer is no:) i did go read this tut http://www.vboston.com/depressedpress/content/coldfusion/guides/locking/5-us ingcflock.cfm
bear in mind it looks to be written for 4.5 Dave -------------- .::. ----------------------------------------- ----- Original Message ----- From: "Christian Cantrell" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, February 06, 2003 11:06 AM Subject: Re: yet another locking ? > 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
