DBMS 📂 Transactions and Concurrency: · 1 of 6 17 min read

Transactions & Concurrency: Transaction States and ACID Properties

A practice-oriented DBMS tutorial covering what a transaction is, the read/write/commit/rollback operations, the full transaction state diagram (Active → Partially Committed → Committed, and Failed → Aborted → Terminated), and the four ACID properties — Atomicity, Consistency, Isolation, Durability. Includes fully solved practice problems on identifying violated properties, the lost-update anomaly, legal vs. illegal state transitions, plus a rapid-fire concept check and golden rules.

Section 01

The Story That Explains a Transaction

The ATM Transfer That Must Not Half-Happen
You walk to an ATM to move ₹5,000 from your Savings account to your friend's account. Internally, the bank does two things: subtract ₹5,000 from your balance, then add ₹5,000 to theirs.

Now imagine the power dies exactly between those two steps. Your money has left your account but never arrived in theirs. ₹5,000 has simply vanished. No bank on Earth would survive this. So the database treats both steps as one indivisible unit — either both happen, or neither does.

That single indivisible unit of work is called a transaction, and the four guarantees that keep it safe are the ACID properties.

A transaction is a logical unit of work that accesses and possibly modifies the contents of a database through a sequence of read and write operations. Crucially, a transaction is all-or-nothing: the database must never be left in a half-finished state where some operations applied and others did not.

🧮
The Core Definition

A transaction is a sequence of one or more operations treated as a single, indivisible unit. It either completes entirely and makes its changes permanent (commit), or it has no effect at all (rollback / abort). There is no valid "partially done" outcome.


Section 02

Transaction Concepts & Operations

Every transaction is built from a small set of low-level operations. Understanding these is the foundation for every practice problem that follows.

⚙️ The Building Blocks of Any Transaction
Read(X)
Reads the data item X from the database into a local buffer/variable. No change is made to the database.
Write(X)
Writes the (possibly modified) value back to data item X. The change may still be in a buffer, not yet on disk.
Commit
Signals successful completion. All changes become permanent and visible to others.
Rollback
Signals failure. All changes made by the transaction are undone, restoring the prior consistent state.

The Classic Fund-Transfer Transaction

Transaction T transfers ₹5,000 from account A to account B. Here it is written in SQL:

BEGIN TRANSACTION;

-- Step 1: take money out of A
UPDATE accounts SET balance = balance - 5000
WHERE acc_id = 'A';

-- Step 2: put money into B
UPDATE accounts SET balance = balance + 5000
WHERE acc_id = 'B';

-- Both succeeded -> make it permanent
COMMIT;

Expressed as abstract read/write operations, the same transaction looks like this:

Transaction T — Operation Sequence
T: Read(A) A := A - 5000 Write(A) Read(B) B := B + 5000 Write(B) Commit
⚠️
The Danger Zone

If a crash occurs after Write(A) but before Write(B), ₹5,000 has been deducted but never credited. The database is now inconsistent. The whole reason transactions exist is to make this impossible — that guarantee is called Atomicity.


Section 03

Transaction States & The State Diagram

During its lifetime, a transaction passes through a fixed set of states. Knowing the exact order — and which transitions are legal — is one of the most commonly tested topics in exams.

01
Active
The initial state. The transaction is executing its read and write operations. It stays here for its entire working life.
02
Partially Committed
Entered right after the final operation executes. Changes are done in memory but not yet written permanently to disk. The transaction is "almost there".
03
Committed
All changes are permanently saved to the database. The transaction succeeded and its effects are now durable and visible to others.
04
Failed
Entered from Active or Partially Committed when normal execution can no longer continue (e.g. hardware crash, constraint violation, deadlock).
05
Aborted → Terminated
After failure, the transaction is rolled back, undoing all changes (Aborted). It may then be restarted or killed. Committed and Aborted both lead to the final Terminated state.
🔗
The Two Possible Endings

Every transaction ends in exactly one of two ways: Active → Partially Committed → Committed (the happy path), or it falls into Failed → Aborted (rolled back). Both paths converge on Terminated. A transaction can never go from Committed back to Active — once committed, it is final.

State Meaning Can Transition To
ActiveExecuting read/write operations (initial state)Partially Committed, Failed
Partially CommittedFinal operation done; changes still in memoryCommitted, Failed
CommittedChanges permanently saved — successTerminated
FailedCannot continue normal executionAborted
AbortedRolled back to prior consistent stateTerminated (or restart)
TerminatedThe transaction has left the system— (final)

Section 04

The ACID Properties

ACID is the set of four guarantees a DBMS provides so that transactions remain reliable even with concurrency and system failures. Memorise the acronym: Atomicity, Consistency, Isolation, Durability.

⚛️
Atomicity
All or Nothing
Every operation in the transaction succeeds, or none of them do. If any step fails, the whole transaction is rolled back. There is no partial execution. Managed by the transaction manager / recovery system.
⚖️
Consistency
Valid State to Valid State
A transaction moves the database from one valid state to another, never violating integrity rules (constraints, keys, balances). The total must add up correctly before and after. Responsibility is shared by the application + DBMS.
🔒
Isolation
No Interference
Concurrent transactions must not see each other's intermediate, uncommitted results. The final outcome must equal some serial order of those transactions. Managed by the concurrency-control manager.
💾
Durability
Survives Crashes
Once a transaction commits, its changes are permanent — they survive power loss, crashes, and restarts. Guaranteed by the recovery manager using logs and stable storage.
🎯
Memory Hook: "A Cat In Danger"

