Concurrency Control

database transactions are performed

concurrently without violating the data integrity
of the respective databases.
To ensure correctness, a DBMS usually
guarantees that only serializable transaction
schedules are generated,
 Atomocity Using Lock-Based
Protocols
▪ A lock is a mechanism to control
concurrent access to a data item Lock-compatibility
matrix

▪ 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 the

concurrency-control manager by the
transaction manager. Transaction can

proceed only after request is granted .

 Atomocity Using Lock-Based
Protocols

Lock-compatibility
matrix
T1 T2 T3 Lock
status
LOCK-S(A) GRANT(A,T
1)
READ(A)
LOCK-S(A) GRANT(A,T
2)
READ(A)
LOCK-X(A) WAIT(A,T3)
WRITE(A)
 Atomocity Using Lock-Based
Protocols

Lock-compatibility
matrix
T4 T5 T6 Lock
status
GRANT(A,T4
)
LOCK-X(A)
WRITE(A) WAIT(A,T5)
LOCK-S(A)
READ(A)
WAIT(A,T6)
LOCK-X(A)
WRITE(A)
 Atomocity Using Lock-Based
Protocols

Lock-compatibility
matrix
T7 T8 T9 Lock
status
GRANT(A,T7
)
LOCK-X(A)
WRITE(A) GRANT(B,T8)
LOCK-X(B)
WRITE(B)
GRANT(C,T9
LOCK-X(C) )
WRITE(C)
 Atomocity Using Lock-Based
Protocols
Lock-compatibility
matrix

Question Put appropriate lock and show lock status

T1 T2 T3 T4 LOCK
STATUS

READ(P)

WRITE(Q)

READ(P)

WRITE(P)
 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.)

 The potential for deadlock exists in most locking

protocols. Deadlocks are a necessary evil.
 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.
 Concurrency control manager can be designed to
prevent starvation.
 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
 Cascading roll-back is possible under two-phase locking.
To avoid this, follow a modified protocol called strict
two-phase locking. Here a transaction must hold all its
exclusive locks till it commits/aborts.
 Rigorous two-phase locking is even stricter: 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
 Implementation of Locking
 A lock manager can be implemented as a separate
process to which transactions send lock and unlock
requests
 The lock manager replies to a lock request by sending a
lock grant messages (or a message asking the
transaction to roll back, in case of a deadlock)
 The requesting transaction waits until its request is
answered
 The lock manager maintains a data-structure called a
lock table to record granted locks and pending requests
 The lock table is usually implemented as an in-memory
hash table indexed on the name of the data item being
locked
Lock Table
 Black rectangles indicate
granted locks, white ones
indicate waiting requests
 Lock table also records the type
of lock granted or requested
 New request is added to the end
of the queue of requests for the
data item, and granted if it is
compatible with all earlier locks
 Unlock requests result in the
request being deleted, and later
requests are checked to see if
they can now be granted
 If transaction aborts, all waiting
or granted requests of the
transaction are deleted
 lock manager may keep a list
of locks held by each
transaction, to implement
this efficiently
 Recovery and Atomicity
 To ensure atomicity despite failures, we first
output information describing the modifications
to stable storage without modifying the
database itself.
 We study log-based recovery mechanisms in
detail
 We first present key concepts
 And then present the actual recovery
algorithm
Example of Data Access
 Log-Based Recovery
 A log is kept on stable storage.
 The log is a sequence of log records, which maintains
information about update activities on the database.
 When transaction Ti starts, it registers itself by writing a
record
<Ti start>
to the log
 Before Ti executes write(X), a log record
<Ti, X, V1, V2>
is written, where V1 is the value of X before the write (the
old value), and V2 is the value to be written to X (the new
value).
 When Ti finishes it last statement, the log record <Ti
commit> is written.
 Two approaches using logs
 Immediate database modification
 Deferred database modification
 Database Modification
 The immediate-modification scheme allows updates of
an uncommitted transaction to be made to the buffer, or
the disk itself, before the transaction commits

 Update log record must be written before a database

item is written
 We assume that the log record is output directly to
stable storage

 Output of updated blocks to disk storage can take place

at any time before or after transaction commit

 Order in which blocks are output can be different from

the order in which they are written.
 Database Modification
 The deferred-modification scheme performs updates to
buffer/disk only at the time of transaction commit
 Simplifies some aspects of recovery
 But has overhead of storing local copy

 We cover here only the immediate-modification scheme

 Transaction Commit
 A transaction is said to have committed when its
