My understanding is that the read lock is unneeded in CFMX. You only need
CFLOCK for preventing race conditions in CFMX, not for syncronizing memory
access, because the underlying java runtime takes care of that for you. You
obviously still have to lock the initialization, because that's preventing a
race condition, not just protecting memory.
My preference is something like this:
------------------------------------------------------------------------
<cfset reloadAppVars = structKeyExists(application, "app_vars_loaded")/>
<cfif reloadAppVars>
<cflock scope="application" type="exclusive">
<cfif structKeyExists(application, "app_vars_loaded")>
.. do whatever ..
<cfset application.app_vars_loaded = true />
</cfif>
</cflock>
</cfif>
------------------------------------------------------------------------
CF will ensure that my structKeyExist() doesn't screw up memory, and then
the CFLOCK will ensure that I never initialize anything twice. You
_definitely_ need the second check as to whether or not to proceed with the
initialization inside the CFLOCK tag, or you might initialize twice. The
first check is just to alleviate the overhead of processing the CFLOCK tag
when it's unneeded, which will be any request that arrives after the first
request finishes loading the variables. It's those non-initial requests
that arrive before the first request finishes loading the variables that all
the locking is there to deal with.
barneyb
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x12
fax : 360.647.5351
www.audiencecentral.com
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Nat Papovich
> Sent: Monday, July 28, 2003 6:07 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] CFCs in memory
>
>
> Sean, my question moves into the realm of cflock, so it might be OT, but
> I'm wondering...
>
> Shouldn't her/your code snippet instead be like:
>
> <cflock scope="app" type="read">
> <cfif isdefined("application.validateservice")>
> <cfset defined="1">
> <cfelse>
> <cfset defined="0">
> </cfif>
> </>
>
> <cfif not defined>
> <cflock scope="app" type="excl">
> ...application.createobject...
> </cflock>
> </>
>
> In the CF5 days, I got clarification from a CF engineer that the first
> cflock was required even to do just a "lookup" on the application scope
> for purposes of an isdefined(). Do you know of the status of this in
> CFMX? I can't imagine that it's allowed now.
>
> Thanks,
> NAT
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield
> > Sent: Saturday, July 26, 2003 11:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [CFCDev] CFCs in memory
> >
> >
> > This is not sufficient to avoid race conditions. You need the
> > following
> > construct:
> >
> > <cfif NOT IsDefined("Application.ValidateService")>
> > <cflock scope="Application" Timeout="10" THROWONTIMEOUT="No"
> > Type="Exclusive">
> > <cfif NOT IsDefined("Application.ValidateService")>
> > <cfobject component="#request.componentpath#ValidateService"
> > name="Application.ValidateService">
> > </cfif>
> > </cflock>
> > </cfif>
> >
>
> ----------------------------------------------------------
> 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).
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 7/24/2003
----------------------------------------------------------
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).
