Here Here!!
Finally someone seems to understand/agree with my frustration on this point.
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.
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.
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.
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.
At 05:47 PM 1/2/01 -0500, Benjamin S. Rogers wrote:
>> The reason why locking is visible to the developer is because it is much
>> more efficient if the person writing the code, who knows how the
>application
>> should work, decides where to lock and more importantly what type of lock
>to
>> use. If the ColdFusion server had to decide whether to use a ReadOnly or
>> Exclusive lock, there would be enormous performance degradation. It is
>much
>> more efficient if the programmer tells the server which type of lock to
>use.
>> It's the same thing as telling the server which scope a variable is in,
>> instead of having the CF Server go through the variable scope hierarchy.
>
>This is incorrect. ColdFusion should handle all locking internally except
>transactional locking. I have yet to see a reason (aside from developer
>laziness) that an exclusive lock should not occur when a session variable is
>being written or a read lock should occur when a session variable is being
>read.
>
>A much better analogy is that of the RDBMSs we all know and love. In those
>environments, locking is handled by the application. If the developer needs
>to combine a series of commands into a single lock (a.k.a. a transaction),
>then that option is available to the developer.
>
>Unlocked commands can cause dirty data at best and system instability at
>worst. I don't see why this would be the default behavior of ColdFusion as
>opposed to locking all commands except where the developer chooses to
>override this to ensure transactional integrity.
>
>I've argued this point before, both on this list and elsewhere. I maintain
>that the issues with <CFLOCK> are the result of asking a single threaded
>application server to behave as a multithreaded application server. Rather
>than rewrite the portions of the ColdFusion server that did not behave
>properly in a multithreaded environment, they have shuffled off this
>responsibility to ColdFusion developers.
>
>Benjamin S. Rogers
>Web Developer, c4.net
>voice: (508) 240-0051
>fax: (508) 240-0057
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
