7.

13 TRANSACTION SUPPORT IN SQL

basic definitions are sim~ ar ~o the earlier
This section explains the trans actio n supp ort in SQL. The
ction and is invo ked md1rectly when
representation. In SQL there is no way to use begi n_tr ansa
have COMMIT or ROLLBACK. Each
SQL statements are executed. Every trans actio n mus t
d using SET TRANSACTION.
transaction has characteristic defined for it and is men tione
The characteristic of a trans actio n are
used. State men ts include INSERT,
Access mode: indicates wha t statements of SQL can be
as READ ONLY then the transaction
DELETE, UPDATE and SELECT. If access mod e is specified
can just use SELECT state men t only. if the acess mod e is
READ WRITE then the transaction can
ts of SQL.
include INSERT, DELETE, UPDATE & SELECT statemen
n can cause erro rs, these errors can
Diagnostic area size: SQL statements within a trans actio
on is brie f so SQL prov ides methods of
be unde rstoo d using SQLSTATE variable. This informati
cs areas. This areas are useful when an
reme mbe ring addi tiona l status infor mati on in diagnosti
STIC SIZE n men tion s how many error
SQL state men t generates more than one error. DIAGNO
status details can be retrieved and passed on to the user.
which trans actio ns are allowed to
Isolation level: The isolation level mentions the way in
levels th at are supp orte d
manipulate the DB. The following are the different isolation
► READ COM MIT TED
► READ UNC OMM ITTE D:
► SERIALIZABLE.
► REPEATABLE READ and
n defined following violations can
The lowest isolation level is READ UNCOMMITED whe
occu r
en by unco mmi tted tran saction T2
Dirt y read : transaction Tl can read a value which is writt
anot her trans actio n T2 write s it.
Nonrepeatable read: transaction Tl reads a value and
has been changed.
When Tl reads the value once agai n, it sees that the value
ves a set of rows based on some
Phantom problem( imag inar y obje ct): transaction Tl retrie
h satisfies the where condition of Tl.
where condition, transaction T2 inserts a new row whic
set of rows (newly adde d row by T2)
Whe n transaction Tl is executed once again it sees different
. this difference is refereed as phan tom problem.
tion
Following table shows violations for different levels of isola
Lev el Dir ty Rea d Non repe atab l e Rea d Ph an tom
REA D UNC OM MIT TED May be May be May be
REA D COM MIT TED No May be May be
REPEATABLE REA D No No May be
SER IAL IZA BLE No No No
 The most restrictive isolation 1 .
lJNCOMMiTTED. eve1 is SERIALIZABLE and the nonrestrictive is the READ

A sample segment of transaction is

. h
s own below
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTIC 3

ISOLATION LEVEL SERIALIZABLE;

EXEC SQL INSERT INTO EMPLOYEE VALUES(III;GOVIND:I,20000);
EXEC SQL UPDATE EMPLOYEE SET ESALARY=SALARY*l.l WHERE DNO=l;

7.14 TWO PHASE LOCKINGJE~HNl·QUE PO:R CONCURRENCY CONTROL

.,,.. • .,.· ,. ' .,.,. ,,·'·., , ,. • ..... , w ~

Locking is one of the important techniques used in concurrency to overcome the anomalies due
interleaved execution. Lock is a variable associated with an object which indicates the possible
operations that can be performed on it. There can be only one lock on an object.

Types of lock and s~~~rn-tdck:~bi;J i

~ .;,,_,, ,,.~. ,,,. _·: '.x~ ; . -~~· ..,;.,ii:,~,-~• r-..

7.14.1 Binary Locks

Locked and unlocked are two states of binary lock. The lock variable for an object can be either set
(value of one) or unset( value of zero). Each object A has a distinct lock. If the value of the lock on
object A is 1, then object A cannot be accessed by any other transaction. If the value of the lock on
Ais Othen object can be accessed when requested by any transaction. the current value of the lock
associated with object A can be set using LOCK (A). There are two operations, LOCK(object):
used for setting the value of the lock variable to one and UNLOCK( object): used for unsetting the
value of the lock variable. A transaction requests access to an object A by first issuing a LOCK(A)
operation. If LOCK (A)is set(value is equal to one, which indicates that the object has been
locked by some other transaction), the transaction is forced to wait. If LOCK (A) is unset (value
is equal to zero and none of the transaction have locked it) it is changed to one (indicating that
the transaction has locked the object) and the transaction is allowed to access object A. When
the transaction completes all its actions then the objects held by the transaction are also released.
transaction uses UNLOCK(A) to release the lock of object A this sets LOCK (A) to zero (unlocks
the object) so that A may be accessed by other transactions.
Binary lock can be implemented easily by using an additional lock variable within the object
X in the database. Each lock can be visualized as three fields <data_object_n ame, LOCK, locking_
transaction> where data_object_na me is the name of the object, LOCK value indicates either o
or 1, if the value is one then the transaction id is saved in the last field locking_tran saction. Data
structure for maintaining how many transaction are waiting for object Xis required. System needs
to have a lock table to know which object is locked by which transaction. Objects which are not
there in the lock table indicates that it is unlocked.

Following rules must be followed by every transaction to achieve concurrency control using
binary lock

1. A transaction must issue the operation LOCK (A) before it wants to read or write an object A.

2. A transaction T must issue the operation UNLOCK(A) after all read and write operations
on object A is completed.

3. A transaction Twill not issue a LOCK(A) operation if it already has the lock on object A.

4. A transaction T will not issue an UNLOCK(A) operation unless it already holds the lock on
object A.

