Sean, thanks for the reply. This was the most insightful, explanatory information I've read on this yet! I really appreciate the time you took to write it. It's a good reference article in itself on the subject.
> -----Original Message----- > From: Sean A Corfield [mailto:sean@;corfield.org] > Sent: Friday, November 01, 2002 1:10 PM > To: CF-Talk > Subject: Re: Understanding Locking In CFMX > Other languages DO need locks to avoid race conditions - CFMX is now > par with them. In Java, you need to use the keyword "synchronized" to > apply locking around operations. Some language provide explicit > functions for locking resources, some languages force you to rely on > external semaphores for resource protection. > > > To me, that says "You still have to lock everything > > you always had to, unless you want corrupt data." > > No, it says you have to think about whether you need to lock or not, > just like in other languages. Consider this construct: > > <cfif isDefined("server.myVar")> > <cfset server.myVar = createObject("component","foo")/> > <cfset server.init()/> > </cfif> > > If this can be executed by multiple requests simultaneously, you need > to lock it. Where do you need the lock? Just around the update? No, in > this case you need the lock around the whole <cfif.../> tag. Why? > Consider this (bogus) code: > > <cfif isDefined("server.myVar")> > <cflock name="server_myVar" type="exclusive"> > <cfset server.myVar = > createObject("component","foo")/> > <cfset server.myVar.init()/> > </cflock> > </cfif> > > Two requests begin to execute this, they both execute the test and find > server.myVar is not defined so they both try to lock - one of them gets > the lock and initializes it all. Then the other request is given the > lock and it initializes server.myVar again. > > The following is the safe way to do this: > > <cflock name="server_myVar" type="exclusive"> > <cfif isDefined("server.myVar")> > <cfset server.myVar = > createObject("component","foo")/> > <cfset server.myVar.init()/> > </cfif> > </cflock> > > Now let's think about multiple requests accessing server.myVar - if > they are just retrieving the value, there won't be a problem. What > about an update? If one request sets server.myVar to some new value, > what could happen? It's an atomic value so requests won't corrupt it. > In other words, you can manipulate the single variable server.myVar > without locking (unless you care about its previous value as in the > initialization above). Up to a point (dependent on the specifics of > your application). > > Now think about calling methods on server.myVar - if you call methods > that don't change the state of the object, are you safe? It depends. > Suppose you two data members inside the object, firstName and lastName. > Suppose you have a method, getFullName(), that returns firstName & " " > & lastName. Suppose you also have a method, setName(), which takes two > arguments for a new first name and a new last name. These operations > are NOT atomic so both the update AND the read will need locking > (exclusive for the setName() calls, readonly for the getFullName() > calls). > > > If I am wrong about this, can anyone explain in English, so my tiny > > little > > brain can comprehend why? > > Locking is a hard subject to deal with. Changing policy from 'lock > everything' to 'lock only when you need to' is a big jump. The simplest > way to think about it now is 'if in doubt, lock it!' but the long-term > goal should be to develop an understanding of how multi-threaded handle > resource contention. No one should expect to 'get it' immediately - we > should expect to see lots of questions on this topic! > > "SOAP is not so much a means of transmitting data > but a mechanism for calling COM objects over the Web." > -- not Microsoft (surprisingly!) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Get the mailserver that powers this list at http://www.coolfusion.com
