suggestions. I though that this did the same thing, because the isdefined
is checked inside the lock also? What am I missing?
<cfif not isdefined("application.ComponentInstance.lfInsertData") or
(attributes.refreshnow)>
<!--- if the components are not defined set this var to true --->
<cflock type="EXCLUSIVE" scope="APPLICATION" timeout="60">
<!--- this flag will ensure that components are created by
this thread only --->
<cfif not
isdefined("application.ComponentInstance.lfInsertData")>
<!--- do it --->
</cfif>
</cflock>
</cfif>
At 02:09 PM 6/29/2004, you wrote:
>Your lock will still cause every request that comes in before the first
>request finishes to recreate all the application-scope CFCs, because the
>conditional is _outside_ the CFLOCK tag. In other words, request 1 will
>come in, do the conditional, do the lock, do the initialization. Request 2
>will come in, do the conditional, wait for the lock, get it, do the
>initialization. Repeat for as many requests as come in before the first one
>finishes.
>
>If you move the conditional inside the CFLOCK tag, you'll solve that
>problem. However, then you'll force every request to get that lock, which
>is bad. To solve both problems, use a dual-lock, dual-conditional setup.
>Here's how we do it:
>
><cflock scope="application" type="readonly" timeout="10">
><cfset reload_app_vars = NOT structKeyExists(application,
>"app_vars_loaded") />
></cflock>
>
><cfif reload_app_vars>
><cflock scope="application" type="exclusive" timeout="60">
><cfif NOT structKeyExists(application, "app_vars_loaded")>
>
><!--- all kinds of initialization crap that I cut out --->
>
><!--- record that we successfully loaded all the variables --->
><cfset application.app_vars_loaded = true />
></cfif>
></cflock>
></cfif>
>
>The first CFLOCK is read-only, so it won't generate any contention on
>requests after the first, and sets a local variable about whether
>initialization is needed. The first conditional skips initialization if
>it's not needed. The second CFLOCK single threads access to the
>initialization code. The second conditional checks to see if initialization
>is still needed, now that this request is the ONLY request that could
>possibly influence the outcome of that decision. That's the part you're
>missing, which is allowing multiple requests to initialize the application,
>thereby slowing it down.
>
>I'm also using a dedicated variable for indicating whether the application
>is loaded or not, rather than one of the actual application variables. I'd
>recommend that, just for clarity's sake.
>
>A side benefit of this, is that if you never write to any of the application
>variables that you set in the initialization block, you never have to lock
>any of the reads anywhere in the application. Keep in mind that instance
>variables of application-scoped CFCs are actually application-scope
>variables, so they count. However, if access to the instance variables is
>synchronized inside the CFC using instance-specific named locks (a good
>idea), then you needn't worry about them
>
>Cheers,
>barneyb
>
> > -----Original Message-----
> > From: Brook Davies [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 29, 2004 1:49 PM
> > To: CF-Talk
> > Subject: RE: Debugging CFMX
> >
> > Thanks for the feedback Barneyb, I appreciate it. I'm having massive
> > trouble getting this app to start-up under load. I have
> > already de-selected
> > the save class files option because there were LOTS of class
> > files, and I
> > think this helped a bit.
> >
> > There is definitely something fishy going on, but I am not
> > sure where it is
> > exactly. My application contains two parts, they share an
> > application.cfm
> > file, but within that application.cfm file there are two different
> > cfapplication tags. The main application is all pages other
> > than a single
> > cfm page that is used to handle 'external' requests. So, in
> > pseudo code,
> > the application.cfm does this:
> >
> >
> > <cfif cgi.PATH_INFO is "/external_requesthandler.cfm">
> >
> > <!--- external request application framework --->
> > <cfapplication name="logiformsV2_external">
> >
> > <!--- do initialization here --->
> >
> > <cfelse>
> >
> > <!--- site & member area application --->
> > <cfapplication name="logiformsV2" setclientcookies="yes"
> > clientmanagement="yes" clientstorage="logiforms_clientvars">
> >
> > <!--- do initialization here --->
> >
> > </cfif>
> >
> > The reason I am pointing this out, is because one of the
> > applications, the
> > site logiformsV2, starts up much more smoothly than the
> > external request
> > handling site (which essentially handles form submissions)
> > which can hang
> > forever...
> >
> > If we focus on the 'problem' app, the initialization code in the
> > application.cfm looks like this:
> >
> > <cfif not isdefined("application.ComponentInstance.lfInsertData") or
> > (attributes.refreshnow)>
> > <!--- if the components are not defined set this var to true --->
> > <cflock type="EXCLUSIVE" scope="APPLICATION" timeout="60">
> > <!--- this flag will ensure that components are
> > created by this
> > thread only --->
> > <cfif not
> > isdefined("application.ComponentInstance.lfInsertData")>
> > <cflog file="startupLog" date="yes" text="Running
> > Instantiation of external application components">
> > <cfobject component =
> > "lfcomponents.triggers.triggerAction" name =
> > "application.ComponentInstance.triggerAction">
> > <cfobject component =
> > "lfcomponents.lfinsert_record" name
> > = "application.ComponentInstance.lfInsertData">
> > <cfobject component =
> > "lfcomponents.lfincrement" name =
> > "application.ComponentInstance.lfincrement">
> > <cfobject component =
> > "lfcomponents.lfcreatetable" name =
> > "application.ComponentInstance.lfcreatetable">
> > <cfobject component =
> > "lfcomponents.lfdescript_string"
> > name = "application.ComponentInstance.lfdescript_string">
> > </cfif>
> > </cflock>
> > </cfif>
> >
> > Now, my startup log file only contains one line, which I
> > guess indicates
> > that this is working, and only being run by one thread.
> >
> > "Information","jrpp-18","06/29/04","12:20:49","LOGIFORMSV2_EXT
> > ERNAL","Running
> > Instantiation of external application components"
> >
> > But, for whatever reason, this app still has a hell of a time
> > starting up.
> > Sometimes the thread count will grow and grow and the
> > processor will sit at 0!
> >
> > If I set the server's timeout to 20 seconds, that seems to
> > help get the
> > server started, about 10 threads will timeout, but then the
> > server will get
> > started. The threads that timeout are usually,
> > cfquery,cfmail and cfloops
> > in various places. The really strange thing is that, on the
> > first run, if
> > I look at the template execution stack and look for what took
> > so bloody
> > long, there is usually always one template that took a really
> > long time.
> > But this changes from time to time, and if I manually exclude
> > that template
> > from the startup sequence, another template (unrelated)
> > becomes the long
> > running template....
> >
> > Anyways, I got some serious problems, and If I don't fix em,
> > I ain't going
> > to Mexico this summer! lol
> >
> > I wish there was a way to get a more detailed look at what
> > the server is
> > doing internally while it was starting up, like what
> > templates/code it is
> > hanging on etc...
> >
> > Brook Davies
> > logiforms.com
>
>----------
>[<http://www.houseoffusion.com/lists.cfm/link=t:4>Todays Threads]
>[<http://www.houseoffusion.com/lists.cfm/link=i:4:168619>This Message]
>[<http://www.houseoffusion.com/lists.cfm/link=s:4>Subscription]
>[<http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=905.825.4>Fast
> Unsubscribe] [<http://www.houseoffusion.com/signin/>User Settings]
>[<https://www.paypal.com/cgi-bin/webscr?amount=&item_name=House+of+Fusion&business=donations%40houseoffusion.com&undefined_quantity=&cmd=_xclick>Donations
>and Support]
>
>----------
><http://www.houseoffusion.com/banners/view.cfm?bannerid=36>
>[]
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
