Thanks to make me understand... but I'm just questionning on one thing...
Let's take this example...
I have this in my Application.cfm
<cfif NOT IsDefined("Application.MailService")>
<cflock scope="Application" Timeout="10" THROWONTIMEOUT="No"
Type="Exclusive">
<cfif NOT IsDefined("Application.MailService")>
<cfobject component="#request.componentpath#MailService"
name="Application.MailService">
</cfif>
</cflock>
</cfif>
And I have this in my MailServiceFacade.cfc
<cfset DeleteMailOut = Application.MailService.DeleteMail(Application,
Session,
Request,
ARGUMENTS.in_callername,
ARGUMENTS.in_language_cd,
ARGUMENTS.in_nickname,
ARGUMENTS.in_mail_id)>
Let's say my Application time out is at every 00:00 AM... and 00:00AM
comes...
1 - The application.cfm is instantiating the MailService CFC into the
Application.MailService
2 - 1000 users are clicking at 00:00 AM to delete their emails
(Application.MailService.DeleteMail)... at exactly the same time that the
creation of the Application.MailService variable is being created.
3 - Is the java runtime will take care to say to these 1000 users...
WAIT.... until the Application.MailService is created! or it will failed!...
or it will do both!
As you can see I'm thinking big for my site, if I have 100 000 users’ on
lines... there's a chance that it could appended... and I don't want to
received 1000 emails because I created an Error Service component...
Stef
----- Original Message -----
From: "Barney Boisvert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 9:34 PM
Subject: RE: [CFCDev] CFCs in memory
> 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).
>
----------------------------------------------------------
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).
