What if your bank could lose money just because a power cut happened mid-transfer?
Why Transaction states in DBMS Theory? - Purpose & Use Cases
Imagine you are manually updating a bank ledger by hand. You write down each deposit and withdrawal carefully, but if you get interrupted or make a mistake, you have to start over or risk errors.
Doing this by hand is slow and risky. If you forget to record a step or if the process is interrupted, the ledger can become inconsistent. Fixing errors later is hard and can cause confusion or loss.
Transaction states in a database help manage these updates automatically. They track each step from start to finish, ensuring that either all changes happen correctly or none at all, keeping data safe and consistent.
Write deposit
Write withdrawal
If error, erase and rewriteBEGIN TRANSACTION
UPDATE balance
COMMIT or ROLLBACKThis makes it possible to handle complex data changes reliably, even if something goes wrong during the process.
When you transfer money between accounts online, transaction states ensure the money leaves one account and arrives in the other without errors or loss.
Transaction states track the progress of data changes step-by-step.
They ensure all changes succeed together or none happen at all.
This protects data accuracy and prevents partial updates.
Practice
Solution
Step 1: List common transaction states
Common transaction states include Running (active), Waiting (blocked), Committed (successfully completed), and Aborted (rolled back).Step 2: Identify invalid state
"Failed" is not a standard transaction state; instead, "Aborted" or "Rolled back" is used for unsuccessful transactions.Final Answer:
Failed -> Option DQuick Check:
Standard states exclude "Failed" [OK]
- Confusing 'Failed' with 'Aborted'
- Thinking 'Waiting' is not a state
- Assuming 'Failed' is official terminology
Solution
Step 1: Understand transaction commands
ROLLBACK undoes changes, SAVEPOINT sets a restore point, BEGIN starts a transaction, and COMMIT finalizes changes.Step 2: Identify command to commit
COMMIT is the command that moves a transaction from Running (active) to Committed (completed) state.Final Answer:
COMMIT -> Option BQuick Check:
COMMIT finalizes transaction [OK]
- Confusing ROLLBACK with COMMIT
- Using SAVEPOINT to commit
- Thinking BEGIN commits
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
What is the final state of this transaction after execution?
Solution
Step 1: Analyze the transaction commands
The transaction starts with BEGIN, performs two updates, then ends with COMMIT.Step 2: Determine transaction state after COMMIT
COMMIT finalizes the transaction successfully, so the state becomes Committed.Final Answer:
Committed -> Option AQuick Check:
COMMIT means transaction is Committed [OK]
- Thinking transaction remains Running after COMMIT
- Confusing Aborted with Committed
- Assuming Waiting state after COMMIT
BEGIN;
UPDATE inventory SET quantity = quantity - 5 WHERE product_id = 10;
ROLLBACK;
COMMIT;
Solution
Step 1: Understand ROLLBACK and COMMIT order
ROLLBACK cancels the transaction, so no changes remain to commit afterwards.Step 2: Identify invalid command sequence
After ROLLBACK, issuing COMMIT is invalid because the transaction is already aborted.Final Answer:
COMMIT after ROLLBACK is invalid -> Option AQuick Check:
Cannot COMMIT after ROLLBACK [OK]
- Thinking COMMIT can follow ROLLBACK
- Assuming ROLLBACK should come after COMMIT
- Missing BEGIN statement
Solution
Step 1: Understand 'Waiting' state cause
Waiting occurs when a transaction is blocked due to locks held by another transaction.Step 2: Analyze actions that unblock waiting
If the blocking transaction commits, rolls back, or releases the lock, the waiting transaction can proceed.Step 3: Identify action that does NOT help
The waiting transaction issuing COMMIT while blocked cannot proceed because it must first acquire the lock.Final Answer:
The waiting transaction issues a COMMIT -> Option CQuick Check:
Waiting means blocked; only blocking transaction actions help [OK]
- Thinking waiting transaction can commit while blocked
- Assuming waiting state ends without lock release
- Confusing roles of blocking and waiting transactions
Ready to prove it?
Pass the test and this pattern moves unknown