commit log record is output to stable storage
 All previous log records of the transaction must
have been output already

 Writes performed by a transaction may still be in the

buffer when the transaction commits, and may be
output later
 Immediate Database Modification
Example
Log Write Output

<T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050>
A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600> BC output before T1
C = 600 commits

BB , BC
<T1 commit>
BABA output after T0
commits
 Note: BX denotes block containing X.
 Undo and Redo Operations
 Undo of a log record <Ti, X, V1, V2> writes the old value V1 to
X
 Redo of a log record <Ti, X, V1, V2> writes the new value V2 to
X
 Undo and Redo of Transactions
 undo(Ti) restores the value of all data items updated by Ti to
their old values, going backwards from the last log record
for Ti
 Each time a data item X is restored to its old value V a
special log record (called redo-only) <Ti , X, V> is written
out
 When undo of a transaction is complete, a log record
<Ti abort> is written out (to indicate that the undo was
completed)
 redo(Ti) sets the value of all data items updated by Ti to the
new values, going forward from the first log record for Ti
 No logging is done in this case
Undo and Redo Operations (Cont.)
 The undo and redo operations are used in
several different circumstances:
 The undo is used for transaction rollback
during normal operation(in case a
transaction cannot complete its execution
due to some logical error).
 The undo and redo operations are used
during recovery from failure.
 We need to deal with the case where during
recovery from failure another failure occurs
prior to the system having fully recovered.
 Transaction rollback (during normal
operation)

 Let Ti be the transaction to be rolled back

 Scan log backwards from the end, and for each log
record of Ti of the form <Ti, Xj, V1, V2>
 Perform the undo by writing V1 to Xj,
 Write a log record <Ti , Xj, V1>
 such log records are called compensation log
records
 Once the record <Ti start> is found stop the scan
and write the log record <Ti abort>
 Undo and Redo on Recovering from
Failure
 When recovering after failure:
 Transaction Ti needs to be undone if the log
 contains the record <Ti start>,
 but does not contain either the record <Ti commit> or <Ti
abort>.
 Transaction Ti needs to be redone if the log
 contains the records <Ti start>
 and contains the record <Ti commit> or <Ti abort>
 It may seem strange to redo transaction Ti if the record <Ti
abort> record is in the log. To see why this works, note that
if <Ti abort> is in the log, so are the redo-only records
written by the undo operation. Thus, the end result will be
to undo Ti 's modifications in this case. This slight
redundancy simplifies the recovery algorithm and enables
faster overall recovery time.
 such a redo redoes all the original actions including the
steps that restored old value. Known as repeating history
 Immediate Modification Recovery
Example

Below we show the log as it appears at three instances of time.

Recovery actions in each case above are:

(a) undo (T0): B is restored to 2000 and A to 1000, and log records
<T0, B, 2000>, <T0, A, 1000>, <T0, abort> are written out
(b) redo (T0) and undo (T1): A and B are set to 950 and 2050 and C
is restored to 700. Log records <T1, C, 700>, <T1, abort> are
written out.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050
respectively. Then C is set to 600
 Checkpoints
 Redoing/undoing all transactions recorded in the log can
be very slow
 Processing the entire log is time-consuming if the
system has run for a long time
 We might unnecessarily redo transactions which have
already output their updates to the database.
 Streamline recovery procedure by periodically performing
checkpointing
 All updates are stopped while doing checkpointing
1. 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 L> onto stable storage
where L is a list of all transactions active at the time of
checkpoint.
 Checkpoints (Cont.)
 During recovery we need to consider only the most recent
transaction Ti that started before the checkpoint, and
transactions that started after Ti.
 Scan backwards from end of log to find the most recent
<checkpoint L> record
 Only transactions that are in L or started after the
checkpoint need to be redone or undone
 Transactions that committed or aborted before the
checkpoint already have all their updates output to stable
storage.
 Some earlier part of the log may be needed for undo
operations
 Continue scanning backwards till a record <Ti start> is
found for every transaction Ti in L.
 Parts of log prior to earliest <Ti start> record above are
not needed for recovery, and can be erased whenever
desired.
 Example of Checkpoints

Tc Tf
T1
T2
T3
T4

checkpoint system failure

 T1 can be ignored (updates already output to disk due to
checkpoint)
 T2 and T3 redone.
 T4 undone