Serializability
Conflict serializable schedule orders any conflicting
operations in same way as some serial execution.
Constrained write rule: transaction updates data item
based on its old value, which is first read.
Practical session 1
Under the constrained write rule we can use precedence
graph to test for serializability.
Thu 3/11/05
COMP 302
V. Tamma
Serializability - some important rules
In serializability, ordering of read/writes is important:
(a) If two transactions only read a data item, they do not
conflict and order is not important.
(b) If two transactions either read or write completely
separate data items, they do not conflict and order is
not important.
(c) If one transaction writes a data item and another
reads or writes same data item, order of execution is
important.
COMP 302
20
V. Tamma
22
V. Tamma
COMP 302
Precedence Graph
Given a schedule S, a precedence graph is a directed
graph G= (N,E) where
• N = set of nodes
• E = set of directed edges
Created as follows:
• create a node for each transaction;
• a directed edge Ti → Tj, if Tj reads the value of an item
written by Ti;
• a directed edge Ti → Tj, if Tj writes a value into an item after
it has been read by Ti.
COMP 302
23
V. Tamma
Precedence Graph and serializability
Example - Non-conflict serializable schedule
If an edge Ti → Tj exists in the precedence graph for S,
then in any serial schedule S’ equivalent to S, Ti must
appear before T j
If the precedence graph contains cycle schedule is not
conflict serializable.
V. Tamma
COMP 302
24
V. Tamma
COMP 302
View Serializability
View Serializability
Offers less stringent definition of schedule
equivalence than conflict serializability.
Two schedules S1 and S2 are view equivalent if:
• Schedule is view serializable if it is view equivalent
to a serial schedule.
• Every conflict serializable schedule is view
serializable, although converse is not true.
• It can be shown that any view serializable
schedule that is not conflict serializable contains
one or more blind writes.
• In general, testing whether schedule is serializable
is NP-complete.
• For each data item x, if Ti reads initial value of x in S1, Ti must
also read initial value of x in S2.
• For each read on x by Ti in S1, if value read by x is written by
Tj, Ti must also read value of x produced by Tj in S2.
• For each data item x, if last write on x performed by Ti in S1,
same transaction must perform final write on x in S2.
COMP 302
V. Tamma
COMP 302
V. Tamma
Exercise settings
Exercise 1
• For this exercise you will work in groups of 3 or 4
people
• You will have 10 minutes to work out the solution to the
problem with your colleagues
• After that, you will have 5 minutes to compare your
solution with the one of your neighbours
Consider the following schedule
Time
t1
t2
t3
t4
t5
T1
T2
T3
begin_transaction
read (balx)
begin_transaction
write (balx)
write(balx)
begin_transaction
commit
commit
read(balx)
commit
Determine whether the schedule is conflict serialisable and/or view
serialisable
V. Tamma
COMP 302
Solution ex 1
Recoverability
The precedence graph looks like
• There is a cycle in the graph, therefore the schedule is NOT
conflict serialisable
• T2 has a blind write, therefore the schedule is NOT view
serialisable
COMP 302
V. Tamma
COMP 302
V. Tamma
Serializability identifies schedules that maintain
database consistency, assuming no transaction fails.
Could also examine recoverability of transactions within
schedule.
If transaction fails, atomicity requires effects of
transaction to be undone.
Durability states that once transaction commits, its
changes cannot be undone (without running another,
compensating, transaction).
COMP 302
29
V. Tamma
Recoverable Schedule
Exercise 2
Consider the following schedule
A schedule where, for each pair of transactions Ti and Tj,
if Tj reads a data item previously written by Ti, then the
commit operation of Ti precedes the commit operation
of Tj.
Time
t1
t2
t3
t4
t5
T1
T2
T3
begin_transaction
read (balx)
begin_transaction
read (baly)
read(baly )
begin_transaction
commit
read(balx)
write(balx)
commit
Determine if the schedule is:
• conflict serialisable
• view serialisable
• recoverable
• avoids abort cascading
30
V. Tamma
COMP 302
V. Tamma
COMP 302
Solution ex 2
Locking methods: problems
The precedence graph looks like
Deadlock: An impasse that may result when two (or
more) transactions are each waiting for locks held by
the other to be released.
•
•
•
The graph does not have a cycle thus the schedule is conflict serialisable
Since the schedule is conflict serialisable, then it is view serialisable
Recoverable; (however, does not avoid cascading abort if T3 had aborted, T2
would also have to abort as it has read the value of an aborted transaction).
COMP 302
V. Tamma
COMP 302
45
V. Tamma
Deadlock - an example
Deadlock - possible solutions?
Only one way to break deadlock: abort one or more of
the transactions.
Deadlock should be transparent to user, so DBMS
should restart transaction(s).
Two general techniques for handling deadlock:
•
•
45
V. Tamma
COMP 302
Deadlock prevention.
Deadlock detection and recovery.
Deadlock Prevention
Deadlock Detection and Recovery
DBMS looks ahead to see if transaction would cause
deadlock and never allows deadlock to occur.
Could order transactions using transaction timestamps:
• Wait-Die - only an older transaction can wait for younger
one, otherwise transaction is aborted (dies) and restarted
with same timestamp.
• Wound-Wait - only a younger transaction can wait for an
older one. If older transaction requests lock held by younger
one, younger one is aborted (wounded).
COMP 302
46
V. Tamma
COMP 302
47
V. Tamma
DBMS allows deadlock to occur but recognizes it and
breaks it.
Usually handled by construction of wait-for graph (WFG)
showing transaction dependencies:
•
•
Create a node for each transaction.
Create edge Ti -> Tj , if Ti waiting to lock item locked by Tj.
Deadlock exists if and only if WFG contains cycle.
WFG is created at regular intervals.
COMP 302
49
V. Tamma
Recovery from Deadlock Detection
Exercise 3
• The locking information for several transactions is shown below. Produce a
wait-for-graph (WFG) for the transactions and determine whether deadlock
exist
Several issues:
• choice of deadlock victim;
• how far to roll a transaction back;
• avoiding starvation.
V. Tamma
COMP 302
Solution ex 3
The WFG looks like
• The graph shows that there is a deadlock
COMP 302
V. Tamma
COMP 302
V. Tamma