<html>
<font size=3>Oh. That may be true, but it is important to point out that
that is wrong and won't work.<br>
<br>
At 01:16 PM 9/14/00 -0400, Mike Amburn wrote:<br>
<blockquote type=cite cite>i'd disagree... if you look back over all the
emails in all of the<br>
threads, you should see that more people only lock writes versus
locking<br>
both. that consensus by the majority is what i was commenting too.<br>
<br>
-mike<br>
<br>
> -----Original Message-----<br>
> From: Peter Theobald
[<a href="mailto:[EMAIL PROTECTED]"
eudora="autourl">mailto:[EMAIL PROTECTED]</a>]<br>
> Sent: Wednesday, September 13, 2000 8:30 PM<br>
> To: [EMAIL PROTECTED]<br>
> Subject: RE: cflocking.. -- ATTENTION -- MY CASE STUDY<br>
> <br>
> <br>
> The consensus was *NEVER* that you didn't have to lock reads.<br>
> Cold Fusion doesn't FORCE locking - it is up to you to lock <br>
> access to an Application variable.<br>
> If you lock the writes but don't lock the reads, then when <br>
> Cold Fusion comes upon a read without a lock it will blindly <br>
> run the read even if there is a (locked) write executing at <br>
> the same time. In other words, locking writes without locking <br>
> reads is completely useless.<br>
> <br>
> All an Exclusive lock does is mark the variable so that <br>
> ANOTHER ATTEMPT TO LOCK IT will have to wait until the lock is
freed. <br>
> It is totally up to YOUR LOCKS to ensure the variable is not <br>
> used by two threads at the same time.<br>
> <br>
> <br>
> At 06:05 PM 9/13/00 -0400, Mike Amburn wrote:<br>
> >i've been following the CFLOCK threads for months and months
<br>
> now. i even<br>
> >started several. unfortunately, the problem is that there <br>
> doesn't seem<br>
> >to be any consensus on what's the end-all, be-all, <br>
> definitive answer to<br>
> >the question "do you have to lock reads or just
writes?" now i can't<br>
> >speak for anyone else, however, i can tell you what we found
<br>
> during load<br>
> >testing and you can do judge for yourself.<br>
> ><br>
> >recently, we hired Allaire to come in and load test (using<br>
> >SilkPerformer) one of our main applications, which is
incredibly<br>
> >database intensive and uses a lot of CFMODULES and <br>
> application variables<br>
> >(no client or session variables). before the test, the <br>
> application ran<br>
> >perfect under normal load. however, as soon as we added
simultaneous<br>
> >load (users requesting the same resources at the same exact
time), we<br>
> >immediately crashed with deadlocks in the database and
application<br>
> >errors. again, runs perfect with all of our customers in <br>
> production, but<br>
> >fails immediately under load.<br>
> ><br>
> >up until this point, our strategy had followed the majority
<br>
> consensus:<br>
> >lock your writes, but not your reads. however, after 14 hours
of<br>
> >analyzing the problems of the load testing between Allaire and
I, we<br>
> >finally just enabled the auto-locking capabilities in CF <br>
> Admin to see if<br>
> >that did anything. (keep in mind, the Allaire rep had warned
before<br>
> >about locking reads) the result after enabling auto-lock? <br>
> not a single<br>
> >problem for the remainder of the engagement! that's right...
<br>
> no errors,<br>
> >no deadlocks, nothing. it functioned under load BEAUTIFULLY with
the<br>
> >auto-lock enabled until we finally got the numbers we wanted
and<br>
> >finished the analysis.<br>
> ><br>
> >so again, i don't want to argue with anyone about their own
strategy.<br>
> >however, seeing it happen right in front of my eyes has me
absolutely<br>
> >convinced WITHOUT A SHADOW OF A DOUBT that allaire is <br>
> COMPLETELY correct<br>
> >when they suggest everyone lock BOTH application writes AND
<br>
> reads. and<br>
> >to tell you the truth, the performance hit for using the <br>
> auto-lock seems<br>
> >to be very minimal (at least on our application) so don't <br>
> worry too much<br>
> >about that if you don't want to go back and insert all the
read-only<br>
> >locks.<br>
> ><br>
> >so that's my two cents. hope it helps. =)<br>
> ><br>
> >-mike<br>
>
>-------------------------------------------------------------<br>
> -----------------<br>
> >Archives:
<a href="http://www.mail-archive.com/[email protected]/"
eudora="autourl">http://www.mail-archive.com/[email protected]/</a><br>
> >To Unsubscribe visit <br>
>
<a href="http://www.houseoffusion.com/index.cfm?sidebarsts&bodysts/cf_t"
eudora="autourl">http://www.houseoffusion.com/index.cfm?sidebarsts&bodysts/cf_t</a><br>
alk or send a message to [EMAIL PROTECTED] with<br>
'unsubscribe' in the body. <br>
<br>
<br>
------------------------------------------------------------------------<br>
---<br>
Peter Theobald, Chief Technology Officer<br>
LiquidStreaming
<a href="http://www.liquidstreaming.com/"
eudora="autourl">http://www.liquidstreaming.com</a><br>
[EMAIL PROTECTED]<br>
Phone 1.212.545.1232 Fax 1.212.679.8032<br>
<br>
------------------------------------------------------------------------<br>
------<br>
Archives:
<a href="http://www.mail-archive.com/[email protected]/"
eudora="autourl">http://www.mail-archive.com/[email protected]/</a><br>
To Unsubscribe visit<br>
<a href="http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk"
eudora="autourl">http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk</a><br>
or send a message to [EMAIL PROTECTED] with<br>
'unsubscribe' in the body.<br>
------------------------------------------------------------------------------<br>
Archives:
<a href="http://www.mail-archive.com/[email protected]/"
eudora="autourl">http://www.mail-archive.com/[email protected]/</a><br>
To Unsubscribe visit
<a href="http://www.houseoffusion.com/index.cfm?sidebarsts&bodysts/cf_talk"
eudora="autourl">http://www.houseoffusion.com/index.cfm?sidebarsts&bodysts/cf_talk</a>
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
</font></blockquote><br>
<br>
-<font
size=3>--------------------------------------------------------------------------<br>
Peter Theobald, Chief Technology Officer<br>
LiquidStreaming <a href="http://www.liquidstreaming.com/"
eudora="autourl">http://www.liquidstreaming.com</a><br>
[EMAIL PROTECTED]<br>
Phone 1.212.545.1232 Fax 1.212.679.8032<br>
</font></html>
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
