<html>
<font size=3>Here Here!!<br>
Finally someone seems to understand/agree with my frustration on this
point.<br>
<br>
The way Cold Fusion handles locking is just DUMB. It is ASKING for
application instability, which in the long run will ruin the reputation
of Cold Fusion as a web development environment. It is especially bad
when you consider that much of the focus of Cold Fusion is to allow less
experienced programmers to produce excellent complex web sites very
rapidly.<br>
<br>
This is also the reason I have been ranting about Automatic Read locking
on this list lately. It works. There is NO performance penalty over
properly used manual read locking. I am sure the ONLY reason it isn't at
least the default if not the ONLY choice is simply a legacy from older
versions of Cold Fusion.<br>
<br>
I submit that the "right way" is to use Automatic Read locking
for those shared scopes that you use in your application. Use manual
write locking for writes. I challenge anyone to give an example where
this ISN'T the right thing to do from a complexity or performance point
of view.<br>
<br>
And I also agree with Benjamin that automatic EVERYTHING locking,
implemented properly inside the Cold Fusion server, would be the true
"right way" to do it.<br>
<br>
At 05:47 PM 1/2/01 -0500, Benjamin S. Rogers wrote:<br>
<blockquote type=cite cite>> The reason why locking is visible to the
developer is because it is much<br>
> more efficient if the person writing the code, who knows how
the<br>
application<br>
> should work, decides where to lock and more importantly what type of
lock<br>
to<br>
> use. If the ColdFusion server had to decide whether to use a
ReadOnly or<br>
> Exclusive lock, there would be enormous performance
degradation. It is<br>
much<br>
> more efficient if the programmer tells the server which type of lock
to<br>
use.<br>
> It's the same thing as telling the server which scope a variable is
in,<br>
> instead of having the CF Server go through the variable scope
hierarchy.<br>
<br>
This is incorrect. ColdFusion should handle all locking internally
except<br>
transactional locking. I have yet to see a reason (aside from
developer<br>
laziness) that an exclusive lock should not occur when a session variable
is<br>
being written or a read lock should occur when a session variable is
being<br>
read.<br>
<br>
A much better analogy is that of the RDBMSs we all know and love. In
those<br>
environments, locking is handled by the application. If the developer
needs<br>
to combine a series of commands into a single lock (a.k.a. a
transaction),<br>
then that option is available to the developer.<br>
<br>
Unlocked commands can cause dirty data at best and system instability
at<br>
worst. I don't see why this would be the default behavior of ColdFusion
as<br>
opposed to locking all commands except where the developer chooses
to<br>
override this to ensure transactional integrity.<br>
<br>
I've argued this point before, both on this list and elsewhere. I
maintain<br>
that the issues with <CFLOCK> are the result of asking a single
threaded<br>
application server to behave as a multithreaded application server.
Rather<br>
than rewrite the portions of the ColdFusion server that did not
behave<br>
properly in a multithreaded environment, they have shuffled off
this<br>
responsibility to ColdFusion developers.<br>
<br>
Benjamin S. Rogers<br>
Web Developer, c4.net<br>
voice: (508) 240-0051<br>
fax: (508) 240-0057<br>
<br>
<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
