Well... I'm the guy wrote just posted the "Shotgun in a dark room" analogy, but I
confess I do use an Application variable without locking it: #Application.DSN#.
In my Application.cfm I have:
<cfif NOT IsDefined("Application.DSN")>
<cfset Application.DSN = "mydsn">
</cfif>
And in every query I write:
<cfquery name="whatever" datasource="#Application.DSN#">
Now, to further the analogy:
When I open the store in the morning, I get my shotgun and shoot my information into
the dark room called 'Application.DSN'.
No one else will ever ever shoot Application.DSN into this room (I know, 'cause it's
MY room, ie: I wrote the whole site)
Plenty of people will be going in there to read Application.DSN, and they will not be
putting a "Do Not Disturb" sign on the door (they will not be locking their reads)
because I have told them all that I promise to NEVER shoot information into that room
except when I open the store in the morning. They do not put the sign up just to save
the trouble of carrying the sign and hanging it (ie: the trouble of typing up a
CFLOCK).
Now two things can go wrong:
(1) People can be waiting at the door when I open (restart the server) and
theoretically one can get into that room before I can shoot (nearly impossible since
the WRITE comes before the READ in my Application.cfm and everyone's got to run
Application.cfm before anything else, but *theoretically possible* (see below)).
(2) Later myself or another developer on this project can break the promise to not
shoot, for example by adding an administration web page that let's the site admin
change that variable while the site is running.
**Note: how is it even theoretically possible if Application.cfm has the WRITE before
the READ?
User1 and User2 go to the site. They are the first user's to go to the site since the
server has been restarted. They get there at nearly the exact same time.
User1: goes into Application.cfm and executes <cfif NOT IsDefined("Application.DSN")>
finds it NOT defined and goes in to the CFSET. Creates the variable and is about to
set it's value *FREEZE*
User2: another thread gets the CPU and goes into Application.cfm and executes <cfif
NOT IsDefined("application.DSN"> finds it IS defined. A few lines later tries to USE
Application.DSN and it has no value yet! ERROR! *FREEZE*
User1: gets the CPU back and sets the value of the new variable it just created... too
late for our dearly departed User2.
Is this example contrived? Yes.
Is it likely that the multiprocessing would interrupt the thread between creating and
setting a variable? Not likely.
But imagine a more vulnerable situation where instead of just setting ONE variable, it
created a structure and then took many milliseconds filling it up with data. Then the
scenario is a little more dangerous.
At 01:19 PM 10/18/00 -0700, paul smith wrote:
>I thot others here had opined reads do not need to be locked if you're
>ABSOLUTELY, POSITIVELY, SURE the variable won't be written to.
>
>'Course if you're wrong.....
>
>best, paul
>
>At 02:30 PM 10/18/00 -0400, you wrote:
>> > I may be wrong, but my understanding is that reads do not need a
>> > lock, only writes
>
>------------------------------------------------------------------------------------------------
>Archives: http://www.mail-archive.com/[email protected]/
>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
>with 'unsubscribe' in the body to [EMAIL PROTECTED]
---------------------------------------------------------------------------
Peter Theobald, Chief Technology Officer
LiquidStreaming http://www.liquidstreaming.com
[EMAIL PROTECTED]
Phone 1.212.545.1232 x204 Fax 1.212.545.0938
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