5. The lock manager module of the DBMS can enforce the above said rules. Lock will be set
between LOCK(A) and UNLOCK(A) operations. At most one transaction can hold the lock
on a particular object at any given instance of time. Thus no two transactions can access
the' same object concurrently. For example two customers want to know the availability(
number )rooms in hotel. The schedule has two transactions Tl(user 1) and T2 (user 2) who
want to read N and check the availability

Tl T2
LOCK(N)
LOCK(N) transaction has to
wait until the completion of
Tl, since the object N has been
locked by Tl

R(N)
UNLOCK(N)
There is no lock for object N and T2 gets unblocked
and is allowed to execute
R(N)
UNLOCK(N)

j
 ntage of binary locks
o,sadva
can access the object of the DB , even if the transa ction is readin g the
Mmost only one transa ction
.1 s of an object X.
w.1ue
, , Shared/exclusive lock
714 2
action of all these
This method allows more than one transa ction to access an object if the
is allow ed to
rransaction is read. If the transa ction writes an object then only one transa ction
ple transa ction
access it. This is the princi ple used in shared/exclusive lock. The reason is multi
when reads the same objec t X does not have any conflicts.
There are two types of locks that can be used
► Share d Lock ► Exclusive Lock
share d locks
Shared lock is applie d when an object from a data base has to be read. Multi ple
can be applied on the same object. Shared lock can be symbolized as 'S'.
n. Only one
Exclusive lock applie d when an object from a data base has to be writte
ction) . Exclu sive
transaction can apply an exclusive lock on an object(exclusively for that transa
lock is symbolized by 'X'.
Tl applie s
For example transa ction Tl and T2 wants to read an object A. initial ly transa ction
on objec t A and
ashared lock on objec t A, followed by transaction T2 can also apply a share d lock
then any transa ction can read the object, the schedule is as follows

Tl T2
S(A)
S(A)
R(A)
R(A)

objec t has to be
. Transaction Tl applies a shared lock on object A for readin g if the same
exclusive lock (Read
Written by transa ction T2 then transa ction T2 will not be allowed to apply
followed by write is not allow ed since it creates conflicts).

Tl T2
S(A)
X(A) Block ed
R(A)
Other actions
 Transaction Tl applies a exclusive lock on object A for writing and if the same object has
to
be written by transaction T2 then transaction T2 will not be allowed to apply exclusive lock
( write
followed by read is not allowed). IfT3 wants to read the object A then the transac tion will
not be
allowed to apply shared lock also.

Tl T2 T3
X(A)
X(A) Blocked
R(A)
S(A) Blocked
W(A)

Transaction that has an exclusive lock can also read the object; an additio nal shared lock
is
not required. A transac tion that requests a lock is suspended (stopped) until the DBMS
is able to
grant the requested lock.
One of the metho d to implement shared/ exclusive lock is to keep track of the numbe r
of
transac tions holdin g read lock on an object X which is saved in lock table. The dtails of
it would
be<object_name, LOCK, No_of _reads, transaction_list> where object_name: is the object
name;
LOCK: indicates wheth er it is shared or exclusive lock; No_of_reads: this is only applica
ble for
SHARED lock & indicates the numbe r of transactions using this object as read, if it is
exclusive
lock then the value is one indicating that there is only one transaction using object as write;
and
transaction_list: contains a list of transactions if it is SHARED lock or transac tion ID of
a single
transac tion if it is EXCLUSIVE.
Unlock(X) is used to release the lock held by a transaction on object X or the locks gets
automatically released when the transaction commits. shared/ exclusive lock is used the
system
enforces the following
1. A transac tion applies shared/exclusive lock on object X before it wants to read/w
rite on an
object X.
2. A transac tion has to use exclusive lock before write action is perfor med on object
X
3. A transaction has to release the lock on an object once read/write is completed.
4. A transac tion will not apply shared lock on an object X if it has already applied
shared or
exclusive lock on the same object X.
s. A transaction will not apply exclusive lock on an object X if it has already applied shared or
exclusive lock on the same object X.
6. A transaction will apply unlock on an object X if it has been either locked as shared or
ex-
clusive lock on the object X.
7.14,3conversion
of locks

lock conversion rules 4 & s i . f dt

for . s not app11eable. The process of converting locks rom rea 0
write lock is called up gradation. If transaction Tl has applied a shared lock on object X and
st
later on reque s for exclusive lock on the same object X, this lock gets upgraded if Tl is the only
transaction using the object X else it must wait.

If a transaction Tl has an exclusive lock on an object x then it can be converted to shared

lock, this process is referred as down gradation of lock.

7.14.4Two-Phase Locking (2PL)

The most ·widely used locking protocol, called Two-Phase Locking, or 2PL. this has two phases an
expanding phase and a shrinking phase. In expanding or growing phase all the locks required for
transaction are applied and will not be released. In shrinking phase existing locks for a transaction
are released and no new locks are applied.

Tl T2
S(A)
S(C)
R(A)
R(C)
UNLOCK(A) a4
UNLOCK( C) as
X(C) a6
X(A) a7
R(C)
R(A)
w·cc)
W(A)

UNLOCK(C)
UNLOCK(A)

fi 11 2 PL since the locks are released in between (action a4

This schedule does not o o; cquire the locks in-between the transaction(action a6
and a5)the transaction as well as t ey a
and a7).
 Tl T2
X(A)
X(B)
W(A)
W(B)
UNLOCK(A)
UNLOCK(B)
X(A)
W(A)
UNLOCK(A)
UNLOCK(A)

