Hi Neil,
>
> 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."
>
Whoops! Must have skipped that bit... Don't know why they think that....
>
> 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?
>
You could just as easily set them all as requet scope, but that would mean
that every user on your site would use a piece of the memory on your server
and use the server *everytime* they hit the application.cfm to set those
variables. If you use a CFIF that checks the status of a key application
variable around your CFSETs then all you do it hit the server everyone once
in a while and use one little bit of memory for the global variables.
Does that make any sense??
Regards
Stephen
------------------------------------------------------------------------------
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.
