Thats it then, no more indecision's?

Only lock when there is a race condition, i.e. <cfset application.somecounter = 
application.somecounter + 1> otherwise no locking necesary in CFMX??

Going once, going twice.........


-----Original Message-----
From: Spike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 November 2003 10:06 AM
To: CFAussie Mailing List
Subject: [cfaussie] RE: CFLOCK


WRONG, WRONG, WRONG!

In CFMX the only time you need to lock the shared scopes (application, 
server, session etc.) is when you have a race condition.

Code like this does not need to be locked:

<cfset application.dsn = "somename">

Code like this _does_ need to be locked:

<cfset application.somecounter = application.somecounter + 1>

i.e. Where you are using the value of a variable on the right hand side 
and left hand side of an assignment.

Locking of file system access is a different story, you still need to 
lock that in the same way as you did in CF5.

Spike

Steve Onnis wrote:

> YES YES YES
>  
> Always lock
> 
>     -----Original Message-----
>     *From:* [EMAIL PROTECTED]
>     [mailto:[EMAIL PROTECTED] Behalf Of *Taco
>     Fleur
>     *Sent:* Tuesday, November 25, 2003 10:39 AM
>     *To:* CFAussie Mailing List
>     *Subject:* [cfaussie] CFLOCK
> 
>     I have followed a few discussions on this subject, but all are
>     contradicting each other or say "it's recommended to lock", I was
>     wondering if anyone could give a firm answer on the following.
> 
>     Do we still need to lock application, server and session variables
>     in CFMX? YES/NO
> 
>     Until recently I set all my application variables like DSN, mappings
>     etc. in the REQUEST scope, so they are available to TAGS and CFCs
>     and whatever.
> 
>     If I ever worked with the SESSION or APPLICATION scope I always made
>     the scope local before I worked with it, like so
> 
>     <cflock timeout="10" throwontimeout="yes" type="readonly"
>     scope="application">
>             <cfset setting = duplicate(application.setting)>
>     </cflock>
> 
>     But for any vars that govern the application this is not possible,
>     because it would mean the variables would not be available to all
>     TAGS and CFCs etc.
> 
>     So I had to lock any call to the vars in TAGS etc. if I wanted to
>     use those scopes, which gets a bit annoying in the end..
> 
>     The REQUEST scope works fine, but it means on every request all the
>     vars get set again, and if I don't need to lock the APPLICATION
>     scope anymore it might be time to move that way./
> 
>     TIA
> 
>     *Taco Fleur
>     07 3535 5072*
>     Tell me and I will forget
>     Show me and I will remember
>     Teach me and I will learn
> 
>     ---
>     You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
>     To unsubscribe send a blank email to
>     [EMAIL PROTECTED]
>     MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
>     http://www.mxdu.com/ + 24-25 February, 2004 
> 
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to 
> [EMAIL PROTECTED]
> MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
> http://www.mxdu.com/ + 24-25 February, 2004

-- 
Stephen Milligan
Software Architect for http://www.bestrates.com.au
MSN: [EMAIL PROTECTED]



---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to