It would need some memory metrics against it I suppose - what would be more efficient: a large 700 resultset residing in memory all the time or X amount of calls asking for said query on each request (it is required) which resides in memory for the duration of the request... Lots of factors to consider however such as scale, query freshness/size etc..
"This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com -----Original Message----- From: James Holmes To: CF-Talk Sent: Sun Nov 12 14:13:51 2006 Subject: Re: Advice about query caching Oh agreed - it's often better use of resources to query the DB rather than to perform elaborate caching when each user needs different results etc. It depends on how big the query is, how much memory is in the server, where the DB is and so many other things. I usually cache the content resulting from the queries instead, using Ray's Scopecache. On 11/12/06, Robertson-Ravo, Neil (RX) <[EMAIL PROTECTED]> wrote: > Indeed, not that I would say holding a recordset in the app scope is good > practice (unless, as stated, the freshness is not an issue) there are > probably loads of apps out there which do it and with the lack of any "best > practice" docs other than advice and preference it would probably work. > > > > > > > > "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, > Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, > Registered in England, Number 678540. It contains information which is > confidential and may also be privileged. It is for the exclusive use of the > intended recipient(s). If you are not the intended recipient(s) please note > that any form of distribution, copying or use of this communication or the > information in it is strictly prohibited and may be unlawful. If you have > received this communication in error please return it to the sender or call > our switchboard on +44 (0) 20 89107910. The opinions expressed within this > communication are not necessarily those expressed by Reed Exhibitions." > Visit our website at http://www.reedexpo.com > > -----Original Message----- > From: James Holmes > To: CF-Talk > Sent: Sun Nov 12 13:50:29 2006 > Subject: Re: Advice about query caching > > Huh? Once it's in the Application scope it can stay there for as long > as you want. > > On 11/12/06, Doug Brown <[EMAIL PROTECTED]> wrote: > > Cachedwithin does load the dataset into server memory but stays there > until > > it times out, and then refreshes. Setting it in the application scope > > requires you to query the database for the data to put into that scope and > > store it on every request. That is my understanding. > > > -- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:260066 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
