2. Transactions
• A transaction is a unit of work that is
treated in a coherent and reliable manner. All
transactions must be independent of one
another
3. Transactions
• A transaction is a unit of work that is
treated in a coherent and reliable manner. All
transactions must be independent of one
another
• Provide concurrency support (next lecture!)
4. Transactions
• A transaction is a unit of work that is
treated in a coherent and reliable manner. All
transactions must be independent of one
another
• Provide concurrency support (next lecture!)
• Fundamental in computer science
7. Atomicity
• Strong guarantee that changes to a
database are applied “all or nothing”
• Atomicity must be maintained in the face of
failures (even from OS, hardware etc...)
8. Atomicity
• Strong guarantee that changes to a
database are applied “all or nothing”
• Atomicity must be maintained in the face of
failures (even from OS, hardware etc...)
• E.g.: move £100 from my bank account to
your bank account. If transfer to your
account fails, I must be credited back!
9. Consistency
• Transactions should not violate integrity
constraints leaving database in illegal state
• E.g.: age cannot be negative number
11. Isolation
• Transactions should not affect one another
• More precisely it defines when the changes
resulting from a transaction will be seen by
other concurrent transactions
12. Durability
• Outcome of transaction must persist
beyond its completion
• i.e.: given a system crash, the state of the
database can be recovered
13. Transaction Example
• Debit £100 from Alice’s bank account and
credit it to Bob’s account
read(Alice)
Alice = Alice - 100
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob)
14. Transaction Example
• Debit £100 from Alice’s bank account and
credit it to Bob’s account
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob)
15. Transaction Example
• Debit £100 from Alice’s bank account and
credit it to Bob’s account
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
} £1850
Alice’s balance = £1900
write(Alice) Bob’s balance = £-50
read(Bob)
Bob = Bob + 100
write(Bob)
16. Transaction Example
• Debit £100 from Alice’s bank account and
credit it to Bob’s account
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
} £1850
Alice’s balance = £1900
write(Alice) Bob’s balance = £-50
read(Bob)
Bob = Bob + 100
} £1950
Alice’s balance = £1900
write(Bob) Bob’s balance = £50
18. Transaction Example (2)
• What if Bob’s account does not exist? Or
permissions are set wrong?
read(Alice)
Alice = Alice - 100
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob)
19. Transaction Example (2)
• What if Bob’s account does not exist? Or
permissions are set wrong?
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob)
20. Transaction Example (2)
• What if Bob’s account does not exist? Or
permissions are set wrong?
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
} £1850
Alice’s balance = £1900
write(Alice) Bob’s balance = £-50
read(Bob)
Bob = Bob + 100
write(Bob)
21. Transaction Example (2)
• What if Bob’s account does not exist? Or
permissions are set wrong?
} £1950
Alice’s balance = £2000
Bob’s balance = £-50
read(Alice)
Alice = Alice - 100
} £1850
Alice’s balance = £1900
write(Alice) Bob’s balance = £-50
read(Bob)
Bob = Bob + 100 Read fails, must
credit Alice back!
write(Bob)
30. Durability
• Transaction logs used to ensure durability
• Log transaction writes, then update
database
• Logs must be written first or else updates
can be lost given a system crash!
31. Durability
• Transaction logs used to ensure durability
• Log transaction writes, then update
database
• Logs must be written first or else updates
can be lost given a system crash!
• Disks can still fail! (disk mirroring?)
32. Failures
• Possible failures include:
• System crash
• Hardware malfunctions
• Disk failure
• Deadlocks
• System errors: out of memory, program errors (see
“man 2 write”)
• etc...
33. State Machine
Partial Commit-
commit ted
Active
Failed Aborted
34. State Machine
Partial Commit-
commit ted
Active
Initial state Failed Aborted
36. State Machine
Partial Commit-
commit ted
Completion
Active
(database updated)
Failed Aborted
37. State Machine
Partial Commit-
commit ted
Active
Failed Aborted
Processing can no
longer proceed
38. State Machine
Partial Commit-
commit ted
Active
Failed Aborted
Transaction rolled
back to prior state
39. Transaction Logging
• Transaction start: <T , start>
i
• Transaction write: <T , X ,V ,V >
i j 1 2
• Transaction commit: <T , commit>
i
40. Transaction Logging
Transaction ID
• Transaction start: <T , start>
i
• Transaction write: <T , X ,V ,V >
i j 1 2
• Transaction commit: <T , commit>
i
41. Transaction Logging
Transaction ID
Data item ID
• Transaction start: <T , start>
i
• Transaction write: <T , X ,V ,V >
i j 1 2
• Transaction commit: <T , commit>
i
42. Transaction Logging
Transaction ID
Data item ID
• Transaction start: <T , start>
i
• Transaction write: <T , X ,V ,V >
i j 1 2
• Transaction commit: <T , commit>
i
Data values before
and after write
44. Transaction Logging
Transaction, ‘T’
<T, start>
read(Alice)
Alice = Alice - 100
<T, Alice, 2000, 1900>
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob) <T, Bob, -50, 50>
<T, commit>
45. Transaction Logging
Transaction, ‘T’
<T, start>
read(Alice)
Alice = Alice - 100
<T, Alice, 2000, 1900>
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob) <T, Bob, -50, 50>
<T, commit>
46. Transaction Logging
Transaction, ‘T’
<T, start>
read(Alice)
Alice = Alice - 100
<T, Alice, 2000, 1900>
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob) <T, Bob, -50, 50>
<T, commit>
47. Transaction Logging
Transaction, ‘T’
<T, start>
read(Alice)
Alice = Alice - 100
<T, Alice, 2000, 1900>
write(Alice)
read(Bob)
Bob = Bob + 100
write(Bob) <T, Bob, -50, 50>
<T, commit>
48. Deferred Modification
• Ensure atomicity by deferring all writes
until partial commit of transaction
• <T , commit> is a partial commit (only
i
affected log so far, not database)
• Given logs are in stable storage, writes can
be made to the database itself !
49. Failure Recovery
• If the system fails we can use the
transaction log to recover the database
• For all <T , start>, <T , commit> in log redo
i i
writes sequentially
55. Immediate Modification
• Instead of waiting for a commit, we could
just perform the writes as they happen (but
still post-log writing)
• Incomplete transactions written to
database require old value V1
56. Failure Recovery
• Again, if the system fails we use the
transaction log to recover the database
• For all <T , start>, <T , commit> in log redo
i i
database write
• For all <T , start>, without <T , commit> in
i i
log undo write
63. Check-points
• Speed up recovery!
• Create a “check-point” to reduce work to
be done given a failure
• Flush all buffers to disk
• Write <checkpoint> to log
• On failure: read log until <checkpoint>
found, then start recovery