The easiest way to see that there are no problems with reading a application
or any other global var with out locks (no writes) given big enough text you
can have everyone read the same news paper. But if you are trying to read
the newspaper at the same time someone is making changes to the news paper
you might not get the correct info or not get anything at all (reading
exactly where they are erasing). Now imagine 2 people tring to make changes
to a single word on a sheet of paper at the same time and how they will bump
into each other. Locking gives the first person there rights to write and
everyone (read and writes) have to wait if reads are next in line the all
reads happen then when they are done the next person who wants to write can
then make there changes. So with only reads the only way you are going to
crash is from Load on the server and that is going to happen even with out
variables.
Daniel
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 8:42 PM
To: Fusebox
Subject: RE: the $5 bet - crash a server with unlocked application scope
READs
Thank you, master Erik. This is the answer I seek.
> -----Original Message-----
> From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 25, 2001 5:05 PM
> To: Fusebox
> Subject: RE: the $5 bet - crash a server with unlocked application scope
> READs
>
>
> It's an interesting topic, and really good timing for
> this to come up. I was at a CFUG sponsored conference,
> CF-Southwest yesterday. And the mighty B.F. was there,
> and talked quite about about this very subject. I do
> remember him answering a question with something like:
>
> "no, if you only read application variables, you do
> not need to lock them."
>
> Maybe I was drunk, but I don't remember drinking anything
> but a coke at lunch.
>
> What I did pull out of that talk, though, was that you
> can not corrupt the server's memory with reads alone.
> Only writing to a variable while it is being read will
> cause the pcode exceptions you so diligently seek.
>
> -Erik
>
> > -----Original Message-----
> > From: Nat Papovich [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 25, 2001 3:08 PM
> > To: Fusebox
> > Subject: RE: the $5 bet - crash a server with unlocked
> > application scope
> > READs
> >
> >
> > As a matter of fact I DO have a magical CF server that never
> > crashes, Erik.
> > You have one too? It's an Amiga.
> >
> > To prove a point, I did not mention the <cfif not
> > IsDefined("application.var")> tag before the application read
> > because I
> > wanted to imagine a case of ONLY reads.
> >
> > I might be seeming weird about it because I'm trying to get
> > the skinny on
> > exactly how locking works - something that I'm not even sure
> > Allaire knows
> > too much about. I think I pretty well have my noggin around it, but if
> > someone shows me the case of unlocked read-only access to a
> > shared scope
> > variable causing problems, then it's back to the drawing board for me.
> >
> > NAT
> >
> > > -----Original Message-----
> > > From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 25, 2001 1:24 PM
> > > To: Fusebox
> > > Subject: RE: the $5 bet - crash a server with unlocked
> > application scope
> > > READs
> > >
> > >
> > > > build. During some of this checking, I re-initialize the
> > application
> > > > variables, for good measure. This is the only time the
> > > > application variables
> > > > ever get written. There is no code anywhere else to do it,
> > > > and I am always
> > > > the only one on the admin area.
> > >
> > > That sounds flakey. What if CF restarts? ba-bye
> > application variables.
> > > Perhaps you have a magical machine with 100% up time?
> > >
> > > A read-only lock only adds overhead if there is an exclusive lock on
> > > the scope. Out of curiosity, why are you being so wierd about it?
> > >
> > >
> > >
> > >
> > >
> > >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
