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