I would think it would depend on the usage in the app. For instance I refer to the data source in dozens if not hundreds of places in my apps and I certainly am going to make that a request scope var because I doubt there is measurable overhead in request.ds=blah and it avoids putting locks in nearly every template. If, however, I have a complex struct which I refer to only in a few places I am going to leave that a session or application var and lock it when necessary rather than duplicate the struct every time I hit application.cfm. I don't think a generalization is possible.
----- Original Message ----- From: "Dave Watts" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 12:09 PM Subject: RE: SUMMARY: Request Scope & Follow up Locking Questions > > Plus, my guess is/was that the general server load would be > > balanced out by the reduction of any number of <CFLOCK>s down > > to one (in application.cfm) - tho this could be a wrong-headed > > way of thinking about it. > > > > Anyone got any opinions - even better, stats! - on the impact of > > using this session > request transference technique on server > > performance/load? At what sort of stage / under what circumstances > > would it become a real issue? > > I don't have any handy statistics, but in most of the cases I've > encountered, this technique has been significantly detrimental to > performance. That doesn't mean that it's always a bad thing to do, or that > there's always a better way, just that in most cases, applications have > enough data in the session or application scopes that it's less expensive to > reference the bits of it that you need within separate CFLOCKs than it is to > copy it back and forth to a local nonpersistent scope. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > phone: (202) 797-5496 > fax: (202) 797-5444 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
