1. Multiversion Concurrency Control
5.4 – 5.6
신홍중

2. 5.4 Limiting the Number of Versions
5.5 Multiversion Concurrency Protocols
5.5.1 THE MVTO Potocol
5.5.2 The MV2PL Protocol
5.5.3 The MVSGT Protocol
5.5.4 A Multiversion Protocol for Read-Only Transactions
5.5.6 Lessons Learned

3. 5.4 Limiting the Number of Versions
The important point
we want to make in this section is that
limiting the number of versions can make a difference,
in the sense
that schedules that are multiversion serializable
if no upper bound on the number of versions exists may lose this property
in the presence of a limit on the total number of versions.
In the presence of an upper bound for the total number of data item versions, view equivalence of histories is again defined as in
Chapter 3, namely, by asking for identical reads-from relations and equal final write operations.
To be even more precise, we can furthermore incorporate a given bound k for the number of versions into the definition and hence speak of k-version view serializability; the corresponding
classes of histories will be denoted by kVSR, k > 0.

4. 5.4 Limiting the Number of Versions(cont...)
For the sample schedule
it then follows immediately
m ∈ MVSR − 2VSR
In addition, it is easily verified that
VSR = 1VSR
Since we have stated above that MVSR has an NP complete decision problem, it moreover follows that the problem of deciding whether a given multiversion schedule is in class kVSR is NP complete for every k > 0.
Finally,
the various classes of k-version view-serializable histories form a classes strict hierarchy
VSR = 1VSR ⊂ 2VSR ⊂ 3VSR ⊂ ⊂ MVSR

5. 5.5 Multiversion Concurrency Protocols
! Develop concurrency control protocols for multiversion databases
Multiversion Database produce Data version orders
Data Versions correctness follows
from the characterization of membership in class MVSR
Develop Concurrency Control Protocol
MVSR
Read-From
Data Version Order
Multiversion Data
Limiting the number of available versions is not an issue
We will assume that all data versions written can be stored

6. 5.5.1 The MVTO Protocol
Multiversion Time Stamp Ordering(MVTO) scheduler’s action
1. A step
is transformed into a step
is the version of
that carries the largest time stamp
and was written by
SQL STATEMENTS
SQL STATEMENTS
SQL STATEMENTS

7. 5.5.1 The MVTO Protocol(cont...)
Multiversion Time Stamp Ordering(MVTO) scheduler’s action
2. A step
is processed as follows:
a) If a step of form
such that
has already been scheduled,
then
is rejected and
is aborted
Abort
Reject
if) T will execute write_item(X) operation
on read_TS(X) > TS(T)
then) Reject write_item(x) and Abort T

8. 5.5.1 The MVTO Protocol(cont...)
Multiversion Time Stamp Ordering(MVTO) scheduler’s action
2. A step
is processed as follows:
b) otherwize,
is transformed into
and executed

9. 5.5.1 The MVTO Protocol(cont...)
Multiversion Time Stamp Ordering(MVTO) scheduler’s action
3. A commit is delayed until the commit of all transaction
that have written new versions of data items read
by have been processed
Read from Write Relation
until

10. 5.5.1 The MVTO Protocol(cont...)
Correctness of MVTO
Gen(MVTO)
MVSR
MVTO protocol correct
Schedule 0
Schedule 1
MVTO
Type Schedule
MVSR
Schedule definite
Version order

11. 5.5.1 The MVTO Protocol(cont...)
Sample Figure 5.3

12. 5.5.1 The MVTO Protocol(cont...)
Sample Execution
Transaction Wait state
uncommitted
Wait
Transaction needs to wait right before its commit, because
it has read the uncommitted version ;
once is committed, can commit as well.

13. 5.5.1 The MVTO Protocol(cont...)
Sample Execution
“Late writer” -> Abort state
late write
Transaction is an example for a “late” writer:
it creates the new version ;
however, transaction has already read the version .
The serialization order , should actually have read
which was impossible,
as that version did not yet exist at the time of ‘s read
Thus, ‘s write occurs “too late”, and must be aborted according to the MVTO rules

14. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Assume
All versions of data items ever written are kept around
Difference of Data version
Committed versions
which have been written by transaction that are already committed
Current version
which is the committed version of data item written by transaction
that was committed last
Uncommitted versions
which are all remaining version(created by transactions that are still active

15. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Scheduler
Several variants of MV2PL can be distinguished
Read steps are allowed to
read only current version
Read steps are allowed to
uncommitted version
So, the scheduler make sure that
there is at most one uncommitted version of any data item.

16. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Scheduler individual step
1. If the step is not final within a transaction
most recently committed version
an is access
uncommitted version
an is access
transaction has written last is finished
there are no other uncommitted verions of
2. If the step is final transaction ,
it is delayed until following types transactions are committed
all those transaction that have read the current version of data item written by
all those from which has read some version

17. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
How such a scheduler works EX 5.9 1 2 3 4 5
6,8 7

18. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Special case of MV2PL : 2V2PL Protocol
2V2PL is particularly relevant in application
Which keeps at most two versions of any data item at each point
Data version control method
Suppose that
writes data item , but is not yet committed
As soon as
commit, the before image can be dropped
In other words,
2V2PL scheduler always maintains a current version for a data item

19. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Characteristic property 2V2PL Protocol
2V2PL variant
that at most one such uncommitted candidate is allowed
at every point of time
So it is mostly read operations that benefit from versioning
2V2PL read operations are restricted to reading current version only
(i.e., the last committed version).

20. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Lock mode for 2V2PL Protocol
uses three kinds of locks on data items

21. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
Rule for 2V2PL Protocol
Unlock operations need to obey the 2PL rule.
The rule of write lock is to ensure
that at most one uncommitted version can exist
The key point to ensure that the resulting output are multiversion serializable
is the acquisition of the certify locks.
The fact that certify locks are acquires only at the end of the transaction
and are thus usually held for a much shorter time
is a great performance advantage over conventional 2PL.

22. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
eXample 5.10 for 2V2PL Protocol
2V2PL input Schedule
before this input schedule starts

23. 5.5.2 The MV2PL(Multiversion 2 Phase Locking Protocol)
eXample for 2V2PL Protocol (cont...)
The 2V2PL produces the following output schedule
denotes unlock operations that remove all lock of a tractions
3. read lock
lock wait
2. cannot be granted
1.requested

24. 5.5.3 The MVSGT Protocol A final multiversion scheduler : Action
SGT protocol enhanced for managing multiple version.
The general scheduler maintains a multiversion conflict graph G
whose nodes are the various transactions including
Assume that arrives at the scheduler; candidates from which can read as well as which have already been scheduled.

25. 5.5.3 The MVSGT Protocol A final multiversion scheduler: excluded case
Now a first nondeterministic step consists of choosing a version for among those written by transactions that are neither late nor early.

26. 5.5.3 The MVSGT Protocol
Example 5.11

27. 5.5.3 The MVSGT Protocol
Example 5.11 (cont...)

28. 5.5.3 The MVSGT Protocol Maintain Conflict Graph G
The multiversion conflict graph G is now maintained as follows:

29. 5.5.4 A Multiversion Protocol for Read-Only Transaction
Intro..
Many modern data-intensive applications exhibit workloads with
a dominant fraction of read-only transactions that read and analyze large amounts of data.
In the presence of (at least a nontrivial fraction of) concurrent update transactions, concurrency control is crucial to ensure that the read-only transactions “see” consistent data.
Under a conventional monoversion scheduler, say, a 2PL protocol, such long transactions would often lead to a high probability of blocking the update transactions and eventually to disastrous performance
Multiversion concurrency control protocols, on the other hand, can void
many of these blocking situations by assigning “old” versions to eaders.
In this subsection we consider a simple hybrid protocol that aims to reconcile the simplicity of conventional (S)2PL or simple timestamping
with the performance benefits of versioning.

30. 5.5.4 A Multiversion Protocol for Read-Only Transaction
The Basis 1 for combined protocol
Update transactions are subject to the conventional S2PL protocol. They acquire conventional locks for both read and write steps, which are released according to the two-phase rule, with write locks held until commit.
In contrast to the conventional monoversion setting, however, each write step creates a new version rather than overwriting the data item; each version is timestamped with the timestamp of its transaction that corresponds to the commit time of the transaction.
So update transactions do not benefit from versioning at all, but provide the potential to benefit the read-only transactions while keeping the overhead of the protocol as low as possible.

31. 5.5.4 A Multiversion Protocol for Read-Only Transaction
The Basis 2 for combined protocol
Read-only transactions are handled by a multiversion timestamp protocol, similar to the MVTO rules but with a twist on committed versus uncommitted versions.
Each such transaction is assigned a timestamp that, unlike the update transactions, corresponds to the begin of the transaction (rather than its commit).
Now the key point of the protocol is that a read operation by a read-only transaction is assigned to the most recent version that has been committed at the time of the reader’s begin.

32. 5.5.4 A Multiversion Protocol for Read-Only Transaction
Sample execution ROMV protol
Figure 5.6 shows a self-explanatory scenario of
how the protocol works, with update transactions ,
and read-only transactions , and
The lock wait of because of the (conventional) lock conflict on x is indicated by a dashed line.

33. 5.6 Lesson Learned
Keeping multiple versions of data items around is an attractive idea, and at the same time it is a practical one, as we will show when we discuss recovery.
From a theoretical point of view, an adaptation of serializability theory to a multiversion setting is straightforward, as soon as the appropriate versioning restrictions have been identified.
A tricky situation, considerably different from the general case, arises for a limited number of versions, as an entire hierarchy
of classes of serializable histories enters the picture.
From a more practical point of view, adapting the various scheduling protocols to a multiversion setting is not too difficult, once the appropriate locks (or alternative synchronization mechanisms) have been found.
The special case of providing consistent views of the data to
read-only transactions, discussed in Section 5.5.4, is of very high
practical relevance and greatly benefits from versioning; protocols
like the one described there are used in several commercial database systems.