Re: row vs row.column level locking

From: Galen Boyer <galen_boyer_at_yahoo.com>
Date: 18 Dec 2005 08:17:01 -0600
Message-ID: <u64pmmidg.fsf@rcn.com>

On Fri, 16 Dec 2005, gogala_at_sbcglobal.net wrote:
> On Thu, 15 Dec 2005 23:09:28 +0000, NetComrade wrote:
>

>> on column level RDBMS will need to track more changes on a sub-row
>> level (e.g. the way UNDO and oracle blocks are architected might have
>> to change).

>
> So, essentially you feel that somebody ought to change name on my bank
> account, while I'm making deposit? Me thinks not. Programming problems
> usually have less ridiculous solutions.

Mladen,

How does a database make sure this doesn't happen? It is quite rare that one locks the bank account table when one is inserting to the transaction table. (I guess the simple design for sake of convo on your example is a bank_account and bank_transaction tables). With these two tables, the update you are worried about could easily happen. It doesn't because a front-end application ties the action together, maybe the code locks this row on purpose, or more probable, the app exclusively lets you see the all the things having to do with you and only those things, as well as other things like that, but the point is that it has little or nothing to do with row-level locking.

-- 
Galen Boyer

Received on Sun Dec 18 2005 - 08:17:01 CST