> Actually Neil what is says is don't put a CFLOCK around the whole of a
> query, set a temporary variable from your application variable
> and use that
> in your query for the datasource name.
> This is to prevent your application variable being locked for too
> long while
> the query is processed, which could potentially create timeouts for other
> users.
The writer does recommend not using application variables for the datasource
name:
"Although application variables are widely used to store data source names,
it probably makes more sense to avoid using an application variable in this
case. This can be done by instead setting a request scope variable in the
application.cfm file."
> > What are the benefits to using shared scope variables? and what types of
> > variables should be set using that scope?
> >
> The biggest benefit is that you set all your global variables in
> one place.
> If, for instance, you need to change the datasource name, you
> change the one
> <Cfset> and all your queries are using the new datasource.
I could just as easily keep all of my request scope variable in one place.
Without having the drawbacks of locking requirements. It seems that the more
variables that are set using shared scope the greater the performance loss
due to locking requirements.
Let me rephrase my question. Why would I use shared scope variables over
request scope variables?
Neil
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
