Re: implementing a database log
Date: Mon, 21 Apr 2008 23:53:42 -0700 (PDT)
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 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?
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 - 08:53:42 CEST