1. 6. Concurrency Control on Objects : Notions of Correctness.
박지혜
Computational Theory Lab.

2. Computational Theory Lab.
Introduction.
6.1 Goal and Overview.
6.2 Histories and Schedules.
6.3 Conflict Serializability for Flat Object Transactions.
6.4 Tree Reducibility.
6.5 Sufficient Conditions for Tree Reducibility.
6.6 Exploiting State Based Commutativity.
6.7 Lesson Learned.
Computational Theory Lab.

3. Computational Theory Lab.
6.1 Goal and Overview.
Goal of this chapter : develop correctness criteria for concurrent
executions of object model transactions.
In our quest for appropriate correctness criteria we have to address
two major differences from the page model:
1. The operations of a transaction are more general than merely
read and write.
2. Operations can themselves invoke other operations, thus
leading to a transaction tree.
Computational Theory Lab.

4. Computational Theory Lab.
6.2 Histories and Schedules.
Recall from Chapter 2 how transactions are characterized in the object model.
The dynamic invocations of operations by a transaction spawn a tree of labeled nodes, where each node corresponds to an invoked operation together with its input and possibly also output parameters.
The parent of a node is the operation from which the node’s operation was called.
The children of a node are the operations called by the node.
Each invoked operation results in calls of read and write operations, which thus form the leaves of the tree.
Computational Theory Lab.

5. Computational Theory Lab.
6.2 Histories and Schedules.
We want to allow concurrent or parallel threads.
The execution order is modeled as a partial order of the leaves.
The ordering of higher-level operations is derived from the leaf order.
p precedes q if p terminates before q begins.
Last leaf-level descendant of p precedes the first leaf-level descendant of q.
Computational Theory Lab.

6. Computational Theory Lab.
6.2 Histories and Schedules.
DEFINITION 6.1 Object Model History
Let T = {t1, … , tn} be a (finite) set of transaction trees, where each ti ∈ T
is a pair (opi, <i) of labeled tree nodes along with a partial order of the leaves.
A history s (or complete schedule) for T is a partially ordered forest
(op(s), <s) with node step op(s) and partial order <s such that:
op(s) ⊆ ∪ni=1 opi ∪ ∪ n i=1 {ai,ci} and ∪ni=1 opi ⊆ op(s), i.e. s contains the
operations of the given transaction trees and a termination operation
ci (commit) or ai (abort) for each transaction ti ∈ T.
2. (∀i, 1 ≤i≤ n), ci ∈ op(s) ⇔ ai  op(s)
Computational Theory Lab.

7. Computational Theory Lab.
6.2 Histories and Schedules.
3. ai or ci is a leaf node with the transaction ti as its parent.
4. ∪ni=1 <i ⊆ <s, i.e. all transaction orders are contained in the partial order
given by s.
5. (∀i, 1 ≤i≤ n), (∀p ∈ opi) p <s ai or p <s ci .
6. Any pair of leaf operations p, q ∈ op(s) from distinct transactions
accessing the same data item s.t. at least one is a write operation must
be ordered in s, i.e. either p <s q or q <s p.
Computational Theory Lab.

8. Computational Theory Lab.
6.2 Histories and Schedules.
Like the individual transaction trees, the partial order of a history refers to
the leaves of the forest, and we can derive a partial order among all nodes
by the following convention:
DEFINITION 6.2 Tree-Consistent Node Ordering
In an object model history s = (op(s), <s ) the ordering <s of leaf nodes is extended to arbitrary nodes as follows:
Two node p and q are considered as ordered, i.e., p <s q if for all leaf-level descendants p’ and q’ of p and q, respectively, the order p’ <s q’ holds according to the original (i.e., nonextended) <s Such an ordering is called tree consistent.
Computational Theory Lab.

9. Computational Theory Lab.
6.2 Histories and Schedules.
Prefix of a history can be applied to transaction forest:
Prefix of a history s = (op(s), <s ) is a forest s’ = (op(s’), <s’) with op(s’) ⊆ op(s) and <s’ ⊆ <s such that for each p ∈ op(s’) all ancestors of p and all nodes q ∈ op(s) with q <s p must be in op(s’) , too, and <s’ equals <s when restricted to op(s’).
DEFINITION 6.3 Object Model Schedule
An object model schedule is a prefix of an object model history.
Computational Theory Lab.

