1. Temple University – CIS Dept. CIS616– Principles of Data Management
V. Megalooikonomou
Transactions
(based on notes by C. Faloutsos at CMU)

2. General Overview Relational model - SQL
Functional Dependencies & Normalization
Physical Design & Indexing
Query optimization
Transaction processing
concurrency control
recovery

3. Transactions - dfn = unit of work, e.g., Atomicity (all or none)
move $10 from savings to checking
Atomicity (all or none)
Consistency (preservation)
Isolation (as if alone)
Durability (changes persist)
recovery
concurrency control

4. Operational details
‘read(x)’: fetches ‘x’ from disk to main memory (= buffer)
‘write(x)’: writes ‘x’ to disk (sometime later)
power failure  troubles!
Also, could lead to inconsistencies ...

5. Durability transactions should survive failures
(after a transaction completes successfully the changes in the DB persist)

6. Atomicity straightforward: Checking = Checking + 10
Savings = Savings - 10

7. Consistency e.g., the total sum of $ is the same, before and after
(but not necessarily during)

8. Isolation Other transactions should not affect us
Counter-example: lost update problem:
read(N)
N = N - 1
write(N)

9. Transaction states
partially
committed
committed
active
failed
aborted

10. Outline concurrency control ( isolation)
- ‘correct’ interleavings
- how to achieve them
recovery ( durability, atomicity)

11. Concurrency Why do we want it?
Increased throughput (# transactions executed in a given amount of time)
Increased utilization (CPU and disk spend less time idle)
Reduced waiting time (avg. response time: avg. time for a transaction to be completed)
Example of interleaving:
T1: moves $10 from savings (X) to checking (Y)
T2: adds 10% interest to everything

12. Interleaved execution
‘correct’?
time

13. How to define correctness?
Back to the basics…
… let’s start from something definitely correct:
 Serial executions

14. Serial execution
‘correct’
by definition

15. How to define correctness?
A: Serializability:
A schedule (=interleaving) is ‘correct’ if it is serializable,
i.e., equivalent to a serial interleaving
(regardless of the exact nature of the updates)
examples and counter-examples:

16. Example: ‘Lost-update’ problem
not equivalent to any serial execution (why not?) 
incorrect!

17. More details: ‘conflict serializability’

18. Conflict serializability
r/w, w/r: e.g., object X read by Ti and written by Tj
w/w: written by Ti and written by Tj
the order matters in both cases …
PRECEDENCE GRAPH:
Nodes: transactions
Arcs: r/w, w/r or w/w conflicts

19. Cycle -> not serializable
Precedence graph T2 N N T1
Cycle -> not serializable

20. Example

21. Example A T3 T1 T2 B
serial execution?

22. Example
A: T2, T1, T3
(Notice that T3 should go after T2, although it starts before it!)
Q: How to generate serial execution from (acyclic) precedence graph?

23. Example A: Topological sorting
A topological sort of a DAG=(V,E) is a linear ordering of all its vertices such that if G contains an edge (u,v), then u appears before v in the ordering.
…it is the ordering of its vertices along a horizontal line so that all directed edges go from left to right.
…topologically sorted vertices appear in reverse order of their finishing times according to depth first search (DFS)

24. Serializability
Ignore ‘view serializability’ (less stringent than ‘conflict serializability’)
We assume ‘no blind writes’, i.e., ‘read before write’

25. (counter) example: ‘Inconsistent analysis’
Precedence graph?

26. Conclusions ‘ACID’ properties of transactions recovery for ‘A’, ‘D’
concurrency control for ‘I’
correct schedule -> serializable
precedence graph
acyclic -> serializable