> -----Original Message-----
> From: Ryan Sabir 
> Sent: Wednesday, 20 April 2005 2:06 PM
> To:   CFAussie Mailing List
> Subject:      [cfaussie] RE: Managing application constants
> 
> I'd probably use locks as well, just to be safe. But if we are to
> believe the official word from Macrobe, then they are not needed
> unless a possible race condition exists. And I can't see how
> 
> <CFSET application.dsn = "blah">
> 
> Could ever cause a race condition... maybe if you had something like:
> 
> <CFSET application.dsn = "blah">
> <CFSET application.dsnuser = "#application.dsn#user">
> <CFSET application.dsnpass = "bloo">
> 
> But that's just silly now...
> 
Actually the last bit can't cause a race condition by itself. The second
line will _never_ run before or during the first line.
If you want to picture how a race condition may happen, think of a frames
page.
You have, say, 3 frames, and each calls a different cfm page. Each cfm page
includes the Application.cfm file, and is run concurrantly at about the same
time. If you did the three lines above, then its possible that line 2 is run
in one frame while line 1 is being run in another frame. This could cause
problems.
Worse still, imagine if some important application scope variable was built
up over several lines, or even was a list of important variables being built
up in a loop. Imagine that the second frame to hit the server is even doing
all the right things and checking that that variable is defined and is a
list. Its likely that, since it hasn't had to go through all the work of
building up this important list, that it will actually get to a point where
it may try to use this list, yet it is still being built, and then several
lines later, when it checks the list again, it has since been finished, and
has a different set of values in it. How will your code cope with that? 
Another example that I've seen people do is to write a temporary file to the
OS, and then read from it and then delete it. The file always has the same
file name. If two users hit the site and cause the file writing process to
happen at a similar time, they could just as easily get each other's files,
or have the other thread delete their file before they had a chance to read
it.
Framed pages are really good examples of a way to cause a race condition,
but it can also be caused by just having another user hitting your site at
the same time.
All these things are examples of race conditions. You need to be aware of
them and avoid them always.

Regards 

Darren Tracey
Systems Analyst
HR Systems and FastTrack, Web and Integration Services
p: + 61 7 3232 4091 (x64091)
f: + 61 7 3232 4744
e: [EMAIL PROTECTED]
l: Lvl 3, 388 Queen St Brisbane QLD 4000
m: Suncorp IPC IT048, GPO Box 1453, Brisbane QLD 4000





-----------------------------------------------------------------------------------
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its 
related entities ("Suncorp"). 

Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 
55  or at suncorp.com.au.

The content of this e-mail is the view of the sender or stated author and does 
not necessarily reflect the view of Suncorp. The content, including 
attachments, is a confidential communication between Suncorp and the intended 
recipient. If you are not the intended recipient, any use, interference with, 
disclosure or copying of this e-mail, including attachments, is unauthorised 
and expressly prohibited. If you have received this e-mail in error please 
contact the sender immediately and delete the e-mail and any attachments from 
your system.

If this e-mail constitutes a commercial message of a type that you no longer 
wish to receive please reply to this e-mail by typing Unsubscribe in the 
subject line.


---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to