Concurrency control & Recovery

•Concurrency control
Lock based protocol
2 phase locking protocol
•Failure Classification
• Storage Structure
• Log-Based Recovery
Deferred Update
Immediate Update
• Check points
•Shadow Paging
 Concurrency Control
• A database must provide a mechanism that will ensure that all possible
schedules are
– either conflict or view serializable, and
• A policy in which only one transaction can execute at a time generates serial
schedules, but provides a poor degree of concurrency
• Goal – to develop concurrency control protocols that will assure serializability.
• Concurrency control and locking is the mechanism used by DBMSs for the
sharing of data. Atomicity, consistency, and isolation are achieved through
concurrency control and locking.
• When many people may be reading the same data item at the same time, it is
usually necessary to ensure that only one application at a time can change a data
item.
• Locking is a way to do this. Because of locking, all changes to a particular data
item will be made in the correct order in a transaction.
 Lock-Based Protocols
• A lock is a mechanism to control concurrent access to a data item
• Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. 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.
 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 on the item by other transactions
• Any number of transactions can hold shared locks on an item,
– but if any transaction holds an exclusive on the item no other transaction
may hold any lock on the item.
• If a lock cannot be granted, the requesting transaction is made to wait till all
incompatible locks held by other transactions have been released. The lock is
then granted.
 Lock-Based Protocols (Cont.)
• Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
• Locking as above is not sufficient to guarantee serializability — if A and B get
updated in-between the read of A and B, the displayed sum would be wrong.
• A locking protocol is a set of rules followed by all transactions while requesting
and releasing locks. Locking protocols restrict the set of possible schedules.
 Pitfalls of Lock-Based Protocols
• Consider the partial schedule

• Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait

for T3 to release its lock on B, while executing lock-X(A) causes T3 to wait for
T4 to release its lock on A.
• Such a situation is called a deadlock.
– To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
 Pitfalls of Lock-Based Protocols (Cont.)
• Starvation is also possible if concurrency control
manager is badly designed. For example:
– A transaction may be waiting for an X-lock on an
item, while a sequence of other transactions request
and are granted an S-lock on the same item.
– The same transaction is repeatedly rolled back due to
deadlocks.
 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. It can be proved that the
transactions can be serialized in the order of their lock points (i.e.
the point where a transaction acquired its final lock).
 The Two-Phase Locking Protocol (Cont.)
• Two-phase locking does not ensure freedom from deadlocks
• Strict two-phase locking: Here a transaction must hold all its
exclusive locks till it commits/aborts.
• Rigorous two-phase locking : here all locks are held till
commit/abort. In this protocol transactions can be serialized in the
order in which they commit.
 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. But still relies on the programmer
to insert the various locking instructions.
 Automatic Acquisition of Locks
• A transaction Ti issues the standard read/write instruction, without
explicit locking calls.
• The operation read(D) is processed as:
if Ti has a lock on D
then
read(D)
else begin
if necessary wait until no other
transaction has a lock-X on D
grant Ti a lock-S on D;
read(D)
end
 Automatic Acquisition of Locks (Cont.)
• 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
 Failure Classification
• Recovery ?
- When Failure is happened, recover consistent state of
loss of information.
- consistent state : non-error state
• Failure Types
(1) Transaction failure : Transaction can no longer continue with
its normal execution owing to some internal condition such
as bad input, data not found, overflow, or resource limit
exceeded.
(2) System failure : The system has entered an undesirable state
(e.g. deadlock, main memory error), as a result of which the
transaction cannot continue with its normal execution.
(3) Media Failure : Nonvolatile storage error such as disk head
crash.
 Failure Recovery Idea
backup Failure
• Basic Recovery Idea ? delta part
- Redundancy of data
- Two Types of Redundancy
(1) Dump : Copy all database into another storage device
(disk or tape) periodically.
(2) Log : Store updated data and time into log file whenever
data are changed.
• Recovery operation
- Redo : When all database are failed, we recover the most recent
backup database and update delta part between backup
database and failed database using the log file.
- Undo : if current transaction have an error, we cancel the current
work.
 Storage Structure
• Volatile storage:
– examples: main memory, cache memory
• Nonvolatile storage:
– examples: disk, tape, flash memory,
non-volatile (battery backed up) RAM
• Stable storage:
– approximated by maintaining multiple copies on distinct nonvolatile
media
 Log-Based Recovery
