Transaction processing Study Guide

📖 Core Concepts Transaction – An indivisible unit of work; it either commits (all changes permanent) or rolls back (no changes remain). ACID Properties – Guarantees for reliable transactions: Atomicity – All‑or‑nothing execution. Consistency – Transaction leaves the database in a valid state, respecting all integrity rules. Isolation – Concurrent transactions appear to run sequentially; each sees only committed data. Durability – Once committed, changes survive crashes (via backups, after‑image journals). Serializability – The concurrency‑control goal: the result of interleaved transactions must be equivalent to some serial (one‑after‑another) order. Rollback vs. Rollforward – Rollback restores the before image (state prior to the transaction). Rollforward reapplies after images (logged changes) after a system‑wide failure and restoration from backup. Deadlock – A circular wait where each transaction holds a resource the other needs, halting progress until resolved. --- 📌 Must Remember Commit = permanent; cannot be undone. Rollback = discards all changes of the current transaction. Serializability = conflict‑free outcome ≈ some serial execution. Before image = snapshot saved before any modification; used for rollback. After image = log entry of each modification; used for rollforward. Deadlock resolution usually cancels one (or all) deadlocked transactions and restarts them. Compensating transaction = explicit “undo” transaction when automatic rollback isn’t available. --- 🔄 Key Processes Transaction Execution Start → acquire needed resources → perform operations → if all succeed → Commit → release resources. If any operation fails → Rollback using before images → release resources. Rollback Procedure System records before images of affected data. On failure, retrieve these images and overwrite current data, restoring the pre‑transaction state. Rollforward (After‑Image Journaling) During normal operation, log after images for every change. After a total DB failure: Restore most recent backup (pre‑failure state). Scan after‑image journal, apply each logged change in order → database reflects all transactions that had committed before the crash. Deadlock Detection & Resolution Periodically build a wait‑for graph; a cycle indicates a deadlock. Break the cycle by cancelling one (or all) involved transactions, rolling them back, then restarting later. --- 🔍 Key Comparisons Rollback vs. Rollforward Rollback: uses before images, restores current transaction only. Rollforward: uses after images, restores entire system after a crash. Deadlock‑Cancel‑All vs. Deadlock‑Cancel‑One Cancel‑All: aborts every transaction in the cycle, then restarts them. Cancel‑One: aborts a single victim transaction, restarts it, leaving others to continue. Compensating Transaction vs. Standard Rollback Compensating: explicit new transaction that undoes effects when automatic rollback isn’t possible. Rollback: automatic reversal using stored before images. --- ⚠️ Common Misunderstandings “Commit can be undone.” – Once a transaction is committed, it is durable; only a system‑wide restore + rollforward can revert it. “Isolation = no concurrency.” – Isolation hides intermediate effects; transactions still run concurrently, but each sees a serializable view. “Deadlock always needs manual intervention.” – Modern systems automatically detect cycles and abort victim transactions. --- 🧠 Mental Models / Intuition All‑or‑Nothing Switch – Picture a light switch that snaps either fully ON (commit) or OFF (rollback); there’s no half‑lit state. Journal as a Diary – The after‑image journal is a diary of everything you did; after a disaster, you reread it to recreate the day. Wait‑For Graph as a Circle – If you can draw a circle of “I’m waiting for you, you’re waiting for me,” you have a deadlock. --- 🚩 Exceptions & Edge Cases Some legacy systems lack built‑in rollback; they must rely on compensating transactions. In high‑availability setups, a partial commit (e.g., two‑phase commit) may leave some participants uncertain; additional coordination is required. --- 📍 When to Use Which Use Rollback whenever a single transaction fails before commit. Use Rollforward after a full database crash after restoring the latest backup. Choose a compensating transaction when the platform does not support automatic rollback (e.g., certain distributed services). Apply deadlock‑cancel‑one when minimizing work loss is critical; use cancel‑all when the system cannot safely isolate a single victim. --- 👀 Patterns to Recognize “If any step fails → rollback” pattern in transaction flowcharts. “Log → backup → apply logs” pattern in recovery procedures. Circular wait → deadlock pattern in resource‑allocation diagrams. --- 🗂️ Exam Traps Choosing “Rollback after commit” – wrong because committed changes are immutable. Confusing isolation with no concurrency – the exam may present concurrent transactions and ask about isolation; remember they still run concurrently. Selecting “After‑image journal is used for rollback” – incorrect; after‑images support rollforward, not rollback. Assuming deadlock always kills all transactions – many systems only abort a single victim. ---