I'm not sure if the first one has to be locked. It depends on the Java
bytecode that the CF compiler generates. I suspect it might have to be,
though the window for problems to occur would be really, really small.
However, the latter MIGHT need to be locked. If you set a variables and
then use it later in the block, you definitely don't want multiple threads
to run the code at the same time. This exact problem plagued FB4 in the
beta stages, particularly when using framesets. Take this block:
<cfif not isDefined("application.init")>
<cfset application.myvar = 3 />
<cfset application.othervar = application.myvar />
<cfset application.myvar = application.myvar + 3 />
<cfset application.thirdvar = application.myvar * 4 />
<cfset application.init = 1 />
</cfif>
Surely it's a contrived example, but if multiple threads executed it
concurrently, it's entirely possible that 'othervar' and 'thirdvar' could
contain inappropriate values.
The short version is that locking (usually using CFLOCK) is needed is that
if you need an atomic operation that consists of more than one statement.
For all shared scope variables, if you can initialize once, and only read
from then on, then you can get away with out locking the reads. But if
you'll ever write to an already initialized variable, then you have to lock
all access, if a race condition can occur.
barneyb
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Camden
> Sent: Wednesday, December 03, 2003 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Basic CFC Design Question
>
> My understanding is quite simple - if there is a logical
> reason to lock,
> then you need a lock. What is a logical reason? Here is a
> simple example:
>
> <cfset app.numberofhits = app.numberofhits + 1>
>
> If 2 (or N) threads run this code at the same time, it is
> possible the wrong
> value would be stored to the variable.
>
> Here is a typical example of something where it doesn't matter:
>
> <cfset app.dsn = "foo">
>
> Who cares if N threads writes this. Or....
>
>
> <cfif not isDefined("application.init")>
> <cfset application.dsn = "foo">
> lots of crap
> <cfset application.init = 1>
> </cfif>
>
> In the example above, it's possible N threads could run this
> code if they
> all hit the app at startup, but it doesn't really impact
> performance any, so
> I wouldn't bother locking it.
>
> ==============================================================
> =============
> Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc
> (www.mindseye.com)
> Member of Team Macromedia
> (http://www.macromedia.com/go/teammacromedia)
>
> Email : [EMAIL PROTECTED]
> Blog : www.camdenfamily.com/morpheus/blog
> Yahoo IM : morpheus
>
> "My ally is the Force, and a powerful ally it is." - Yoda
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kotek
> > Sent: Wednesday, December 03, 2003 2:01 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [CFCDev] Basic CFC Design Question
> >
> > Ray, I must admit that I am one of the people from the "old
> > days" who is somewhat confused about what/how to lock things
> > in CFMX, especially when it comes to CFC's persisted in the
> > session or application scope. My gut instinct is still to
> > lock everything. Without asking you to write a tome, can you
> > (or Sean or Matt or anyone who knows) boil it down to a few
> > bullet points or tips? What needs to be locked and what can
> > be left unlocked, under what conditions?
> >
> > Thanks,
> >
> > Brian
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Camden
> > > Sent: Wednesday, December 03, 2003 2:50 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [CFCDev] Basic CFC Design Question
> >
> > > Sorry for the late response on this, but I wanted to be
> sure of one
> > > thing. Barney, you aren't saying that all uses of data
> needs to be
> > > locked, right? I guess I'm asking you to define
> > "appropriately." Some
> > > people (based on life during the cf5
> > > times) still say, "LOCK EVERYTHING OR DIE!", and certainly
> > that is not
> > > the case anymore. You can have instance data in a
> > persistant CFC that
> > > is NOT in danger of race conditions, and of course would
> > not need to
> > > be locked.
> >
> > ----------------------------------------------------------
> > 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]
> >
>
>
> ----------------------------------------------------------
> 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]
>
----------------------------------------------------------
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]
