Database Design – Rollback vs. Roll-Forward Transactions for Fault Tolerance

database-designdesigntransaction

I've been reading about systems that employ transactions to provide fault-tolerance — SQLite, for instance, implements a journal that allows the database to be rolled back to a known state in case of a failure.

Most of the systems I've been reading about write the current state to the journal and use this to roll back when required. I have found far fewer examples where the next state is journalled and used to complete the transaction after a failure.

Are there some good examples out there of systems that employ roll-forward transactions? Are there reasons to choose a roll-forward design over one that rolls back?

Best Answer

Most database schemes use both!

RollBack is the process of undoing changes and reverting to a previous state. This usually occurs either on request when a program detects some logical error and decides the transaction should not take place, or, when the DBMS loses contact with the program before an explicit "COMMIT" has been requested.

RollForward occurs when the database restarts after an abnormal shutdown. Its a process of going to the log files and applying changes from the log files to the underlying database. In the case where the underlying tables have been restored from an old backup this can involve millions of updates and take several hours.

Related Topic