Re: row vs row.column level locking

From: Galen Boyer <galen_boyer_at_yahoo.com>
Date: 18 Dec 2005 08:09:02 -0600
Message-ID: <uaceymiqf.fsf@rcn.com>

On Fri, 16 Dec 2005, postbus_at_sybrandb.demon.nl wrote:
> On Fri, 16 Dec 2005 18:43:52 GMT, netcomradeNSPAM_at_bookexchange.net
> (NetComrade) wrote:
>

>>Your name will most likely be stored in a separate table if the table
>>is normalized :) The PK on your account would be the account#. Unless
>>there is a additional business logic, I see no issues (on the db side)
>>of updating your name while you're making a deposit.

>
> Obviously this is an example that doesn't support your 'case' at all.
> How about a different example:
> A call has a start date, and based upon a SLA, a call to fix date.
> What about one process updating the call to fix (the algorithm is
> quite complicated, so it can't be set upon insert) and another process
> updating the start date?
> Should that be allowed?

Isn't this example showing a dependency of start_date and fix_date irrespective of the Primary Key, which then violates database design principles?

> If that, according to you, shouldn't be allowed, please admit the
> concept of column level locking is quite often completely absurd.

I think that column level locking holds loads of merit. In a 3rd normal form database, column level locking would make all sorts of sense. Each attribute is based solely on the PK and just the PK, correct? There are no interdependencies between columns, correct? Then, why couldn't one guy update one attribute while another update a different attribute? Why is row-level better than page level? There are all sorts of reasons, mainly having to do with the fact that one is updating a small section of the page being locked, so why lock the whole damn page, just lock the row! Well, in general, one is normally updating a small number of columns so why lock the whole damn row!

-- 
Galen Boyer

Received on Sun Dec 18 2005 - 08:09:02 CST