I have thought about this some, and I have not come up with any good reasons to use
the APPLICATION and SESSION shared scope variables.
Instead of application variables, use request variables.
Instead of session variables, use client variables (from a DB, not the
registry)
Instead of server variables: use? (never used 'em before!)
Once I realized how to use request and client scopes, the locking overhead, the extra
thinking and programming involved, and the generally poorly understood principles of
locking variables by CF programmers (including myself) , seems to outweigh other
considerations.
I decided a couple of week ago, that unless I hear other arguments to the contrary, at
this point, I am not going to use the application and session scope for any future
projects.
Use request and client variables, and then never have to worry about locking your
variables again!
Douglas Smith
At 10:09 AM 9/27/00 -0400, Neil Peaslee wrote:
>> 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.
====================================================
Douglas M. Smith - Database Architect/Web Integration Specialist
====================================================
TeraTech Inc - Tools for Programmers(tm)
VisualBasic, Web (ColdFusion and ASP), Math and Statistics,
Access, SQL, programming tools & consulting
100 Park Ave, Suite 360, Rockville MD 20850 USA
Voice: 301-424-3903, Fax: 301-762-8185
http://www.teratech.com
====================================================
Email: [EMAIL PROTECTED]
Mobil/Cell Phone: (240) 601-5520
ICQ: 41044319
====================================================
Do you need a group calendar or scheduler?
How about a free ColdFusion Tag and Function Reference?
Go to http://www.teratech.com/freestuff.cfm
====================================================
------------------------------------------------------------------------------
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.
