OK gentlemen, I've done some research and modifiy my earlier post as
follows:
You can expect that a user's browser is hitting you with 4 simultaneous
threads, AOL uses 2, and the CFSserver is handling these concurrently
because it is mult-threaded. It is very possible that requests to shared
memory variables can and will collide. The result is a hang or corruption
of the variable.
Using the CFLock tag will make sure that access to all variables is single
threaded, this does enable the que as mentioned. This was the approach
befor CF4.5. In 4.5 you have changes both to the use of the lock tag and CF
administrator.
If using CFA, setting single threaded sessions applies only to session
variables, you still have to address server and application variables
separately. This also incurs a perfomance hit if your session variables are
not secured with the CFLOCK tag.
In CFA, automatic read locking CHECKS whether shared variable scope writes
are locked and AUTOMATICALLY locks shared variabel scope reads. If variable
scope writes are not locked, an error is thrown. This option does incur a
performance hit but saves writing CFLOCKS around the variables.
The important change that we seem to be missing is that the syntax is
changed in 4.5. The scope setting can take the value of either application,
server or session and will automatically lock the shared variables at the
correct level. There is also a migration wizard that will scan your files
and convert them to the new syntax.
Conclusion.
all locking efforts (tag or CFA) will manage those simultaneous requests so
they are single threaded for the duration of that call.
You do incur a performance hit with any form of locking, the automatic
locking through CFA requires more processing to check the variables whereas
the explicit declaration is immediately processed.
Without locking you will suffer greater grief than any performance hit
incurred by locking.
Peter's approach is valid for him and the approach as first addressed in the
initial msg of this thread also appears valid, mostly dependent on your
coding style.
With the changes in 4.5 I suspect that Allaire is opening the door to
streamling the code writing, which causes some rethinking of the established
ways of coding. I infer this from the lack of emphasis in speed in the
Allaire documentation but 100% agreement that locking is necessary for
shared variables and database access. BTW the basis for most of the above
came from KB article 14165.
Richard Kern
No offense, but that is nonsense.
My Cold Fusion server is still multi-threaded and multi-processed. It is
still handling every incoming request at the same time.
The only time it will act "single threaded" is when two requests attempt to
read an Application scope variable at the same time. And guess what? That is
exactly the same thing that will happen if you DONT use automatic read
locking, but properly use <CFLOCK> around your Application variables.
Automatic read locking doesn't lock the entire page request, (which would be
single threading the entire server). It locks read access around those
variables that need it.
This is not just an academic issue for me. I have a site running with 10-100
reads from an Application structure on every page. To make the code more
readable, I am using automatic read locking for Application scope variables
instead of <CFLOCK>#Application.myvar#</CFLOCK> tens or hundreds of times on
each page.
On a related note, if I have automatic read locking enabled for Application
scope and I assign a local Variable to an Application variable, it will
essentially make a copy to the pointer. Is CF smart enough then to
automatically lock accesses to this local Variables, which is pointing into
Application space?
< !--- automatic read locking is ON for Application variables --->
< cfset myvar = Application.bigvar>
< cfoutput> #myvar# </cfoutput> < !--- <<<=== IS THIS AUTOMATICALLY
LOCKED?? --->
At 02:13 PM 12/19/00 -0700, Richard Kern wrote:
>It was expressed before that turning this on via the server will
essentially
>drop your application to single thread mode, slowing down all responses
from
>the system. Remember that CF is server side so doing this is like knocking
>on the door and opening it for each request and then closing it before
>anyone else enters, no matter how many people are queued at the door.
>
>---------------------------------------------------------
>
>Ok, given that we all agree:
>
>** Access to shared variables should *ALWAYS* be locked **
>
>Then why on Earth shouldn't I just turn on Automatic Read Locking for
>Application (and Session et al if I use them) scope and only worry about
>write locking in my code?
>
>Why doesn't everyone do that, with the rare exception of some code that has
>unusual locking needs.
>
>I've heard the argument that automatic read locking is a slight performance
>hit. It couldn't be more of a hit than parsing <cflock> </cflock> around
>every access and still doing the read lock anyway!
>---------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
