Adam is correct in that Sean's code allows unsynchronised reads - something
that may be a huge problem under load in code that matters.
It's easy enough to demonstrate with two templates and a sleep() to
exaggerate the time taken to write inside the excusive lock (to easily
generate the race condition). Assuming you have an cfapplication tag
somewhere, try this (html omitted for clarity):
<!---
Template 1
This code has two separate locks,
setting values in a struct
that should be set and read together
--->
<!--- first block --->
<cflock timeout="10" throwontimeout="yes" type="exclusive"
scope="application">
<cfset APPLICATION.MyStruct = StructNew()>
<cfset APPLICATION.MyStruct.MyText = "One">
<cfset APPLICATION.MyStruct.MyNumber = 1>
</cflock>
<!--- second block --->
<cflock timeout="10" throwontimeout="yes" type="exclusive"
scope="application">
<cfoutput>
Start Sleep @ #timeFormat(now(), "HH:mm:ss")#<br />
<cfflush>
<cfset APPLICATION.MyStruct.MyText = "Two">
<cfset createObject("java",
"java.lang.Thread").sleep(10000)>
Wake up @ #timeFormat(now(), "HH:mm:ss")#<br />
<cfset APPLICATION.MyStruct.MyNumber = 2>
</cfoutput>
</cflock>
<!---
template 2
This code just goes ahead and reads the values, no locking
--->
<cfoutput>Text is #APPLICATION.MyStruct.MyText#; Number is
#APPLICATION.MyStruct.MyNumber#</cfoutput>
Run template 1, and then in another window run template 2 a couple of
seconds later. See that the output in 2 is messed up (half the struct was
set and it was read in the middle of that exclusive lock).
Now wrap a readonly lock around template 2 and see that it will wait until
template 1 finishes and produce the correct results - this is what locking
is for. Also note that it works in two separate windows - also what locking
is for.
-----Original Message-----
From: Matt Robertson [mailto:[EMAIL PROTECTED]
Sent: Monday, 9 May 2005 8:58
To: CF-Talk
Subject: Re: High Load Server... how much more can it take?
[snip]
This is a subject that has been beaten to death over and over again.
IIRC the shared-scope portion of these docs is a fairly recent revision, and
probably placed as an attempt to add some reasonably official clarity to a
subject that -- unquestionably -- is poorly understood by the CF community.
I don't buy that it would wrong at this late date.
-----Original Message-----
From: Adam Churvis [mailto:[EMAIL PROTECTED]
Sent: Monday, 9 May 2005 7:20
To: CF-Talk
Subject: Re: High Load Server... how much more can it take?
[snip]
> "...remember that you are only trying to prevent race conditions
> affecting your code: most read operations do not need to be locked;
> most write operations should be locked (unless the race condition is
> either unimportant or cannot affect the outcome)."
>
> In the case I was positing, a race condition is unimportant and cannot
> affect the outcome.
These are not Macromedia's coding guidelines; these are Sean Corfield's
coding guidelines, and his statement is wrong. The only thing that
synchronizes reads and writes between separate blocks of code is CFLOCK
using either the same scope or the same lock name. Using Sean's approach,
one block of code could read a value that has not yet been properly set by
another block of code.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:206030
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
