1. File Processing : Transaction Management
2018, Spring
Pusan National University
Ki-Joune Li

2. Basic Concepts of Transaction
A set of operations
Atomic :
All or Nothing : Consistent State of Database
Example : Flight Reservation
Cf. Partially Done : Inconsistent State

3. Transaction States Partially Committed Committed ALL Active NOTHING
the initial state; the transaction stays in this state while it is executing
Partially Committed
Committed
ALL
Active
NOTHING
Failed
Aborted
after the discovery that normal execution can no longer proceed.
after the transaction has been rolled back and the database restored to its state prior to the start of the transaction.
- restart the transaction or
- kill the transaction

4. ACID Properties Atomicity. Consistency. All or Nothing
Not Partially Done
Example : Failure in Flight Reservation
Consistency.
Execution of a transaction preserves the consistency of the database.
State 2
All
State 1
Consistent
State 2’
Partially Done
Nothing

5. ACID Properties Isolation. Durability.
Although multiple transactions may execute concurrently, each transaction must be unaware of other concurrently executing transactions.
Intermediate transaction results must be hidden from other concurrently executed transactions.
Durability.
After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. DB
Transation 1
No Effect
Transation 2

6. Example Transaction : 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)
Consistency requirement
the sum of A and B is unchanged after the transaction.
Atomicity requirement
Durability
Isolation

7. Example : Concurrent Execution
Two Transactions
T1 : transfer $50 from A to B,
T2 transfer 10% of the balance from A to B
Serial Schedule
Concurrent Schedule

8. Serializability What happens after these transactions ?
Serial Schedule :
Always Correct
T1 T2 and T2 T1
Concurrent Schedule
Serializable if
Result (T1 || T2) = Result(T1 T2) or
Result(T2 T1)

9. Transaction Management
Guarantee ACID Properties of Transaction by
Concurrency Control : Isolation and Consistency
Recovery : Atomicity and Durability

10. File Processing : Concurrency Control

11. Serializability For given transactions T1, T2,.., Tn,
Schedule (History) S is serializable if
Result(S)  Result(Sk) where Sk is a serial excution schedule.
Note that Result(Si ) may be different from Result(Sj ) (i  j )
How to detect whether S is serializable
Conflict Graph

12. Conflict Graph S1 T1 r(a) r(b) affects Res(S1)  Res( (T1, T2) ) T2
w(a)
w(b) T1 T2
r(a)
w(a)
affects
r(b)
w(b) S2
Res(S1)  Res( (T1, T2) )
Res(S1)  Res( (T2, T1) )

13. Detect Cycle in Conflict Graph
If  Cycle in Conflict Graph
Then Not Serializable
Otherwise Serializable T1
r(a)
r(b) T2 T1
affects T2
w(a)
w(b)

14. How to make it serializable
Control the order of execution of operations in concurrent transactions.
Two Approaches
Two Phase Locking Protocol
Locking on each operation
Timestamping :
Ordering by timestamp on each transaction and each operation

15. Lock-Based Protocols A lock Data items can be locked in two modes :
mechanism to control concurrent access to a data item
Data items can be locked in two modes :
Exclusive (X) mode : Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
Shared (S) mode : Data item can only be read. S-lock is
requested using lock-S instruction.
Lock requests are made to concurrency-control manager.
Transaction can proceed only after request is granted.

16. Lock-Based Protocols (Cont.)
Lock-compatibility matrix
A transaction may be granted a lock on an item
if the requested lock is compatible with locks already held
Any number of transactions can hold shared locks
If a lock cannot be granted,
the requesting transaction is made to wait
till all incompatible locks held have been released.
the lock is then granted.

17. Lock-Based Protocols Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);

18. The Two-Phase Locking Protocol
This is a protocol which ensures conflict-serializable schedules.
Phase 1: Growing Phase
transaction may obtain locks
transaction may not release locks
Phase 2: Shrinking Phase
transaction may release locks
transaction may not obtain locks
The protocol assures serializability

19. Lock Conversions Two-phase locking with lock conversions:
First Phase:
can acquire a lock-S on item
can acquire a lock-X on item
can convert a lock-S to a lock-X (upgrade)
Second Phase:
can release a lock-S
can release a lock-X
can convert a lock-X to a lock-S (downgrade)
This protocol assures serializability

