Chapter 15: Transactions

Chapter 15: Transactions

Transaction Concept

Transaction State
Concurrent Executions
Serializability

Recoverability

Implementation of Isolation
Transaction Denition in S!"

Testin# for Serializability$

Transaction Concept

% transaction is a unit of pro#ram execution that accesses

an& possibly up&ates various &ata items$

E$#$ transaction to transfer '5( from account % to account ):

1$ read*A+
,$ A :- A 5(
.$ write*A+
/$ read*B+
5$ B :- B + 5(
0$ write*B)
T1o main issues to &eal 1ith:

2ailures of various 3in&s4 such as har&1are failures an&

system crashes

Concurrent execution of multiple transactions

Example of 2un& Transfer
Transaction to transfer '5( from account % to account ):
1$ read*A+
,$ A :- A 5(
.$ write*A+
/$ read*B+
5$ B :- B + 5(
0$ write*B)
Atomicity requirement
if the transaction fails after step . an& before step 04 money 1ill be 5lost6
lea&in# to an inconsistent &atabase state
2ailure coul& be &ue to soft1are or har&1are
the system shoul& ensure that up&ates of a partially execute& transaction
are not re7ecte& in the &atabase
Durability requirement 8 once the user has been notie& that the
transaction has complete& *i$e$4 the transfer of the '5( has ta3en place+4 the
up&ates to the &atabase by the transaction must persist even if there are
soft1are or har&1are failures$
Example of 2un& Transfer
*Cont$+
Transaction to transfer '5( from account % to account ):
1$ read*A+
,$ A :- A 5(
.$ write*A+
/$ read*B+
5$ B :- B + 5(
0$ write*B)
Consistency requirement in above example:
the sum of % an& ) is unchan#e& by the execution of the transaction
In #eneral4 consistency re9uirements inclu&e
Explicitly specie& inte#rity constraints such as primary 3eys an& forei#n
3eys
Implicit inte#rity constraints
e$#$ sum of balances of all accounts4 minus sum of loan amounts must
e9ual value of cash:in:han&
% transaction must see a consistent &atabase$
Durin# transaction execution the &atabase may be temporarily inconsistent$
;hen the transaction completes successfully the &atabase must be consistent
Erroneous transaction lo#ic can lea& to inconsistency
Example of 2un& Transfer
*Cont$+
Isolation requirement 8 if bet1een steps . an& 04 another
transaction T, is allo1e& to access the partially up&ate& &atabase4
it 1ill see an inconsistent &atabase *the sum A + B 1ill be less
than it shoul& be+$
T1 T2
1$ read*A+
,$ A :- A 5(
.$ write*A+
rea&*%+4 rea&*)+4 print*%<)+
/$ read*B+
5$ B :- B + 5(
0$ write*B
Isolation can be ensure& trivially by runnin# transactions serially
that is4 one after the other$
=o1ever4 executin# multiple transactions concurrently has
si#nicant benets4 as 1e 1ill see later$
%CID >roperties

Atomicity. Either all operations of the transaction are properly

re7ecte& in the &atabase or none are$

Consistency. Execution of a transaction in isolation preserves

the consistency of the &atabase$

Isolation. %lthou#h multiple transactions may execute

concurrently4 each transaction must be una1are of other
concurrently executin# transactions$ Interme&iate transaction
results must be hi&&en from other concurrently execute&
transactions$
That is4 for every pair of transactions T
i
an& T
j
, it appears to T
i

that either T
j
, nishe& execution before T
i
starte&4 or T
j
starte&
execution after T
i
nishe&$

Durability. %fter a transaction completes successfully4 the

chan#es it has ma&e to the &atabase persist4 even if there are
system failures$
A transaction is a unit of program execution that accesses and possibly
updates various data items.To preserve the integrity of data the database
system must ensure:
Transaction State

Active ? the initial state@ the transaction stays in this state

1hile it is executin#
Partially committed ? after the nal statement has been
execute&$
Failed -- after the &iscovery that normal execution can no
lon#er procee&$
Aborted ? after the transaction has been rolle& bac3 an& the
&atabase restore& to its state prior to the start of the
transaction$ T1o options after it has been aborte&:

restart the transaction

can be &one only if no internal lo#ical error
3ill the transaction

Committed ? after successful completion$

Transaction State *Cont$+
Implementation of %tomicity
an& Durability

The recovery-management component of a &atabase system

implements the support for atomicity an& &urability$

E$#$ the shadow-database scheme:

all up&ates are ma&e on a shadow copy of the &atabase

db!ointer is ma&e to point to the up&ate& sha&o1

copy after
the transaction reaches partial commit an&
all up&ate& pa#es have been 7ushe& to &is3$
Implementation of %tomicity an& Durability
*Cont$+
&bApointer al1ays points to the current consistent copy of the &atabase$
In case transaction fails4 ol& consistent copy pointe& to by
db!ointer can be use&4 an& the sha&o1 copy can be &elete&$
The sha&o1:&atabase scheme:
%ssumes that only one transaction is active at a time$
%ssumes &is3s &o not fail
Bseful for text e&itors4 but
extremely ineCcient for lar#e &atabases *1hyD+
Eariant calle& sha&o1 pa#in# re&uces copyin# of &ata4 but is
still not practical for lar#e &atabases

Does not han&le concurrent transactions

;ill stu&y better schemes in Chapter 1F$
Concurrent Executions

Gultiple transactions are allo1e& to run concurrently in the

system$ %&vanta#es are:

increased !rocessor and dis" utili#ation4 lea&in# to

better transaction throughput

E$#$ one transaction can be usin# the C>B 1hile

another is rea&in# from or 1ritin# to the &is3
reduced average res!onse time for transactions: short
transactions nee& not 1ait behin& lon# ones$
Concurrency control sc$emes ? mechanisms to achieve
isolation
that is4 to control the interaction amon# the concurrent
transactions in or&er to prevent them from &estroyin# the
consistency of the &atabase

;ill stu&y in Chapter 104 after stu&yin# notion of

correctness of concurrent executions$
Sche&ules

%c$edule ? a se9uences of instructions that specify the

chronolo#ical or&er in 1hich instructions of concurrent
transactions are execute&

a sche&ule for a set of transactions must consist of all

instructions of those transactions

must preserve the or&er in 1hich the instructions appear in

each in&ivi&ual transaction$

% transaction that successfully completes its execution 1ill have

a commit instructions as the last statement

by &efault transaction assume& to execute commit

instruction as its last step

% transaction that fails to successfully complete its execution 1ill

have an abort instruction as the last statement
Sche&ule 1
"et T
1
transfer '5( from A to B4 an& T
,
transfer 1(H of the balance
from A to B.
% serial sche&ule in 1hich T
1
is follo1e& by T
,
:
Sche&ule ,

A serial schedule where T

2
is followed by T
1
Sche&ule .
"et T
1
an& T
,
be the transactions &ene& previously. The follo1in#
sche&ule is not a serial sche&ule4 but it is equivalent to Sche&ule 1$
In Schedules 1, 2 and 3, the sum A + B is preserved.
Sche&ule /

The follo1in# concurrent sche&ule &oes not preserve

the value of *A < B )$
Serializability
&asic Assum!tion ? Each transaction preserves &atabase
consistency$
Thus serial execution of a set of transactions preserves &atabase
consistency$
% *possibly concurrent+ sche&ule is serializable if it is e9uivalent to a
serial sche&ule$ DiIerent forms of sche&ule e9uivalence #ive rise to
the notions of:
1$ con'ict seriali#ability
,$ view seriali#ability
Simplied view o! transactions
;e i#nore operations other than read an& write instructions
;e assume that transactions may perform arbitrary computations
on &ata in local buIers in bet1een rea&s an& 1rites$
Jur simplie& sche&ules consist of only read an& write
instructions$
Con7ictin# Instructions
Instructions l
i
an& l
j
of transactions T
i
an& T
j
respectively4
con'ict if an& only if there exists some item " accesse& by
both l
i
an& l
j
4 an& at least one of these instructions 1rote ".
1$ l
i
- read*"), l
j
# read*"+$ l
i
an& l
j
&onKt con7ict$
,$ l
i
- read*"), l
j
# write*"+$ They con7ict$
.$ l
i
- write*"), l
j
# read*"+$ They con7ict
/$ l
i
- write*"), l
j
# write*"+$ They con7ict
Intuitively4 a con7ict bet1een l
i
an& l
j
forces a *lo#ical+ temporal
or&er bet1een them$
If l
i
an& l
j
are consecutive in a sche&ule an& they &o not
con7ict4 their results 1oul& remain the same even if they
ha& been interchan#e& in the sche&ule$
Con7ict Serializability

If a sche&ule S can be transforme& into a sche&ule S$ by a

series of s1aps of non:con7ictin# instructions4 1e say that S
an& S$ are con'ict equivalent.

;e say that a sche&ule S is con'ict seriali#able if it is

con7ict e9uivalent to a serial sche&ule
Con7ict Serializability *Cont$+

Sche&ule . can be transforme& into Sche&ule 04 a

serial sche&ule 1here T
,
follo1s T
1
4 by series of s1aps
of non:con7ictin# instructions$

Therefore Sche&ule . is con7ict serializable$

Schedule 3
Schedule 6
Con7ict Serializability *Cont$+
Example of a sche&ule that is not con7ict serializable:

;e are unable to s1ap instructions in the above sche&ule to

obtain either the serial sche&ule L T
.
4 T
/
M4 or the serial
sche&ule L T
/
4 T
.
M$
Eie1 Serializability

"et S an& S$ be t1o sche&ules 1ith the same set of

transactions$ S an& S$ are view equivalent if the follo1in#
three con&itions are met4 for each &ata item ",
1$ If in sche&ule S4 transaction T
i
rea&s the initial value of "4
then in sche&ule S% also transaction T
i
must rea& the
initial value of ".
,$ If in sche&ule S transaction T
i
executes read*")4 an& that
value 1as pro&uce& by transaction T
j
*if any+4 then in
sche&ule S% also transaction T
i
must rea& the value of "
that 1as pro&uce& by the same write*!+ operation of
transaction T
j
$
.$ The transaction *if any+ that performs the nal write*"+
operation in sche&ule S must also perform the nal
write*"+ operation in sche&ule S%.
%s can be seen4 vie1 e9uivalence is also base& purely on reads
an& writes alone$
Eie1 Serializability *Cont$+
% sche&ule S is view seriali#able if it is vie1 e9uivalent to a serial
sche&ule$
Every con7ict serializable sche&ule is also vie1 serializable$
)elo1 is a sche&ule 1hich is vie1:serializable but not con7ict
serializable$
;hat serial sche&ule is above e9uivalent toD
Every vie1 serializable sche&ule that is not con7ict serializable has
blind writes.
Jther Notions of Serializability

The sche&ule belo1 pro&uces same outcome as the serial

sche&ule L T
1
4

T
5
M4 yet is not con7ict e9uivalent or vie1
e9uivalent to it$

Determinin# such e9uivalence re9uires analysis of

operations other than rea& an& 1rite$
Testin# for Serializability
Consi&er some sche&ule of a set of transactions T
1
4
T
,
4 $$$4 T
n

Precedence gra!$ 8 a &irect #raph 1here the vertices

are the transactions *names+$
;e &ra1 an arc from T
i
to T
j
if the t1o transaction
con7ict4 an& T
i
accesse& the &ata item on 1hich the
con7ict arose earlier$

;e may label the arc by the item that 1as accesse&$

()am!le 1
x
y
Example Sche&ule *Sche&ule %+ < >rece&ence
Oraph
T
1
T
,
T
.
T
/
T
5
rea&*P+
rea&*Q+
rea&*R+
rea&*E+
rea&*;+
rea&*;+
rea&*Q+
1rite*Q+
1rite*R+
rea&*B+
rea&*Q+
1rite*Q+
rea&*R+
1rite*R+
rea&*B+
1rite*B+
T
3
T
4
T
1
T
2
T
5
Test for Con7ict Serializability

% sche&ule is con7ict serializable if an&

only if its prece&ence #raph is acyclic$

Cycle:&etection al#orithms exist 1hich

ta3e or&er n
,
time4 1here n is the number
of vertices in the #raph$

*)etter al#orithms ta3e or&er n < e

