1. Concurrency Control Algorithms (4.4~4.6)
Netlab 최현수

2. 4.4 Nonlocking Schedulers
Contents
4.4 Nonlocking Schedulers
4.4.1 Timestamp Ordering
4.4.2 Serialization Graph Testing
4.4.3 Optimistic Protocols
4.5 Hybrid Protocols
4.6 Lesson Learn

3. 4.4 Non-locking Schedulers
The protocols can all guarantees the safety of their output
without using locks
Their use in commercial database systems is limited
They may be suited for distributed systems and can also
be used in hybrid protocols

4. 4.4.1 Timestamp Ordering
A first approach to getting rid of locks is to use timestamp.
These are values from a totally ordered domain
ex) natural numbers
The transaction manager assigns to each transaction ti a unique timestamp t s(ti)
A scheduler based on the use of timestamps now has to order conflict operations based on their timestamps

5. 4.4.1 Timestamp Ordering Timestamp Ordering rule
(TO rule) If pi(x) and qj(x), i ≠ j, are operations in conflict, the following has to hold:
pi(x) is executed before qj(x) iff ts(ti) < ts(tj)
THEOREM 4.15
Gen(TO) ⊆ CSR
Proof
Let s be a history generated by the TO protocol, and let (ti, tj) be an edge in the conflict graph G of s. Then there are operations pi(x) and qi(x) in conflict such that pi(x) <s qi(x)
By the TO rule, this implies ts(ti) < ts(tj)
Now if a transaction tk is involved in a cycle of G, by induction we find that ts(tk) < ts(tk),
a contradiction. Thus, G is acyclic, which means that s ∈ CSR

6. 4.4.1 Timestamp Ordering
A simple, optimistic implementation
- To transfer each operation submitted by the TM to the data
manager for execution right away, with the only exception
of those that arrive “too late”
- Operation pi(x) is too late if it arrives after the scheduler has
already output a conflicting operation qj(x) such that i ≠ j
and ts(tj) > ts(ti)

7. 4.4.1 Timestamp Ordering BTO scheduler
When some operation pi(x) arrives,
ts(ti) is compared to max-q-scheduled(x) for each operation q that is in conflict with p
And if ts (ti) < max-q-scheduled(x) holds, pi(x) is rejected, since it has arrived too late
Otherwise, it is sent to the data manager, and max-p-scheduled(x) is updated to ts(ti) if ts(ti) > max-p-scheduled(x)

8. 4.4.1 Timestamp Ordering BTO Example
s = r1(x) w2(x) r3(y) w2(y) c2 w3(z) c3 r1(z) c1
r1(x) w2(x) r3(y) a2 w3(z) c3 a1 t1
r1(x) t2
w2(x) t3
r3(y)
w2(y)
w3(z)
abort c3
r1(z)

9. 4.4.2 Serialization Graph Testing
A serialization graph tester(SGT protocol)
Maintains a conflict graph in which nodes and edges are added or removed dynamically depending on the operations that arrive at the scheduler.
The CSR property of the output is preserved by making sure that this graph remains acyclic at any time.

10. 4.4.2 Serialization Graph Testing
SGT Protocol works as follows
Whenever a new operation pi(x) arrives from the transaction manager,
The scheduler creates a new node for transaction ti in the current graph G if pi(x) is the first operation it sees from ti
The insert edges of the form (ti, tj) into G for each operation qj(x) that is in conflict with pi(x), i ≠ j, and that has been output previously.

11. 4.4.2 Serialization Graph Testing
SGT Protocol works as follows(cont)
Two cases can arise
The resulting graph G is cyclic. If pi(x) were executed, the resulting schedule would no longer be serializable. Thus, pi(x) is rejected and ti aborted, and the node for ti and all its incident edges are removed from G.
G is (still) acyclic. Then pi(x) can be output – that is, added to the schedule already output – and the tentatively updated graph is kept as the new current one.

12. 4.4.3 Optimistic Protocol
The schedule produced have to validate their output occasionally, which is why they are also known as validation protocols (sometimes also called certifiers)
Do not interrupt the production of a schedule in order to validate what and how scheduler has been doing so far.

13. 4.4.3 Optimistic Protocol
Perceive a transaction’s execution as taking place in three phases
Read phase
Execute transaction with writes into private workspace
Validation phase (certifier)
Upon t’s commit request
Test if schedule remains CSR if t is committed now
Whether the transaction’s result can be copied into DB
Write phase
Upon successful validation
- Transfer the workspace contents into the database(deferred writes)
Otherwise abort t (i.e., discard workspace)

14. 4.4.3 Optimistic Protocol
We assume as a simplification that phases (2) and (3) are executed indivisibly as a non-interruptible “critical section”, meaning that all other transaction are suspended during such a critical section.
We call this combined phase the val-write phase
Note that the indivisibility of this phase may be quite problematic in real implementation
If the write phase merely needs to modify a few entries in a page allocation table, then the critical section is not really harmfully
But, if the write phase needs to copy records from working space into disk pages, suspending all concurrent transactions for such an extended time period would inevitably result in significant performance losses

15. 4.4.3 Optimistic Protocol
LEMMA 4.9
Let G be a DAG. If a new node is added to G in such a way that no edges start from the new node, then the resulting graph is still a DAG
* DAG : A directed graph with no path that starts and ends at the same vertex
If a new node is added to an acyclic graph and the graph thereby becomes cyclic, then the new node must be involved in the cycle. But in order to be on a cycle, there would have to be at least one edge going into the node and at least one coming out

