Chapter 4

Concurrency Control

1
 Outline
Definition and Purpose

Problem of Concurrency

Concurrency Control Techniques

Lock-based Protocols

Binary and Multi-mode Locking

Two Phase Locking
Timestamp-based Protocols

Multiple Granularity Locking

Validation Based protocols

2
 4.1 What is Concurrency Control?
 Concurrency control is the process of managing simultaneous
operation (execution) of transaction(update, insert, deletes,
etc.) on the database (special in shared database) without
having them interfere with one another to ensure the
serializability of transactions.
Multiple transaction  executed at a time
Database shared
A techniques to ensure the isolation property of concurrently
executing transactions.
The objective of concurrency control is similar to the objective
of multiuser computer system like multiuser OS like Unix or
multiuser application programs like (banking system, airline
3
reservation system ,and so on)
Cont... NB
 Purpose of Concurrency Control
To enforce Isolation (through mutual exclusion) among
conflicting transactions.
To preserve database consistency through consistency
preserving execution of transactions.
To resolve read-write and write-write conflicts.
To ensure database correctness.

Example:
In concurrent execution environment if T1 conflicts with
T2 over a data item A, then the existing concurrency control
decides if T1 or T2 should get the A and if the other
transaction is rolled-back or waits.
4
 4.2 Classic problem of Concurrency NB
Many users can perform different operations at the same time.

BUT concurrent operations (simultaneous execution of

transactions) on a database (specially over a shared database)
there can be serious problems such as loss of data integrity &
consistency.
Loss of data integrity & consistency can be occur, if the
execution is not properly managed, scheduled and organized.
Even if transactions execute correctly, results may interleave in
different ways and can be lead to one of the following problem
• Lost of Updates (WWC)
• Uncommitted Data (WRC)
• Inconsistent retrievals (RWC)
5
 Multiple update problem NB
Write – write conflict of transaction
The data written by one transaction (an update operation) is
being overwritten by another update transaction.
For example:
Account CA2090 that has $5000 Balance in it.
Suppose T1 is withdrawing $1000 Account at time t1
Another transaction T2 is depositing $2000 to the account at
time t2.
If these transaction were executed serially(one after the other)
the final result is $6000 irrespective of the order in which the
transaction executed.
But if the transaction executed concurrently, then depending
6 on how the transactions are executed the results will vary.
Cont...
Sequence T1 T2 Balance
01 Begin transaction 5000
02 Read(CA2090) Begin transaction 5000
03 CA2090:= CA2090-1000) Read(CA2090) 5000
04 Write(CA2090) CA2090:=CA2090+2000 4000
05 Commit Write(CA2090) 7000
06 Commit 7000

 Both transaction start nearly at the same time and read account
balance of $5000.
 T1 will reduce the balance by $1000 write the result at time t4 and T2
will increase the amount by $2000 and write the result after the T1 is
committed.
 Finally the account gain extra $1000 which would have been wrong
7
 Uncommitted dependency problem.N
 Write – read conflict of transaction
 Occurs when one transaction is allowed to see the intermediate
results of another transaction before it is committed.
Sequence T1 T2 Balance
01 Begin transaction 5000
02 Read(CA2090) 5000
03 CA2090:= CA2090-1000) 5000
04 Write(CA2090) Begin transaction 4000
05 Read(CA2090) 4000
06 Roll back CA2090:=CA2090+2000 4000
07 Write(CA2090) 6000
08 Commit 6000
8
 Incorrect Analysis problem NB
read – write conflict of transaction
So far we have seen problem arise when concurrent
transactions are updating the database.
But problem could arise even when transaction is not
updating the DB.
So if they are allowed to read the DB when the database is in
an inconsistent state.
This problem is often referred to as dirty read or unrepeated
read.
The problem of dirty read occurs when a transaction reads
several values from the DB while other transaction are
updating those values.
9
 Cont…
Initially: Acc 1 = 40; Acc2 = 50; Acc3 = 30;

Time User 1 (Trans A) User 2 (Trans B)

1 Retrieve Acc 1: Sum = 40
2 Retrieve Acc2 : Sum = 90
3 Retrieve Acc3 :
4 Update Acc3: 30 → 20
5 Retrieve Acc1:
6 Update Acc1: 40 → 50
7 commit
8 Retrieve Acc3:
Sum = 110 (not 120)
10
4.3 Concurrency control Techniques NB
 Pessimistic concurrency control
Take an assumption that conflicts will happen
Detect conflicts as soon as they occur and resolve them using
blocking by means of locking
Synchronizing concurrent access to database item
Mainly used in environments where there is high contention for
data, where the cost of data locks is less than cost of rolling back.
 Optimistic concurrency control
