Good stuff, Sean. Thank you. I've decided to move the application-scoped variables in this small app into the request scope. They do need to be available to all instances of the application, but I have a feeling they will change more often than I originally anticipated. :)
----- Original Message ----- From: "Sean A Corfield" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, July 13, 2003 4:09 PM Subject: Re: Refresh application-scoped variables > On Sunday, Jul 13, 2003, at 13:21 US/Pacific, Matt Robertson wrote: > > Well, I don't fully understand where you're at applicationwise, but I > > try to use a cached query for most of my application-wide settings. > > Interesting. mm.com uses a couple of techniques: > 1. 'constant' values are set in request scope for every request via an > include file pulled into Application.cfm (e.g., server names - the > include file is auto-generated by the build system). > 2. 'initialized-once' entities are lazily created and stored in shared > scope (we use server scope since we don't share with other apps, most > folks would use application scope). > > The second class of entities includes certain database-derived values, > e.g., localized application strings. These are created by running a > 'bootstrap' script - none of the applications of the server will run > unless the system is bootstrapped and we can re-run the bootstrap if > needed to refresh the server scope entities. > > The bootstrap script can only be executed within the firewall - the > equivalent of having an application admin option to refresh the values > stored in application scope. > > We don't rely on simple cached queries because: > 1. the 'constant' entities come from a file that is auto-generated by a > build script: it would be more effort to have the build system populate > the database and then have the applications pull those back from the > database - it would also require that each server environment used a > different database whereas we often share databases between distinct > testing / development systems. > 2. the more complex entities are calculated from a variety of sources - > sometimes including calling web services - so the calculated entity > needs to cached, rather than the raw data underneath. > > For many, simpler applications, Matt's solution is a very good one - > appropriate caching means the database is hit as rarely as you want it > to be. > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