Atomicity = all-or-nothing · Consistency = rules never broken · Isolation = transactions don't peek at each other · Durability = committed means committed forever.


Section 05

Which Property Fails? — Before / After

The fastest way to truly understand ACID is to see what breaks when a property is missing. Using the fund-transfer (A→B of ₹5,000, starting A=10000, B=2000):

❌ Without Atomicity (crash mid-way)
StepAB
Start100002000
Write(A)50002000
💥 CRASH50002000
Result50002000
✅ With Atomicity (rolled back)
StepAB
Start100002000
Write(A)50002000
↺ ROLLBACK100002000
Result100002000

On the left, ₹5,000 vanished (total dropped from 12000 to 7000) — both Atomicity and Consistency were violated. On the right, rollback restored the original consistent state. Total stays 12000 either way it should.


Section 06

Practice Problems (Fully Solved)

✏️
How To Use This Section

Read each problem, attempt it on paper before revealing the reasoning, then check the worked solution. These are written in the style of typical university and competitive-exam questions.

Problem 1 — Identify the Violated Property

A transaction successfully commits and the system confirms it. Five minutes later the server loses power. On reboot, the committed changes are gone. Which ACID property was violated?

✅ Solution
Answer
Durability. Durability guarantees that once a transaction commits, its effects survive any later failure. Committed data disappearing after a crash is a textbook durability failure — usually caused by not flushing the write-ahead log to stable storage.
Not Atomicity
Atomicity is about partial execution before commit, not loss after commit.

Problem 2 — The Lost Update (Isolation)

Two transactions run concurrently on the same item X = 100. Both read X, add 10, and write back, with operations interleaved as shown:

Interleaved Schedule
T1: Read(X) X = 100 T2: Read(X) X = 100 T1: X := X + 10 (local = 110) T1: Write(X) X = 110 T2: X := X + 10 (local = 110) T2: Write(X) X = 110 <-- T1's update is lost!

Expected final value: 120 (two increments of 10). Actual: 110. What problem is this, and which property prevents it?

✅ Solution
Problem
This is the Lost Update anomaly. T2 read X before T1 committed its change, so T2 overwrote T1's update with stale data.
Property
Isolation. Proper isolation (e.g. via locking) would force T2 to wait until T1 finishes, producing the correct value 120.

Problem 3 — Legal or Illegal State Transition?

For each transition, decide whether it is a valid transaction state change:

#TransitionValid?Reason
aActive → Partially CommittedYESHappens after the final operation executes.
bActive → FailedYESA crash or error during execution.
cCommitted → ActiveNOCommit is final; you cannot re-run a committed transaction.
dPartially Committed → CommittedYESChanges are flushed to stable storage successfully.
eFailed → CommittedNOA failed transaction must be Aborted, never committed.
fPartially Committed → FailedYESWriting to disk can still fail at the last moment.

Problem 4 — Why Does This Transaction Need Atomicity AND Durability?

An e-commerce checkout (1) deducts stock, (2) charges the card, (3) creates an order. The card charge at step 2 is rejected. What should happen, and which properties are at work?

✅ Solution
Atomicity
Step 1's stock deduction must be rolled back since step 2 failed. Otherwise stock is reduced for an order that never happened.
Durability
If instead all three steps succeed and commit, the completed order must survive a crash that occurs one second later.
Consistency
Either way, the invariant "stock removed ⇔ order exists & paid" is preserved.

Section 07

Rapid-Fire Concept Check

Cover the right column and test yourself. These match the most frequently asked one-liners.

QuestionAnswer
The initial state of every transactionActive
State entered after the final operation, before disk writePartially Committed
Property ensuring "all or nothing" executionAtomicity
Property ensuring committed data survives a crashDurability
Property preventing concurrent transactions from interferingIsolation
Property keeping the database in a valid stateConsistency
Operation that makes changes permanentCommit
Operation that undoes all changesRollback / Abort
The two final outcomes of any transactionCommitted or Aborted
Anomaly where one update overwrites anotherLost Update

Section 08

Golden Rules

🧮 Transactions & ACID — Non-Negotiable Rules
1
A transaction is atomic: there is no "half done". Either everything commits or everything rolls back. Never design logic that depends on partial completion.
2
The legal happy path is Active → Partially Committed → Committed. The failure path is Active/Partially Committed → Failed → Aborted. Both end at Terminated.
3
Committed is forever. You can never transition a committed transaction back to Active or to Aborted. If you need to reverse it, that requires a brand-new compensating transaction.
4
Consistency is the goal; Atomicity, Isolation, and Durability are the mechanisms that achieve it. If A, I, and D all hold, the database stays consistent.
5
Concurrency anomalies — lost update, dirty read, unrepeatable read, phantom read — are all failures of Isolation. The cure is a concurrency-control protocol such as locking or timestamp ordering.
6
Durability relies on the write-ahead log: changes are logged to stable storage before commit is acknowledged, so recovery can replay them after a crash.
7
When asked "which property is violated?", map the symptom: partial execution → Atomicity, broken rule/total mismatch → Consistency, transactions seeing each other → Isolation, committed data lost after crash → Durability.