10. Computational Theory Lab.
6.2 Histories and Schedules.
t t2
Withdraw(a) Withdraw(b) Deposit(c) Deposit(c) c c
r(p) r(q) w(p) w(t) w(q) w(t) r(r) w(r) r(r) w(r)
Figure 6.1 Example of an object model history.
Computational Theory Lab.

11. Computational Theory Lab.
6.2 Histories and Schedules.
Assume that both of these operations are directly “translated” into
page operations, that is, reads and writes.
t1: transfers money from account a to c,
t2: transfers money from account b to c.
Assume that the relevant records for accounts a, b, and c
reside on pages p, q, and r.
Withdraw operations need to access page t to obtain and track
an approval code.
For simplicity :
1. disregard steps for location these page.
2. Simplify the notation in that we only list those parameters of the invoked
operations.
Computational Theory Lab.

12. Computational Theory Lab.
6.2 Histories and Schedules.
We indicate the ordering of operations by drawing the leaf nodes in their
execution order from left to right.
Caller-Callee relationship is captured by vertical or diagonal arcs.
The crossing of arcs indicates that two operations are concurrent.
In Figure 6.1, two Withdraw operations that from t1 and t2, are concurrent.
It is necessary to indicate the caller-callee relationship more explicitly.
Use subscripts for tree nodes as follows:
subscript of a root ti is i.
subscript of the j-th child of node with subscript w is wj.
For example, w(t) operation belonging to t1 would be denoted as w113(t)
Thus bearing the identification of its entire ancestor chain.
Computational Theory Lab.

13. Computational Theory Lab.
6.2 Histories and Schedules.
DEFINITION 6.4 Serial Object Model Schedule
An object model schedule is serial if its roots are totally ordered and
for each root and each i > 0 the descendants with distance i from the
root are totally ordered.
Transactions are executed sequentially.
All steps within a transaction are also sequential.
It is not enough to require that all leaves of a root are ordered, as this
would still allow interleaved executions of some inner-node operations.
Computational Theory Lab.

14. Computational Theory Lab.
6.2 Histories and Schedules.
DEFINITION 6.5 Isolated Subtree
A node p and the corresponding subtree in an object model schedule s
are called isolated if
For all nodes q other than ancestors or descendants of p the property
holds that for all leaves w of q either w <s p or p <s w ,
For each i > 0 the descendants of p with distance i from p are
totally ordered.
No other subtree can have any leaf operation between one of the leaves of subtree p.
Subtree rooted at p forms an indivisible unit.
It is allowed for another subtree to have some leaves both preceding and following p.
Computational Theory Lab.

15. Computational Theory Lab.
6.2 Histories and Schedules.
In Figure 6.1, two interleaved transaction trees are both perfectly
balanced trees, meaning that all leaves have the same distance
from their roots.
It structured in three levels :
1. Page accesses at the bottom level.
2. Method invocations on account objects at the middle level.
3. Transactions at the top level.
Computational Theory Lab.

16. Computational Theory Lab.
6.2 Histories and Schedules.
DEFINITION Layered History and Schedule
An object model history is a layered history if all leaves other than Commit
or Abort operations have identical distance from their roots.
A layered history with a leaf-to-root distance of n is called an n-level history.
In an n-level history, operations with distance i to the leaf level are called
level-i operations (Li operations).
(i.e., leaves are at level L0 and roots at Level Ln).
A layered schedule is a prefix of a layered history.
Computational Theory Lab.

17. Computational Theory Lab.
6.2 Histories and Schedules.
t t2
Withdraw(a) Withdraw(b) Deposit(c) Deposit(c)
r(p) r(q) w(p) w(t) w(q) w(t) r(r) w(r) r(r) w(r)
Withdraw(a) Withdraw(b)
Figure 6.2 Two examples of nonlayered object model schedules.
Computational Theory Lab.