Take an assumption that occurrences of conflicts are rare
Does not require locking or time stamping techniques
Transaction executed without restrictions until it is committed
Check for conflicts just before commit
Mainly used when low contention for data, and where the cost of
rolling back a transaction is lower than the cost of locking
11
4.3.1 Locked Based Protocol
A locked transaction is a transaction which, in addition to read
and write actions, contains lock and unlock operations to the
data items.
Lock and unlock operations enable a database system to
control the order of read and write actions of a concurrent set
of transactions.
A locking policy is a set of rules which restrict the possible
ways to introduce lock and unlock operations into a
transaction.
A locking policy is safe, if whenever all the transactions
conform to the policy, any history of the transactions is
guaranteed to be serializable.
12
Cont… NB
 Locking:- is “pessimistic”
Main techniques used for controlling the concurrent execution of
transactions by synchronizing an access to data item).
A lock describes the status of the data item with respect to
possible operations that can be applied to that item.
Guarantees exclusive use of a data item to a current transaction
Required to prevent another transaction from reading inconsistent
data

 Locking types
Binary Locks
Multiple-mode locks
Two phase locking

13
1) Binary Locks
The lock can have two states (locked, unlocked) or (1,0).
It is simple but restrictive.
A distinct lock is associated with each database item X.
The current value of the lock of item X is LOCK(X).
If LOCK(X) is 0, item X can be accessed when required.
If LOCK(X) is 1, item X cannot be accessed when required.

Lock-item and unlock_item operations are implemented as

indivisible units (no interleaving should be allowed once the
operation is started until it terminates or waits).
The wait command within the operations is implemented by
putting the transaction on a waiting queue for item X until the
item is unlocked.
14
 Cont…
 Binary locking can be implemented by representing the lock as
record of the form
<data item name, lock, locking-transaction> + a queue
 The queue is for waiting transactions for the data item X.
 The records of the currently locked items are maintained in a lock
table.

 Lock table entry:

Number of transactions currently holding a lock
Type of lock held (shared or exclusive)
Pointer to queue of lock requests
 Items not in the lock table are considered unlocked.

15
 Cont…
Example:
 Lock_item(X)
B: if LOCK(X) = 0 (* item is unlocked *)
then LOCK(X)  1 (* lock the item *)
else
begin
wait (until LOCK(X) = 0 and lock manager wakes up the
transaction);
go to B
end;
 Unlock_item(X)
LOCK(X) 0; (* unlock the item*)
if any transaction are waiting
then wakeup one of the waiting transactions;
16
 Cont…
Rules followed in binary locking by every transaction
1. A transaction T must issue lock_item(X) before any read item(X)
or write_item(X) performed in T.
2. A transaction T must issue unlock_item(X) after all read item(X)
and write_item(X) performed in T.
3. A transaction T will not issue a lock_item(X) if it already holds
the lock on item X.
4. A transaction T will not issue an unlock_item(X) unless it already
holds the lock on item X.

 The rules can be forced by the lock manager module of the DBMS
 Thus, at most one transaction can hold the lock on an item which
leads to no two transactions can accessed the same item
concurrently.
17
2) Shared/Exclusive Locking
 It is called Read/Write locking and a multiple-mode lock.
 The lock has three values and data items can be locked in two
modes:
read locked (shared lock): the item is locked for read purpose
and can be shared for reading by another transaction.
write locked (exclusive lock): the item is locked for write
purpose and cannot be accessed by another transaction.
unlocked: the item is unlocked and can be accessed by any
transaction.
 The three operations are also indivisible.
 Lock requests are made to concurrency control manager.
 Transaction can proceed only after request is granted.
18
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
19 released.
Cont…
 Rules for Read/Write locking
1. A transaction T must issue read_lock(X) or write_lock(X)
before any read_item(X) performed in T.
2. A transaction T must issue write_lock(X) before any
write_item(X) performed in T.
3. A transaction T must issue unlock(X) after all read_item(X)
and write_item(X) performed in T.
4. A transaction T will not issue read_lock(X) if it already holds a
read lock or write lock on item X.
5. A transaction T will not issue write_lock(X) if it already holds
a read lock or write lock on item X.
 If LOCK(X)=write_locked, the value of the locking-transaction is a
single transaction that holds the exclusive lock on X.
 If LOCK(X)=read_locked, the value of the locking-transaction is a
list of transactions that hold the shared lock on X.
20
Cont…
 Example Algorithm: Read lock(X)

B: if LOCK(X) = “unlocked“
then begin
LOCK(X)  “read locked“;
no_of_reads(X)  1
end
else if LOCK(X) = “read locked“
then begin
no_of_reads(X)  no_of_reads(X) + 1
else
begin
wait (until LOCK(X) = “unlocked“ and
the lock manager wakes up the transaction);
go to B
21
end;
Cont…
 Example Algorithm: Write_lock(X)

