1. Temple University – CIS Dept. CIS661 – Principles of Data Management
V. Megalooikonomou
Transactions
(based on slides 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, eg. Atomicity (all or none)
move $10 from savings to checking
Atomicity (all or none)
Consistency ()
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 succesfully the changes in the DB persist)

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

7. Consistency eg., 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
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? Example of interleaving:
T1: moves $10 from savings (X) to checking (Y)
T2: adds 10% interest to everything

12. Interleaved execution
‘correct’?

13. How to define correctness?
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,
ie., 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: eg., object X read by Ti and written by Tj
w/w: written by Ti and written by Tj
PRECEDENCE GRAPH:
Nodes: transactions
Arcs: r/w 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: algo for generating 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’
We assume ‘no blind writes’, ie, ‘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