Peter,
Actually the reverse is true. You should as a developer place your READ
locks. The way that the code optimizer in CF works it basically puts the
lock around the assignments then processes. You will gain much better
performance by manually placing these then allowing CF to do it for you. The
main issue is that CF has to do the work to parse your file and ensure the
locks are in place, then reprocess the code. By not allowing CF to perform
this, it simply processes your code.
Thanks,
David Sparkman
Application Development Team Leader
Weberize, Inc.
http://www.weberize.com
-----Original Message-----
From: Peter Theobald [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 20, 2000 12:00 PM
To: CF-Talk
Subject: RE: LOCKING revisited...
Richard, you wrote:
>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.
In the case of manual read locking, the server has to parse three tags
(CFLOCK, the assignment, and /CFLOCK), and then it has to perform a lock, a
read, and an unlock. Since the server has the feature of automatic read
locking implemented it must also, for each variable accessed check "What is
the scope of this variable, and is automatic read locking enabled for this
scope?" to which, in this example, the answer is NO, automatic read locking
is NOT enabled.
In the case of automatic read locking, the server has only to parse one tag
(the assignment), and then it has to perform a lock, a read, and an unlock.
Again, for each variable accessed it has to check "What is the scope of this
variable, and is automatic read locking enabled for this scope?" to which,
in THIS example, the answer is YES, automatic read locking is enabled.
It looks like automatic read locking is a winner, hands-down.
If I am right about this, then this implies that automatic read locking
should almost ALWAYS be used. Manual read locking should almost NEVER be
used.
At 09:38 AM 12/20/00 -0700, Richard Kern wrote:
>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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
