1. Multiversion Concurrency Control
Chapter 5
송 인선

2. Contents 1. Goal and Overview 2. Multiversion Schedules 3.
Multiversion Serializability 3.

3. 1. Goal and Overview Main Idea of Multiversion Concurrency Control
One copy of each data item
Overwriting and read-from relationship
Add more copy of each data item
Keep the old version of a data item
reasonable extension of serializability theory
the presentation focus on..
Accurate Notation of Multiversion Concurrency Control
Define the Multiversion Schedule, MCSR and MVSR
Dealing with possible issues of Multiversion Concurrency Control

4. 2. Multiversion Schedules
Example 5.1
𝒔 𝟏 = r1(x) w1(x) r2(x) w2(y) r1(y) w1(z) c1 c2
𝒔 𝟏  CSR (cyclic conflict between t1 and t2)
but, schedule would be tolerable
if r1(y) could read the old version y0 of y to be consistent with r1(x),
s would then be equivalent to a serial s‘ = t1 t2
𝒔 𝟏
𝒔 𝟐 T1 T2
𝑟𝑒𝑎𝑑 𝑥
𝑤𝑟𝑖𝑡𝑒 𝑥
𝑟𝑒𝑎𝑑(𝑦)
𝑤𝑟𝑖𝑡𝑒 𝑧
𝐶 1
𝑤𝑟𝑖𝑡𝑒 𝑦
𝐶 2 T1 T2
𝑟𝑒𝑎𝑑 𝑥
𝑤𝑟𝑖𝑡𝑒 𝑥
𝑟𝑒𝑎𝑑( 𝑦 0 )
𝑤𝑟𝑖𝑡𝑒 𝑧
𝐶 1
𝑤𝑟𝑖𝑡𝑒 𝑦
𝐶 2
𝒔 𝟐 ∈ CSR

5. 2. Multiversion Schedules
Definition < Version Function >
Let s be a history with initial transaction t0 and final transaction t.
A version function for s is a function h,
which associates with each read step of s a previous write step on the
same data item, and the identity for writes.
h(ri(x)) = wj(x) for some wj(x) <s ri(x), and ri(x) reads xj
(Read Step)
h(wi(x)) = wi(x), and wi(x) writes xi.
(Write Step)

6. 2. Multiversion Schedules
Definition < Multiversion schedule >
Let T = {t1, ... , tn} be a (finite) set of transactions.
1. A multiversion history for transactions T ={t1, ..., tn} is a pair
m=(op(m), <m) where <m is an order on op(m) and
op(m) = i=1..n h(op(ti)) for some version function h,
for all t  T and all p, q  op(ti): p <t q  h(p) <m h(q),
if h(rj(x)) = rj(xi), ij, and cj is in m then ci is in m and ci <m cj.
2. A multiversion schedule is a prefix of a multiversion history.
Example 5.2
totally ordered multiversion schedule for the history from Example 5.1
with a version function h
s = r1(x) w1(x) r2(x) w2(y) r1(y) w1(z) c1 c2
m = r1(x0) w1(x1) r2(x1) w2(y2) r1(y0) w1(z1) c1 c2
: h(r1(y0) ) = w0(y0)

7. 2. Multiversion Schedules
Definition < Monoversion Schedule >
A multiversion schedule is a monoversion schedule if its version function
maps each read to the last preceding write on the same data item.
Example
m = r1(x0) w1(x1) r2(x1) w2(y2) r1(y2) w1(z1) c1 c2
s = r1(x) w1(x) r2(x) w2(y) r1(y) w1(z) c1 c2
effect of a monoversion schedule a single version of each data item is kept
order of steps version function of a monoversion schedule is uniquely determined

8. 3.1 Multiversion View Serializability
Example 5.3
s = w0(x) c0 w1(x) c1 r2(x) w2(y) c2 : 3 different conflicts
m = w0(x0) c0 w1(x1) c1 r2(x0) w2(y2) c2 : only 1 conflict
Definition < Reads-From Relation >
Let m be a multiversion schedule, ti, tj ∈ trans(m).
The reads-from relation of m is defined by
RF(m) = {(ti, x, tj) | rj(xi)  op(m)}.

