Re: why do you apply undo before redo?

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:OKXgc.78459$FK6.5316747_at_phobos.telenet-ops.be...
> Paul G. Brown wrote:
> > Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
news:<Cwzgc.76768$nU5.5168180_at_phobos.telenet-ops.be>...
> >
> > [ snip ]
> >
> >
> >>Of course most concurrency control mechanisms that guarantee
> >>serializability would prevent that.
> >
> >
> > I think you mis-spelled 'atomicity'. (Could be you misspelled
> > 'atomicity/durability', also.)

>

Are you sure??? Didn't the OP frame the question in terms of "recovery"?

I know I question you at my own risk, Jan, but it seems that Paul might correct in this case. Aborts and commits do have some effect on isolation, but they are specifically defined in terms of atomicity IMO. Aborts will require a rollback, sometimes using a log, sometimes relying on other mechanisms such a multi-version read consistency and rollback memory space. Durability is directly related to system failure recovery.

However, I believe that in terms of recovery and commit/abort approaches, undo/redo and force/no-force recovery mechanisms have not as much to do with isolation and more to do with the checkpoint/buffer flush approach, the buffer management algorithms, and the logging protocol (write-ahead, etc.) more than anything else. Wouldn't this be a direct function of the durability and atomicity properties. Durability in that any commited transaction is guaranteed to have all changes made permanent, even in the face of failures. Atomicity is related in that any delineated transaction, upon commit or rollback, is all or nothing, even in the face of failure.

As for redo/undo algorithms. There are several that I can recall off the top of my head, all of which are different (based on Bernstein's original models, I believe): 1) redo/undo where both operations are required because buffers might be flushed and changes made permanent before or after transaction ending statements; 2) undo/no-redo where only undo operations are required because buffers are flushed at commit time; 3) redo/no-undo, where checkpoint flushes are only allowed to write previously commited transactions to disk; and 4) no-undo/no-redo, where flushes occur only at the time of commit....etc.

Oracle doesn't use a log to undo upon abort I believe. It keeps a separate buffer (rollback segment) which it releases upon abort. Other DBMSs do use logs to undo, however.

Regards,

• Dan

> -- Jan Hidders
Received on Tue Apr 20 2004 - 12:20:56 CEST