1here e is the number of e&#es$+

If prece&ence #raph is acyclic4 the

serializability or&er can be obtaine& by a
topological sorting of the #raph$

This is a linear or&er consistent 1ith

the partial or&er of the #raph$

2or example4 a serializability or&er for

Sche&ule % 1oul& be
T
5
T
1
T
.
T
,
T
/

%re there othersD

Test for Eie1 Serializability

The prece&ence #raph test for con7ict serializability cannot be

use& &irectly to test for vie1 serializability$

Extension to test for vie1 serializability has cost exponential

in the size of the prece&ence #raph$

The problem of chec3in# if a sche&ule is vie1 serializable falls

in the class of &':complete problems$

Thus existence of an eCcient al#orithm is e(tremely

unli3ely$

=o1ever practical al#orithms that Sust chec3 some su*cient

conditions for vie1 serializability can still be use&$
Recoverable Sche&ules
+ecoverable sc$edule 8 if a transaction T
j
rea&s a &ata item
previously 1ritten by a transaction T
i
4 then the commit operation
of T
i
appears before the commit operation of T
j
.
The follo1in# sche&ule *Sche&ule 11+ is not recoverable if T
)

commits imme&iately after the rea&
If T
T
shoul& abort4 T
U
1oul& have rea& *an& possibly sho1n to the
user+ an inconsistent &atabase state$ =ence4 &atabase must
ensure that sche&ules are recoverable$
Need to address the efect of transaction failures on concurrently
running transactions.
Casca&in# Rollbac3s