9. 3.1 Multiversion View Serializability
Definition < View Equivalence >
Let m and m` be two multiversion schedule such that trans(m`) = trans(m).
m and m` are view equivalent, abbreviated m v m`, if RF(m) = RF(m`).
difference between multiversion and monoversion of view equivalence :
multiversion schedules m and m‘ with trans(m)=trans(m‘) always have
the same final writes
(‮since writes produce versions that are not erased anymore)
consideration of final write operations is now irrelevant !
but, this no longer holds
if the number of versions can be stored is limited!

10. 3.1 Multiversion View Serializability
Example 5.4
m = w0(x0) w0(y0) c0 r3(x0) w3(x3) c3 w1(x1) c1 r2(x1) w2(y2) c2
m‘ = w0(x0) w0(y0) c0 w1(x1) c1 r2(x1) r3(x0) w2(y2) w3(x3) c3 c2
Then m v m‘
It is not sufficient to require that given multiversion schedule m is view
equivalent to serial multiversion schedule m`.
The reason is that even a serial m` does not necessarily have a reads-from
relation that is compatible with a serial monoversion schedule.
Example 5.5
m = w0(x0) w0(y0) c0 r1(x0) r1(y0) w1(x1) w1(y1) c1 r2(x0) r2(y1) c2
s = w0(x) w0(y) c0 r1(x) r1(y) w1(x) w1(y) c1 r2(x) r2(y) c2
RF(m) ≠ RF(s)

11. 3.1 Multiversion View Serializability
Definition < Multiversion view serializability >
Let m be a multiversion history. Then m is called multiversion view serializable
if there exists a serial monoversion history m` for the same set of transactions
such that m v m'.
Let MVSR denote the class of all multiversion view-serializable histories.
for m  MVSR, there is always a serial monoversion history s
for trans(m) = trans(s) such that m v s
Example 5.6
Let m = w0(x0) w0(y0) c0 w1(x1) c1 r2(x1) r3(x0) w3(x3) c3 w2(y2) c2
m‘ = w0(x0) w0(y0) c0 r3(x0) w3(x3) c3 w1(x1) c1 r2(x1) w2(y2) c2
Then we have m v m‘.
s = w0(x) w0(y) c0 r3(x) w3(x) c3 w1(x) c1 r2(x) w2(y) c2
Moreover, m’ is vew equivalent to history m‘ v s

12. 3.2 Testing Membership in MVSR
Theorem 5.1
VSR  MVSR
Every view-serializable history can be perceived as a monoversion history and hence as a specific multiversion history (in MVSR)
Example
m = w0(x0) w0(y0) c0 r1(x0) w2(x2) w2(y2) c2 r1(y0) c1
s = w0(x) w0(y) c0 r1(x) w2(x) w2(y) c2 r1(y) c1
s  VSR, but m  MVSR ( m v <t0t1t2> )
MVSR is a relaxation of conditions over VSR,
in other words, with additional restrictions (in VSR) over MVSR

13. 3.2 Testing Membership in MVSR
Theorem 5.2
Deciding if a given mv history m is in MVSR is NP-complete.
The conflict graph of a multiversion schedule m is a directed graph G(m)
with transactions as nodes and an edge from ti to tj if rj(xi)  op(m).
Theorem 5.3
For any two multiversion schedules m, m‘ :
m v m‘  G(m) = G(m‘).
Example (T5.3) is not true
m = w1(x1) r2(x0) w1(y1) r2(y1) c1 c2
m‘ = w1(x1) w1(y1) c1 r2(x1) r2(y0) c2
G(m) = G(m‘), but not m v m‘

14. 3.2 Testing Membership in MVSR
Definition < Version Order >
A version order for a data item x is any nonreflexive & total ordering of all
versions of x that are written by operations in m.
A version order << for m is the union of all version orders of data items
written by ops in m.
wi(xi) preceded wj(xj) in the schedule : xi << xj
Example 5.7
m = w0(x0) w0(y0) w0(z0) c0 r1(x0) r2(x0) r2(z0) r3(z0) w1(y1) w2(x2) w3(y3) w3(z3) c1 c2 c3 r4(x2) r4(y3) r4(z3) c4
A version order for m could be
x0 << x2, y0 << y1 << y3, z0 << z3

15. 3.2 Testing Membership in MVSR
Definition < Multiversion serialization graph(MVSG) >
For a given schedule m and a version order <<,
the multiversion serialization graph MVSG (m, <<) of m
is a graph with transactions as nodes and the following edges:
(i) all edges of G(m) are in MVSG(m, <<)
(i.e., for rk(xj) in op(m) there is an edge from tj to tk)
(ii) for rk(xj), wi(xi) in op(m): if xi << xj then there is an edge from ti to tj
(iii) for rk(xj), wi(xi) in op(m): if xj << xi then there is an edge from tk to ti

16. 3.2 Testing Membership in MVSR
Example 5.8
m = w0(x0) w0(y0) w0(z0) c0 r1(x0) r2(x0) r2(z0) r3(z0)
w1(y1) w2(x2) w3(y3) w3(z3) c1 c2 c3 r4(x2) r4(y3) r4(z3) c4
version order for m : x0 << x2, y0 << y1 << y3, z0 << z3
Edges that do not occur in G(m) are the following :
by (iii) (t1, t2) : r1(x0), w2(x2)  op(m), and x0 << x2
by (ii) (t1, t3) : w1(y1), r4(y3)  op(m), and y1 << y3
by (iii) (t2, t3) : r2(z0), w3(z3)  op(m), and z0 << z3 t0 t1 t2 t3 t4 t0 t1 t2 t3 t4

17. 3.2 Testing Membership in MVSR
Theorem 5.4
m is in MVSR iff there exists a version order << such that MVSG(m, <<) is acyclic.
Proof
(If) Since MVSG(m,<<) is acyclic, it can be sorted topologically into a serial history m' such that RF(m)=RF(m'), i.e., m v m'.
Suppose that m' contains rk(xj), wi(xi), k ≠ j, i ≠ j, i ≠ k.
if xi << xj : ti → tj, ti <m‘ tj,
if xj<< xi : tk → ti, tk <m‘ ti
so, no transaction writes x between tj and tk in m‘, version number can be dropped from m‘ without changing the reads-from relation.
(only if) Let MV(m,<<) denote the graph that contains version order edge only.
If trans(m)=trans(m‘), then MV(m,<<)=MV(m‘,<<) for every version order << .
Let m  MVSR, and m‘ be a serial monoversion history for the same transactions
such that m v m‘
G(m) = G(m‘) by Thm. 5.3, and G(m‘) is acyclic(by m‘ is serial), hence so is G(m).
Now define a specific version order xi <<0 xj : ti <m‘ tj (i.e. if ti → tj is in G(m‘))
Thus, if MV(m‘,<<0) is added to G(m‘), the result graph MVSG(m‘,<<0) remains acyclic. And the same holds MV(m‘,<<0)=MV(m,<<0) is added to G(m)[=G(m‘)],

