- 1 -

1. Concurrency Control
1.1 Locks
attempt to ensure serializability by allowing transactions to access data items in a mutually
exclusive manner
many different lock types can be defined, although we concentrate on following:
shared - a read only lock mode on data item X denoted by LSX!" #ore than one
transaction may simultaneously ac$uire a shared lock on the same data item X"
exclusive - a lock with read%write privileges on a data item X denoted by LXX!" &nly
a single transaction may ac$uire an exclusive lock on the same data item" &ther
transactions must wait until the data item in unlocked '(X!! before the data item can
be locked with either a shared or exclusive lock"
the shared and exclusive lock modes are not compatible with each other"
if a data item has a shared lock on it, then other transactions may also ac$uire shared locks
without any wait penalties" )lthough a transaction which wants an exclusive lock on the data
item will wait until all shared locks have been removed"

it is also possible to define refinements of the basic lock types to allow upgrades, for
example:

UP(X) - upgrade a shared lock to an exclusive lock *possibly wait if other outstanding shared
locks in effect+

DN(X) - downgrade an exclusive lock to a shared lock" *may often enhance concurrency +

it may also be possible for underlying system to issue lock%unlock re$uests on behalf of the
transaction transparent to the transaction!:

if ,i issues a readX, xi! then LSX! generated if LXX! not already owned"

if ,i issues a writeX, xi! then either an '-X! or LXX! is issued"

the use of locks does not guarantee serializability nor freedom from deadlock
what is also needed is a locking protocol that all transactions must follow
consider the following schedule where only the pertinent locking instructions are shown:
S
,
i
,
.

LX)!
LS/!
LS)!
-1-
- 2 -
LX/!
we note that the two transactions are in deadlock and cannot proceed with normal execution
without system intervention e"g" one of the transactions will generally be rolled back!
as well, if data items are unlocked too early in an attempt to increase system concurrency,
then it is possible to leave the database in an inconsistent state - not reachable by any serial
schedule"
1.2 Test or !eriali"a#ility
$l%orith&'
Serializability test for schedules with shared%exclusive locks"
(n)ut'
) schedule S for a set of transactions ,
0
, ,
1
,""", ,
k
*ut)ut'
) determination whether S is serializable
+ethod'
0! if in S, transaction ,
i
share locks item X, and ,
.
is the next transaction if it exists! to
exclusive lock X, then place an edge from ,
i
to ,
.
"
1! assume that in S, ,
i
exclusive locks X, and ,
.
is the next transaction if it exists! to
exclusive lock X" ,hen place an edge from ,
i
to ,
.
" )lso, let ,
m
be any transaction that
share locks X after ,
i
unlocks its exclusive lock on X, but before ,
.
exclusive locks X if
there is no ,
.
, then ,
m
is any transaction to share lock X after ,
i
unlocks X!" ,hen place an
edge from ,
i
to ,
m
"
2! if the resultant graph has a cycle, then S is not serializable" &therwise, then any
topological sort of the graph is a serial order for the transactions
,xa&)le -
determine whether the following schedule is serializable:
S
time ,
3
,
4
,
5
,
6

0 LX)!
1 LX/!
-2-
- 3 -
2 '()!
3 LS)!
4 '(/!
5 LX/!
6 LS)!
7 '(/!
8 LX/!
09 '()!
00 '()!
01 LX)!
02 '(/!
03 LS/!
04 '()!
05 '(/!
1.. T/o Phase Lockin% Protocol

a simple scheme which ensures serializability but not freedom from deadlock"

each transaction issues lock%unlock re$uests in two phases:

1) growing phase: transaction ac$uires all necessary locks with no locks released"
2) shrinking phase: all ac$uired locks are released and no new locks are allowed"

consider the following simple example which illustrates the possibility of deadlock even
though the protocol is followed"
,0 ,1
LX)!
LS/!
LS)!
LX/!
-3-
- 4 -
deadlock occurs on ,0:s LX/! attempt" ;ence either let deadlock happen and deal
with it later or try to detect the possible deadlock and prevent it"

what is needed are protocols which ensure serializability and freedom from deadlock"
1.- 0ra)h12ased Protocols

for non two phase protocols we need additional information on how the transaction will
access the database to ensure serializability"

assume there exists some partial ordering on the set < of data items, where
< = > d0, d1, """, dn ?

if there exists an edge di d., then if access is needed to both di and d., then di must be
accessed first"
A
B
C
E
F
D
G H J
,xa&)le' a tree based protocol exclusive locks only!

each ,i can lock a data item at most once and:

1) the first lock by ,i may be on any item"
2) thereafter, item X can only be locked by ,i if the parent of X has also been
previously locked by ,i"
.) data may be unlocked at anytime"
-) ,i can not unlock an item and then lock the same item again"

all legal schedules are serializable, deadlock free, no rollbacks are needed"
1.3 Ti&esta&) *rderin%

