multiversion concurrency control - uni konstanz€¦ · · 2016-03-30multiversion concurrency...

MultiversionConcurrency

Control

SebastianFaller

Introduction

MultiversionSchedules

MultiversionSerializability

MultiversionConcurrencyControlProtocols

LessonsLearned

Literatur

Multiversion Concurrency Control

Sebastian Faller

30. Juni 2009


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Introduction

A book is a version of the world. If you do not like it,ignore it; or offer your own version in return.-Salman Rushdie

What’s the use of a good quotation if you can’tchange it-Anonymous


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Introduction

theoretically attractive and practically relevant

more than one copy of the same data item

keep old version until write operation commits successfullydistinct transactions could be given distinct versions of thesame data item to read or to overwrite.keep track of changes ⇒ history

assumption transparent versioning

versioning is transparent to outside worldusers or applications are not aware of the fact that dataitems can appear in multiple versions.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Schedules

Multiversion Schedule isessentially a schedule s in the sense used so far

Excursion: Schedule

s consists of the union of the operations from the given transactions plus a termination operation

for each transaction, there is either a commit or an abort in s

all transaction orders are contained in the partial order given by s

the commit or abort operation always appears as the last step of a transaction

every pair of operations p, q ∈ op(s) from distinct transaction that access the same data item andhave at least one write operation among them is ordered in s such a way that either p <s q orq <s p

a schedule is a prefix of a history

+ a version function

it contains

versioned read and write operationswhose ordering respects the individual transaction ordering


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Version Function

Let s be a history with initialisation transaction t0 and finaltransaction t∞. A version function for s is a function h, whichassociates with each read step of s a previous write step on thesame data item, and which is the identity on write steps.

write steps are translated into a version creation step

w(x) (always) creates a new version of xh(wi (x)) = wi (x), and wi (x) writes xj

read steps are translated into a version read step

r(x) reads an (existing) version of xh(ri (x)) = wj(x) for some wj(x) <s ri (x),and ri (x) reads xj


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Multiversion Schedule

Let T = t1, ...., tn be a finite set of transactions.1 A multiversion history (or complete multiversion schedule)

for T is a pair m = (op(m), <m), where <m is an order onop(m) and

1 op(m) = h(∪ni=1op(ti )) for some version function h (here

we assume that h has been canonical extended from singleoperations to sets of operations)

2 for all t ∈ T and all operations p, q ∈ op(t) the followingholds:

p <t q ⇒ h(p) <m h(q)

3 if h(rj(x)) = rj(xi ), i 6= j , and cj is in m, then ci is in mand ci < cj .

2 A multiversion schedule is a prefix of a multiversion history


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Monoversion Schedule

A multiversion schedule is called monoversion schedule ifversion function maps each read step to the last precedingwrite step on the same data item.

m = r1(x0)w1(x1)r2(x1)w2(y2)r1(y2)w1(z1)c1c2

s = r1(x)w1(x)r2(x)w2(y)r1(y)w1(z)c1c2


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion SerializabilityMultiversion View Serializability

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)

View Equivalence

Let m be two multiversion schedules such that trans(m′) = trans(m).m and m′ are view eqivalent, abbreviated m ≈v m′, if RF (m) = RF (m′)

Multiversion View Serializability

Let m be a multiversion history. Then m is called multiversion viewserializable if there exist a serial monoversion history m′ for the same set oftransactions such that m ≈v m′

Let MVSR denote the class of all multiversion view-serializable histories


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Example View Equivalence:

m = w0(x0)w0(y0)c0r3(x0)w3(x3)c3w1(x1)c1r2(x1)w2(y2)c2

m′ = w0(x0)w0(y0)c0w1(x1)c1r2(x1)r3(x0)w2(y2)w3(x3)c3c2

Then m ≈v m′

Example Multiversion View Serializability:

Let m = w0(x0)w0(y0)c0w1(x1)c1r2(x1)r3(x0)w3(x3)c3w2(y2)c2

and m′ = w0(x0)w0(x0)c0r3(x0)w3(x3)c3w1(x1)w2(y2)c2

Then we have m ≈v m′. Moreover, m′ is view equivalent tohistory s = w0(x)w0(y)c0r3(x)w3(x)c3w1(x)w2(y)c2


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Example View Equivalence



Then m ≈v m′






Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Example View Equivalence:



Then m ≈v m′






Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion SerializabilityTesting Membership in MVSR

Theorem

VSR ⊂ MVSR

Example:

m = w0(x0)w0(y0)c0r1(x0)w2(x2)w2(y2)c2r1(y0)c1

Theorem

The Problem of deciding weather a given multiversion history isin MVSR is NP complete


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Theorem

For any two multiversion schedules m and m′, m ≈v m′ impliesG (m) = G (m′)

Excursion: Conflict Graph

Let s be a schedule. The conflict graph G(s) = (V , E) is a directed graphwith vertices V := commit(s) andedges E := {(t, t′)|t 6= t′ and there are stepsp ∈ t, q ∈ t′with(p, q) ∈ conf (s)}.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Version Order

If x is a data item, a version order for x is any nonreflexive andtotal ordering of all vesrsions of x that are written byoperations by m. A version order � for m is the union of allversion orders of data items written by operations in m.

Multiversion Serialization Graph (MVSG)

For a given schedule m and a version order �, the multiversionserialization graph MVSG (m,�) of m then is the conflictgraph G (m) = (V , E ) with the following edges added for eachrk(xj) and wi (xi ) in CP(m), where k , i and j are pairwisedistinct:

if xi � xj , then (ti , tj ∈ E ), otherwise (tk , ti ) ∈ E .


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Example:


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion SerializabilityMultiversion Conflict Serializability

Multiversion Conflict

A multiversion conflict in a multiversion schedule m is a pair ofsteps ri (xj) and wk(xk) such that ri (xj) <m wk(xk)

Multiversion Reduceability

A (totally ordered) multiversion history m is multiversionreducible if it can be transformed into a serial monoversionhistory by a infinite sequence of transformation steps, each ofwhich exchanges the order of two adjacent steps, (i.e. stepsp, q with p < q such that o < p or q < o for all other steps o)but without reversing the ordering of a multiversion conflict(i.e. rw pair)


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Multiversion Conflict Serializability

A multiversion history m is multiversion conflict serializable ifthere is a serial monoversion history for the same set oftransactions in which all pairs of operations in multiversionconflict occur in the same order as in m. Let MCSR denote theclass of all multiversion conflict-serializable histories.

Multiversion Conflict Graph

Let m be a multiversion schedule. The multiversion conflictgraph of m is a graph that has the transactions of m as itsnodes and an edge from ti to tk if there are steps ri (xi ) andwk(xk) for the same data item x in m such thatri (xi ) <m wk(xk).


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Theorem

A multiversion history is multiversion reducible iff it ismultiversion conflict serializable.

Theorem

A multiversion history is MCSR iff its multiversin conflict graphis acyclic.

Theorem

MCSR ⊂ MVSR


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe MTVO (multiversion timestamp ordering) Protocol

scheduler processes operations in FIFO fashion

transforms data operations into operations on versions ofdata items

are then processed that the result appears as if producedby a serial monoversion schedule with transactions in theorder of timestamps that are assigned at the beginning ofa transaction.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Protocol Rules:1 A step ri (x) is transformed into a step ri (xk). where xk is

the version of x that carries the largest timestamp ≤ ts(ti )and was written by tk , k 6= i .

2 A step wi (x) is processed as follows:1 If a step of the form rj(xk) such that

ts(tk) < ts(ti ) < ts(tj) has already been scheduled, thenwi (x) is rejected and ti is aborted,

2 otherwise, wi (x) is transformed into wi (xi ) and executed.

3 A commit ci is delayed until the commit cj of alltransactions tj that have written new versions of dataitems read by ti have been processed. (This part of theprotocol is optional and included in order to ensure correcttransaction recovery)

Correctness of MVTO (i.e. Gen(MVTO)) ⊆ MVSR)

xi � xj ⇐⇒ ts(ti ) < ts(tj)


Control

SebastianFaller

Introduction




LessonsLearned

Literatur


Example:


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe MV2PL (multiversion two-phase locking) Protocol

Protocol Rules:1 If step is not final within the transaction:

1 an r(x) is executed right away, by assigning to it thecurrent version of the requested data item, i.e. the mostrecently committed version (but not any other, previouslycommitted one), or by assigning to it an uncommittedversion of x;

2 a w(x) is executed only when the transaction that gaswritten x last is finished, so that there are no otheruncommitted versions of x

2 If the step is final within the transaction ti , it is delayeduntil the following types of transactions are committed:

1 all those transactions tj that have read the current versionof a data item written by ti ,

2 all those tj from which ti has read some version.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe MV2PL (multiversion two-phase locking) Protocol

Example on how M2VPL works:

Input: s = r1(x)w1(x)r2(x)w2(y)r1(y)w2(x)c2w1(y)c11. r1(x) assigned to x0 and executed: r1(x0)2. w1(x) executed since no other transaction is still active: w1(x1)3. let r2(x) be assigned to x1 and executed: r2(x1)4. w2(y) is executed: w2(y2)5. let r1(y) be assigned to y0 and execute: r1(y0)

6. if w2(x) were not the last step of t2, it would be delayed since t1 is still active and has

written x1. However, as it is the final step of t2, the final step rules need to be applied. It

turns out that t2 nonetheless has has to wait for the following reason:

a) t1 has read the current version of the data item y (y0), and t2 overwrites thisversion,

b) t2 has read x1 from t1

7. w1(y), the final step of t1, is executed since

a) t2 has not read a current version of a data item written by t1 (current versions arex0, y0),

b) t1 has not read a version written by t2 w1(y1)

8. finally, w2(x) can be executed: w2(x2)

Output:m = r1(x0)w1(x1)r2(x1)w2(y2)r1(y0)w1(y1)c1w2(x2)c2


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe MVSGT (multiversion serilization graph testing) Protocol

Protocol Rules:1 wi (x)

add edge from (tj , ti ) to the graphfor each tj for which an rj(x) has already been scheduledif G becomes cyclic

wi (x) is not executed

else

wi (x) is executed the newly written version is kept

2 ri (x)

is scheduled and receives version written by wj(x)add edge from (tj , ti ) to Gsince tj is not late, this does not close a cyclein additon

add edge from either (tk , tj) or (ti , tk) for each step wk(x)already scheduledtk is neither late or early


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe MVSGT (multiversion serilization graph testing) Protocol

those tj on a path that originates from ti , since these aresupposed to follow ti in an equivalent serial schedule; letus call them late;

those tj for which a path exists from tj to anothercandidate tk that writes x and from tk to ti , since in anequivalent serial schedule, tk writes x after tj ; let us callthem early.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe ROMV (read-only multiversion protocol)Protocol

Protocol Rules:

each update transactions uses 2PL on both its read andwrite set but each write creates a new version andtimestamps it with the transaction’s commit time

each read-only transaction ti is timestamped with its begintime

ri (x) is mapped to ri (xk) where xk is the version thatcarries the largest timestamp ≤ ts(ti ) (i.e., the mostrecent committed version as of the begin of ti )

Correctness (i.e Gen(ROMV ) ⊆ MVSR)

xi � xj ⇔ ci < cj


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Multiversion Concurrency Control ProtocolsThe ROMV (read-only multiversion protocol)Protocol

Exampel:


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Lessons Learned

A Multiversion Schedule is essentially a schedule in thesense used so far together with a version function.

Multiversion Serializabilityis more powerfulperformance improvements achievable

Multiversion Protocolstransparent versioning adds a degree of freedom toconcurrency control protocols, making MVSR considerablymore powerful than VSRThe most striking benefit is for long read transactions thatexecute concurrently with writers.This specific benefit is achieved with relatively simpleprotocols


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature I

[AB87] M.L. Ahuja and J.C. Brown. Concurrency control bypreordering entities in databases with multiversionalentities. In In Proc. 3rd IEEE InternationalConference on Data Engineering, pages 312 – 321,1987. srihdsthsdathdsfhtudfstdsth.

[AS93] R. Agrawal and S. Sengupta. Modular sychronizationin distributed, multiverion databases: Version controland concurrency control. In IEEE Transactions onKnwoledge and Data Engineering, volume 5, pages126 – 137, 1993.

[BC92a] P.M. Bober and M.J. Carey. Multiversion querylocking. In In Proc. 18th International Conference onVery Large Databases, pages 497 – 510, 1992.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature II

[BC92b] P.M. Bober and M.J. Carey. On mixing queries andtransactions via multiversion locking. In In Proc. 8thIEEE International Conference on Data Engineering,pages 535 – 545, 1992.

[Ber98] P.A. Bernstein. Repositories and object orienteddatabases. SIGMOD Record, 27(1), 1998.

[BG83] P.A. Bernstein and N. Goodman. Multiversionconcurrency control - theory and algorithems. InACM Transaction on Database Systems, volume 8,pages 465 – 483, 1983.

[BG87] V. Hadzilacos Bernstein, P.A. and N. Goodman.Concurrency Control and Recovery in DatabaseSystems. Addison - Wesley, 1987.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature III

[BR80] H. Heller Bayer, R. and A. Reiser. Parallelism andrecovery in database systems. Transactions onDatabase Systems, 5:139 – 156, 1980.

