Re: implementing a database log
Date: Tue, 22 Apr 2008 11:39:17 -0400
"David BL" <davidbl_at_iinet.net.au> wrote in message
> On Apr 22, 6:58 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Christoph Rupp" <cruppst..._at_gmail.com> wrote in message
>> > Brian,
>> > On Apr 21, 11:00 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> >> Why not go with #4:
>> >> 4. a physical log based on modified rows. Whenever a row is modified,
>> >> added
>> >> or removed, it is logged. Then you could also implement row
>> >> versioning--just add a row version field to the physical rows. I
>> >> believe
>> >> that this what snapshot isolation is built on.
>> > It's not an SQL database, i don't even have the notion of "rows", but
>> > basically i think your #4 is the same as my #1 or #2.
>> No, it isn't. #1 requires the logging of additional records that may not
>> have been affected by an update. #2 doesn't log the entire changed
>> but only bits and pieces. I would think that limiting the units of
>> to individual records--entire records--would simplify the process of
>> and isolating units of work while at the same time guaranteeing
> I don't think an atomic unit of work is always associated with a
> change to an individual record. Are you suggesting transactions to
> define arbitrarily large units of work aren't needed?
No, that's not what I'm suggesting. What I'm suggesting is that the atomic unit of work should be a /set/ of /records/--either the old records in the case of a before image or the new records in the case of an after image.
> Typically a log will contain special log records to mark transaction
> boundaries. Many systems allow interleaving of transaction log
> records by using a transaction id in each log record. Each
> transaction is normally expected to end with a commit or abort log
> This is irrespective of whether physical or logical changes are
Received on Tue Apr 22 2008 - 17:39:17 CEST