basically, an attempt to ensure serializability by selecting an ordering in advance between

each pair of transactions"

a timestamp ,S,.! is assigned to transaction ,., #eore execution begins"

if ,. follows ,i i"e" begin execution after ,i!, then ,S,i! @ ,S,.! *i"e" timestamps are
generating in increasing Avalue:+" -erhaps use a software incremental counter or the system
clock - timestamps must be uni$ue"

the basic strategy is: if ,S,i! @ ,S,.!, then we must ensure that the resultant schedule is
e$uivalent to the serial schedule >,i, ,.?
-4-
- 5 -

in addition, with each data item X we associate the following timestamps:

1) B,X! - the largest timestamp of any transaction which performed a successful
writeX!"
2) C,X! - the largest timestamp of any transaction which performed a successful
readX!"

a ma.or impact is the granularity of the item X" Ds it an attribute, tuple, relation, etc" ,his has
impact on the overheads and the memory re$uirements to hold the timestamps as well as
probable impact on concurrency achievable"
1.3.1 Tho&as4 5rite 6ule

more basic protocols exist, but ,homas: write rule is an improvement over more basic
timestamp ordering protocols"
1) ,i performs a readX!:

if ,S,i! @ B,X!, then ,i is rolled back since it re$uires the value of X which was previously
overwritten"

if ,S,i! B,X!, then the read is performed and C,X! is assigned the max C,X!, ,S,i! !
2) ,i performs a writeX!:

if ,S,i! @ C,X!,
the value to be written was previously needed, it was assumed never
produced and read out of serial order"
then, the write is re.ected and ,i is rolled back"

if ,S,i! @ B,X!,
,i is writing an obsolete value, hence the writeX! is ignored and ,i continues"

else the writeX! is performed and B,X! ,S,i!"

a rolled back transaction is restarted and is given a new timestamp"

a rolled back transaction, ,i, can also cause cascaded rollbacks:

any ,. that used values produced by ,i is also rolled back"

as well, any ,k that used values generated by ,. is also rolled back

and so on"""

hence rollbacks can be very expensive and disruptive"

1.3.2 7alidation Techni8ues

in these schemes, a transaction undergoes several phases:

$) 6ead Phase

any re$uired data items are read by ,i

updates are only performed to local variables not to the database"

2) 7alidation Phase
-5-
- 6 -

now determine if local variables can be copied to the database without any serializability
violations"
C) 5rite Phase

if phase / was successful then the database is updated otherwise ,i is rolled back"

we also re$uire the following associated timestamps:

Start,i! - when ,i starts execution"
Ealidation,i! - when ,i starts to validate"
Finish,i! - when ,i finished the writes to the database"

in general, ,S,i! Ealidation,i!" ,his usually leads to better response times provided the
conflict rates are low"
7alidation Test

in testing for the validation for ,. , for all ,i with ,S,i! @ ,S,.! one of the following must
hold:
1. Finish,i! @ Start,.!: if ,i completes before ,. starts then serial ordering is
maintained"
2. Start,.! @ Finish,i! @ Ealidation,.! : the writes of ,i and ,. do not overlap" ,he
writes of ,. can not affect the reads of ,i and hence serial order is maintained"

,he protocol also guards against cascading rollbacks since the actual writes occur only after
transaction commitment"
1.3.. +ultiversion !che&es

,his scheme attempts to aid those transactions which only read but not update the database
and prevent their rollbacks *in many systems this type of transaction is in the ma.ority+

&n each writeX!, a new version of X is created *the previous value still exists and may be
read+

&n a readX!, the system selects which version of X is to be read"

)gain, a ma.or performance impact is the granularity of X"

For each item X we maintain a se$uence of versions:

> X0, X1, X2, """, Xn ?

Gach version of Xk has:

1. the contents of X
2. B,Xk! - the timestamp of the creating transaction
.. C,Xk! - the largest timestamp of the transaction which successfully performed a
read"

transaction ,i creates a new version of X *Xk+ by issuing a writeX! and setting:

B,Xk! ,S,i!

C,Xk! ,S,i!
-6-
- 7 -

on a successful read of Xk by transaction ,. , then

C,Xk! max C,Xk!, ,S,.! !

assume that ,i issues a read or write to X and B,Xk! is the largest timestamp ,S,i!:
1. if ,i does a readX!, then the value read is the value of Xk"
2. if ,i does a writeX! and ,S,i! @ C,Xk! then ,i is rolled back, otherwise a new
version of Xk is created"
*,i is rolled back since it attempts to write a version that some other ,. would have
read, hence it can not be allowed to proceed+

a ma.or advantage is that read re$uests never fail *in many systems these are in the
ma.ority+"

disadvantages: obvious overheads *how long are Aold: versions retainedH+

reading of data re$uires update to C,Xk! - possibly a disk access

conflicts are resolved by rollbacks rather than waits - expensive to rollback"