In this example Tl ot T2 will lock all the objects which is required for transaction(growing
phase) and later once the transaction has completed read/write on objects the locks gets released
at the end(shrinking phase). The above schedule hence follows 2 PL, this protocol when used
ensures Serializability of schedules( concurrent execution with no anomalies).
For example there are two transaction Tl: transferring of amount Rs 500 from account A to
account B and T2 : Adding Rs 10 as interest to account A.
Assume the initial balance of A=lS00 & B=800

Tl T2
Action 1 X(A)
Action 2 R(A) A=lS00
Action 3 W(A) A=IS00-500 =1000
Action 4 X(A) Blocked
Action 5 X(B)
Action 6 R(B) B=S00
Action 7 W(B) B=S00+ 500= 1300
Action 8 Commit Locks are release
Action 9 R(A) A-1000
Action 10 W(A) A-1000+10 -1010
Action 11 Commit Locks are released
 Transa ction Tl applies an exclu · .
l f A which is d Sive 1ock sin e object A has to be written , it initiall y reads
0 1500
the va ue . k b. an deducts 500 from it. In action 4 transac tion T2 will request for
an exclusive 1ode) ~n Jee~ A , which makes the transaction T2 blocke d ( mul tiple exclusi ve
° lode
are not all owe . 1 ransac tion T 1 cont"mues, m . . .
action 5 it applies the exclusi ve lock on obJect B
since the object has to be written , reads B which is 800 and adds 500 to it Transa ction T l
comm its
and releases _all ~e locks. Transa ction T2 after action 8 gets unbloc ked & starts executing,
it reads
object A which is ~OO~ adds 10 and saves it throug h commit, Lock gets release d. The result
of this
interleaved execut ion is exactly equiva lent to serial executi on .
There are numbe r of variant s of two phase locking

7.14.5 Basic
The above mentio ned metho d is basic 2 PL

7.14.&Conservative 2PL or static 2PL:

It uses read_s et and write_ set method , read_se t is the list of all objects that the transa ction
reads
and write_s et is a set of all objects that the transac tion writes. In this approa ch read_
set and
write_set are pre-de clared and locks are applied to all these objects, if any one of the
object is not
available for lockin g then the entire transac tion is blocked. It is a dead lock free protoc
ol This is
difficult to use since the entire set of objects will not be known to most of the applica tions.
The most popula r varian t is strict 2 PL
In this, exclusi ve locks are not release d until the transac tion commi ts or aborts
this ,,ill
make all other transac tions to wait. Read locks can be released in betwee n the transac tion.

Tl T2
i
X(A)
S(B)
X(D)
W(A) I

R(B) i
Unloc king is done in betwe en
UNLO CK(B)
the transa ctio n
X(B)
I
W(D) I
COMM IT will release all locks
W( B)
C OMM IT will releas e all locks
 7.14.7 Rigorous 2 PL:
. .I Iock(both shared and exclusive) until it commi ts or aborts.
In this transactron does not re ease any

Tl T2
X(A)
W(A)
X(D)
S(B)
vV(D)

Locks are applie d in between S(E)

R(B)
COMM IT
UNLO CK(A)
UNLO CK(B)
R(E)
COMM IT
UNLO CK(D)
UNLO CK(E)

are
Locks can be applied in betwee n but after the transac tion comm its/ aborts the locks
released. It has a shrink ing phase only.

7 .14.8 Dealing with dead lock and starvation

le there are
The disadv antage of 2PL is that the transac tion may end up with deadlo cks. For examp
T2: Adding
two transac tion Tl: transfe rring of amoun t Rs 500 from accoun t A to accoun t B and
e of A=lS0 0
Rs 10 as interes t to accoun t B first and then to accoun t A. Assun1e the initial balanc
& B=B00. The schedu le can be

Tl T2
Action I X(A)
Action 2 X(B)
Action 3 R(A) A=l50 0
Action 4 R(B) 8=800
Action 5 W(A) A-=150 0-500 =1000
Action 6 W(B) B-800 + l0 -810
Action 7 X(B) Bloc ,rd
1

Action 8 X(A) Blocke d

 B,
sact ion TI _ sets
_ an excl u sive lock o n o bj ec t A, T2 se ts an excl usiv e lock o~
Tran e
an exclu sive lock on B and is bloc ked smc
fl proceeds afte r wnt mg A it will requ ests for
is held by tran sa ctio n T2. Tran sact ion T 2 also writ es obje ct B and requ ests an
object A T2 is
TI is wai ting for T2 to rele ase its lock and
exclu sive lo ck on A and is bloc ked . Now, is
for T 1 to rele ase its lock . Suc h a cycl e of tran sact ions wai ting for lock s to be rele ased
waiting
called a deadlock.
k pre ven tion protocols
7.14.9 Dead loc th
st th0 d is to lock all obje cts befo re we star t the tran sact ion. If any one of e
The simpie me effi cien t
sact ion gets bloc ked . This met hod is not
objec t cann ot be lock ed then the enti re tran
ces the aspe cts of con curr ency . Tran sact ion tim esta mp can be use d to ens ure
since it redu p whi ch
ion can be asso ciat ed with a tim e stam
Serializability of sche dule s. Eac h tran sact ted
whi ch tran sact ion has star ted first , if TS( Tl) <TS (T2 ) then tran sact ion Tl has star
indicates ng the
can be used to reso lve the con flic ts amo
early as com pare d with tran sact ion T2. this
trans acti ons.
lock are wai t-di e and wou nd- wai t
Two sche mes whi ch are used to prev ent dead
an
any tran sact ion. If tran sact ion Ti requ ests
Wai t-die : this app roac h doe s not pree mpt
has bee n held by Tj, it is allo wed to wait if it satis fies TS( Ti)< TS( Tj) (Th at is Ti is
object A whi ch e tim e-
ple supp ose that tran sact ion Tl, T2, T3 hav
older than Tj) else Ti gets abo rted . For exam TS of
ps 5, 10 and 15 resp ectiv ely. IfT I requ ests a data item held by T2 then Tl will wai t(si nce
stam nce
item held by T2, then T3 will be roll ed bac k(si
Tl<TS ofT 2 5les s than lO). IfT3 requ ests a data
TS ofT 3>T S ofT 2 15 grea ter than lO).

7.14.1 OWo und -wait scheme

e
roac h uses pree mpt ive tech niqu e on tran sact ion. It is a com plem ent to the wai t-di
This app to wai t if
A whi ch has bee n held by Tj, it is allo wed
scheme. If tran sact ion Ti requ ests an obje ct with the
d bac k (Tj is wou nde d by Ti). Tj is star ted
it satis fies TS( Ti)< TS( Tj) othe rwis e Tj is rolle
same time stam p.(t o avoi d repe ated wou nds)
T3 hav e time -sta mps 5, 1Oand 15 resp ecti vely
For exam ple sup pos e that Tran sact ions Tl, T2,
a data obje ct A held by T2( TS( Tl)< TS( T2) ), then data obje ct A will be pree mpt ed
-IfT1 requ ests wait.
ests a data obje ct A held by T2, then T3 will
from T2 and T2 will be roJl ed back. Jf T3 requ
the
wait for a yo unge r tran sact ion to rele ase
In wait -die olde r tran sac tion is allowed to sact ion,
ests for a n o bjec t whi ch is held by olde r tran
object whe reas if the you nge r tran sac tion requ
Younger tran sact ion is abo rted .
sact ion is allowed to wait for olde r tran sact ion
t Wou nd -wa it doe s the_ opp osit e, you nge r tr_an nge r
ion requ ests an obje ct whi ch is held by you
to release the lock , whe reas 1f the olde r tran sact
.
ransaction then you nge r tran sact ion is abo rted
 No wnltl11g ,,lHorlthin : 1h1 1' docs not require any tim e stamp , if a transaction is unable
to j.tc t II lo( k II w· ts nhort<'d 11 11d Is stnrtr d oft er so m e Juralion of time. This algorithm does not
thn k whe'I h<· • I hr, ,: II\ n dcndl tH. k hos n( I 11 ally occ urred. the ad vantage of this approach is that we
1q w.i trdl y 11hn11/ r,·~ rnrt th e t 1.111 snt IIon .

~ .14. 1 1 Cautloua waiting algorithm

To I cd lh the I cpc111cd .,hor t ~1rc~turt s, th e cau tious algorithm was propose. In this approach,
l'

1-uppnM' tl wrr 1lH' two t 1 ,lllM\Ct ion Ti and Tj. Ti is waiting for a object X which is locked by Tj. The
lollowin~ PJ)1 h)n~ ,\re applied