20. Where to insert Lock related operations ?
A transaction Ti
issues the standard read/write instruction,
without explicit locking calls.
Automatic Acquisition of Locks
The operation read(D) is processed as:
if Ti has a lock on D
then read(D)
else
begin
wait until no other transaction has a lock-X on D
grant Ti a lock-S on D;
read(D)
end

21. Automatic Acquisition of Locks
write(D) is processed as:
if Ti has a lock-X on D
then write(D)
else
begin
if necessary wait until no other trans. has any lock on D,
if Ti has a lock-S on D
then upgrade lock on D to lock-X
else grant Ti a lock-X on D
write(D)
end;
All locks are released after commit or abort

22. Lock Manager Transaction Lock Table
Transaction sends lock request to Lock Manager
Lock Manager determines whether to allow or not
Lock Table
Keeps granted locks and pending locks for each item
In-memory Hash Table

23. Problem of Two Phase Locking Protocol
Deadlock
Growing Phase and Shrinking Phase
Prevention and Avoidance : Impossible
Only Detection may be possible
When a deadlock occurs
Detection of Deadlock : Wait-For-Graph
Abort a transaction
How to choose a transaction to kill ?

24. Tree Lock : A Special Locking Mechanism
Only exclusive locks are allowed.
The first lock by T may be on any data item.
Subsequently, a data Q can be locked by T only if the parent of Q is currently locked by T.
Data items may be unlocked at any time.
Pairwise lock
Not Allowed

25. Timestamp-Based Protocols
Each transaction is issued a timestamp when
TS(Ti) <TS(Tj) :
old transaction Ti and new transaction Tj
Each data Q, two timestamp :
W-timestamp(Q) : largest time-stamp for successful write(Q)
R-timestamp(Q) : largest time-stamp for successful read(Q)

26. Timestamp-Based Protocols : Read
Transaction Ti issues a read(Q)
If TS(Ti)  W-timestamp(Q),
then Ti needs to read a value of Q that was already overwritten.
Hence, the read operation is rejected, and Ti is rolled back.
If TS(Ti)  W-timestamp(Q),
then the read operation is executed, and
R-timestamp(Q) is set set

27. Timestamp-Based Protocols : Write
Transaction Ti issues write(Q).
If TS(Ti) < R-timestamp(Q),
then the value of Q that Ti is producing was needed previously,
and the system assumed that that value would never be produced.
Hence, the write operation is rejected, and Ti is rolled back.
If TS(Ti) < W-timestamp(Q),
then Ti is attempting to write an obsolete value of Q.
Hence, this write operation is rejected, and Ti is rolled back.
Otherwise,
the write operation is executed,
and W-timestamp(Q) is reset

28. Correctness of Timestamp-Ordering Protocol
The timestamp-ordering protocol guarantees serializability since all the arcs in the precedence graph are of the form:
Thus, there will be no cycles in the conflict graph
Timestamp protocol : free from deadlock
transaction
with smaller
timestamp
transaction
with larger
timestamp

29. Problem of Time-Stamping Protocol
Rollback and Restarting Overhead
Rollback and Restarting
relatively more frequent than deadlock
Instead of Deadlock Detection
Cost
? pRB(CRB+CRStart) > pDL CDL + CDLDetect

30. Long Duration Transaction
of Long Duration
with large number of operations
Problem
Expensive rollback and restart
Degradation of concurrency
Approach
Nested Transaction
Semantic Consistency rather than Serializability

31. File Processing : Recovery

32. Failure Classification
Transaction failure :
Logical errors: internal error condition
System errors: system error condition (e.g., deadlock)
System crash:
a power failure or other hardware or software failure
Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system crash
Database systems have numerous integrity checks to prevent corruption of disk data
Disk failure

33. Recovery Algorithms Recovery algorithms : should ensure
database consistency
transaction atomicity and
durability despite failures
Recovery algorithms have two parts
Preparing Information for Recovery : During normal transaction
Actions taken after a failure to recover the database

34. Storage Structure Volatile storage: Nonvolatile storage:
does not survive system crashes
examples: main memory, cache memory
Nonvolatile storage:
survives system crashes
examples: disk, tape, flash memory, non-volatile (battery backed up) RAM
Stable storage:
a mythical form of storage that survives all failures
approximated by maintaining multiple copies on distinct nonvolatile media