B: if LOCK(X) = “unlocked or 0“
then begin
LOCK(X)  “write_locked“;
end
else
begin
wait (until LOCK(X) = “unlocked“ and
the lock manager wakes up the transaction);
go to B
end;

22
Cont…
 Example Algorithm: Unlock(X)

B: if LOCK(X) = “write_locked“
then begin
LOCK(X)  “unlocked“;
wakeup one of the waiting transaction, if any
end
else if LOCK(X) = “read_locked“
then begin
no_of_reads(X)  no_of_reads(X) - 1
if no_of_reads(X) = 0
then begin
LOCK(X) = “unlocked“;
wakeup one of the waiting
transaction, if any
end
end;
23
 Conversion of Locks NB
A Transaction is allowed under certain conditions to convert the lock
from one state to another.
 Upgrading:
Convert the lock from shared to exclusive by issuing
write_lock(X) after its read_lock(X).
The transaction must be the only one has the read lock or it must
wait.
 Downgrading:
Convert the lock from exclusive to shared by issuing
read_lock(X) after the write_lock(X).
 Notes:
Upgrading and downgrading relax rule 4 and 5 of the
Read/Write locking scheme.
24
Cont… NB
Algorithms for conversion of locks
Lock upgrade: existing read lock to write lock
if Ti has a read-lock (X) and Tj has no read-lock(X) (i  j)
then
convert read-lock (X) to write-lock (X)
else
force Ti to wait until Tj unlocks X

Lock downgrade: existing write lock to read lock

Ti has a write-lock (X)
(*no transaction can have any lock on X*)
convert write-lock (X) to read-lock (X)

25
Cont…
 Binary locks or R/W locks will not guarantee serializability
 Example 1:
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 read of 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.
26
Cont…
Example 2:
T1 T2
read_lock(Y); read_lock(X);
read_item(Y); read_item(X);
unlock(Y); unlock(X); Initial values: X=20, Y=30

write_lock(X); write_lock(Y); Executing T1-T2  X=50, Y=80

read_item(X); read_item(Y); Executing T2-T1  X=70, Y=50

X:=X+Y; Y:=X+Y;
write_item(X); write_item(Y);
unlock(X): unlock(Y);

27
Cont…

Result of schedule S
Time X=50, Y=50
(nonserializable)

28
 3) Two-phase Locking Protocol (2PL)
 A safe locking policy which is based on the simple rule saying a
transaction is not allowed to further lock a data item once it has
already unlocked some data item.
 A transaction is said to follow the 2PL protocol if all locking
operations precede the first unlock operation of the transaction.
 The transaction is divided into two phases:
 Phase 1: Growing or Expanding Phase
Where new locks can be issued and non can be released
Transaction may obtain locks, but may not release locks
 Phase 2: Shrinking Phase
Where existing locks can be released and no new locks can be
granted
Transaction may release locks, but may not obtain locks
29
Cont…

• Two-phase locking.
Cont…
 Requirement for 2PL:
For a transaction lock and unlock phases must be mutually
exclusively, that is, during locking phase unlocking phase must
not start and during unlocking phase locking phase must not
begin.
 2PL limits the concurrency by
Early locking all items even it may not need all of them early
Delaying unlocking all items until locking all the item it needs
even it may not need the locked item.
 The protocol assures(guarantees) serializability schedule without
the need of testing it.
 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
31
final lock).
Cont… NB
 Conservative 2PL: It is called also Static 2PL.
It requires a transaction to lock all the items it accesses before the
transaction begins execution (by declaring its read and write
sets).
If the transaction cannot lock any item, it must wait until lock all
the items.
Not practical because it is not possible to get the read and write
sets in most cases.
The conservative 2PL is a deadlock-free protocol.

 Strict 2PL: It is the most popular variation of 2PL in practice.

It guarantees strict schedule.
It requires that a transaction T does not release any of its
exclusive locks until it commits or aborts.
32 Strict 2PL is not a deadlock-free protocol.
Cont… NB
 Rigorous 2PL:
It is a more restrictive variation of Strict 2PL.
It guarantees strict schedule also.
It requires that a transaction T does not release any of its locks
(shared or exclusive) until after it commits or aborts.
It is easier to be implemented than the strict 2PL.
The transaction is in its expanding phase until it ends.

33
Cont…

• Strict two-phase locking.

 Implementation of Locking
 Lock manager:
Can be implemented as a separate process to which transactions
send lock and unlock requests
Responsible for assigning and policing the locks used by
transactions
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)
Maintains a data structure called a lock table.
May keep a list of locks held by each transaction, to implement
this efficiently
 Lock table:
Usually implemented as an in-memory hash table indexed on the
name of the data item being locked
Records the type of lock granted or requested
35
Cont…  Black rectangles indicate granted
locks, white ones indicate
waiting requests
 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
 The requesting transaction waits
until its request is answered
 Unlock requests result in the
request being deleted, and later
requests are checked to see if
they can now be granted
 If transaction aborts, then all
waiting or granted requests of the
36
Lock Table transaction are deleted
 Pitfalls of Lock-Based protocols NB
 If Concurrency control manager no designed well (or designed
badly) it result in to the following pitfalls.
 Deadlock:
 This problem occurs when each transaction T in a set of two or
more transactions is waiting for some item that is locked by
some other transaction T’ in the set.
 Starvation
 Possible occur if concurrency control manager is badly
designed.
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.
It may occur if the waiting scheme for locked item is unfair.
37
Cont…
 Consider the partial schedule

 In such case, neither T nor T can make progress executing since

3 4
lock-S(B) causes T to wait for T to release its lock on B,
4 3
executing lock-X(A) causes T to wait for T to release its lock
3 4
on A.
 Such a situation is called a deadlock.

38
Cont…
Solutions for deadlock:
 Deadlock Prevention Protocols.
 Using the conservative 2PL (not practical).
 Ordering the DB items.
 Nowaiting Protocols (NW).
 Using the concept of transaction Timestamps.
 Cautious waiting Protocol.

 Deadlock Detection Protocols.

 Wait-for graph is a simple

 Timeouts.
Having a system-defined timeout period and a mechanism to
abort the transaction that waits for a period longer than the
predefined timeout
39
 Cont…
I) Deadlock Prevention Protocols
1) Using the Conservative 2PL protocol:
 The protocol had been discussed and it was shown it is a deadlock-free
protocol.
 The protocol is not practical because of the need of the pre-declared
read and write sets.
2) Ordering the DB items:
 The protocol needs to order the DB items and enforce the transaction to
lock its items in that order.
 It is impractical because it requires that the programmer be aware of the
chosen order of the items.
3) No Waiting Protocol (NW):
 If a transaction is unable to obtain a lock, it is immediately aborted and
then restarted after a certain time delay without checking if a deadlock
will actually occur or not.
 The protocol can cause transactions to abort and restart needlessly.
40
Cont…
4) The concept of transaction Timestamp:
Used to decide if the transaction involved in a deadlock
situation should wait, abort or preempt another transaction.
The timestamp of a transaction T is TS(T) which is a unique
identifier assigned to the transaction T and is based on the
order in which the transaction T is started.
If T1 started before T2, then TS(T1) < TS(T2)
[T1 is the older and T2 is the younger]
 There are two schemes to prevent deadlock which are wait-
die and wound-wait.
The wait-die aborts Ti if it is the younger while wound-wait
aborts Tj if it is the younger.
Both protocols may cause some transactions to be aborted and
41 restarted even they may never actually cause a deadlock.
Cont…
 Wait-die:
Suppose that T tries to lock X but it is not able to because X is
i
locked by Tj with a conflicting lock:
The rule is:
If TS(T ) < TS(T ), then T is allowed to wait; otherwise abort
i j i
Ti (Ti dies) and restart it later with the same timestamp.

 Wound-wait:
Suppose that T tries to lock X but it is not able to because X is
i
locked by Tj with a conflicting lock:
The rule is:
If TS(T ) < TS(T ), then abort T (T wounds T ) and restart
i j j i j
it later with the same timestamp; otherwise Ti is allowed to
wait.
42
Cont…
5) Cautious Waiting Protocol:
Proposed to reduce the number of needless aborts/restarts.
Suppose that T tries to lock X but it is not able to because X is
i
locked by Tj with a conflicting lock:
The rule is:
If T is not blocked (not waiting for some other locked item),
j
then Ti is blocked and allowed to wait; otherwise abort Ti.

II. Timeouts
It is simple and practical due to its low overhead.
The idea is to have a system-defined timeout period and a
mechanism to abort the transaction that waits for a period longer
than the predefined timeout.
The system assumes that the transaction expired the timeout may
be in a deadlock.
43
 Cont…
I) Deadlock Detection Protocols
 The concept is to not enforce any restrictions on executing the
transactions, but check if a deadlock actually exists.
 It is a more practical set of protocols.
 It is a beneficial if the transactions are short or the load is light
(conflicts are not expected to highly exist).
 Wait-for graph is a simple way to detect the state of deadlock.
Wait-for graph:- used to check the existing of a deadlock.
 How to build it:
1. One node for each currently executing transaction.
2. If Ti is waiting to lock an item X that is currently locked by T j, a
directed edge from Ti to Tj is created.
3. If Tj releases the lock of item that Ti was waiting for, the directed
edge is dropped from the graph.
 If the graph has a cycle, the state of the deadlock exists.
44
Cont…
 The system must abort some of the transactions when a deadlock
had been detected.
 Selecting a transaction to be aborted is known as Victim Selection.
 The algorithm of Victim Selection should avoid selecting
transactions that have been running for a long time and that have
performed many updates.
T1’ T2’
read_lock(Y);
read_item(Y);
T1’ T2’
read_lock(X);
Tim
e read_item(X);
Wait-for graph write_lock(X);
write_lock(Y);

45 Sample example of Wait-for graph

Cont…
Solutions for Starvation:
 The problem occurs when transaction cannot proceed for an
indefinite period of time while other transactions in the system
continue normally.
 The solutions:
1. Using of a fair waiting scheme as first-come first-serve.
2. Allowing priorities for transaction but increase the priority of a
transaction the longer it waits, until it eventually gets the highest
priority and proceeds.
 It also may occur if the Victim Selection algorithm used in
deadlock detection protocol selects the same transaction as a
victim repeatedly.
 The solution:
 The algorithm can use higher priorities for transactions that
have been aborted multiple times.
 Note: Wait-die and Wound-wait protocols avoid starvation.
46
Cont… NB
 Disadvantages of locking

Lock management overhead.

Deadlock detection/resolution.

Concurrency is significantly lowered, when congested nodes are

locked.
To allow a transaction to abort itself when mistakes occur, locks
can’t be released until the end of transaction, thus currency is
significantly lowered
(Most Important) Conflicts are rare. (We might get better
performance by not locking, and instead checking for conflicts at
commit time.)

47
4.3.2 Multiple Granularity NB
 What is Granularity?
Granularity is the size of the data item chosen as the unit of
protection by a concurrency control program.
The size of the locked item determines the granularity of the
lock.
The data item can be as large as the entire database or it can
be as small a field value of a record.
When the size of the data item is small we say the
granularity is fine & when it is large we say it is coarse.
Fine granularity (lower in tree): high concurrency, high
locking overhead
Coarse granularity (higher in tree): low locking overhead,
low concurrency
48
Cont…
 Granularity Locking
 Up to now we have considered locking (and execution) at the level
of a single item/row
 However there are circumstances at which it is preferable to perform
lock at different level (sets of tuples, relation, or even sets of
relations)
As extreme example consider a transaction that needs to access
to whole database: performing locks tuple by tuple would be
time-consuming
 Data item granularity significantly affects concurrency control
performance. Thus, the degree of concurrency is low for coarse
granularity and high for fine granularity.
 Allow data items to be of various sizes and define a hierarchy (tree)
of data granularities, where small granularities are nested within
49 larger ones
Cont… NB
 Locking can take place at following levels:
Database-level lock:- Entire database is locked

Table-level lock:- Entire table is locked

Page-level lock:- Entire diskpage is locked

A diskpage (page) is the equivalent of a diskblock which
is directly addressable section of a disk.
Has a fixed size, such as 4k, 8k, or 16k.
Example: if you want to write only 73 bytes to a 4k page,
the entire 4k must be read from disk, updated in memory
and written back to disk
Page-level locks are currently the most used multi-user
DBMS locking methods.
50
Cont…
Row-level lock
Allows concurrent transactions to access different rows of
same table, even if rows are located on same page
A row-level lock is less restrictive than the previous
locking methods.
Advantage: improves the availability of data.
Disadvantage: its management require high overhead (a
lock exists for every row in a table).
Field-level lock
Allows concurrent transactions to access same row, as
long as they require use of different fields (attributes)
within that row
When a transaction locks a node in the tree explicitly, it
implicitly locks all the node's descendents in the same mode.
51
Example of Granularity Hierarchy

The levels, starting from the coarsest (top) Database

level are:
Database Tables
Area contains
File Pages
Record
Tuples
52
Cont…
 Intention Lock Modes
In addition to S and X lock modes, there are three additional
lock modes with multiple granularity:
intention-shared (IS): indicates explicit locking at a lower
level of the tree but only with shared locks.
intention-exclusive (IX): indicates explicit locking at a
lower level with exclusive or shared locks
shared and intention-exclusive (SIX): the sub tree rooted
by that node is locked explicitly in shared mode and
explicit locking is being done at a lower level with
exclusive-mode locks.
Intention locks allow a higher level node to be locked in S
or X mode without having to check all descendent nodes.
53
Cont…
 Multiple Granularity Locking Scheme
 Transaction T can lock a node Q, using the following rules:
i
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, and may be locked in
any mode
3. A node Q can be locked by Ti in S or IS mode only if the parent
of Q is currently locked by Ti in either IX or IS mode.
4. A node Q can be locked by Ti in X, SIX, or IX mode only if the
parent of Q is currently locked by Ti in either IX or SIX mode.
5. Ti can lock a node only if it has not previously unlocked any
node (that is, Ti is two-phase).
6. Ti can unlock a node Q only if none of the children of Q are
currently locked by Ti.
 Observe that locks are acquired in root-to-leaf order, whereas they
54 are released in leaf-to-root order.
Cont…
 Compatibility Matrix with Intention Lock Modes

IS IX S SIX X

IS     

IX     

S     

SIX     

X     

55
Cont…
 Granularity of data items and Multiple Granularity Locking: An
example of a serializable execution:
T1 T2 T3
IX(db)
IX(f1)
IX(db)
IS(db)
IS(f1)
IS(p11)
IX(p11)
X(r111)
IX(f1)
X(p12)
S(r11j)
IX(f2)
IX(p21)
IX(r211)
Unlock (r211)
Unlock (p21)
Unlock (f2)
56
S(f2)
Cont…
 Granularity of data items and Multiple Granularity Locking: An
example of a serializable execution (continued):

T1 T2 T3
unlock(p12)
unlock(f1)
unlock(db)

unlock(r111)
unlock(p11)
unlock(f1)
unlock(db)
unlock (r111j)
unlock (p11)
unlock (f1)
unlock(f2)
57
unlock(db)
4.3.3 Timestamp-Based Protocol
 This protocols using the timestamps to order the execution of
transaction for an equivalent serial schedule to guarantee
serializability instead of determining the order of each operation in a
transaction at execution time.
Definition:
 Timestamp TS(T) is a unique identifier created by the DBMS to
identify the transaction.
 Each transaction is issued a timestamp when it enters the system.
 The timestamp values are assigned in the order in which the
transactions are submitted to the system.
 The timestamps can be generated by using a logical counter that is
incremented each time its value is assigned to a transaction or by
58
using the current value of date/time value of the system clock.
Cont…
 Since there is no lock, the timestamp concurrency protocols are free
from deadlock and starvation!
If an old transaction Ti has time-stamp TS(Ti), a new transaction
Tj is assigned time-stamp TS(Tj) such that TS(Ti) < TS(Tj).
The protocol manages concurrent execution such that the time-
stamps determine the serializability order.
 In order to assure such behavior, the protocol maintains for each
data Q two timestamp values:
W-timestamp(Q) is the largest time-stamp(youngest transaction)
of any transaction that executed write(Q) successfully.

R-timestamp(Q) is the largest time-stamp(youngest transaction)

of any transaction that executed read(Q) successfully.
59
Cont…
Timestamp Protocol Algorithm
 Suppose that transaction T issues write(Q).
i
1. 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 T is rolled back.
i

2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an

obsolete value of Q.
 Hence, this write operation is rejected, and T is rolled back.
i

3. Otherwise, the write operation is executed, and W-

timestamp(Q) is set to TS(Ti).
60
Cont…
 Suppose a transaction T issues a read(Q)
i
1. 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 T is rolled back.
i
2. If TS(Ti) W-timestamp(Q), then the read operation is
executed, and R-timestamp(Q) is set to max(R-timestamp(Q),
TS(Ti)).
 The timestamp-ordering protocol guarantees serializability since all
the arcs in the precedence graph are of the form:
Transaction Transaction
with smaller with larger
timestamp timestamp

Thus, there will be no cycles in the precedence graph

 Even if transactions are deadlock free, the schedule may not be
61 cascade-free, and may not even be recoverable.
Cont…
Basic ideologies of time stamping technique
Produces explicit order in which transactions are submitted
to the DBMS
Uniqueness
Ensures that no equal time stamp values can exist

Monotonicity
Ensures that time stamp values always increase

All database operations (read and write) within the same

transaction must have the same time stamp.

62
Cont…
Example
A partial schedule for several data items for transactions with
timestamps 1, 2, 3, 4, 5
T1 T2 T3 T4 T5
read(X)
read(Y)
read(Y)
write(Y)
write(Z)
read(Z)
read(X)
abort
read(X)
write(Z)
abort
write(Y)
write(Z)

63
4.3.4

Validation-Based Protocol NB
If majority of transactions are read-only transactions, the rate of
conflicts among transactions may be low.
 Protocol requires that each transaction T executes in two or three
different phases in its lifetime, depending on whether it is a read-
only or an update transaction.
 The three phases of concurrently executing transactions can be
