no longer entirely applicable
On 5/10/07, Joe Kelly <[EMAIL PROTECTED]> wrote:
Here's how/why it started!
Why It's Wrong to Use Application.dsn in Your Templates
http://cfdj.sys-con.com/read/41791.htm
What Charlie says, goes! But this is from 2001 and no longer applicable.
Thanks,
Joe Kelly
On 5/10/07, Dave Shuck <[EMAIL PROTECTED]> wrote:
> 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/
>
>
_______________________________________________
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/
