c2cedge
CS Fundamentals · B — Database Management

Transactions & Concurrency Control

A transaction is a unit of work that must be all-or-nothing. ACID, isolation levels and locking are favourite questions for product and service companies alike.

Test weight: HighAsked by: TCS, Infosys, product cosDifficulty: Medium–Hard

A transaction is a sequence of operations treated as a single logical unit — a money transfer that debits one account and credits another must either fully happen or not at all. The DBMS guarantees this through the ACID properties, and it controls simultaneous transactions with isolation levels and locking.

ACID

Atomicity: all operations succeed or none do. Consistency: the database moves from one valid state to another. Isolation: concurrent transactions don't see each other's partial work. Durability: once committed, changes survive crashes.

Concurrency problems & isolation levels

ProblemWhat happens
Dirty readreading another transaction's uncommitted change
Non-repeatable reada re-read returns a different value (it was updated)
Phantom reada re-run query returns new rows (inserted by another)
⚡ The edge
  • Remember ACID by what each protects: Atomicity = all-or-nothing, Consistency = valid states, Isolation = no interference, Durability = survives crashes.
  • Higher isolation levels (up to Serializable) prevent more anomalies but reduce concurrency. The order of strength: Read Uncommitted < Read Committed < Repeatable Read < Serializable.
Worked example
'Explain the ACID properties with the bank-transfer example.'
  1. Atomicity: debit and credit both happen or neither does — money is never lost mid-way.
  2. Consistency: total balance across accounts is preserved; Isolation: a concurrent transfer doesn't see the half-done state.
  3. Durability: once the transfer commits, it stays even if the server crashes a second later.
Worked example
'What is a deadlock in a database and how is it handled?'
  1. Two transactions each hold a lock the other needs, so both wait forever — a deadlock.
  2. DBMSs typically detect deadlocks (a wait-for cycle) and abort one transaction (the victim) to break it.
  3. Prevention options include acquiring locks in a consistent order or using timeouts.
⚠ Watch out
  • Don't confuse consistency (valid states / constraints) with isolation (not seeing others' partial work).
  • Higher isolation = fewer anomalies but lower concurrency/throughput — it's a trade-off.
  • A dirty read (uncommitted data) is different from a non-repeatable read (committed update between reads).
Practice this — take a timed mock →
1,300+ questions, scored, with a weak-area report.
Know who's ready. Not who finished.
HomeLibraryPrivacyTerms