18. Computational Theory Lab.
6.2 Histories and Schedules.
In figure 6.2,
Upper example : Withdraw operations don’t include the step for obtaining
and tracking an approval code, so transactions invoke the data
server operations directly.
Lower example : the deposit steps aren’t explicitly represented.
and the corresponding page operations are invoked directly by the
transactions.
- why would the withdrawals be explicit, whereas the Deposit operations
no longer show up?
Transactions do “bypass” the object interface, avoiding the call
of the deposit method.
Merely model, so we don’t necessarily need to be complete
pictures of everything.
Computational Theory Lab.

19. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
Within the class of layered schedules, a special subclass of particular interest is what we call flat object schedules.
These are two-level schedules with object method invocations at the higher level L1 and r/w operations at the lower level L0.
We disallow concurrent L1 operations in this subclass.
Transactions may be interleaved, but for each pair of object method executions we require an ordering.
Computational Theory Lab.

20. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
DEFINITION 6.7 Flat Object Schedule
A two-level schedule s is called a flat object schedule if for each pair p,q
of L1 operations the following two conditions hold:
(∀p’ ∈ child(p), q’ ∈ child(q)) p’ <s q’ or q’ <s p’.
(∀p’, p’’ ∈ child(p)) p’ <s p’’ or p’’ <s p’.
Where child(p) denotes the set of children of operation p.
Total order among L1 operations.
Each L1 operation is itself a serial execution of page accesses.
Computational Theory Lab.

21. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
t t2
Withdraw(a) Withdraw(b) Deposit(c) Deposit(c)
r(p) w(p) w(t) r(q) w(q) w(t) r(r) w(r) r(r) w(r)
Figure 6.3 Example of a flat object schedule.
Note that the total ordering of L1 operations and their sequentiality are easily recognized by the observation that none of the caller-callee arcs from the L1 operations to their L0 children cross each other.
Computational Theory Lab.

22. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
DEFINITION 6.8 Commutative Operations
Two operations p and q (on some objects) are commutative (or they
Commute) if for all possible sequences of operations α and ω, the return
Parameters in the concatenated sequence αpq ω are identical to those
in the sequence αqp ω.
For example, two operations deposit(a, 10) and deposit(a, 20) can be tested
By various numbers of successive Withdraw operations to see that both
Possible orderings of the two Deposit operations achieve the same effects.
Computational Theory Lab.

23. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
Withdraw(x, ∆2) Deposit(x, ∆2) GetBalance(x)
Withdraw(x, ∆1)
Deposit(x, ∆1)
Getbalance(x)
Table 6.1 Commutativity table for bank account operations.
Computational Theory Lab.

24. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
DEFINITION 6.9 Commutativity Based Reducibility
A flat object schedule s is commutativity based reducible if it can be
transformed into a serial schedule by applying the following rules
finitely many times:
Commutativity rule : The order of two ordered operations p and q with,
say, the order p <s q can be reversed if
Both are isolated, adjacent in that there is no other operation r with
p <s r <s q and commutative, and
(b) The operations belong to different transactions, or if they belong to
the same transaction ti, the reversal does not contradict the
specified order <i within ti.
Computational Theory Lab.

25. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
2. Ordering rule : Two unordered leaf operations p and q can (arbitrarily)
be ordered, i.e., assuming either p < q or q < p if they are commutative
(i.e., both are reads, or they operate on different data items).
In Figure 6.3, transform this schedule into a serial one is to exchange
the order of t1’s Deposit operation with the deposit of t2 and then, in a
second transformation step, with the withdrawal of t2.
These steps pull t1’s Deposit operation back, out of the interleaving with t2.
Transformations are feasible only because the affected L1 operations are
already isolated in that their page-level executions are strictly sequential.
Computational Theory Lab.

26. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
DEFINITION 6.10 Conflict Equivalence and Conflict Serializability
Two flat object schedules s and s’ are conflict equivalent if they consist of
the same operations and both have the same ordering for all
noncommutative pairs of L1 operations.
A flat object schedule is conflict serializable if it is conflict equivalent to
a serial schedule.
Computational Theory Lab.

27. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
For a flat object schedule s, the corresponding conflict graph is a graph
with the transactions of s as nodes and an edge from ti to tj if there are
noncommutative L1 operations pi and qj belonging to ti and tj.
THEOREM 6.1
Let s be a flat object schedule. Then s is conflict serializable iff
its conflict graph is acyclic. Furthermore, s is conflict serializable iff
it is commutativity based reducible.
Computational Theory Lab.

28. Computational Theory Lab.
6.3 Conflict Serializability for
Flat Object Transactions.
In Figure 6.3, the conflict graph doesn’t have any edges because all
L1 operations commute, and thus it is trivially acyclic.
Conflict graph derived from the L0 operations would have a cycle
caused by the conflicts on pages t ( with t1 preceding t2) and
r ( with t2 preceding t1).
This shows exactly the benefit of exploiting the “semantic knowledge”
about the object level operations for withdrawals and deposits.
We can now allow schedules that would be disallowed under the
purely read/write based viewpoint of the page model.
Computational Theory Lab.

29. Computational Theory Lab.
6.4 Tree Reducibility.
Recall
t t2
Withdraw(a) Withdraw(b) Deposit(c) Deposit(c) c c
r(p) r(q) w(p) w(t) w(q) w(t) r(r) w(r) r(r) w(r)
Figure 6.1 Example of an object model history.
t t2
Withdraw(a) Withdraw(b) Deposit(c) Deposit(c) c c
r(p) w(p) w(t) r(q) w(q) w(t) r(r) w(r) r(r) w(r)
Computational Theory Lab.

30. Computational Theory Lab.
6.4 Tree Reducibility.
The second and third page access of operation withdraw11(a), namely,
w112(p) and w113(t), both commute with the preceding r211(q)
operation of t2.
Hence the two write accesses of t1 can be pulled back so that t1’s
withdraw operation would completely precede the withdraw
All object-level operations are isolated and commute with each other,
so that the entire schedule is equivalent to either of the two
possible serial orders of t1 and t2.
Computational Theory Lab.

31. Computational Theory Lab.
6.4 Tree Reducibility.
DEFINITION 6.11 Tree-Reducible History
An object model history s= (op(s), <s) is tree reducible if it can be
transformed into a total order of its roots by applying the following rules
finitely many times:
Commutativity rule : The order of two ordered leaf operations p and q
with, say, the order p <s q can be reversed provided that
Both are isolated, adjacent in that there is no other operation r with
p <s r <s q and commutative, and
(b) The operations belong to different transactions, or if they belong to
the same transaction ti, the reversal does not contradict the
specified order <i within ti. and
Computational Theory Lab.

32. Computational Theory Lab.
6.4 Tree Reducibility.
(c) the operations p and q don’t have ancestors, say, p’ and q’,
respectively, which are noncommutative and totally ordered
(in the order p’ <s q’).
2. Ordering rule : Two unordered leaf operations p and q can (arbitrarily)
be ordered, i.e., assuming either p < q or q < p if they are commutative
(i.e., both are reads, or they operate on different data items).
3. Tree pruning rule : An isolated subtree can be pruned in that it is
replaced by its root.
An Object model schedule is tree reducible if its committed projection
is tree reducible.
Computational Theory Lab.

33. Computational Theory Lab.
6.4 Tree Reducibility.
t t2
Store11(z) Fetch21(x) Modify12(y) Modify21(y) Modify13(w)
r(t) r(p) r(q) r(t) r(p) w(q) w(p) w(t) r(t) r(p) w(p) r(t) r(t) r(p) w(p) r(p) w(p)
Figure 6.4 Example of correct object model schedule with record-level operations.
Computational Theory Lab.

34. Computational Theory Lab.
6.4 Tree Reducibility.
All object-level operations isolated, so that the page-level subtrees can
be pruned:
Fetch21(x) store11(z) modify12(y) modify13(w) modify21(y)
Noncommutative pair of operations consists of the two Modify operations
on record y :
Rearrange the commutative operations to produce a serial order with all
operations of t1 preceding all of t2.
t t2
Fetch21(x) Store11(z) Modify12(y) Modify13(w) Modify21(y)
Computational Theory Lab.