[BS83] G.N. Buckley and A. Silberschatz. Obtainingprogessive protocols for a simple multiversiondatatbase model. In In Proc. 9th InternationalConference on Very Large Data Bases, pages 74 – 80,1983.

[CG85] A. Chan and R. Gray. Implementing distributedread-only transactions. In IEEE Transaction onSoftware Engineering, volume 11, pages 205 – 212,1985.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature IV

[CJ90] W. Cellary and G. Jamier. Consistency of versions inobject-oriented databases. In In Proc. 16thInternational Conference on Very Large Data Bases,pages 432 – 441, 1990.

[Cla92] B. Claybrook. OLTP - Online Transaction ProcessingSystems. New York: J. Wiley Sons, 1992.

[CM88] E. Gelenbe Cellary, W. and T. Morzy. ConcurrencyCointrol in Distributed Data Base Systems.Amsterdam: North-Holland, 1988.

[CR82] S. Fox W.K. Lin A. Nori Chan, A. and D.R. Ries. Theimplementation of an integrated conccurrency controland recovery scheme. In In Proc. ACM SGMODInternational Conference on Management of Data,pages 184 – 191, 1982.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature V

[DuB82] D. DuBourdieu. Impelementation of distributedtransactions. In In Proc. 6th Berkley Workshop onDistributed Data Management and ComputerNetworks, pages 81 – 93, 1982.

[Had88] T. Hadzilacos. Serilization graph algorithems formuliversion concurrency control. In In Proc. 7th ACMSIGACT-SIGMOD Symposium on Principals ofDatabase Systems, pages 135 – 141, 1988.

[HS00] W. Mahnke N. Ritter Haerder, T. and H.-P. Steiert.Generating versioning facilities for a design-datarepository supporting cooperative applications.International Journal of Cooperative InformationSystems, 9:117 – 146, 2000.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature VI

[IM90] T. Kameda Ibaraki, T. and T. Minoura. Multiversioncautious schedulers for database concurrency control.In IEEE Transaction on Software Engineering,volume 16, pages 302 – 315, 1990.

[Kat90] R.H. Katz. Toward a unified framework for versionmodelling in engineering databases. ACM ComputingSurveys, 22:375 – 408, 1990.

[Lau83] G. Lausen. Formal aspects of optimistic concurrencycontrol in a multipel version database system.Information Systems, 8:291 – 301, 1983.

[ML92] H. Pirahesh Mohan, C. and R. Loire. Efficent andflexible methods for transient versioning of record toavoid locking by read-only transactions, 1992.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature VII

[Mor93] T. Morzy. The correctness of concurrency control ofmultiversion database systems with limited number ofversions. In In Proc 9th IEEE International Conferenceon Data Engineering, pages 565 – 604, 1993.

[Pap86] C.H. Papadimitriou. The Theory of DatabaseConcurrency Control. MD: Computer Science Press,1986.

[PK84] C.H. Papadimitriou and P. Kanellakis. Onconcurrency control by multiple versions. ACMTransactions on Database Systems, 9:89 – 99, 1984.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature VIII

[Raz93] Y. Raz. Commitment ordering based distributedconcurrency control for bridging single and multiversion resources. In In Proc. 3rd InternationalWorkshop on Research Issues in Data Engineering:Interoperability in Multi Database Systems, pages 189– 199, Vienna, Austria, 1993.

[Ree78] D.P. Reed. Naming and Synchronization in aDecentralized Computer System. PhD thesis, MIT,Camebridge, MA, 1978.

[Ree83] D.P. Reed. Implementing atomic actions ondcentralized data. ACM Transaction on ComputerSystems, 1:3 – 23, 1983.


Control

SebastianFaller

Introduction




LessonsLearned

Literatur

Literature IX

[Sch77] B.-M Schueler. Update reconsidered. In In Proc. IFIPWorking Conference on Architecture and Models inDBMS, pages 149–164. Amsterdam: North-Holland,1977.

[SR81] Richard E. Stearns and Daniel J. Rosenkrantz.Distributed database concurrency controls usingbefore-values. In SIGMOD ’81: Proceedings of the1981 ACM SIGMOD international conference onManagement of data, pages 74–83, New York, NY,USA, 1981. ACM.

[Vid91] K. Vidyasankar. Unified theory of databaseserializability. Fundamenta Informaticae, 14:147 –183, 1991.

multiversion concurrency control - uni konstanz€¦ · · 2016-03-30multiversion concurrency...

Documents