1. C. Faloutsos Transactions
Carnegie Mellon Univ. Dept. of Computer Science Database Applications
C. Faloutsos
Transactions

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

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
recovery
concurrency control
C. Faloutsos

4. 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
C. Faloutsos

5. 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...
C. Faloutsos

6. Durability
transactions should survive failures
C. Faloutsos

7. Atomicity straightforward: Checking = Checking + 10
Savings = Savings - 10
C. Faloutsos

8. Consistency eg., the total sum of $ is the same, before and after
(but not necessarily during)
C. Faloutsos

9. Isolation other transactions should not affect us
counter-example: lost update problem:
read(N)
N = N - 1
N=N-1
write(N)
C. Faloutsos

10. Isolation other transactions should not affect us
counter-example: lost update problem:
read(N)
N = N - 1
N=N-1
write(N) 1 1
C. Faloutsos

11. Transaction states active aborted failed commited partially committed
C. Faloutsos

12. Outline concurrency control (-> isolation)
‘correct’ interleavings
how to achieve them
recovery (-> durability, atomicity)
C. Faloutsos

13. Concurrency why do we want it? Example of interleaving:
T1: moves $10 from savings (X) to checking (Y)
T2: adds 10% interest to everything
C. Faloutsos

14. Interleaved execution
‘correct’?
C. Faloutsos

15. How to define correctness?
Let’s start from something definitely correct:
Serial executions
C. Faloutsos

16. Serial execution
‘correct’
by definition
C. Faloutsos

17. 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:
C. Faloutsos

18. Example: ‘Lost-update’ problem
not equivalent to any serial execution (why not?) ->
incorrect!
C. Faloutsos

19. More details: ‘conflict serializability’
C. Faloutsos

20. 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
C. Faloutsos

21. Cycle -> not serializable
Precedence graph T2 N N T1
Cycle -> not serializable
C. Faloutsos

22. Example
C. Faloutsos

23. Example A T3 T1 T2 B
serial execution?
C. Faloutsos

24. 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?
C. Faloutsos

25. Example
A: Topological sorting
C. Faloutsos

26. Serializability Ignore ‘view serializability’
assume ‘no blind writes’, ie, ‘read before write’
C. Faloutsos

27. (counter) example: ‘Inconsistent analysis’
Precedence graph?
C. Faloutsos

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