35. Computational Theory Lab.
6.4 Tree Reducibility.
t t2
Store(z) Fetch(x)
r(t) r(p) r(q) w(q) w(p) r(t) r(p) w(t)
Figure 6.5 Example of a disallowed object model schedule with record-level operations.
Page-level conflicts between w115(p) and r212(p), r211(t) and w116(t),
it is impossible to rearrange the page-level operations toward isolating the
store(z) and fetch(x) operations. Hence the schedule is not tree reducible.
Computational Theory Lab.

36. Computational Theory Lab.
6.4 Tree Reducibility.
t t2
CheckItem CheckItem Shipment Payment Payment
Append Append CheckCard CheckCash
r(p) w(p) r(p) w(p) r(q) w(q) r(q) w(q) r(r) w(r) r(s) w(s) r(s) r(t) w(t) w(s) r(t) w(t)
Figure 6.6 Example of correct object model schedule from an e-Commerce scenario.
Computational Theory Lab.

37. Computational Theory Lab.
6.4 Tree Reducibility.
t t2
CheckItem CheckItem Shipment Payment Payment
Append Append CheckCard CheckCash
CheckItem : initate stock refilling by means of appending appropriate entries to
a list of items with low quantity-on-hand
Payment : put entries into some kind of audit trail, stored on page t, for tracking
purposes. noncommutative among themselves.
Shipment, CheckItem are commutative with each other and also with payment.
The schedule shown is tree reducible, arriving at the serial order t2 < t1.
Computational Theory Lab.

38. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
DEFINITION Level-to-Level Schedule
Let s = (op(s), <s) be an n-level schedule with layers L0, …, Ln (in bottom up
order). The level-to-level schedule from Li to Li-1 with i>0, or
Li-to-Li-1 schedule for short, is a one-level schedule s’ = (op(s’), <s’) with
op(s’) consisting of the Li-1 operations of s,
<s’ being the restriction of the extended order <s to the Li-1 operations,
The Li operations of s as the roots,
The parent-child relationship identical to that of s.
Computational Theory Lab.

39. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
t t L2
Withdraw11(a) Withdraw21(b) Deposit22(c) Deposit12(c) c13 c L1
t t t t L1
r111(p) r211(q) w112(p) w113(t) w212(q) w213(t) r221(r) w222(r) r121(r) w122(r) L0
Figure 6.7 Level-to-level schedules constructed from the layered object model schedule of Figure 6.1.
Computational Theory Lab.

40. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
L2-to-L1 schedule has partially ordered leaves, and the order is explicitly indicated by the directed arcs in the figure.
This partial order is exactly the original schedule’s partial order of the L1 operations as derived from the ordering of their leaves.
CONJECTURE 6.1
Let s be an n-level object model schedule. If for each i, 0 < i  n, the
Li-to-Li-1 schedule derived from s is conflict serializable,
then s is tree reducible.
Computational Theory Lab.

41. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
t t L2
Withdraw11(a) Withdraw21(b) Deposit22(c) Deposit12(c) c13 c L1
t t t t L1
r111(p) r211(q) w112(p) w113(t) w212(q) w213(t) r221(r) w222(r) r121(r) w122(r) L0
Figure 6.7 Level-to-level schedules constructed from the layered object model schedule of Figure 6.1.
L1-to-L0 schedule is equivalent to the serial order
t11 < t21 < t22 < t12
L2-to-L1 schedule is equivalent to the serial order
<t1, t2> , <t2, t1>
Computational Theory Lab.

42. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
t t t L2
f11(x) g21(x) h31(z) f12(y) g22(y) L1
r111(p) w112(p) r211(p) w212(p) w213(t) w311(q) r121(q) r221(p) r222(t) w312(t) L0
Figure 6.8 Non-tree-reducible layered object model schedule with conflict serializable level-to-level schedules.
Computational Theory Lab.

43. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
L2-to-L1 : t1 precede t2, equivalent to t1 < t2 < t3
L1-to-L0 : equivalent to t11 < t21 < t22 < t31 < t12
It is impossible to isolate all three subtrees, t31, t12, t22 by commutativity rule.
Hence the schedule is not tree reducible due to part 1(c) of Def 6.11.
Decisive problem : L1-to-L0 reverses the actual execution order of the
two conflicting L1 operations f12(y) and g22(y).
Serialization order for L1-to-L0 schedule does not preserve the execution
order at level L1
That is, the level-to-level schedule from L1-to-L0 is
not order preserving conflict serializable.
Computational Theory Lab.

44. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
(In Chapter 3)
DEFINITION 3.18 Order Preservation
A history s is called OCSR, if it is conflict seralizable, i.e., there exists a serial history s’ such that op(s) = op(s’) and s c s’ and if the following holds for all t ,t’ trans(s): if t occurs completely before t ’ in s, then the same holds in s ’.
Let OCSR denotes the class of all order-preserving conflict serializable histories.
Computational Theory Lab.

45. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
THEOREM 6.2
Let s be an n-level object model schedule. If for each i, 0 < i ≤ n,
the Li-to-Li-1 schedule derived from s is order preserving conflict
serializable, then s is tree reducible.
Proof
Order-preserving conflict serializability from level 1-to-level 0 allows us to apply the ordering and commutativity rules to isolate the subtrees rooted at level L1 such that the execution order of L1 is preserved.
Then we can prune all operations of L0 by the tree pruning rule. Now consider the new leaves of the pruned transaction forest (i.e., the operations at level 1).
Any noncommutative operations among these new leaves must have been executed in total order, and because of the order-preserving serialization, this original execution order is retained.
Computational Theory Lab.

46. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
So the outcome of pruning all operations of level 0 is a transaction forest whose new leaf ordering is compatible with the original ordering of the operations at level 1 in the sense that all “critical” ordering between noncommutative operations are included, some previously unordered but commutative operations may have become ordered, and the original ordering of some commutative operations may have been switched.
Thus, since the original level-to-level schedule from level 1-to-level 0 is assumed to be OCSR, this property also holds for the result of the first pruning round.
Then the same argument can be iterated, and by induction on the number of levels, we see that we arrive at a total order of the transaction root.
Computational Theory Lab.

47. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
t t t L2
f11(x) g21(x) h31(z) h12(y) h22(y) L1
r111(p) w112(p) r211(p) w212(p) w213(t) w311(q) r121(q) r221(p) r222(t) w312(t) L0
Figure 6.9 Tree-reducible layered object model schedule with non-OCSR level-to-level schedule.
L1-to-L0 schedule is not order preserving conflict serializable.
Possible serialization would reverse the order of h12(y) and h22(y),
contradicting their actual execution order.
Computational Theory Lab.

48. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
Definition Conflict Faithfulness
A layered object model schedule s = (op(s), <s) is conflict faithfulness if for each pair p, q  op(s) that are noncommutative and each i>0 the corresponding sets of descendants with distance i to p and q contain at least one operation pair p`, q` where p` and q` are descendants of p and q, respectively, and are in conflict.
Computational Theory Lab.

49. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
THEOREM 6.3
A layered object model schedule s = (op(s), <s) is tree reducible if it is conflict faithful and all its level-to-level schedules are conflict serializable.
Proof
The proof is by induction on the number n of nonroot levels.
For n = 1, we consider a page model schedule, and the claim trivially holds.
Now assume that our claims holds for n – 1 (n > 1) nonroot levels, and consider a schedule with n nonroot levels.
we can prune all subtrees rooted at level n – 1 such that the resulting transaction forest preserves the original execution order of all noncommutative operations at level n – 1. Because of this property and since the level-to-level schedule from level n-to-level n – 1 is conflict serializable,
Computational Theory Lab.

50. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
we can isolate the operations at level n and once again prune subtrees
What remains to be shown is that this pruning step must also preserve the execution order of any noncommutative operations at level n.
So suppose that two such noncommutative level n operations, f and g with the original execution order f < g, are rearranged by the transformation steps for isolating the level n operations such that g precedes f in the resulting transaction forest.
Now the property of conflict faithfulness tells us that f and g have children, say, f’ and g’, that are noncommutative at level n – 1. Since the original execution order is f < g, f’ must have preceded g’ originally.
Therefore, the serialization of the level-to-level schedule from level n-to-level n – 1 must have preserved this ordering. So it is impossible to violate the original execution order of noncommutative operations at level n.
Computational Theory Lab.

51. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
t t L2
Modify11(x) Fetch21(x) Fetch22(y) Modify12(y) L1
r111(t) r211(t) r112(p) r212(p) w113(p) r221(t) r222(p) r121(t) r122(p) w123(p) L0
Figure 6.10 Tree-reducible schedule with concurrent, conflicting L1 operations.
Computational Theory Lab.

52. Computational Theory Lab.
6.5 Sufficient Conditions for
Tree Reducibility.
Level-to-level serializability and conflict faithfulness isn’t a necessary condition for tree reducibility.
Conflicting higher-level operations may be allowed to run concurrently as long as they are properly serialized at the underlying implementation level.
Figure 6.10 shows a concrete example with conflicting, unordered record operations fetch(x) and modify(x).
The schedule is tree reducible to the transaction order t2<t1.
Computational Theory Lab.

53. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity.
Definition State-dependent commutativity
Operations p and q on the same object are commutative in object state  if for all operation sequences 
the return parameters in the sequence pq applied to 
are identical to those in qp applied to .
Withdraw1(x,30) deposit2(x,50) deposit2(y,50) withdraw1(y,30)
If we know about the original balance of the account, we may be in a position to
approve the above schedule as one that is equivalent to a serial execution.
For example, if the original balance was known to be $40 and the threshold for the
overdraft protection was zero, then the first withdraw operation could be commutative
with the two deposit, thus eliminating the conflict cycle and rendering the schedule
equivalent to the transaction order t2<t1.
Computational Theory Lab.

54. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity.
Exploiting state knowledge poses severe difficulties in a real system environment.
The notion of a state is not easy to define, given that operations may have side effects on more than one object, some of witch may be observed much later.
Even if we had a clean definition of object states, we would still need an algorithm for inspecting states.
For example, with Bank account objects, we may internally use the GetBalance method for testing the object state upon each Withdraw method, but this could result in inefficiencies.
Restrict ourselves to observing only operation parameters.
Computational Theory Lab.

55. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity.
Definition Return-value commutativity
An operation execution p (x1, ...,  xm, y1, ...,  yn) is return-value
commutative with an immediately following operation execution
q (x1`, ...,  xm``, y1`, ...,  yn‘`) if for every possible sequences  and  s.t.
p and q have indeed yielded the given return values in pq, all operations
in the sequence qp yield identical return values.
For example, if p is withdraw(x,30) OK operation execution, only  sequences are
relevant that resulted in an account balance of at least $30.
The set of relevant  sequences for the ordered pair pq may differ from that for the
ordered pair qp. If q is deposit(x,50)  OK, pq ≠ qp.
Computational Theory Lab.

56. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity.
withdraw
(x,2)ok
(x,2)no
deposit
(x,1)ok + _
(x,1)no q p
Table 6.2 Return Value Commutativity table for bank account operations.
Computational Theory Lab.

57. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity.
t t2
Decr(x,20) No Incr(x,30) OK Decr(y,20) OK Incr(y,30) No
r(p) r(p) w(p) r(p) w(p) r(p)
X= 15
y = 45
X= 15
y = 45
X= 45
y = 45
X= 45
y = 25
X= 45
y = 25
Figure Example schedule on counter objects.
Computational Theory Lab.

58. Computational Theory Lab.
6.6 Exploiting State Based
Commutativity. q
Enqueueok
enqueueone
dequeueok
dequeueempty p _
enqueueok
impossible +
impossible _ _
enqueueone
impossible
impossible _ _ _
dequeueok + _ _
dequeueempty
impossible +
Table 6.3 Return Value Commutativity table for queue operations.
Computational Theory Lab.