from what i understood about locking and memory-resident variable access in
cf, this will never produce errors. If you put read locks around all of
these reads, cfserver will perform the actions no differently. 5 million
read locks with the same scope and applicationname can all be running at
the same instant. It is not until writes are introduced into the mix that
cflock starts preventing things from happening at the same time. Funky CF
errors occur if two writes occur simultaneously or a write and a read occur
simultaneously, and this is what the cflock tag prevents. So I'll give 2
to 1 on another $5 bet to anyone that thinks they can produce variable
access errors along the lines of nat's suggestion.
An interesting idea might be to see if we get errors by having one of those
framesets running variable writes, and the others all running reads. then
we'd be sure to have reads running at the same time as writes.. this is the
most likely cause of errors of this type.. the cached stuff being refreshed
while another request is reading it.
On a similar topic i had an idea recently. I cache my stuff in the
application scope and duplicate it to the request scope for use. Something
that theoretically could happen if you're NOT doing stuff this way and
accessing your application cached stuff directly from the application scope
(with proper locking) is this: Your page request runs, the application
variables are checked for existing and do exist.. later in the page
request you attempt to use some applicaiton variable, but between the
initial check and this part of the page request (a few milliseconds) the
daily timeout has occurred and now this customer gets an error. If you had
copied them to the request scope right after you checked their existance,
they would still be present in the request scope even though the
application scoped structure timed out during this page request. make sense?
--Ken
At 10:32 AM 4/25/01 -0700, you wrote:
>The subject pretty much says it all, but I'd like to see someone crash a
>server or produce a pcode exception error or (getting easy here) produce one
>of those "donteverusethisvariablenameinyourcfmlcode123456789" errors by
>using concurrent unlocked application scoped variable reads.
>
>I've already built a frameset with 50 frames, each frame page looping over
>the output of an application variable 100,000 times. Now out of those 5
>million read hits to my application variable that occur within the space of
>maybe 10 seconds, NONE produce any error whatsoever, no matter how many
>times I try. Of course, doing 5 million WRITE hits will produce errors
>pretty quickly, and eventually destroy my server. Anybody have Silk or Load
>Runner?
>
>I'm not interested in session variable locking issues, nor with cfquery's
>cachedwithin attribute. I only want to see application variable reads
>causing detrimental effects to a CF server.
>
>$5 to be delivered at the next major CF conference, should I be able to
>reproduce the error on my machine (single proc p3-650, 256 mb ram, CF 5 Beta
>3, PWS, NT 4 Workstation SP6). The cash only goes to the first person...
>
>Good luck - I don't think it's possible!
>
>NAT
>Nat Papovich
>Webthugs Consulting
>ICQ 32676414
>"If it was hard to write,"
>says the Real Programmer,
>"it should be hard to understand."
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
