AEiE0704 Transaction processing, concurrency control and crash recovery
ACID properties
| Property |
Meaning |
| Atomicity |
All-or-nothing execution |
| Consistency |
Transaction preserves integrity rules |
| Isolation |
Concurrent execution should appear safe |
| Durability |
Committed effects survive failures |
Concurrent executions and serializability
- Concurrent execution improves throughput and resource use.
- Serial schedule runs one transaction completely before the next.
- Serializable schedule is interleaved but equivalent in effect to some serial schedule.
- Conflict serializability is tested using conflicting read/write operation order.
Lock-based protocols
| Lock |
Meaning |
| Shared lock |
Read lock; multiple readers allowed |
| Exclusive lock |
Write lock; excludes other locks as needed |
- Two-phase locking has a growing phase for lock acquisition and a shrinking phase for release.
- Strict two-phase locking delays write-lock release until commit or abort, simplifying recovery and avoiding dirty reads.
Deadlock handling and prevention
- Deadlock occurs when transactions wait cyclically for each other.
- Necessary intuition: mutual exclusion plus hold-and-wait plus no preemption plus circular wait.
Handling methods:
| Method |
Core idea |
| Prevention |
Break one necessary condition |
| Avoidance |
Grant requests only when safe |
| Detection and recovery |
Allow deadlock, detect it, then recover |
| Timeout |
Practical heuristic approach |
Deadlock avoidance does not “detect deadlock in advance.” It evaluates each request and grants it only if the resulting allocation remains in a safe state. Deadlock detection searches for an existing deadlock after allocations have occurred.
Failure classification
| Failure type |
Cue |
| Transaction failure |
Logical error, deadlock abort, explicit rollback |
| System crash |
Power or OS crash, volatile memory lost |
| Media failure |
Disk damage or persistent-storage loss |
Recovery and atomicity
- Recovery ensures committed work is redone if needed and uncommitted work is undone.
- Log-based recovery records update information in a log on stable storage.
- Write-ahead logging principle: log record must be written before corresponding data page is written.
Log-based recovery cues
- Undo handles uncommitted transactions.
- Redo restores committed transactions if data pages were not persisted before crash.
- Checkpoints reduce recovery time by limiting how much log must be processed.
Transaction-and-recovery examples
- If two transactions each wait for the other to release a resource, deadlock exists.
- If a schedule is equivalent to some serial order, it is serializable even if operations interleave.
- If committed effects survive crash, that is durability.
AEiE0704 revision box
- ACID must be recalled exactly.
- Serializable does not mean literally serial; it means equivalent to serial.
- Shared lock for read, exclusive lock for write.
- Strict 2PL helps both isolation and recovery.
- Undo uncommitted work; redo committed work when needed.