Personally, I've always used the session scope more heavily than the application scope. However, if you tinker with the gutz ot Tartan, Fusebox, MachII and any of a number of other products, they're all using the application scope HEAVILY. Couple that with the availability of the application scope tools in application.cfc (simply by example) and even Ray Camden's RAM-caching custom tag, and you can really only arrive at one conclusion:
Use it! Use it lots!!! Use the application scope, please, that's WHAT IT'S THERE FOR. I'd recommend an asynchronous process to update the application scope data, i.e. a cron job in CFADMIN to create the data. Use a temp application var that only it knows about to create the data for the application scope every half-hour or whatever, and then at the last second use a named lock to do structInsert(application, "cacheData", cronCacheData,true). I don't have time to write out all the benefits from that method, but they should be fairly obvious. Speed, minimal locking, complete flexibility, abstraction from users, time-based instead of click-based... I used this on a project with a process that genned a PDF containg 6 pages of CFM-created GANTT charts. I'm still uber-proud of that site. Saved me countless amounts of trouble. JPA said that adding RAM to a server is cheaper than development/testing, and he makes a great point. The ONLY GOTCHA with using the application scope: DO it RIGHT. Account for updates and the locking they may or may not require depending on how you implement them... just insure that they happen in an orderly and controlled fashion. Don't use scope locks, use named locks, and if you want to, simply combine static HTML generation with the application scope and cache a completed HTML file. Fusebox4 does it, and Camden's RAM cache does it. I will argue this point with Kam, though. There isn't even romotely enough justification to use getPageScope() here. It's an unsupported feature, and it's to be used at ones own risk... it should require heavy justification before incorporating it into the application. Using it to save a few cycles when it would be just as easy to create a scheduled template, even if it uses cfsavecontent and cffile action="write" is a Really Bad Idea, especially from a standards perspective. I want my code to be as widely runnable and as simple as possible. From a CF perspective that means standards, and to start pulling the underlying Java into CF for no truly justifyable reason is... well... a Really Bad Idea. Laterz, J On Thu, 24 Feb 2005 12:18:33 -0700, Figy, Kam <[EMAIL PROTECTED]> wrote: > I'd be less worried about the speed of serving or ram usage as I would > how long the X minutes between reloads is. Re-grabbing several MB of > data from a database is going to make your site speed crawl while it > happens, not to mention you'd need to carefully cflock the application > scope writes to ensure your content was coherent - so it'd all be > single-threaded as well. > > Overall I agree with the people who are suggesting static publishing, > since a static HTML page is probably as fast as a cf page coming out of > the application scope. As a hybrid solution, or if securing pages is > needed, consider publishing the static pages outside the web root and > using a CF page and getPageContext().include() - which doesn't have CF > parse the include if it's a static type (iirc). > > Kam > -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://cfobjective.neo.servequake.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:196680 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