lf t 1.m~,H tion Tj is already blocked since it is waiting for object X in some other transaction
thrn 'I,,~ .,hortcd .

If tt .rn~act ion Tj b not blocked th en transaction Ti is blocked and allowed to wait.

'llH.' C i'\ut iou~ Waiting is Deadlock Free because no transaction will never wait for another
hlod{(:-d t rall!,:lCt ion .

~ .14. 120eadl ock detection

·1h,-, b th e most practi cal approach used in transactions. the system checks whether there is a any
dead lock~ among t ransaclion. lf th ey exists then some of the transactions are aborted and are
allowed to restart form the beginning.
'n1 c most simplest way lo detect deadlock is by using wait-for-graph. In wait-for graph the
follo wing steps are performe d
• A node is construct ed for each transaction.

• An edge is drawn for Ti to Tj if Ti is waiting for an object which is held by transaction Tj.

Jf there exists a cycle in the graph then there is a deadlock.

Example
Tl T2
X(A)

X(B)
W(A)
--
X_(A) get ~ hl ocked
-
For this transactio n a wait for graph can be construct ed, T2 is waiting for transactio n Tl to
complcte(it requires object A whi ch i1. held by TI).
 This graph shows that it is acyclic and there is no dead lock. transaction will continue as
follows

Tl T2
X(A)

X(B)
W(A)
X(A) gets blocked
commit gets unblocked
W(B)
W(A)
Commit

Example _

Tl T2 T3

X(A)

X(B)
X(C)

W(A)
X(B) gets blocked
W(B)
X( C) gets blocked
W(C)
X(A) gets blocked
 Wait for graph for the above transaction would be

There is a cycle and hence there is a deadlock.

aborted, the process
If the system is in dead lock then some of the transaction has to be
tion. usually transaction
of identifying transaction which gets abort ed is referred as victim selec
which is runni ng for too long will not be considered as victim.
anism. If a transaction
Timeouts: A simple way to identify deadlocks is to use a timeout mech
that it is in a deadlock and
has been waiting too long for a lock, we can assume (pessimistically)
abort the transaction. This meth od is not efficient.
ERIN G
7.1 5 CONCURRENCY CONTROL BASED ON TIME STA MP ORD

7 .15.1 Time stam ps

recognition. These values
timestamp is a uniqu e identifier which is assigned to a transaction for
d, hence timestamp can be
are assigned to transactions in the order in which it has been create
trans actio n can be retrieved
thoug ht of as the staring time of a transaction. The time stamp for a
use locks and hence there
using TS(T). Conc urren cy control techniques using timestamp do not
is no need for deadlock prevention/ detection mechanisms.
to use counters, first
Timestamps can be generated in several ways. One approach is
and so on. This is referred as
transaction will have coun ter numb ered 1, second transaction with 2,
this value has a maximum
incremental counter. The disadvantage is that the variable which holds
ification for transaction and
limit. Most timestamp protocols use the actual date/time as an ident
the same time stamp.
the system must also ensure that no two transactions are allocated with
For example each Transaction is assigned a time stamp
In ascending order
Tl T2 T3 T4
10 20 30 40

T 4 is the youngest transaction and T 1 IS THE oldest transaction

d
 _1s.2The timestamp ordering algorithm
7
'fhe prerequisite of th is approach is that the transaction must be given time stamp in a predefined
order. Transactions which participate in the schedule can be then serializable, and the only
transaction which is allowed to access the objects is based on the time stamp ordering and this
approach is called timestamp ordering (TO). This method uses two timestamp values for the same
object X
read_TS(X). this is the largest timestamp among all the transactions timestamp that use the
object X and have successfully read object x. then read_TS(X) = TS(T) retrieves the times tamp of
the youngest transaction that has read object X successfully.
write_TS(X). this is the largest timestamp among all the transactions timestamp that use the
object X and have successfully written object x. then write_TS(X) = TS(T) retrieves the timestamp
of the youngest transaction that has written object X successfully.

7.15.3 BasicTimestamp Ordering (TO)

The transaction which wants to execute read/write on an object X will compare the timestamp of
the transaction with read_TS/write_TS. This comparison will ensure that ordering of transaction
retains the timestamp. Those transaction who do not satisfy the condition will be aborted and
must be restarted with new timestamp. If a transaction T 1 gets rolled back, any transaction which
has used the same object as that of Tl must also be rolled back. This is referred as cascaded roll
back.
1. Whenever a transaction T executes W(X) the following is checked

a. If timestamp value of read_TS(X) is greater than the star~ing time of transaction which
is TS(T) or if timestamp value of write_TS(X) is greater than the starting time of trans-
action TS(T), then it means some other transaction has already used the object X and
it gets rolled back.
b. If the above condition does not occur then the transaction is allowed to change the
value of object W(X) and the corresponding value of transaction timestamp is initial-
ized to write_TS(X)=TS(T).
2. Whenever a transaction T executes R(X) the following is checked

a. If transaction timestamp value is less than the time stamp of object X which is write_
TS(X) then it means that some other transaction has accessed the object X for write
and the transaction operation is rolled back.
b. Else then transaction executes the read_item(X) operation of T and set read_TS(X) to
the timestamp of transaction.
 Example 1: Tl T2 T3
R(A)
R(A)
R(A)
Write and read time stamp of object A will be initialized to WRITE_TS(A)=O and RTS(A)=O .
this indicted that there are no transacti ons which have accessed object A. Let us try to execute the
above schedule

First transacti on reads the object A, the condition that will be checked is
If ts(Tl) < write time stamp of object A,( 10 <0 its not true), transacti on is allowed to access
the object A and read timestam p( read_TS(A)=0) is updated with the timestam p of transaction
Tl ( TS(Tl)= I0). After the execution of transacti on Tl the resultant read and write timestam p will
be equal to
READ_TS(A)=lO;
WRITE_TS(A)=O;
Next the third transacti on reads the object A
If ts(T3) < write time stamp of object A,( 30 <0 its not true), transacti on is allowed to
access the object A and read timestam p( READ_T S(A)=l0) is updated with the timestamp of
transacti on Tl( TS(T3)=30). After the execution of transaction T3 the resultant read and write
timestamp will be equal to
READ_TS(A)=30;
WRITE_TS(A)=O;
Next the second transacti on reads the object A
If ts(T2) < write time stamp of object A,( 20 <0 its not true), transacti on is allowed to access
the object A and read timestam p( READ_TS(A)=30) is not updated. Since the read timestamp
of object A( READ_TS(A)=30) is greater than timestamp of transacti on T2( T2=20). After the
execution of transaction T2 the resultant read and write timestam p will be equal to

READ_TS(A)=30;
WRITE_TS(A)=O;
Since all three transactions does not conflict the conditions and are executed successfully.
Example 2: Tl T2 T3
R(A)
W(A)
R(A)
 E_TS (A)=O and READ _
Write and read time stamp of objec t A will be initia lized to WRIT
acces sed objec t A. Let us try to
rs(A)==O. th is i ndicted th at there are no transa ctions which have
execute the above sched ule
ed is
First trans actio n reads the objec t A, the condi tion that will be check
allow ed to acces s
If ts(Tl ) < write time stamp of objec t A,( 10 <O its not true) , trans actio n is
the object A and read times tamp ( READ _TS(A )=O) is updat ed
with the times tamp of trans actio n
TS(T l)=l0 ). After the execu tion of transa ction Tl the result ant
read and write times tamp will
Tl(
be equal to
READ _TS(A )=lO;
WRIT E_TS(A)=O;
tion must not be true
secon d trans actio n execu tes write on objec t A. The follow ing condi
for successfully execu ting write
if READ _TS(A ) > TS(T2) (10>20 its not true) &
if WRIT E_TS (A) > TS(T2) (0>20 and even this is not true)
tamp of trans actio n will
This trans actio n is allow ed to write and result ant read & write times
be equal to
READ _TS(A )=lO;
WRIT E_TS(A)=20;
tions can be check ed
Next first trans actio n once again reads objec t A. rThe follow ing condi
n Tl has to be rolled
If ts(Tl ) < write time stamp of objec t A,( 10 <30 its t true) , trans actio
back.

7.15.4 Strict Time stam p Orde ring (TO).

actio n T that wants to read/
Is a variat ion of basic Time stamp order ing. In this variat ion, a trans
Time stamp of the trans actio n is
write an objec t X issues a read_ item( X)/ write _item (X) such that
opera tion delay ed until the
greater than the times tamp value of write _TS(X) has its read or write
ed.
older transa ction which wrote the objec t X has comm itted or abort

7.15.5 Thomas's Write Rule

ct to the write of an objec t
It does not enfor ce confli ct serializability, the modi ficati on is with respe
is incor porat ed as comp ared to time stamp order ing algor ithm.
write _item (X) is
The condi tion for check ing writin g an objec t X for a transa ction
transa ction TS(T ), then
a. If times tamp of read_TS(X) is greate r than times tamp of the
abort the transa ction and roll back.
 b. If timestamp of write_TS(X) is greater than timestamp of the transaction TS(T), then
do not execute the write operation but continue, this means the some transaction has
already written it.
c. Else the transaction is allowed to change the value of object W(X) and the correspond-
ing value of transaction timestamp is initialized to write_TS(X)=TS(T).

7.16 LOCKING OF OBJECTS

The meaning of object in SQL is either a table or a record or a column value also. For example the
employee table can be locked or record <111, 'Govind',1,2000> can be locked. The locking can also
be done for a specific department number also.

Row level locking can give better performance but is not guaranteed since it depends on the
query and application.

Suppose that the transaction Tl sets shared locks on all the employee rows wher dno=l and
retrieves the total salary. Let us assume there is one more Transaction T3 which tries to insert a
new employee row with dno= 1 and since it is writing exclusive lock is used. This new row affects
the total salary and hence the order of execution of Tl and T3 becomes important. The result
varies and this phenomenon is called the phantom problem. To overcome this probiem, locking
must be applied to the entire table.

7 .17 OTHER ISSUES: LATCHES, CONVOYS:

Latches can be used for ensuring atomic execution of lock and unlock request. Before a lock is
applied, it is checked whether a latch exists for that memory/ object if latch is not applied then
the lock manager applies the latch and goes for either read or write. Once the read or write of the
object is completed the latch on that object is automatically released. If the latch already exists
for an object then the transaction will get blocked. The advantage of using latch is that it can be
applied for a particular duration of time.

Convoy(group/line) are long queue of transactions waiting for the lock. Lock manager
locks and unlocks the object through the scheduling process of Operating System(OS). Each
transaction can is equivalent to a process. Usually transactions (process) gets switched from one
transaction(process) to the other or else transactions may have to wait for a longer duration of
time(starvation). During the process of switching a transaction which has heavily used lock and
resuming it back, the delay incurred would be more. During this delay too many requests for the
objects may have been made, indirectly increasing the queue length of the transaction waiting.
These convoys can become long and affect the performance of both OS and DBMS.
7,18 INTR ODU CTI ON TO DATABASE RECOVERY PROTOCO
LS
7.1 s.1 Recovery concepts
Recovery process gets initia ted when there is a failure of a transa ction.
To recover and conve rt the
database from incon sisten t state to consi stent state, recovery mana
ger shoul d have saved certa in
details of transa ction. The details of transa ction are kept in the system
log. Infor mally the recov ery
process can be summ arize d as follows

If the failure is due to catast rophi c such as hard disk failure, the DB
will restor ed to the most
recent copy of the backu p.

The other types of failures must be handl ed by recovery mana ger.

Initia lly it identi fies the
transaction which has not been comm itted, the write action are recog
nized and these actio ns must
be undone. The trans actio n which has comm itted but the action s of
write is still on main mem ory,
in this situat ion redo activi ty is initia ted which transf ers the infor
matio n on to the disk.
There are two techn iques for recovery from non-c atastr ophic failur
es
► Defer red updat e ► Imme diate updat e
7.18.2 Defe rred upda te (NO- UND O/REDO algorithm)

The basic idea behin d defer red updat e is to defer or postp one
any actua l upda tes to the
database( whic h exists in disk) until the transa ction comp letes
its execu tion succe ssfull y and
reaches its comm it point .

Main Memory

Tl Vt/(A) Data base

Tl W (B)

Log Tl W (A ) Tl W(B)

Durin g transa ction execu tion, the updat es are recor ded only in
the log and in the cache
buffer s. After the transa ction reaches its comm it point and the log
is force -writt en to disk, the
updates are recor ded in the database. If a transa ction fails befor e reach
ing its comm it point , there
is no need to undo any opera tions becau se the transa ction has not
affected the datab ase on disk in
any way. Therefore, only REDO -type log entrie s are neede d in the
log, which is used to perfo rm
actions of transa ction which has been comm itted. Since we are using
only redo and no undo , the
algorithm is called NO_U NDO /RED O algor ithm.
 Tl Data bue
TlW ~
Commit

First writes the log first

Log Tl W(A) Tl W(B) Log Tl W(A) Tl W(B)

Main Memory
Tl W(A) Database
Tl W(B) Object A modified
Object B modified
Commit

Log Tl W(A) Tl W(B) Log Tl W(A) Tl W(B)

7.18.3 Imme diate Update

the transaction
Durin g transa ction execution the update actions are savedon to the database before
and are force written
enters the comm it point. These actions of update are also recorded in the log
to the database are
before any updat e actions are applied on DB.On comm it all changes made
of a transaction,
made perma nent and the records in the log file are discarded. If there is a failure
fied. These updates
the log details of that transa ction are searched and update actions are identi
d may require both
are undon e from the DB and is rolled back to a consistent state. This metho
UND O/RE DO and UND O/NO -RED O approach.

Main Memory
Fir-;t writes A on to DB
Tl W(A) Database
Tl W(B) 1-'i r~I writes Bon to DB
Object A modified
Object B modified
•Co1nn1it
First writes log information also
Log Tl W(A) Tl W(B ) I Log Tl W(A) Tl W(B)
 caching of disk blocks
7.1 8.4
ps.MS mu st closely work wi th operatin g system to perform 1/0 activity. Althoug h th e buffer
cache can be rega rd ed as a memory resource, it is primari ly an 1/0 resource due to its use in
facilitating data transfer. When a user process issues a read request, the operatin g system sea rches
the buffer cache for th e request ed data. If the data is in the buffer cache, the request is sati sfied
,,ritbout accessing th e physical device. It is quite likely that data to be read is already in the buffer
cache because th e OS copies an entire block contain ing the data from disk into memory . This
allows any subsequ ent data falling within that block to be read more quickly from the cache in
111 e01 ory, rather than having
to re-access the disk. The OS also perform s read-ah ead of blocks on
the assumpt ion that most files are accessed from beginni ng to end. DBMS must have facilities
of invoking operati ng system API to copy contents of DB as pages of memor y and copying back
from main memor y to disk. Recovering can be assume in terms of disk pages manipu lation.
This in memory buffers referrin g to DB is called DBMC cache. This directly works under the
DBMS application and a reference is saved about which db(disk)is present in which buffer(DB:tvlS
cache). The entries would be <Disk_page_address, Buffer_location, ... > saved in a table for further
maintenance. When an update action is initiated initially it will checked whethe r the inform ation
is in DBMS cache, it exists then updatio n will be done. If the value does not exist then the block
which contains the value must be copied in to DBMS cache and is updated . During this process few
pages in the cache has to be remove d. It 1nay use least recently used(LS U), First in first out(FIF O)
or any specific method s similar to operatin g system can be used by DBMS.
To check whethe r the page in the cache has been modifie d a flag Dirty bit can be used.
This flag set on a page(va lue will be one: 1) indicates that the value has been modifie d. The entry
for this will be unset(v alue will be zero: O) when a new page is copied for DBMS to the main
memory. DBMS Cache has a director y which has the details of disk page address , buffer locatio n,
dirty bit, transac tion id which has changed the value of the page is recorde d. pin-un pin bit is
also used to check whethe r the changes made to the cache pages have success fully been saved
in to the disk. The value of one(l) indicates it is still not been copied and the transac tion has
committed. Two main strategy is used when copying modifie d cache pages to disk first strategy is
called in-place updatin g, in this approac h the content s will be copied back to the san1 e location
~nd indirectly overwrites the previou s data. This has only one copy of each block. second approac h
is called shadow ing, in this approac h it writes the updated block on to a differen t location . This
has multiple version of the same data.

The DB value before getting updated is refereed as before image(BFIM) and value
after updatio n is referred as after in1age(AFIM).ln shadow ing approac h both BFiivl and AFHvl
are saved.
 7 .18.5 Write-ahead logging, Steal/No-Steal and Force/No-Force

We assume that in-place updatton • 1s • used wh1c· h means tl1e va lue is written back to the same
memory location. . . method recovery manager must ensure that BFIM of each object i
In tlus s
recorded on to log entry. 1111s must be flushe to th e d.1s k b efiO re BFIM value is. replaced with
· d
AFIM. Since we are writing the details of log before we actually write the obJect changes on
disk it is referred as write ahead logging. This requires UNDO algorithm in case of failure of a
transaction.

We can distinguish the log entry in to two types

Redo type log entry: where the new value AFIM of the object is stored and is required dur-
ing redo operation.
Undo type log entry: where the old value BFIM of the object is stored and is required dur-•
ing undo operation.

Steal/Nosteal approach
If the recovery protocol uses the following approach where updation made to the cache buffer( write
operation on object X which exists in main memory) by the transaction will not be written to disk(
DB)until transaction commits is referred as No-steal approach. The pin-unpin bit will indicate
whether the value within the cache has been copied back to the disk(DBMS) for a committed
transaction. This approach does not require Undo for recovery.

If the recovery protocol, updates the changes 1nade to the cache buffer( write operation on
object X which exists in main memory) by the transaction on to disk( DB) before transaction
commits is referred as Steal approach. Since we are copying the object value on to the DB before
the transaction commits and hence it is referred as steal.

Force approach

If the transaction changes an object in cache buffer(main memory in the form of pages) it must be
immediately changed on disk(DB), this is refereed as Force approach or else it is No-force.

Difference between steal and force approach

Assume that a transaction Tl wants to read a data object A, but the Cache buffer(main memory)
is full with pages of other transaction. So Tl needs to clear some cache buffer memory, this is
done by moving some other page in cache buffer to disk. This can create lot of issues because we
can't be sure that what T 1 is moving to stable storage has been committed yet. This is known as
stealing.
 Forcing n1eans that ever y t·Ime a trans f
to disk(DB). This is inefficient b ac Ion commits, all the affected pages will be pushed
' ecause each b
sloW the systen1 down. c page may e written by many transact ions and will

Deferre d update recover y mec h anism u l

teal/no-force approac h Th d ses no-stea approach. Most crash recovery uses
as ' . . l .
e a vantage of stea l Is
ated transac tion(t. . t 1at 1t does not require to store all the pages
0 f uPd 1ansactio n wh ic· h h
·~ need to tr-3• c h as used write). The advantage of No-force is that
tI1ere ~
l 110 uilS1er t e pag .f
. . d by other t 1. . e even 1 the transact ion has commit ted and this page can be
utl1ize k ansactio n. This reduces the time of 1/0 cost to transfer page from buffer to disk
and bac .

7.18.6 Checkpoints in the system lo 9 an d f uzzy check pointing

Checkpoint is a point of time at which a record is written onto the database from the DBMS cache.
· and start
· nt point
The advantage is that when th e sys t e1n eras h es we can move to some consiste
c t er recovery.
doing redo activity. This 1nethod is, used fior 1as
The two types of checkp ointing techniques are
► Consis tent checkp ointing ► Fuzzy checkpo inting

Consis tent Checkp ointing : Consist ent checkpointing creates a consiste nt image of the
entire content s which are there in the DBMS cache. The actions taken during creation of
checkp ointing are
► The transac tions which are currentl y getting executed are suspend ed tempora rily.
► All change s in DBMS cache are written onto the disk(DB).
► A "checkp oint" record is written in the transact ion log and this log is also written to
the disk.
► The suspen ded transac tions are resumed.

Fuzzy Checkp ointing : In fuzzy checkpointing, at the time of checkpo int, since all the active
transac tions and its log are written in to disk. In case of power failure, the recover y manage r
finds the most recent check point and executed the transac tion after this point to reach to a
consiste nt state.
7.18.7 No-Un do/red o recovery based on deferred update
The basic idea behind deferre d update is to defer or postpon e any actual updates to the databas e
(which exists in disk) until the transac tion completes its executi on successfully and reaches its
commit point.
During transac tion executi on, the updates are recorde d only in the log and in the cache
buffers. After the transac tion reaches its commit point and the log is force-w ritten to disk, the
updates are recorded in the database. If a transaction fails before reaching its com mit point, there
is no need to undo any operations because the transaction has not affected the database on disk in
any way. Therefore, only REDO-type log entries are needed in the log, which is used lo perform
actions of transaction which has been committed. Since we are using only redo and no undo, the
algorithm is called NO_UNDO/REDO algorithm.
Typical deferred update protocol can be explained as follows
Transaction must not change DBMS cache until it reaches its commit point.
Transaction must have written REDO-type log entries in the log and this is forcibly written
on the disk before it reaches its commit point.

7.18.8 Recovery Techniques using Immediate Update

Values in DBMS cache are updated on to the DB when ever transactions execute the statement.
Each actions of the transaction is recorded in the system log and later on transferred to disk. When
there is a failure then we undo the actions from the previous check point. We also redo actions of
the committed transaction.

Undo Operations is required for all actions of transactions which has not been commited.
Log entry details are searched which has write of an object X were old value and new value are
saved. The log entries are executed in the reverse order.

PROCEDURE RIU_S
l. System maintains two lists of transactions in the system: the committed transactions since
the last checkpoint and the active transactions within the system
2. Undo all the write_item operations on objects which contains the old value using UNDO
procedure described below.
3. Redo the transactions write_item operations which have committed and has new value in
the log.
The UNDO procedure is defined as follows:
UNDO(WRITE_OP): this accepts a log entry of write. The log is examined which has the
object old value and new value [write_item, T, X, old_value, new_value]. The DB is copied with
the old vale. This process is continued for all the log entries.

~.19 SHADOW PAGING

This recovery technique does not require log. In this method all the transactions are executed in
the DBMS cache which is the main memory. This is referred as shadow because the exact replica
of the DB is created. Once all the actions of transactions are completely executed then the entire
memory is copied back to the DB. This DB can have pages and shadow of the page which go t
· ma d e o f pages.
up dated is copied to the DB · For un d erstandmg
. let us assume that DB 1s

DB

2
3
4

When there is a request from user a shadow of the table in the form of pages is created and
copied on to the main memory.

shadow DB
~ Pl-22
LlliLJ P2-44
P3-88
P4-99

For the sake of understanding let us assume that the query requires only the first two pages
whose values are 22 and 44. At this instance if there is a failure then the entire shadow is lost and
the DB is still in a consistent state.
Assume there is a change in the value of P 1-22 to P 1-11 , these changes only happen to pages
in shadow.
shadow DB
Pl-11 Pl-22
P2-44 P2-44
P3-88
P4-99

Once the execution commits only the updated pages are copied to DB.

DB
Pl-11
P2-44
P3-88
P4-99

It will be updated to the database. Hence, if there is any failure in the middle of transaction, it
will not be reflected in the database. Database will be updated after all the transaction is complete.
This approach can be used when the size of the DB is small.
 -
QUESTIONS

1. Explain three phases involved in an ARIES algorithm with an appropriate example

2. Explain properties of a transaction with state transition diagram
3. What is a schedule ? Explain with examples serial , non-serial and conflict serializable
schedules
4. Write short notes on:

i) Two phase locking protocol

ii) Transaction support in SQL
iii) Write ahead log protocol

iv) Time stamp ordering algorithm

5. Briefly discuss the two phase locking protocol used in concurrency control.
6. What is two phase locking protocol ? How does it guarantee Serializability?

7. What are ACID properties? Explain.