Cascading rollbac" ? a sin#le transaction failure lea&s to

a series of transaction rollbac3s$ Consi&er the follo1in#
sche&ule 1here none of the transactions has yet
committe& *so the sche&ule is recoverable+
If T
1(
fails4 T
11
an& T
1,
must also be rolle& bac3$

Can lea& to the un&oin# of a si#nicant amount of 1or3

Casca&eless Sche&ules

Cascadeless sc$edules 8 casca&in# rollbac3s cannot occur@ for

each pair of transactions T
i
an& T
j
such that T
j
rea&s a &ata item
previously 1ritten by T
i
4 the commit operation of T
i
appears before
the rea& operation of T
j
$
Every casca&eless sche&ule is also recoverable

It is &esirable to restrict the sche&ules to those that are

casca&eless
Concurrency Control

% &atabase must provi&e a mechanism that 1ill ensure that all

possible sche&ules are

either con7ict or vie1 serializable4 an&

are recoverable an& preferably casca&eless

% policy in 1hich only one transaction can execute at a time

#enerates serial sche&ules4 but provi&es a poor &e#ree of
concurrency

%re serial sche&ules recoverableVcasca&elessD

Testin# a sche&ule for serializability a!ter it has execute& is a little
too lateW
,oal ? to &evelop concurrency control protocols that 1ill assure
serializability$
Concurrency Control vs$ Serializability
Tests
Concurrency:control protocols allo1 concurrent sche&ules4 but ensure that
the sche&ules are con7ictVvie1 serializable4 an& are recoverable an&
casca&eless $
Concurrency control protocols #enerally &o not examine the prece&ence
#raph as it is bein# create&
Instea& a protocol imposes a &iscipline that avoi&s nonseralizable
sche&ules$
;e stu&y such protocols in Chapter 10$
DiIerent concurrency control protocols provi&e &iIerent tra&eoIs bet1een
the amount of concurrency they allo1 an& the amount of overhea& that they
incur$
Tests for serializability help us un&erstan& 1hy a concurrency control
protocol is correct$
;ea3 "evels of Consistency

Some applications are 1illin# to live 1ith 1ea3 levels of

consistency4 allo1in# sche&ules that are not serializable

E$#$ a rea&:only transaction that 1ants to #et an approximate

total balance of all accounts

E$#$ &atabase statistics compute& for 9uery optimization can be

approximate *1hyD+

Such transactions nee& not be serializable 1ith respect to other

transactions

Tra&eoI accuracy for performance

"evels of Consistency in S!":
U,

%eriali#able 8 &efault
+e!eatable read 8 only committe& recor&s to be rea&4
repeate& rea&s of same recor& must return same value$
=o1ever4 a transaction may not be serializable ? it may n&
some recor&s inserte& by a transaction but not n& others$
+ead committed 8 only committe& recor&s can be rea&4 but
successive rea&s of recor& may return &iIerent *but
committe&+ values$

+ead uncommitted 8 even uncommitte& recor&s may be

rea&$

Lower degrees of consistency useful for gathering approximate

information about the database

Warning: some database systems do not ensure serializable

schedules by default

E.g. Oracle and PostgreSQL by default support a level of

consistency called snapshot isolation (not part of the SQL
standard)
Transaction Denition in S!"
Data manipulation lan#ua#e must inclu&e a construct for
specifyin# the set of actions that comprise a transaction$
In S!"4 a transaction be#ins implicitly$
% transaction in S!" en&s by:
Commit wor" commits current transaction an& be#ins a
ne1 one$
+ollbac" wor" causes current transaction to abort$
In almost all &atabase systems4 by &efault4 every S!"
statement also commits implicitly if it executes successfully
Implicit commit can be turne& oI by a &atabase &irective
E$#$ in XD)C4 connection$set%utoCommit*false+@
En& of Chapter
Sche&ule F
>rece&ence Oraph for
*a+ Sche&ule 1 an& *b+ Sche&ule ,
>rece&ence Oraph
#$ 15$,1
Implementation of Isolation

Sche&ules must be con7ict or vie1 serializable4 an&

recoverable4 for the sa3e of &atabase consistency4 an&
preferably casca&eless$
% policy in 1hich only one transaction can execute at a time
#enerates serial sche&ules4 but provi&es a poor &e#ree of
concurrency$

Concurrency:control schemes tra&eoI bet1een the amount

of concurrency they allo1 an& the amount of overhea& that
they incur$
Some schemes allo1 only con7ict:serializable sche&ules to
be #enerate&4 1hile others allo1 vie1:serializable
sche&ules that are not con7ict:serializable$
2i#ure 15$0