Transactions, ACID Properties, Schedules, and Serializability
Understand how DBMS ensures correctness when multiple operations and users interact with data simultaneously.
Inside this chapter
- What a Transaction Is
- ACID Properties
- Simple Transaction Example
- Schedules and Serializability
- Common Problems Without Proper Control
- Real Usage Example
Series navigation
Study the chapters in order for the clearest path from database fundamentals and SQL to transactions, indexing, recovery, distributed systems, tuning, and advanced DBMS engineering understanding. Use the navigation at the bottom to move smoothly across the full tutorial series.
What a Transaction Is
A transaction is a logical unit of work that should either complete fully or not happen at all. Examples include transferring money between accounts, placing an order, reserving a seat, or updating inventory after payment.
ACID Properties
- Atomicity: all or nothing
- Consistency: rules remain valid before and after the transaction
- Isolation: concurrent transactions do not corrupt each other’s intermediate work
- Durability: committed data survives crashes
Simple Transaction Example
BEGIN TRANSACTION;
UPDATE Accounts SET balance = balance - 500 WHERE account_id = 1;
UPDATE Accounts SET balance = balance + 500 WHERE account_id = 2;
COMMIT;If the second step fails after the first succeeds, a rollback must happen to preserve correctness.
Schedules and Serializability
When multiple transactions run concurrently, their steps interleave to form a schedule. A schedule is considered serializable if the final result is equivalent to some serial execution. This concept is essential for correctness in multi-user systems.
Common Problems Without Proper Control
- Lost update
- Dirty read
- Non-repeatable read
- Phantom read
Real Usage Example
In a ticket-booking system, two users might try to reserve the last seat at the same time. Transaction isolation and concurrency control are what stop the system from selling the same seat twice.