35. Recovery and Atomicity
Modifying the database
must be committed
Otherwise it may leave the database in an inconsistent state.
Example
Consider transaction Ti that transfers $50 from account A to account B; goal is either to perform all database modifications made by Ti or none at all.
Several output operations may be required for Ti
For example : output(A) and output(B).
A failure may occur after one of these modifications have been made but before all of them are made.

36. Recovery and Atomicity (Cont.)
To ensure atomicity despite failures,
we first output information describing the modifications to stable storage without modifying the database itself.
We study two approaches:
log-based recovery, and
shadow-paging

37. Log-Based Recovery A log : must be kept on stable storage.
<Ti, Start>, and <Ti, Start>
< Ti, X, V1, V2 >
Logging Method
When transaction Ti starts, <Ti start> log record
When Ti finishes, <Ti commit> log record
Before Ti executes write(X), <Ti, X, Vold , Vnew > log record
We assume for now that log records are written directly to stable storage
Two approaches using logs
Deferred database modification
Immediate database modification

38. Deferred Database Modification
The deferred database modification scheme
records all modifications to the log, writes them after commit.
Log Scheme
Transaction starts by writing <Ti start> record to log.
write(X) :
<Ti, X, V>
Note: old value is not needed for this scheme
The write is not performed on X at this time, but is deferred.
When Ti commits, <Ti commit> is written to the log
Finally, executes the previously deferred writes.

39. Deferred Database Modification (Cont.)
Recovering Method
During recovery after a crash,
a transaction needs to be redone if and only if both <Ti start> and<Ti commit> are there in the log.
Redoing a transaction Ti ( redoTi) sets the value of all data items updated by the transaction to the new values.
Deletes Ti such that <Ti ,start> exists but <Ti commit> does not.

40. Deferred Database Modification : Example
If log on stable storage at time of crash is as in case:
(a) No redo actions need to be taken
(b) redo(T0) must be performed since <T0 commit> is present
(c) redo(T0) must be performed followed by redo(T1) since <T0 commit>
and <Ti commit> are present
T0: read (A) T1 : read (C) A: = A C:= C write (A) write (C) read (B) B:= B write (B)

41. Immediate Database Modification
Immediate database modification scheme
Database updates of an uncommitted transaction
For undoing : both old value and new value
Recovery procedure has two operations
undo(Ti) : restores the value of all data items updated by Ti
redo(Ti) : sets the value of all data items updated by Ti
When recovering after failure:
Undo if the log <Ti start>, but not <Ti commit>.
Redo if the log both the record <Ti start> and <Ti commit>.

42. Immediate Database Modification : Example
Recovery actions in each case above are:
(a) undo (T0): B is restored to 2000 and A to 1000.
(b) undo (T1) and redo (T0): C is restored to 700, and then A and B are
set to 950 and 2050 respectively.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050
respectively. Then C is set to 600

43. Idempotent Operation Result (Op(x)) = Result (Op(Op(x))
Example
Increment(x); : Not Idempotent
x=a; write(x); : Idempotent
Operations in Log Record
Must be Idempotent, otherwise
Multple Executions (for redo) may cause incorrect results

44. Checkpoints Problems in recovery procedure by Log record scheme :
searching the entire log records : time-consuming
Discard unnecessary redo transactions already executed.
Checkpoint Method
Marking Checkpoint
Recovery from Checkpoint
Output all log records currently residing in main memory onto stable storage.
Output all modified buffer blocks to the disk.
Write a log record < checkpoint> onto stable storage.

45. Checkpoints (Cont.) In case of failure Tc Tf T1 T2 T3
T1 can be ignored
T2 and T3 redone.
T4 undone Tc Tf T1 T2 T3 T4
checkpoint
system failure

46. Shadow Paging Mechanism maintain two page tables shadow page table
the current page table, and
the shadow page table
shadow page table
state of the database before transaction execution
Shadow page table is never modified during execution
To start with, both the page tables are identical.
Whenever any page is about to be written for the first time
A copy of this page is made onto an unused page.
The current page table is then made to point to the copy
The update is performed on the copy

47. Shadow Page : Example
Old State
New State