2. Deadlock 9andlin%

,here are basic broad approaches:

1. 'se a protocol to prevent deadlock from occurring
2. 'se deadlock detection and handling

allow deadlock to occur

detect this state

attempt recovery procedure

2.1 Deadlock Prevention

there are many possible approaches, a few examples:

i! lock all re$uired data in one step! before execution, if fail, then try again
*obvious potential problems+
ii! impose a partial ordering on data i"e" the previous tree protocol!"
iii! use preemption and transaction rollbacks"

timestamps used to determine if ,i waits or is rolled back"

if rolled back, then ,i retains its previous timestamp"

2.1.1 5ait1Die +ethod

a non-preemptive approach"

let ,i re$uest data owned by ,. :

if ,S,i! @ ,S,.! then ,i waits else ,i is rolled back dies!

older transactions wait for younger ones"

the older the transaction gets, the more it may wait"

-7-
- 8 -

,i may be rolled back several times trying to access data held by some other transaction

starvation is avoided since eventually, ,i will become the oldest transaction have the
smallest timestamp! and will not be rolled back"
2.1.2 5ound15ait +ethod

a preemptive scheme, let ,i re$uest data owned by ,. :

if ,S,i! I ,S,.! then ,i waits else ,. is rolled back"

older transactions never get rolled back and never wait for younger ones"

if ,. is rolled back due to a re$uest by ,i, then ,. will wait the next time if ,i still holds onto the
data"

again, starvation is avoided as in the wait-die method"

2.1.. Ti&eout 2ased !che&es

basic idea:

after re$uesting a lock, a transaction waits for a specified timeout to ac$uire the lock"

if the lock is not attained before the timeout expires, then the transaction rolls JitselfK back
and restarts"

if there was a deadlock present, then one of the transactions involved in the deadlock will
eventually timeout and roll itself back allowing the others to proceed"

simple to implement but the choice of timeout could affect the system operation:

if timeout too short, then too many needless rollbacks may occur when a deadlock condition
does not exist"

if timeout too long, then there could be long delays with the system in deadlock! until a
transaction eventually times out"

this scheme has limited potential"

2.2 Detection and 6ecovery

periodically invoke an algorithm to determine the system state with respect to deadlock"

the system must retain information of all allocated data items as well as outstanding
re$uests"
2.2.1 Detection

possibly use directed graphs called wait-for graphs!

nodes the transactions in the system"

edges ordered pair ,i, ,.! where ,i waits for ,. to release a data item"

an edge ,i ,. is removed when ,. releases data ,i needs"

deadlock occurs if the directed graph has a cycle"

the system maintains the graph and periodically examines the graph for cycles"
-8-
- 9 -

it is usually expensive to invoke the algorithm - constraints involve how often and when
invoked"

for example:
T1
T4
T2
T3

if ,3 re$uests data held by ,2, then a cycle occurs deadlock! between >,1, ,2, ,3?
2.2.2 6ecovery

usually by rolling back one or more transactions - which onesH

2.2.2.1 !election o 7icti&

attempt to rollback those which incur Aminimum: cost is best:

determine the duration of ,i and additional time re$uired to complete"

the number of data items accessed so far"

the number of additional items needed"

the number of transactions involved in the rollback - cascadedH

2.2.2.2 6oll#ack

how far to rollback the selected victims! instead of total rollback:

only as far back to remove the deadlock is optimal"

it may re$uire additional state information to perform a partial rollback"

2.2.2.. !tarvation

often a small subset of transactions may be picked very fre$uently"

they Anever: complete their task"

can place a limit on the number of times any particular transaction may be rolled back"
2.. (nsert and Delete *)erations

assume we now allow insert and delete operations on data items in the database:

insert(X): inserts a new data item X into the database and assigns it an initial value"

delete(X): deletes data item X from the database"

obvious logical errors can be detected, e"g": attempt to read X after it has been deleted, or to
read X before it has been inserted, etc"
2...1.1 delete'

if two phase locking protocol is used, then an exclusive lock must be obtained for a data
item before it can be deleted
-9-
- 10 -

under timestamp-ordering protocol, a similar test as for /rite must be performed:

,i performs a deleteX!:

if ,S,i! @ C,X!,
the value to be deleted was previously read by another transaction ,. where
,S,.! I ,S,i! ,hence the delete is re.ected and ,i is rolled back"

if ,S,i! @ B,X!,
transaction ,. where ,S,.! I ,S,i! has previously written to X, hence the delete
is re.ected and ,i is rolled back"

else the deleteX! is performed"

2...1.2 (nsertion

since an insert assigns a value to a data item" Dt may treated similar to a write operation for
concurrency control purposes"

under two-phase locking protocol:

if ,i performs an insertX!, ,i is given an exclusive lock on the newly created data item"

under timestamp-ordering: if ,i performs an insertX!, then B,X!=C,X! ,S,i!

-10-