Patrick, The "people in the know" have been very clear that locking in that case is not necessary, nor has it been since at least 6.1. The only time locking is used for the most part anymore in cases where there may be thread race conditions on writing them.
~Dave On 5/10/07, Patrick Steil <[EMAIL PROTECTED]> wrote:
We also simply set all static variables in the request scope... we used to use the application scope, but then when Allaire started telling us we needed to CFLOCK all accesses to the application scope (even though we disagreed with that for 'read only' purposes), we just by passed the whole cflock issue by using the request scope instead... Also "request" is quicker to type than "application" when scoping variables... :) Does anyone know if Adobe is still saying you have to CFLOCK an application variable just to "read" it? I thought that was still the "mantra"... Patrick Steil On 5/10/07, Joe Kelly <[EMAIL PROTECTED]> wrote: > > Someone from Universal Mind (Adobe Professional Services), a > consultant told my employer to put all the appication variable into > the request scope. But for the life of me, I can't remember why! I > believe this is left over from CF5 where we had to lock all our shared > scope variables. > > Also, this from CF7 live docs: > > Using the Request scope for static variables and constants > > This section describes how to partially break the rule described in > the section Referencing caller variables. Here, the function defines > variables in the Request scope. However, it is a specific solution to > a specific issue, where the following circumstances exist: > > * Your function initializes a large number of variables. > * The variables have either of the following characteristics: > o They must be static: they are used only in the function, > the function can change their values, and their values must persist > from one invocation of the function to the next. > o They are named constants; that is the variable value never > changes. > * Your application page (and any custom tags) calls the function > multiple times. > * You can assure that the variable names are used only by the > function. > > In these circumstances, you can improve efficiency and save processing > time by defining your function's variables in the Request scope, > rather than the Function scope. The function tests for the Request > scope variables and initializes them if they do not exist. In > subsequent calls, the variables exist and the function does not reset > them. > > > Either way, it makes the most sense to do it as Dave suggests, set a > stuct and check for it's existance. > > Thanks, > Joe Kelly > > > > On 5/10/07, Dave Shuck < [EMAIL PROTECTED]> wrote: > > I store large chunks of applications in the application scope of my > apps. In > > the case of most ColdFusion frameworks for instance, they are loaded > into > > memory (aka Application scope) on their first load. In our code on > > InstantSpot, we keep entire sites stored in memory. > > > > In a case like this, a simple 8 character string wouldn't make a dent! > :) > > > > ~Dave > > > > > > On 5/10/07, Kevin < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > Dave: > > > > > > > > > > > > I thought that it was better to store as few variables as possible > in the > > application scope. Is that not the case? > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > > > > > > > Kevin Fricke > > > > > > Lone Star Media > > > > > > [EMAIL PROTECTED] > > > > > > Office: (512) 371-1822 > > > > > > Mobile: (512) 626-0528 > > > > > > Fax: (512) 597-0909 > > > > > > Toll Free: (877) 791-7083 > > > > > > > > > > > > http://www.lonestarmedia.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] > > On Behalf Of Dave Shuck > > > Sent: Thursday, May 10, 2007 2:21 PM > > > To: Dallas/Fort Worth ColdFusion User Group Mailing List > > > Subject: Re: [DFW CFUG] Application Variables > > > > > > > > > > > > > > > I wouldn't :) > > > > > > I often include things like this in configuration files rather than > inline > > in the code to keep it more portable, but there is nothing that would > keep > > you from doing this inline in your Application.cfm . > > > > > > I would actually take it a step further though. Just to keep from > setting > > and resetting on your application on every request I set my > application > > scoped variables in a block like this: > > > > > > <cfif NOT StructKeyExists(application,"DawnsDsn")> > > > <cflock > > name="#application.applicationname#_DawnsDsn" > > type="exclusive" timeout="30"> > > > <cfif NOT > > structKeyExists(application,"DawnsDsn")> > > > <cfset application.DawnsDsn = "SuperCoolDsn" /> > > > </cfif> > > > </cflock> > > > </cfif> > > > > > > The second conditional check is to ensure thread safety, which is > not a > > really important issue when it comes to something like setting a DSN, > but > > imo is still good practice. > > > > > > Hope that helps. > > > > > > ~Dave > > > > > > > > > > > > > > > On 5/10/07, Green, Ms. Dawn <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > In an application.cfc page, why would you use request variables to > set > > your datasource, rootname of your site & adminEmail instead of > Application > > variables? > > > > > > > > > > > > What are the pros and cons of doing it either way? > > > > > > > > > > > > Thanks for any help in clarifying this for me. > > > > > > > > > > > > Dawn Green > > > > > > > > > _______________________________________________ > > > Reply to DFWCFUG: > > > [email protected] > > > Subscribe/Unsubscribe: > > > http://lists1.safesecureweb.com/mailman/listinfo/list > > > List Archives: > > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > > http://www.mail-archive.com/list%40dfwcfug.org/ > > > DFWCFUG Sponsors: > > > www.instantspot.com/ > > > www.teksystems.com/ > > > > > > > > > > > > > > > -- > > > ~Dave Shuck > > > [EMAIL PROTECTED] > > > http://daveshuck.instantspot.com > > > _______________________________________________ > > > Reply to DFWCFUG: > > > [email protected] > > > Subscribe/Unsubscribe: > > > http://lists1.safesecureweb.com/mailman/listinfo/list > > > List Archives: > > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > > http://www.mail-archive.com/list%40dfwcfug.org/ > > > DFWCFUG Sponsors: > > > www.instantspot.com/ > > > www.teksystems.com/ > > > > > > > > > > > > > > -- > > ~Dave Shuck > > [EMAIL PROTECTED] > > http://daveshuck.instantspot.com > > _______________________________________________ > > Reply to DFWCFUG: > > [email protected] > > Subscribe/Unsubscribe: > > http://lists1.safesecureweb.com/mailman/listinfo/list > > List Archives: > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > http://www.mail-archive.com/list%40dfwcfug.org/ > > DFWCFUG Sponsors: > > www.instantspot.com/ > > www.teksystems.com/ > > > > > > _______________________________________________ > Reply to DFWCFUG: > [email protected] > Subscribe/Unsubscribe: > http://lists1.safesecureweb.com/mailman/listinfo/list > List Archives: > http://www.mail-archive.com/list%40list.dfwcfug.org/ > http://www.mail-archive.com/list%40dfwcfug.org/ > DFWCFUG Sponsors: > www.instantspot.com/ > www.teksystems.com/ > > -- Patrick Steil _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
-- ~Dave Shuck [EMAIL PROTECTED] http://daveshuck.instantspot.com
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