interleaved, but each transaction must go through the three phases
in that order.
 It is a type of optimistic concurrency control

1. Read and execution phase:

It reads the values of the various data items and stores them in
variables local to Ti.
It performs all write operations on temporary local variables,
without updates of the actual database
64
Cont…
2. Validation phase:
Transaction Ti performs a “validation test” to determine if local
variables can be written without violating serializability.
• For read only validation consists of checks to ensure that the
values read are the current values
• For updates transactions, it consists of determining whether the
current transaction leaves the database in a consistent state
If a transaction fails the validation test, the system aborts the
transaction.
3. Write phase:
If the validation test succeeds for transaction Ti , the value of
temporary local variables that hold the results of any write
operations performed by Ti are copied to the database.
65
Read-only transactions omit this phase
Cont…
 Each transaction Ti has 3 timestamps
Start(Ti) : the time when Ti started its execution

Validation(Ti): the time when Ti entered its validation phase

 Finish(Ti) : the time when Ti finished its write phase

 Serializability order is determined by timestamp given at validation

time, to increase concurrency.
 This protocol is useful and gives greater degree of concurrency if
probability of conflicts is low.
 That is because the serializability order is not pre-decided and
relatively less transactions will have to be rolled back.
• The scheduling is done by assigning transaction numbers and each
Transaction Ti is explicitly assigned a unique integer transaction
66 number t(i)
Cont…
 Condition of Validation Test for Transaction Tj
 For all Ti with TS (Ti) < TS (Tj) either one of the following condition
holds:
finish(Ti) < start(Tj) :- Meaning Ti completes its write phase
before Tj starts its read phase.
start(Tj) < finish(Ti) < validation(Tj):- Meaning the set of data
items written by Ti does not intersect with the set of data items read
by Tj.
In other word Ti finish its write before (Tj) enter or starts its its
validation phase
Then validation succeeds and Tj can be committed. Otherwise,
validation fails and Tj is aborted.
The write set of Ti does not intersect the read set or write set of T j ,

67
and Ti completes its read phase before Tj complete its read phase.
Cont…
Example of schedule produced using validation

T14 T15
read(B)
read(B)
B:- B-50
read(A)
A:- A+50
read(A)
(validate)
display (A+B)
(validate)
write (B)
write (A)

68
Cont…
Reading Assignment
Thomas’s Write Rule

Multiversion sheme
o Multiversion Timestamp Ordering
o Multiversion Two-Phase Locking

69
 THE END!
Do you have QUESTION’S ???
70
 When we need Concurrency Control

Concurrent access to data is desirable when:

1.The amount of data is sufficiently great that at any given
time only fraction of the data can be in primary memory &
rest should be swapped from secondary memory as
needed.
2. Even if the entire database can be present in primary
memory, there may be multiple processes.

71
 Concurrency Control vs. Serializability Tests
Concurrency-control protocols allow concurrent schedules,
but ensure that the schedules are conflict/view serializable,
and are recoverable and cascadeless .
Concurrency control protocols generally do not examine the
precedence graph as it is being created
Instead a protocol imposes a discipline that avoids
nonseralizable schedules.
Different concurrency control protocols provide different
tradeoffs between the amount of concurrency they allow and
the amount of overhead that they incur.
Tests for serializability help us understand why a concurrency
control protocol is correct.
72
Cont…
 The R/W locking operations can be implemented by using a lock
table consisting of records of the type
<data item name, lock, no_of_reads, locking-transaction(s)>

 If LOCK(X)=write_locked, the value of the locking-transaction is a

single transaction that holds the exclusive lock on X.

 If LOCK(X)=read_locked, the value of the locking-transaction is a

list of transactions that hold the shared lock on X.

73
 Timestamps (continued)
Thomas’s Write Rule
 It is another variation for the basic TO.
 It does not enforce conflict serializability, but it rejects fewer
write operations.
 The rule modifies the write_item(X) as follows:
 If read_TS(X) > TS(T), then abort and rollback T and reject
the operation.
else If write_TS(X) > TS(T), then do not execute the
operation but continue processing.
else execute write_item(X) and set
write_TS(X)=TS(T).

74
 Multiversion Schemes
 Up to now we only considered a single copy (the most recent) of each database
item.
 Multiversion schemes keep old versions of data item to increase concurrency.
 Multiversion Timestamp Ordering
 Multiversion Two-Phase Locking
 Basic Idea of multiversion schemes
 Each successful write results in the creation of a new version of the data
item written.
 Use timestamps to label versions.
 When a read(Q) operation is issued, select an appropriate version of Q
