Just trying to answer your question, I remember asking the same question and
I got a very good answer and I found the email in question... taking back my
example...
<cfif NOT IsDefined("Application.MailService")>
<cflock name="MailServiceLock" Timeout="10" THROWONTIMEOUT="No"
Type="Exclusive">
<cfif NOT IsDefined("Application.MailService")>
<cfobject component="#request.componentpath#MailService"
name="Application.MailService">
</cfif>
</cflock>
</cfif>
Here's the explaination of Sean Corfield....
The code below checks for existence of the variable, unlocked, which is
safe. However, two threads could both theoretically execute the test at
the same time and both would 'succeed' on the cfif condition...
>> <cfif NOT IsDefined("Application.MailService")>
...hence the exclusive cflock that comes next, to ensure only one
thread can move forward...
>> <cflock name="MailServiceLock" Timeout="10" THROWONTIMEOUT="No"
>> Type="Exclusive">
...and then we re-test in single-threaded mode. We need to do this in
case two threads executed the cfif above and one of them already got as
far as initializing the variable before the other thread even got to
the cflock.
>> <cfif NOT IsDefined("Application.MailService")>
>> <cfobject component="#request.componentpath#MailService"
>> name="Application.MailService">
>> </cfif>
>> </cflock>
>> </cfif>
Why do the cfif / cflock / cfif instead of just cflock / cfif? Because
you do not want the overhead of calling cflock on every request. The
vast majority of all requests will find the application variable
already initialized - in fact only the first request to hit the server
will find it uninitialized (modulo race conditions on the first few
simultaneous requests!). By using an unlocked cfif, you place no
locking overhead on subsequent requests.
I hope that clarifies things - locking strategies and multi-threading
concerns are not straightforward!
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----- Original Message -----
From: "Cohen, Michael" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 18, 2003 3:22 PM
Subject: RE: [CFCDev] OT: Locking
Thanks for the help guys. Just to clarify, do you mean "race conditions" as
in two threads "racing" to the same piece of data? I understand why you need
to the whole if-lock-if thing - two threads could both arrive at the first
<if> and the variable will both be undefined for them, at which point the
first thread will lock, then create the variable, then release the lock, and
then the second thread will overwrite the variable. Is this a race
condition?
-----Original Message-----
From: St�phane Bisson
To: [EMAIL PROTECTED]
Sent: 9/18/03 3:03 PM
Subject: Re: [CFCDev] OT: Locking
Also, here's the right way to prevent race condition...
<cfif NOT IsDefined("Application.MailService")>
<cflock name="MailServiceLock" Timeout="10" THROWONTIMEOUT="No"
Type="Exclusive">
<cfif NOT IsDefined("Application.MailService")>
<cfobject component="#request.componentpath#MailService"
name="Application.MailService">
</cfif>
</cflock>
</cfif>
Stephane
----- Original Message -----
From: "Sean A Corfield" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 18, 2003 2:53 PM
Subject: Re: [CFCDev] OT: Locking
> On Thursday, Sep 18, 2003, at 11:17 US/Pacific, Cohen, Michael wrote:
> > This may sound stupid but did I read somewhere that it *really*
wasn't
> > necessary to lock writes to shared scope variables in MX? That seems
> > impossible to me but...
>
> You only need to lock to prevent race conditions.
>
> > Also, assuming you do have to lock writes, is it preferable to use
the
> > name
> > attribute rather than scope?
>
> This is from our Coding Guidelines (3.0):
>
> "Locking & Shared Scopes
>
> When accessing and / or updating data in shared scopes, always
consider
> the possibility of race conditions (i.e., where two concurrent
> requests could access and / or update the same data). If a race
> condition is possible and might affect the behavior of your code,
you
> need to use cflock to control execution of the code around the
shared
> resource.
>
> If the shared resource is in server or application scope, you
should
> use named locks to control access - and choose a name that uniquely
> identifies the resource being locked, e.g., use server_varname when
> locking an update to server.varname.
>
> If the shared resource is in session scope, you should generally use
> a scoped lock on session itself.
>
> In both cases, remember that you are only trying to prevent race
> conditions affecting your code: most read operations do not need to
> be locked; most write operations should be locked (unless the race
> condition is either unimportant or cannot affect the outcome)."
>
> > <!---lock one session variable---->
> > <cflock name="session.UserID" type="exclusive" timeout="10">
> > <cfset session.UserID = someValue />
> > </cflock>
> >
> > <!---on another page---->
> > <cflock name="session.Cart" type="exclusive" timeout"10">
> > <cfset session.Cart = aStructure />
> > </cflock>
> >
> > Would these locks have no bearing on each other?
>
> Correct, they are independent locks although with session scope, you
> might as well lock on session scope since you'll only block one
user...
>
> Sean A Corfield -- http://www.corfield.org/blog/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the word '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 word '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 word '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 word '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]
