Transactions and Concurrency

This topic covers reliable concurrent access. You study the ACID properties, the concurrency anomalies that arise without control, serialisability as the correctness criterion, two-phase locking, isolation levels, and write-ahead logging for recovery.

Relation 1 —

Write this relation with symbols exactly as in Database System Concepts — Korth, Silberschatz & Sudarshan before substituting numbers. Examiners award partial marks for a correct setup even when arithmetic slips.

Relation 2 —

Write this relation with symbols exactly as in Database System Concepts — Korth, Silberschatz & Sudarshan before substituting numbers. Examiners award partial marks for a correct setup even when arithmetic slips.

Relation 3 —

Write this relation with symbols exactly as in Database System Concepts — Korth, Silberschatz & Sudarshan before substituting numbers. Examiners award partial marks for a correct setup even when arithmetic slips.

Transactions let multiple users share a database without corrupting it. Atomicity makes a transaction all-or-nothing, isolation makes concurrent transactions appear to run alone, and durability makes committed changes survive crashes — the last relying on write-ahead logging, which records intended changes before touching the data so recovery can redo or undo them. Correctness of concurrency is defined by serialisability: an interleaved schedule is acceptable only if it is equivalent to some serial order. Two-phase locking guarantees this by forbidding new lock acquisitions once any lock is released. Weaker isolation levels permit specific anomalies (dirty, non-repeatable and phantom reads) in exchange for more concurrency.

State assumptions explicitly before using any relation for transactions and concurrency — steady state, uniform properties, linear elastic material, ideal gas, incompressible flow, etc., as applicable.

Wrong assumptions invalidate the entire solution even when the formula is correct. In Database Systems viva and GATE descriptive questions, listing valid assumptions often earns separate marks.

1. Read the question and list given data with SI units (common in Database Systems papers).
2. Draw a neat labelled diagram where applicable — examiners in Indian universities award diagram marks even when arithmetic slips.
3. Identify which relation from this topic applies to transactions and concurrency.
4. Use equation 1: .
5. Use equation 2: .
6. Substitute values, compute, and verify units and sign (direction).
7. State conclusion in one line — e.g. safe/unsafe, stable/unstable, feasible/infeasible.

Transactions and Concurrency appears in enterprise applications. In Indian it software curricula this topic is tested because it connects theory to relational model and SQL.

GATE and semester exams often combine transactions and concurrency with earlier units — revise prerequisites before attempting mixed problems.

Industry interview panels sometimes ask: "Where did you use transactions and concurrency?" — answer with a lab, mini-project, or plant visit example if possible.

Students confuse the three read anomalies and which isolation level prevents each, forget that 2PL requires all locks acquired before any release, and equate any interleaving with a serialisable one. Overlooking that higher isolation costs concurrency is a practical gap.

Before attempting transactions and concurrency problems, confirm you can:

1. Isolation levels: READ UNCOMMITTED up to SERIALIZABLE
2. Anomalies: dirty read, non-repeatable read, phantom read
3. Write-ahead logging records changes before applying them

Revise the solved examples in Database System Concepts — Korth, Silberschatz & Sudarshan and one previous-year GATE or university paper for this unit.