based on the timestamp of the transaction, and return the value of the
selected version.
 reads never have to wait as an appropriate version is returned immediately.
 A drawback is that creation of multiple versions increases storage overhead
 Garbage collection mechanism may be used…

75
 Multiversion Timestamp Ordering
 Each data item Q has a sequence of versions <Q1, Q2,...., Qm>. Each version Qk
contains three data fields:
 Content -- the value of version Qk.
 W-timestamp(Qk) -- timestamp of the transaction that created (wrote) version
Qk
 R-timestamp(Qk) -- largest timestamp of a transaction that successfully read
version Qk
 when a transaction Ti creates a new version Qk of Q, Qk's W-timestamp and R-
timestamp are initialized to TS(Ti).
 R-timestamp of Qk is updated whenever a transaction Tj reads Qk, and TS(Tj) >
R-timestamp(Qk).

76
Multiversion Timestamp Ordering (Cont)
 Suppose that transaction Ti issues a read(Q) or write(Q) operation. Let Qk
denote the version of Q whose write timestamp is the largest write timestamp less
than or equal to TS(Ti).
1. If transaction Ti issues a read(Q), then the value returned is the content
of version Qk.
2. If transaction Ti issues a write(Q)
1. if TS(Ti) < R-timestamp(Qk), then transaction Ti is rolled back.
2. if TS(Ti) = W-timestamp(Qk), the contents of Qk are overwritten
3. else a new version of Q is created.
 Observe that
 Reads always succeed
 A write by Ti is rejected if some other transaction Tj that (in the serialization
order defined by the timestamp values) should read
Ti's write, has already read a version created by a transaction older than Ti.
 Protocol guarantees serializability
77
 Multiversion Two-Phase Locking
 Differentiates between read-only transactions and update transactions
 Update transactions acquire read and write locks, and hold all locks up to the
end of the transaction. That is, update transactions follow rigorous two-phase
locking.
 Each successful write results in the creation of a new version of the data item
written.
 each version of a data item has a single timestamp whose value is obtained
from a counter ts-counter that is incremented during commit processing.
 Read-only transactions are assigned a timestamp by reading the current value of
ts-counter before they start execution; they follow the multiversion timestamp-
ordering protocol for performing reads.

78
 Multiversion Two-Phase Locking (Cont.)
 When an update transaction wants to read a data item:
 it obtains a shared lock on it, and reads the latest version.
 When it wants to write an item
 it obtains X lock on; it then creates a new version of the item and sets this
version's timestamp to .
 When update transaction Ti completes, commit processing occurs:
 Ti sets timestamp on the versions it has created to ts-counter + 1
 Ti increments ts-counter by 1
 Read-only transactions that start after Ti increments ts-counter will see the
values updated by Ti.
 Read-only transactions that start before Ti increments the
ts-counter will see the value before the updates by Ti.
 Only serializable schedules are produced.

79
Insert and Delete Operations
 If two-phase locking is used :
A delete operation may be performed only if the transaction
deleting the tuple has an exclusive lock on the tuple to be deleted.
A transaction that inserts a new tuple into the database is given
an X-mode lock on the tuple
 Insertions and deletions can lead to the phantom phenomenon.
A transaction that scans a relation (e.g., find all accounts in
Perryridge) and a transaction that inserts a tuple in the relation
(e.g., insert a new account at Perryridge) may conflict in spite of
not accessing any tuple in common.
If only tuple locks are used, non-serializable schedules can result:
the scan transaction may not see the new account, yet may be
serialized before the insert transaction.
Insert and Delete Operations (Cont.)
 The transaction scanning the relation is reading information that indicates
what tuples the relation contains, while a transaction inserting a tuple
updates the same information.
 The information should be locked.
 One solution:
Associate a data item with the relation, to represent the information
about what tuples the relation contains.
Transactions scanning the relation acquire a shared lock in the data
item,
Transactions inserting or deleting a tuple acquire an exclusive lock on
the data item. (Note: locks on the data item do not conflict with locks
on individual tuples.)
 Above protocol provides very low concurrency for insertions/deletions.
 Index locking protocols provide higher concurrency while
preventing the phantom phenomenon, by requiring locks
on certain index buckets.
Weak Levels of Consistency
 Some applications are willing to live with weak levels of consistency,
allowing schedules that are not serializable
 E.g. a read-only transaction that wants to get an approximate total
balance of all accounts
 E.g. database statistics computed for query optimization can be
approximate
 Such transactions need not be serializable with respect to other
transactions
 Tradeoff accuracy for performance

 In many database systems, such as Oracle, read committed is

the default consistency level
 has to be explicitly changed to serializable when required
 set isolation level serializable
 Lower degrees of consistency useful for gathering approximate
information about the database

82