[thelist] CF: Determining which DB used.

.jeff jeff at members.evolt.org
Wed Sep 12 13:27:31 CDT 2001


joshua,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Joshua Olson
>
> out of curiosity, how often do you find yourself using
> the global scopes (application, server, etc) to store
> data rather than just initializing into variables which
> expire at the end of the request?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

personally, almost never.  once in a while i'll run into a situation where
i've got a query that returns information i need for every request.  with
the likelihood of the resultset changing, i avoid the application scope as
it's difficult to trigger it to reset.  so, instead, to reduce the load on
the database server, i'll use a cached query.  this doesn't alleviate the
problem of resetting the resultset, but at least it'll do it automatically
as soon as the cache timeout occurs.  during peak times you'll see the most
benefit from this as the cache timeout should be long enough to guarantee
cached queries for most, if not all of your visitors.  during non-peak times
visitors will hardly notice the time it takes for the query to run as the
server has more resources to devote to their request.

that being said, i'd like to add that i don't think i can *ever* recall
using the server scope to store information and only using it once or twice
to retrieve preset information.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From a development standpoint it seems *much* quicker
> to have a cfinclude file that does a bunch of cfsets
> to a "local" scope instead of having to worry about
> locking all the dang time.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

agreed.  i'd imagine there's a performance gain by not temporarily
single-threading the server so you can read or write inside those locks.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/






More information about the thelist mailing list