I'm curious why you advocated the use of cflock here? I didn't read his original message, only the part your quoted, but it sounds like all he is doing is reading in config data, static type data. How is it a race condition if N threads all set the same values, ie
<cfset foo = 5> I'm not saying the lock is wrong or bad - but I don't see how this is a race condition, unless he has code that does something like <cfset startuptime = now()> Or did I miss that from his original email? ======================================================================== === Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc (www.mindseye.com) Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) Email : [EMAIL PROTECTED] Blog : www.camdenfamily.com/morpheus/blog Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield > Sent: Wednesday, May 28, 2003 6:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] CFCs in memory > > > On Wednesday, May 28, 2003, at 13:17 US/Pacific, Justin Balog wrote: > > I know this information is in the list archive, but I can't > get to the > > site > > right now. What I have done recently is set up a > config.cfc that has > > several methods that get DSN values, application paths, etc. The > > config.cfc > > reads an XML file to set these values. I really want to > avoid having > > to > > read that file for every request, what is a good way to > cache that cfc > > so > > that I don't have to make that read every time. Any input would be > > much > > appreciated. > > Stick it in application scope. Use code like this in Application.cfm: > > <cfif not structKeyExists(application,"configObject")> > <cflock name="myAppNameConfiguration" type="exclusive"> > <cfif not > structKeyExists(application,"configObject")> > <cfset application.configObject = > > createObject("component","config")/> > <!--- any other initialization > you need ---> > </cfif> > </cflock> > </cfif> > > Why the if/lock/if, you might ask? Race conditions. You want > to ensure > only one request actually initializes it. > > Why put the unguarded if around the lock? The vast majority > of requests > will happen after the object has been initialized so you > don't want the > overhead of the lock on all requests. > > Why put the if inside the lock as well? In case another > request hit the > outer if at the same time as this request and went ahead and > locked and > created the object. This way you're guaranteed not to > initialize twice. > > Sean A Corfield -- http://www.corfield.org/blog/ ---------------------------------------------------------- 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).
