transactions concurrency control and recovery short notes

Summary: ACID and Anomaly Quick Reference

ACID Properties Quick Reference Atomicity: All or nothing. (Mechanism: Undo Log) Consistency: Valid state to valid state. (Mechanism: Application logic + Constraints) Isolation: Concurrent = Serial. (Mechanism: Locks / Concurrency Control) Durability: Committed = Permanent. (Mechanism: Redo Log) Concurrency Anomalies Matrix Anomaly Cause Property Violated Lost Update T1 and T2 read same value, both write. T2 overwrites T1. Isolation, Consistency Dirty Read T1 reads data written by T2, but T2 aborts. Isolation Unrepeatable Read T1 reads a row, T2 updates and commits it, T1 reads again. Isolation Phantom Read T1 queries a range, T2 inserts or deletes in that range and commits, T1 queries again. Isolation Diagnostic Heuristic: If a scenario describes a final database state that breaks a business rule (like total money changing), Consistency is violated. If it describes interleaving causing the error, Isolation is the root failure that allowed it.

Summary: Conflict Serializability Checklist

Summary: Conflict Serializability Checklist 1. Identify Conflicts Look for pairs from different transactions, accessing the same data item, with at least one Write (R - W, W - R, W - W). Ignore R - R . 2. Draw Edges For each conflict, draw a directed edge T_{i} \to T_{j} if O_{i} appears before O_{j} in the schedule. 3. Check for Cycles No Cycle ⟹ Conflict Serializable. Cycle Exists ⟹ Not Conflict Serializable. 4. Find Equivalent Schedule If acyclic, the valid topological sorts of the graph represent the equivalent serial schedules.

Topic Summary and Exam Checklist

Topic Summary and Exam Checklist Core Definitions: Recoverable: reads from T_i \implies Commit(T_i) &lt; Commit(T_j). Cascadeless: reads from T_i \implies Commit(T_i) &lt; Read(T_j). Strict: reads/writes from or Abort(T_i) &lt; Read/Write(T_j). Hierarchy: Strict Cascadeless Recoverable. Crash Recovery Rules: WAL: Log record to disk before data page to disk. Checkpoint: Limits recovery scan range; records active transactions. Redo: Applied to transactions with a <Commit> record after the last checkpoint. Undo: Applied to transactions with a <Start> record but no <Commit> record. Exam Trap: A schedule can be recoverable but not cascadeless. Always check the exact definition requested in the question. Do not assume recoverable implies cascadeless.

1 more card in this chapter

Transactions, Concurrency Control and Recovery Short Notes for GATE CS

Transactions, Concurrency Control and Recovery short notes for GATE CS: 4 study cards covering concepts, formulas, shortcuts and exam traps, plus solved practice questions.

Summary: ACID and Anomaly Quick Reference

ACID Properties Quick Reference

Atomicity: All or nothing. (Mechanism: Undo Log)
Consistency: Valid state to valid state. (Mechanism: Application logic + Constraints)
Isolation: Concurrent = Serial. (Mechanism: Locks / Concurrency Control)
Durability: Committed = Permanent. (Mechanism: Redo Log)

Concurrency Anomalies Matrix

Anomaly	Cause	Property Violated
Lost Update	T1 and T2 read same value, both write. T2 overwrites T1.	Isolation, Consistency
Dirty Read	T1 reads data written by T2, but T2 aborts.	Isolation
Unrepeatable Read	T1 reads a row, T2 updates and commits it, T1 reads again.	Isolation
Phantom Read	T1 queries a range, T2 inserts or deletes in that range and commits, T1 queries again.	Isolation

Diagnostic Heuristic: If a scenario describes a final database state that breaks a business rule (like total money changing), Consistency is violated. If it describes interleaving causing the error, Isolation is the root failure that allowed it.

Summary: Conflict Serializability Checklist

1. Identify Conflicts

Look for pairs from different transactions, accessing the same data item, with at least one Write (

R - W

W - R

W - W

). Ignore

R - R

2. Draw Edges

For each conflict, draw a directed edge

T_{i} \to T_{j}

O_{i}

appears before

O_{j}

in the schedule.

3. Check for Cycles

No Cycle

⟹

Conflict Serializable. Cycle Exists

⟹

Not Conflict Serializable.

4. Find Equivalent Schedule

If acyclic, the valid topological sorts of the graph represent the equivalent serial schedules.

Topic Summary and Exam Checklist

Core Definitions:

Recoverable: $T_{j}$ reads $X$ from $T_i \implies Commit(T_i) < Commit(T_j)$ .
Cascadeless: $T_{j}$ reads $X$ from $T_i \implies Commit(T_i) < Read(T_j)$ .
Strict: $T_{j}$ reads/writes $X$ from $T_{i} ⟹ C o mmi t (T_{i})$ or $Abort(T_i) < Read/Write(T_j)$ .

Hierarchy: Strict

⟹

Cascadeless

⟹

Recoverable.

Crash Recovery Rules:

WAL: Log record to disk before data page to disk.
Checkpoint: Limits recovery scan range; records active transactions.
Redo: Applied to transactions with a <Commit> record after the last checkpoint.
Undo: Applied to transactions with a <Start> record but no <Commit> record.

Exam Trap: A schedule can be recoverable but not cascadeless. Always check the exact definition requested in the question. Do not assume recoverable implies cascadeless.

Exam Readiness Checklist

Core Rules to Memorize:

2PL Definition: Growing phase (acquire only) $\to$ Lock Point $\to$ Shrinking phase (release only).
Guarantee: 2PL $⟹$ Conflict Serializability.
Non-Guarantee: 2PL $\centernot ⟹$ Deadlock Freedom.
Non-Guarantee: 2PL $\centernot ⟹$ Recoverability (unless Strict).
Logic: 2PL is a sufficient condition for conflict serializability, but not necessary.

Variant Cheat Sheet:

Basic 2PL: Release anytime after lock point.
Strict 2PL: Hold X-locks until Commit/Abort. (Prevents cascading rollbacks).
Rigorous 2PL: Hold All locks (S and X) until Commit/Abort.

Exam Strategy: When asked "Which schedule is 2PL?", check each transaction individually for any Lock occurring after an Unlock. When asked about recoverability, immediately check if Exclusive locks are held until commit (Strict 2PL).