> 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