16. 4.4.3 Optimistic Protocol Two different types of validation approaches
Under backward-oriented optimistic concurrency control(BOCC)
A transaction under validation executes a conflict test against all those transactions that are already committed
Under forward-oriented optimistic concurrency control(FOCC)
A transaction is validated against all transactions that run in parallel, but that are still their read phase

17. 4.4.3 Optimistic Protocol BOCC validation
A transaction tj is positively validated (or “accepted”) if one of the following holds for each transaction ti that is already committed.
ti has ended before tj has started (which implies that all of ti has been executed before all of tj)
Otherwise, RS(tj) ∩ WS(ti) = Ø, and the val-write phase of ti has ended prior to the val-write phase of tj(assuming a “critical section”) Thus, tj has not had a chance to read from ti, and again if there are conflicts at all, they give rise to an edge from ti to tj, but one in the opposite direction is impossible

18. 4.4.3 Optimistic Protocol Proof:
THEOREM 4.17
BOCC validation produces acyclic conflict graphs only, i.e., Gen(BOCC) ⊆ CSR
Proof:
Assume that G(s) is acyclic. Adding a newly validated transaction can insert only edges into the new node, but no outgoing edges (i.e., the new node is last in the serialization order).

19. 4.4.3 Optimistic Protocol BOCC Example t1 r1(x) r1(y) w1(x) read phase
write
val. t2
r2(y)
r2(z)
w2(z) t3
r3(x)
r3(y)
abort t4
r4(x)
w4(x)

20. 4.4.3 Optimistic Protocol FOCC
Validate a transaction tj against all concurrent transaction ti that are still reading.
Let RSn(ti) denote the read set of ti at some time n. Then tj is accepted under FOCC at that time n if the following holds for all transactions ti that are still reading at time n:
WS(tj) ∩ RSn(ti) = Ø

21. 4.4.3 Optimistic Protocol Proof: Theorem 4.47: Gen (FOCC)  CSR.
Assume that G(s) has been acyclic and that validating tj would create a cycle. So tj would have to have an outgoing edge to an already committed tk.
However, for all previously committed tk the following holds:
If tk was committed before tj started, then no edge (tj, tk) is
possible.
If tj was in its read phase when tk validated, then WS(tk) must be
disjoint with RS*(tj) and all later reads of tj and all writes of tj
must follow tk (because of the strong critical section);
so neither a wr nor a ww/rw edge (tj, tk) is possible.

22. 4.4.3 Optimistic Protocol FOCC validation(cont) t1 r1(x) r1(y) w1(x)
read
phase
write
val. t2
r2(y)
r2(z)
w2(z) t3
r3(z)
abort t4
r4(x)
w4(y)
r4(y) t5
r5(x)
r5(y)

23. 4.5 Hybrid Protocols Hybrid Protocols
Combine different protocols, each handling different types of conflicts (rw/wr vs. ww) or data partitions
since the component need proper integration such a scheduler is called a hybrid scheduler.
RW(or WR) synchronization
two operation are in conflict if They access the same data item. one is r step, the other a w step.
WW synchronization
two operation are in conflict if They access the same data item. one is w step, the other a w step.

24. 4.5 Hybrid Protocols A pure integrated scheduler Organization
r/w sync : Basic TO(BTO)
w/w sync : Thomas Write Rule (TWR)
This scheduler behave as follows :
1. r-w(w-r) conflict check (BTO rule)
it schedules ri [x] if for all wj[x] that have already scheduled, ts(ti ) > ts(tj), otherwise it rejects ri [x]. And it reject wi[x] if it has already scheduled some rj[x] with ts(ti ) < ts(tj)
2. w-w conflict check (TWR)
if it has scheduled some wj [x] with ts(ti ) < ts(tj), it ignores wi [x](not abort)
example ( ts(t1) < ts(t2) )
s1 = w1(x) r1(z) r2(x) w2(y) w1(y)
=> s1 = w1(x) r1(z) r2(x) w2(y)

25. 4.5 Hybrid Protocols A Mixed integrated Scheduler Organization
r/w sync : Strong 2PL(SS2PL)
w/w sync : Thomas Write Rule (TWR)
The combination must guarantee that the union of the underlying “local” conflict graphs is acyclic. but not guarantee.

26. 4.5 Hybrid Protocols Example 4.15
s1 = w1(x)r2(y)w2(x)w2(y)c2w1(y)c1, where ts(T1) < ts(T2)
w1(y) is ignored by TWR.
s2 = w1(x)r2(y)w2(x)w2(y)c2r1(y)w1(y)c1
r1(y) step would be executed, leading to a conflict cycle between T1 and T2
the combination does not properly guarantee CSR

27. 4.5 Hybrid Protocols Example 4.15 (cont.)
As the s2 indicates, an integration of SS2PL and TO or TWR has to be done cautiously
The following holds for every output s:
(1) Grw(s) is acyclic (due to the use of SS2PL)
(2) Gww(s) is acyclic (due to TWR)
To gurantee the G(s) = Grw(s) ∪ Gww(s) is acyclic as well, it apparently suffices to state the following :
(a) (ti, tj) ∈ Grw(s)  ts(ti ) < ts(tj)
- tj cannot terminate before ti release a lock that tj needs
Under SS2PL, every transaction holds its lock until commit
(b) if ti commits before tj , then ts(ti ) < ts(tj)
- for assuring (b), the scheduler needs to block the assignment of a timestamp to ti until it reaches its commit point

28. Lessons Learned
S2PL is the most versatile and robust protocol and widely used in practice.
Knowledge about specifically restricted access patterns
facilitates non-two-phase locking protocols (e.g., TL, AL)
O2PL and SGT are more powerful but have more overhead.
FOCC can be attractive for specific workloads
Hybrid protocols are conceivable but non-trivial

29. Thank you