Re: implementing a database log

"David BL" <davidbl_at_iinet.net.au> wrote in message news:265621e9-25fd-46d5-9e2d-7a4f63fa84b4_at_m3g2000hsc.googlegroups.com...
> On Apr 22, 6:58 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Christoph Rupp" <cruppst..._at_gmail.com> wrote in message
>>
>> news:91140c56-1f05-4b5d-b45f-b34920db2051_at_x41g2000hsb.googlegroups.com...
>>
>> > 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
>> record,
>> but only bits and pieces. I would think that limiting the units of
>> change
>> to individual records--entire records--would simplify the process of
>> marking
>> and isolating units of work while at the same time guaranteeing
>> consistency.
>
> 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
> record.
>
> This is irrespective of whether physical or logical changes are
> logged.
>
>
Received on Tue Apr 22 2008 - 17:39:17 CEST