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]
