When I get the chance I will compare timings for:
<
!---------------------------------------------------------------------------------------------------------------------------->
< !--- manual locking. Automatic read locking for Application scope turned OFF in
administrator --->
< cflock Application exclusive>
< cfset Application.test="hello">
< / cflock>
< cfloop > 1000 times
<cflock read Application >
< cfset Variables.tmp = Application.test >
< / cflock >
< / cfloop>
<
!---------------------------------------------------------------------------------------------------------------------------->
< !--- automatic read locking turned ON in administrator for Application scope --->
< cflock Application exclusive>
< cfset Application.test="hello">
< / cflock>
< cfloop > 1000 times
< cfset Variables.tmp = Application.test >
< / cfloop >
<
!---------------------------------------------------------------------------------------------------------------------------->
At 12:25 PM 12/20/00 -0500, Hal Helms wrote:
>I wonder, has anyone actually done any metrics on this to see if automatic
>read locking imposes a penalty (that's the conventional wisdom) and if so,
>how much of one?
>
>Hal Helms
>== See www.ColdFusionTraining.com for info on "Best Practices with
>ColdFusion & Fusebox" training, Jan 22-25 ==
>
>
>-----Original Message-----
>From: Peter Theobald [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, December 20, 2000 11:05 AM
>To: CF-Talk
>Subject: RE: LOCKING revisited...
>
>
>You just did read locking by hand. Your code has one place where it accesses
>an Application variable, and you properly surrounded it with a lock. If you
>were to turn on automatic read locking of Application scope the server would
>put a read lock around the expression application.myvariable for you and you
>wouldn't have to do the lock manually.
>In your example, it wouldn't really matter which way you chose, as it's only
>ONE access to an Application variable on the whole page. In my example I
>have between 10 and 100 accesses TO DIFFERENT Application variables on the
>page, and would have to put that three line locked/access/unlock expression
>around each one.
>
>I am suggesting that EVEN IN YOUR EXAMPLE it will take longer for the server
>to parse three tags and do a read lock than it would to parse ONE tag and do
>a read lock (automatically).
>
>At 10:51 AM 12/20/00 -0500, Evan Lavidor wrote:
>>Are you saying that if I do the following:
>>
>> <cflock scope="application" timeout="30" type="readonly">
>> <cfset variables.myvariable = application.myvariable>
>> </cflock>
>>
>>and then later on down the page I do the following:
>>
>> <cfif variables.myvariable GT 10>
>> do something
>> </cfif>
>>
>>then I haven't solved the locking "issue"? I thought that by setting my
>>application variables to local variables within a lock, I could now
>>reference the local variables with abandon and not have to worry about
>>locking any more. Is this not the case?!?
>>
>>Thanks,
>>
>>Evan
>>
>>> -----Original Message-----
>>> From: Peter Theobald [mailto:[EMAIL PROTECTED]]
>>> Sent: Wednesday, December 20, 2000 10:21 AM
>>> To: CF-Talk
>>> Subject: RE: LOCKING revisited...
>>>
>>>
>>> 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.
>>> >
>>> >Richard Kern
>>> >
>>> >-----Original Message-----
>>> >From: Peter Theobald [mailto:[EMAIL PROTECTED]]
>>> >Sent: Tuesday, December 19, 2000 1:16 PM
>>> >To: CF-Talk
>>> >Subject: LOCKING revisited...
>>> >
>>> >
>>> >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!
>>> >
>>> >
>>> >
>>> >-----------------------------------------------------------------
>>> ----------
>>> >Peter Theobald, Chief Technology Officer
>>> >LiquidStreaming http://www.liquidstreaming.com
>>> >[EMAIL PROTECTED]
>>> >Phone 1.212.545.1232 x204 Fax 1.212.545.0938
>>> >
>>> >To put this contact information into your Palm device, click here:
>>> >http://www.coola.com/cgi-bin/addinfo.cgi?pid=15803&rid=972879910&type=A
>>> >
>>>
>>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