18. 3.3 Multiversion Conflict Serializability
Definition 5.9 < Multiversion conflict >
A multiversion conflict in multiversion schedule m is a pair of steps
ri(xj) and wk(xk) such that ri(xj) <m wk(xk).
convention : wr operation pairs on the same version
the above : rw operation pairs on the same data item
Definition < Muliversion reducibility >
A multiversion history is multiversion reducible if it can be transformed
into a serial monoversion history by exchanging the order of adjacent steps
other than multiversion conflict pairs.
Definition < Muliversion conflict serializability >
A multiversion history m is multiversion conflict serializable if there is a
serial monoversion history for the same set of transactions in which all
pairs of operations in multiversion conflict occur in the same order as in m.
MCSR denotes the class of all multiversion conflict serializable histories.

19. 3.3 Multiversion Conflict Serializability
Theorem 5.5
A multiversion history is multiversion reducible iff it is multiversion conflict
serializable.
Theorem 5.6
MCSR  MVSR
Example
m = w0(x0) w0(y0) w0(z0) c0 r2(y0) r3(z0) w3(x3) c3 r1(x3) w1(y1) c1
w2(x2) c2 r(x2) r(y1) r(z0) c
m  MCSR, but m  MVSR (m v t0t3t2t1t)

20. 3.3 Multiversion Conflict Serializability
Definition < Multiversion conflict graph>
For a multiversion schedule m the multiversion conflict graph is a
graph with transactions as nodes and an edge from ti to tk if there are
steps ri(xj) and wk(xk) such that ri(xj) <m wk(xk).
Theorem 5.7
A multiversion history is MCSR iff its multiversion conflict graph is acyclic.
MCSR has a polynomial membership test, and all practical mv concurrency
control protocols fall into this class.

21. 3.3 Multiversion Conflict Serializability
All histories
MVSR
MCSR
VSR
CSR
𝑠 1
𝑠 5
𝑠 4
𝑠 3
𝑠 2
S1 = r1(x) r2(x) w1(x) w2(x) c1 c2
S2 = w1(x) c1 r2(x) r3(y) w3(x) w2(y) c2 c3
S3 = w1(x) c1 r2(x) r3(y) w3(x) w2(y) c2 c3 w4(x) c4
S4 = r1(x) w1(x) r2(x) r2(y) w2(y) r1(y) w1(y) c1 c2
S5 = r1(x) w1(x) r2(x) w2(y) c2 w1(y) w3(y) c1 c3