• Log
- Most widely used structure for recording database
- Log record describes a single database write
• Log Record Type
<Ti , start> : Transaction Ti has started.
<Ti , Xj , V1, V2> : Transaction Ti has performed a write on
data item Xj. Xj had value V1 before the write and will have
value V2 after the write.
<Ti , commit> : Transaction Ti has committed.
* Ti : Transaction name Xj : data item name (account-name)
V1 : old value V2 : new value
 Log-Based Recovery (cont'd)
• Operation
- Whenever a transaction performs a write, it is essential that the
log record is created.
- The log record must be created before the database is modified.
- Once a log record exists we can output (write to disk physically)
the modification to the database.
- If we have some problem, we also have the ability to undo
a modification that has already been output to the database.
- The log must reside in stable storage.
 Log example

Transaction T1 Log

Read(A) <T1, start>

A =A-50 <T1, A, 1000, 950>
Write(A) <T1, B, 2000, 2050>
Read(B) <T1, commit>
B = B+50
Write(B)
 Deferred Database Modification
• What?
- Ensures transaction atomicity by recording all database
modification in the log, but deferring the execution of all write
operations of a transaction until the transaction partially commits.
- Not use undo :
If system crashes or the transaction aborts, then the information
on the log is simply ignored.
- Operation :
<Ti , start> : Before starts its execution, log record is written to the log.
<Ti , Xj , V2> : The write operation by Ti results in the writing of new record
to the log.
<Ti , commit> : When Ti partially commis, this record is written to the log
 Deferred Database Modification (Example)
• Example
- Let T1 be a transaction that transfers 100 won from account A
to account B. This transaction may be defined as :
T1 : Read(A, a)
a = a - 100
Write(A, a)
Read(B, b)
b = b + 100
Write(B, b)
Let T2 be a transaction that withdraws 200 won from account C.
This transaction can be defined as :
T2 : Read(C, c)
c = c - 200
Write(C, c)
Deferred Database Modification (Example)
• State of log and database
- A result of the execution T1 and T2, Note that the value of A is
changed in database only after the record <T1, A, 900> :
Log Database Sequence of Time
<T1, start> (Buffer)
<T1, A , 900>
<T1, B , 2100>
<T1, commit>
A = 900
B = 2100
<T2, start> We don't know the value A, B are
stored in disk physically, Because
<T2, C , 2800> the system decides it (output).
<T2, commit>

C = 2800
Deferred Database Modification (Example)
• Redo(Ti)
which sets the value of all data items updated by transaction Ti
to the new values in the order of log records.
• Determine which transactions need to redo (Failure 발생시 )
(1) redo :
The log contains both the record <T1, start > and the record
< T1, commit >.
This transaction may be or may not be stored disk physically.
(2) Reexecute transaction :
Other case.
Deferred Database Modification (Example)
• Example of the System Crash before the Completion of the Transactions
<T1, start> <T1, start> <T1, start>
<T1, A , 900> <T1, A , 900> <T1, A , 900>
<T1, B , 2100> <T1, B , 2100> <T1, B , 2100>
<T1, commit> <T1, commit>
<T2, start> <T2, start>
<T2, C , 2800> <T2, C , 2800>
<T2, commit>
(a) (b) (c)

(a) Clash occurs just after write(B, b) :

- No recovery action need be taken, since no commit record
appears in the log.
- A = 1000, B = 2000, C = 3000 remain in disk.
Deferred Database Modification (Example)
(b) Clash occurs just after write(C, c) :
- Recovery : redo(T1) is performed since the record < T1, commit >
appears in the log.
- Result : A = 900, B = 2100 come backup.
* T2 transaction must be reexecuted.

(c) Clash occurs just after < T2 , commit> :

- Recovery : redo(T1) and redo(T2) is performed since the
record < T1, commit > and the record < T2, commit > appears
in the log.
- Result : A = 900, B = 2100, C = 2800 come backup.
Deferred Database Modification (Example)
(d) Crash occurs during Recovery Action :
- Some transaction may recover and other transaction may not
recover.
- Recovery actions are restarted from beginning.
 Immediate Database Modification
• What?
- Uncommitted modifications : Allows database modifications to
be output to database while the transaction is still in the
active state.
- Use undo :
If system crashes or the transaction aborts, then the old-value
field of log record is used to restore.
• Log Record Format :
<Ti , Xj , Vold ,Vnew>

• Undo(Ti)
which restores the value of all data items updated by transaction
Ti to the old values.
 Immediate Database Modification (Example)
• State of log and database
- A result of the execution T1 and T2, Note that the value of A is
changed in database before partially committed :
Log Database
<T1, start>
<T1, A , 1000, 900>
A = 900
<T1, B , 2000, 2100>
B = 2100 uncommitted update,
<T1, commit> if transaction is aborted,
<T2, start> new values must be recovered
<T1, C , 3000, 2800> old values.
C = 2800
<T2, commit>
 Immediate Database Modification (Example)
• Two Recovery Schemes :
(1) Undo(Ti) :
If the log contains the record <Ti, start > but does not contain
the record < Ti, commit >.
 This transaction is crashed during execution. Thus transaction Ti
needs to be undone.
(2) Redo(Ti) :
If the log contains both the record <Ti, start > and the record
< Ti, commit >.
 This transaction is crashed just after partially committed.
Thus transaction Ti needs to be undone.
 Immediate Database Modification (Example)
• Example of the System Crash before the Completion of the Transactions
<T1, start> <T1, start> <T1, start>
<T1, A , 1000, 900> <T1, A , 1000, 900> <T1, A , 1000, 900>
<T1, B , 2000, 2100> <T1, B , 2000, 2100> <T1, B , 2000, 2100>
<T1, commit> <T1, commit>
<T2, start> <T2, start>
<T1, C , 3000, 2800> <T1, C , 3000, 2800>
<T2, commit>
(a) (b) (c)

(a) Clash occurs just after write(B, b) :

- Recovery : Undo(T1), this means transaction T1 must be undone.
- A = 1000, B = 2000, C = 3000 remain in disk.
 Immediate Database Modification (Example)
(b) Clash occurs just after write(C, c) :
- Recovery : redo(T1) is performed since the record < T1, commit >
appears in the log. And undo(T2) .
- Result : A = 900, B = 2100 come backup.
* T2 transaction must be reexecuted.

(c) Clash occurs just after < T2 , commit> :

- Recovery : redo(T1) and redo(T2) is performed since the
record < T1, commit > and the record < T2, commit > appears
in the log.
- Result : A = 900, B = 2100, C = 2800 come backup.
 Example of Recovery
• Go over the steps of the recovery algorithm on the following log:
<T0 start>
<T0, A, 0, 10> Redo-list{T3}
<T0 commit> Undo-list{T1, T2}
<T1 start>
<T1, B, 0, 10> Undo:
<T2 start>
Redo:
<T2, C, 0, 10>
Set C to 10 Set A to 20
<T2, C, 10, 20> Set C to 0 Set D to 10
<checkpoint {T1, T2}> Set B to 0
<T3 start>
<T3, A, 10, 20>
<T3, D, 0, 10> DB A B C
D
<T3 commit> Initial 0 0 0
0
Crash!!!!
At crash 20 10 20 10
After rec. 20 0 0 10
 Checkpoints
• Neccessity
- When system failure occurs, it is necessary to determine at the
point of time for redo or undo action.
- The searching entire log is time-consuming.
- The system periodically performs checkpoints.
• Tasks in Checkpoint
(1) Output all log records currently residing in main memory
onto stable storage.
(2) Output all modified buffer block to the disk.
(3) Output a log record <checkpoint> onto stable storage.
 Checkpoints (cont'd)
• Recovery Method by Each Transaction Type
c (checkpoint) f (failure)
Time
T1
T2
T3
T4
Disk T5
Memory
• T1 : committed prior to the checkpoint.
• T2 : started prior to the checkpoint and committed prior to the f.
• T3 : started prior to the checkpoint but did not committed until f.
• T4 : started after checkpoint and committed prior to the f.
• T5 : started after checkpoint but did not committed until f.
 Checkpoints (cont'd)
• Recovery Procedure (immediate case)
T 1 : Already written on the disk at the checkpoint c
T 3 : Since failed on active state, T3 must execute undo operation

from c to f. Especially, part of prior c must be included the

undo operation.
 T5 : Undo operation
 T4 : Redo operation
 T2 : Especially, part of after c need to
execute redo operation
RULE :
1. < Ti, start > and < Ti, commit > : redo
2. < Ti, start > : undo
* written on disk checkpoint reside on memory
 Shadow Paging
• Shadow paging is an alternative to log-based recovery; this scheme is useful if
transactions execute serially
• Idea: maintain two page tables during the lifetime of a transaction –the current
page table, and the shadow page table
• Store the shadow page table in nonvolatile storage, such that state of the database
prior to transaction execution may be recovered.
– Shadow page table is never modified during execution
• To start with, both the page tables are identical. Only current page table is used for
data item accesses during execution of the transaction.
• 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
Sample Page Table
 Example of Shadow Paging
Shadow and current page tables after write to page 4
Shadow Paging (cont'd)
• Operation of Shadow Paging
(1) Environment :
- Shadow paging considers the database to be made up of
a number of fixed-size disk pages.
- Page table (directory) points to the i-th database page on disk.
- All references (read or write) to database pages on disk
go through the page table.
(2) Operation :
a) Copy current page table into shadow page table and save
shadow page table on disk.
b) During transaction execution, a new copy of the modified
database page is created, but old page is not overwritten.
Shadow Paging (cont'd)
c) New page is written on unused block. Current page table
entry is modified to point to the new disk block. But
shadow page table is not modified.
d) To recover from failure, it discard the current page table.
• Advantages :
- Not require the use of a log, thus no-undo/redo technique.
=> recovering is simple
• Disadvantages :
- It difficult to keep related database pages close together
on disk
- Overhead of writing shadow page tables to disk
- Garbage collection
- Not suitable multi-user environment