> 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??
It should be noted that you still need to put a CFLock (type=read) around an
IsDefined check on a shared scope variable. IMO, this often negates any
performance gain you might achieve by using application variables for
constant values (like DSN names). By setting your constants to the request
scope instead, it's true that those variables are written to memory for
every user, but the RAM is realeased (or whatver the new "Smart Heap"
garbage collector in 4.5 does with it) as soon as the thread is killed. In
the long run, using the request scope seems to be more scalable and stable
than the application scope, because you don't have to worry about locking
all your rights and reads.
------------------------------------------------------------------------------
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.
