Log Based vs Shadow Paging: Key Differences and Usage

In log based recovery, changes are recorded in a log before applying to the database, enabling rollback and redo. Shadow paging keeps a copy (shadow) of the database pages and switches to updated pages atomically, avoiding logs but requiring more storage.

Quick Comparison

This table summarizes the main differences between log based and shadow paging techniques in database management systems.

Factor	Log Based	Shadow Paging
Recovery Method	Uses logs to redo or undo transactions	Switches to updated shadow pages atomically
Storage Overhead	Stores logs separately, less space for data copies	Maintains full shadow copies, higher space usage
Write Performance	Slower due to logging overhead	Faster writes by swapping pages
Complexity	Requires log management and checkpoints	Simpler recovery without logs
Data Consistency	Ensures atomicity via logs	Ensures atomicity via shadow page swapping
Rollback Capability	Supports undo using logs	Rollback by discarding shadow pages

Key Differences

Log based recovery records every change in a separate log file before applying it to the database. This allows the system to redo committed transactions or undo uncommitted ones after a crash, ensuring data integrity. It requires managing logs and checkpoints, which adds complexity but provides fine control over recovery.

In contrast, shadow paging avoids logs by maintaining two copies of database pages: the current and the shadow copy. Updates are made on the shadow copy, and once complete, the system atomically switches the pointer to the shadow pages. This method simplifies recovery since the original pages remain unchanged until commit, but it uses more storage and can be less flexible for complex transactions.

Overall, log based methods are more common in systems needing detailed recovery and concurrency control, while shadow paging suits simpler or read-heavy systems where quick atomic updates are preferred.

Code Comparison

Example of a simple log based update operation recording changes before applying them:

javascript

class LogBasedDB {
    constructor() {
        this.data = {};
        this.log = [];
    }

    update(key, value) {
        // Record change in log
        this.log.push({ key, oldValue: this.data[key], newValue: value });
        // Apply change
        this.data[key] = value;
    }

    rollback() {
        // Undo changes from log
        while (this.log.length > 0) {
            const change = this.log.pop();
            this.data[change.key] = change.oldValue;
        }
    }

    showData() {
        return this.data;
    }
}

const db = new LogBasedDB();
db.update('x', 10);
db.update('y', 20);
console.log(db.showData());
db.rollback();
console.log(db.showData());

Output

{"x":10,"y":20}
{}

Shadow Paging Equivalent

Equivalent shadow paging example where updates are made on a shadow copy and committed by swapping:

javascript

class ShadowPagingDB {
    constructor() {
        this.currentPages = {};
        this.shadowPages = null;
    }

    startUpdate() {
        // Create shadow copy
        this.shadowPages = { ...this.currentPages };
    }

    update(key, value) {
        if (!this.shadowPages) {
            throw new Error('Start update first');
        }
        this.shadowPages[key] = value;
    }

    commit() {
        // Atomically switch to shadow pages
        this.currentPages = this.shadowPages;
        this.shadowPages = null;
    }

    rollback() {
        // Discard shadow pages
        this.shadowPages = null;
    }

    showData() {
        return this.currentPages;
    }
}

const db = new ShadowPagingDB();
db.startUpdate();
db.update('x', 10);
db.update('y', 20);
db.commit();
console.log(db.showData());
db.startUpdate();
db.update('x', 30);
db.rollback();
console.log(db.showData());

Output

{"x":10,"y":20}
{"x":10,"y":20}

When to Use Which

Choose log based recovery when your system requires detailed transaction control, supports complex rollback and redo operations, and can handle the overhead of log management. It is ideal for high-concurrency environments where precise recovery is critical.

Choose shadow paging when you want simpler recovery without managing logs, especially in systems with fewer writes or where atomic page swaps are sufficient. It suits read-heavy workloads or simpler databases where storage overhead is acceptable.

Key Takeaways

Log based recovery uses logs to track changes, enabling precise undo and redo.

Shadow paging keeps a shadow copy of pages and switches atomically for recovery.

Log based methods handle complex transactions better but add overhead.

Shadow paging offers simpler recovery but requires more storage space.

Choose log based for complex, high-concurrency systems; shadow paging for simpler or read-heavy ones.