The document discusses transaction concepts, concurrency control, and recovery in database systems. It defines a transaction as a unit of work executed using DML commands that must see a consistent database. Concurrency control techniques like locking protocols ensure transactions execute reliably in the presence of concurrent access. Recovery managers use transaction logging to restore the database to a consistent state after failures and abort uncommitted transactions.

1. Chapter Nine
Transactions, Recovery and
concurrency
1

2. Transaction Concept
 A transaction is a unit of work that is executed in an
order by using DML commands ..
 A transaction must see a consistent database.
 commit : saving a transaction .
 Rollback: cancelling the entire transaction.
 Rollback to save points : to cancel partial
transaction .
2

3. Cont…
 Based on the following code and answer the subsequent questions
>SQL set autocommit off
1 Insert into emp
2 Insert into emp
3 Delete from emp where basic>1000;
4 Commit;
5 Update emp set basic=0 where basic>1000;
6 Save point x1;
7 Insert into emp
8 Rollback to x1;
9 rollback;
a. What are the commands that are saved give line numbers?
b. What are the commands canceled give line numbers ?
3

4. Concurrency Control & Recovery
 Concurrency Control
 Provide correct and highly available data access
in the presence of concurrent access by many
users
 Recovery
 Ensures database is fault tolerant, and not
corrupted by software, system or media failure
 24x7 access to mission critical data

5. Important transaction properties
(ACID Properties)
 To preserve the integrity of data, the database system must ensure:
 Atomicity. Either all operations of the transaction are:
 properly reflected in the database or none are.
 Consistency. Execution of a transaction in isolation:
 preserves the consistency of the database.
 Isolation. Although multiple transactions may execute concurrently,
 each transaction must be unaware of other concurrent transactions.
 Intermediate transaction results must be:
– hidden from other concurrently executed transactions.
 That is, for every pair of transactions Ti and Tj, it appears to Ti that either Tj,
finished execution before Ti started, or Tj started execution after Ti finished.
 Durability. After a transaction completes successfully,
 the changes it has made to the database persist or survive,
– even if there are system failures.
5

6. Example of Fund Transfer
 Transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
6

7. Example of transaction
 Transfer £50 from account
A to account B
Read(A)
A = A - 50
Write(A)
Read(B)
B = B+50
Write(B)
Atomicity - shouldn’t take money
from A without giving it to B
Consistency - money isn’t lost or
gained
Isolation - other queries shouldn’t
see A or B change until
completion
Durability - the money does not
go back to A
transaction
7

8. Atomicity and Durability
 A transaction ends in one of two ways:
 commit after completing all its actions
 “commit” is a contract with the caller of the DB
 abort (or be aborted by the DBMS) after executing some
actions.
 Or system crash while the xact is in progress; treat as abort.
 Two important properties for a transaction:
 Atomicity : Either execute all its actions, or none of them
 Durability : The effects of a committed xact must survive
failures.
 DBMS ensures the above by logging all actions:
 Undo the actions of aborted/failed transactions.
 Redo actions of committed transactions not yet

9. Isolation (Concurrency)
 DBMS interleaves actions of many xacts
concurrently
 Actions = reads/writes of DB objects
 DBMS ensures xacts do not “step onto” one another.
 Each xact executes as if it were running by itself.
 Concurrent accesses have no effect on a Transaction’s
behavior
 Net effect must be identical to executing all transactions
for some serial order.
 Users & programmers think about transactions in isolation
 Without considering effects of other concurrent transactions!

10. Example
 Consider two transactions (Xacts):
T1: BEGIN A=A+100, B=B-100 END
T2: BEGIN A=1.06*A, B=1.06*B END
• 1st xact transfers $100 from B’s account to A’s
• 2nd credits both accounts with 6% interest.
• Assume at first A and B each have $1000. What are the legal outcomes of running
T1 and T2?
• T1 ; T2 (A=1166,B=954)
• T2 ; T1 (A=1160,B=960)
• In either case, A+B = $2000 *1.06 = $2120
• There is no guarantee that T1 will execute before T2 or vice-versa, if both are
submitted together.

11. Example (Contd.)
 Consider a possible interleaved schedule:
T1: A=A+100, B=B-100
T2: A=1.06*A, B=1.06*B
 This is OK (same as T1;T2). But what about:
T1: A=A+100, B=B-100
T2: A=1.06*A, B=1.06*B
• Result: A=1166, B=960; A+B = 2126, bank loses $6 !
• The DBMS’s view of the second schedule:
T1: R(A), W(A), R(B), W(B)
T2: R(A), W(A), R(B), W(B)

12. Scheduling Transactions: Definitions
 Serial schedule: no concurrency
 Does not interleave the actions of different transactions.
 Equivalent schedules: same result on any DB state
 For any database state, the effect (on the set of objects in
the database) of executing the first schedule is identical to
the effect of executing the second schedule.
 Serializable schedule: equivalent to a serial schedule
 A schedule that is equivalent to some serial execution of the
transactions.
(Note: If each transaction preserves consistency,
every serializable schedule preserves consistency. )

13. Anomalies with Interleaved Execution
 Reading Uncommitted Data (WR Conflicts, “dirty reads”):
 Unrepeatable Reads (RW Conflicts):
T1: R(A), W(A), R(B), W(B), Abort
T2: R(A), W(A), C
T1: R(A), R(A), W(A), C
T2: R(A), W(A), C

14. Anomalies (Continued)
 Overwriting Uncommitted Data (WW Conflicts):
T1: W(A), W(B), C
T2: W(A), W(B), C

15. Lock-Based Concurrency Control
 A simple mechanism to allow concurrency but avoid
the anomalies just described…
 Two-phase Locking (2PL) Protocol:
 Always obtain a S (shared) lock on object before reading
 Always obtain an X (exclusive) lock on object before writing.
 If an Xact holds an X lock on an object, no other Xact can get a lock (S
or X) on that object.
 DBMS internally enforces the above locking protocol
 Two phases: acquiring locks, and releasing them
 No lock is ever acquired after one has been released
 “Growing phase” followed by “shrinking phase”.
 Lock Manager tracks lock requests, grants locks on database
objects when they become available.

16. Strict 2PL
• 2PL allows only serializable schedules but is subjected to cascading
aborts.
• Example: rollback of T1 requires rollback of T2!
• To avoid Cascading aborts, use Strict 2PL
• Strict Two-phase Locking (Strict 2PL) Protocol:
– Same as 2PL, except:
– A transaction releases no locks until it completes
T1: R(A), W(A), Abort
T2: R(A), W(A), R(B), W(B)

17. Crash Recovery
 Recovery Manager
 Upon recovery from crash:
 Must bring DB to a consistent transactional state
 Ensures transaction Atomicity and Durability
 Undoes actions of transactions that do not commit
 Redoes lost actions of committed transactions
 lost during system failures or media failures
 Recovery Manager maintains log information
during normal execution of transactions for
use during crash recovery