As a coding practice I would advise specifically declaring all internal 
variables using the <cfset var name=.../> syntax for a object/function 
that is instanated in the application scope. I know in C++ this could be 
an issue since variables may live in the heap space or on the stack. Using 
this syntax means the variable is declared in the stack. Hence, you get a 
fresh copy of the variable with each function call. Otherwise you could 
create a race condition (at least in C++) where two threads are changing 
the value within the function. Again I'm assuming CF / Java works the same 
way.

If anyone knows if this is an issue for CF/Java sound off. I suspect it 
is. As far as locking, you most likely would not need to implement 
locking, unless you are modifying a global variable.

Sincerely,

Brooks Wilson
Never miss a good chance to shut up. - Will Rogers




 Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta 
Georgia 30309-4470 
404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED]

 



[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
09/13/2007 02:57 PM
Please respond to
[email protected]


To
[email protected]
cc
[EMAIL PROTECTED], [email protected]
Subject
Re: [ACFUG Discuss] application-scoped function







Ditto, that's not an "application-scoped" function nor would any params 
used in an Application.cfc or cfm be application-scoped unless they are 
scoped with the application scope ie. application.parameter="frogs" (which 
you can scope anywhere). 

Man, thats a lot of scopping. 






shawn gorrell <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 
09/13/2007 02:47 PM 

Please respond to
[email protected]


To
[email protected] 
cc

Subject
Re: [ACFUG Discuss] application-scoped function








That shouldn't be an issue since it won't be reading or writing to shared 
scope variables. 

----- Original Message ----
From: JON SMITH <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, September 13, 2007 2:16:59 PM
Subject: [ACFUG Discuss] application-scoped function

Scenario question: Suppose I have a function called calcArea that takes in 
a length and a width and returns a calculated area (it does not change any 
variables; it simply returns a result). I am considering placing it in the 
application scope for ease of use and faster response time. I can find 
online that I need to lock any calls to an application variable to prevent 
race conditions; does that same logic hold true for an application-scoped 
function that simply returns a result as well? Will my application fail 
out if two different users try to call the application-scoped calcArea 
function at the same time without calling a cflock first?



I realize one function like this could be easily placed in the 
Application.cfm, but if I were to create a full blown object with a few 
dozen calculation functions in it, I would think it would be faster to 
scope it than to recreate the object over and over.



Any advice appreciated.



Jon





-----------------------------------------

NOTICE: This communication is intended only for the person or
entity to whom it is addressed and may contain confidential,
proprietary, and/or privileged material. Unless you are the
intended addressee, any review, reliance, dissemination,
distribution, copying or use whatsoever of this communication is
strictly prohibited. If you received this in error, please reply
immediately and delete the material from all computers. Email sent
through the Internet is not secure. Do not use email to send us
confidential information such as credit card numbers, PIN numbers,
passwords, Social Security Numbers, Account numbers, or other
important and confidential information.


------------------------------------
Annual Sponsor FigLeaf Software - http://www.figleaf.com

To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------





------------------------------------------------------------- 
Annual Sponsor - Figleaf Software 

To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink 
------------------------------------------------------------- 

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

Reply via email to