File Processing : Transaction Management 2015, Spring Pusan National University Ki-Joune Li
Jan 20, 2016
File Processing : Transaction Management
2015, Spring
Pusan National University
Ki-Joune Li
STEMPNU
Basic Concepts of Transaction
Transaction A set of operations Atomic :
All or Nothing : Consistent State of Database Example : Flight Reservation Cf. Partially Done : Inconsistent State
STEMPNU
Transaction States
Active
PartiallyCommitted
Failed Aborted
Committedthe initial state; the transaction stays in this state while it is
executing
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
ALL
NOTHING
STEMPNU
ACID Properties
Atomicity. All or Nothing Not Partially Done Example : Failure in Flight Reservation
Consistency. Execution of a transaction preserves the consistency of the
database.
State 1 State 2
All
Nothing
State 2’PartiallyDone
Consistent
Consistent
STEMPNU
ACID Properties
Isolation. 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
Transation 2
No Effect
STEMPNU
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
STEMPNU
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
STEMPNU
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)
STEMPNU
Transaction Management
Transaction Management Guarantee ACID Properties of Transaction by
Concurrency Control : Isolation and Consistency Recovery : Atomicity and Durability
File Processing : Concurrency Control
STEMPNU
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
STEMPNU
Conflict Graph
T1
T2
r(a)
w(a)
affects
r(b)
w(b)
S1S1
T1
T2
r(a)
w(a)
affects
r(b)
w(b)
S2S2
Res(S1) Res( (T1, T2) )Res(S1) Res( (T1, T2) )
Res(S1) Res( (T1, T2) )Res(S1) Res( (T1, T2) )
Res(S1) Res( (T2, T1) )Res(S1) Res( (T2, T1) )
STEMPNU
Detect Cycle in Conflict Graph
T1
T2
r(a)
w(a)
affects
r(b)
w(b) T2T2
T1T1
If Cycle in Conflict Graph Then Not Serializable Otherwise Serializable
STEMPNU
How to make it serializable
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
STEMPNU
Lock-Based Protocols
A lock 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.
STEMPNU
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.
STEMPNU
Lock-Based Protocols
Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
STEMPNU
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
STEMPNU
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
STEMPNU
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
STEMPNU
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
STEMPNU
Lock Manager
Transaction 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
STEMPNU
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 ?
STEMPNU
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
STEMPNU
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)
STEMPNU
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
STEMPNU
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
STEMPNU
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
transactionwith smallertimestamp
transactionwith largertimestamp
Correctness of Timestamp-Ordering Protocol
STEMPNU
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
STEMPNU
Long Duration Transaction
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
File Processing : Recovery
STEMPNU
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
STEMPNU
Recovery Algorithms
Recovery algorithms : should ensure database consistency transaction atomicity and durability despite failures
Recovery algorithms have two parts1. Preparing Information for Recovery : During normal transaction
2. Actions taken after a failure to recover the database
STEMPNU
Storage Structure
Volatile 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
STEMPNU
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.
STEMPNU
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
STEMPNU
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
STEMPNU
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.
STEMPNU
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.
STEMPNU
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 - 50 C:= C- 100 write (A) write (C) read (B) B:= B + 50 write (B)
STEMPNU
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>.
STEMPNU
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
STEMPNU
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
STEMPNU
Checkpoints
Problems in recovery procedure by Log record scheme :1. searching the entire log records : time-consuming
2. Discard unnecessary redo transactions already executed.
Checkpoint Method Marking Checkpoint Recovery from Checkpoint
Marking Checkpoint1. Output all log records currently residing in main memory onto stable
storage.
2. Output all modified buffer blocks to the disk.
3. Write a log record < checkpoint> onto stable storage.
STEMPNU
Checkpoints (Cont.)
In case of failure
T1 can be ignored
T2 and T3 redone.
T4 undone
TcTf
T1
T2
T3
T4
checkpoint system failure
STEMPNU
Shadow Paging
Mechanism maintain two page tables
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
STEMPNU
Shadow Page : Example
Old State
New State