1. 8. Concurrency Control on Relational Database
Computer Science & Engineering
Park, Sang-Joon

2. Index 8.1 Goals and Overview
8.2 Predicate-Oriented Concurrency Control
8.3 Relational Update Transactions
8.4 Exploiting Transaction-Program Knowledge
8.5 Lessons Learned

3. 8.1 Goals and Overview
Closer look at semantic approaches to concurrency control about relational model.
Manipulated by query or update operations(SQL query and update operation).
Should be understood as samples of what can be done to utilize semantic knowledge.

4. 8.1 Goals and Overview Predicate-Oriented Concurrency Control
Derive granules that are subject to locking from the relational query or update expressions that trigger the data accesses.
Relational Update Transactions
For update operations, a theory of concurrency control can be established(FSR, CSR,…).
Exploiting Transaction-Program Knowledge
Chopping transactions into semantically equivalent smaller pieces.

5. Index 8.1 Goals and Overview
8.2 Predicate-Oriented Concurrency Control
8.3 Relational Update Transactions
8.4 Exploiting Transaction-Program Knowledge
8.5 Lessons Learned

6. 8.2 Predicate-Oriented Concurrency Control
Layered locking in Section 7.3
Lock modes can be attached to operations.
Relational data model is used in this Section for explanation.
In transactional access, there are two extremes with respect to locking.
Locking entire relations.
Low concurrency.
Locking individual tuples.
So many locks causing lock administration problem.

7. 8.2 Predicate-Oriented Concurrency Control
Example 8.1
Emp
Name
Department
Position
Salary
Jones
Service
Clerk
20,000
Meier
22,000
Paulus
Manager
42,000
Smyth
Toys
Cashier
25,000
Brown
Sales
28,000
Albert
38,000

8. 8.2 Predicate-Oriented Concurrency Control
Delete the former manager of the service department:
DELETE FROM Emp
WHERE Department = ‘Service’
AND Position = ‘Manager’
Insert a new manager of the service department named Smith with a salary of $40,000:
INSERT INTO Emp
VALUES (‘Smith’, ‘Service’, ‘Manager’, 40,000)
(c) Move all employees who are not managers from the service to the sales department:
UPDATE Emp
SET Department = ‘Sales’
AND Position <> ‘Manager’
(d) Insert a new employee named Stone into the service department with a salary of $13,000:
VALUES (‘Stone’, ‘Service’, ‘Clerk’, 13,000)

9. 8.2 Predicate-Oriented Concurrency Control
Consider the following transaction:
Ask for name, position, and salary of all employees of the sales department.
SELECT Name, Position, Salary
FROM Emp
WHERE Department = ‘Service’
Locking the tuples has some problem.

10. 8.2 Predicate-Oriented Concurrency Control
Retrieval transaction right after:
Step (a)
Department without a manager.
Step (b)
Department with a new manager and the old staff.
Step (c)
Department with the new manager and no clerks for doing actual work.
There exists phantom phenomenon.

11. 8.2 Predicate-Oriented Concurrency Control
To avoid the phantom phenomenon with high concurrency, locking the subset of database which predicates specify is possible.
Predicate : occurring in the WHERE clause of an SQL SELECT, UPDATE, or DELETE statement.
Hyperplane (H):
H(C) = {μ∈dom(A1)ⅹ…ⅹdom(An)| μ satisfies C}

12. 8.2 Predicate-Oriented Concurrency Control
Example 8.2
<Predicates for Update Transaction of Example 8.1>
Ca: Department = ‘Service’ ∧ Position = ‘Manager’
Cb: Name=‘Smith’∧ Department=‘Service’∧ Position=‘Manager’∧Salary=40000
Cc: Department = ‘Service’∧ Position ≠ ‘Manager’
C’c: Department = ‘Sales’∧ Position ≠ ‘Manager’
Cd: Name=‘Stone’∧ Department=‘Service’∧ Position=‘Clerk’∧ Salary=13000
<Prdeicates for Retrieval Transaction>
Cq: Department = ‘Service’
Cp: Department = ‘Sales’
H(Ca)∩H(Cq)≠∅, H(Cb)∩H(Cq)≠∅, H(Cc)∩H(Cq)≠∅, H(Cd)∩H(Cq)≠∅
H(C’c) ∩H(Cq)=∅
H(Ca)∩H(Cp)=H(Cb)∩H(Cp)=H(Cc)∩H(Cp)=H(Cd)∩H(Cp)=∅
H(C’c)∩H(Cp)≠∅

13. 8.2 Predicate-Oriented Concurrency Control
Predicate locks on predicates Ct and Ct‘ on behalf of transactions t and t‘ in modes mt and mt‘ are compatible if
t = t‘ or
both mt and mt‘ are read (shared) mode or
H(Ct) ∩ H(Ct‘) = ∅
Testing whether H(Ct) ∩ H(Ct‘) = ∅ is NP-complete
For preventing the phantom problem it is sufficient that
queries lock predicates and
insert, update, and delete operations lock individual records, and
compatibility is checked by testing that an update-affected record does not satisfy any of the query predicate locks

14. 8.2 Predicate-Oriented Concurrency Control
Precision Locking
Avoids the statisfiability test.
The scheduler grants all lock requests right away without testing predicates.
When transaction reads or writes a tuple, it is tested for compatibility with all other outstanding predicates of other transactions.
There are no predicates associated with write operations.
Thus, it is handled as a predicated-oriented read followed by a discrete write of the qualifying tuples.
Example
DELETE FROM Emp
WHERE Department = ‘Toys’ And Position = ‘Clerk’
And
INSERT INTO Emp VALUES
(‘Johnson’, ‘Toys’, ‘Clerk’, 19000)

15. Index 8.1 Goals and Overview
8.2 Predicate-Oriented Concurrency Control
8.3 Relational Update Transactions
8.4 Exploiting Transaction-Program Knowledge
8.5 Lessons Learned

16. 8.3 Relational Update Transactions
There are three constituents of flat object model transactions.
Insertion (iR(C)) :
INSERT INTO R VALUES C
Effect is represented as
eff[iR(C)](r) := r∪{C}
Deletion (dR(C)) :
DELETE FROM R WHERE C
eff[dR(C)](r) := r – H(C)
Modification (mR(C1;C2)) :
UPDATE R SET C2 WHERE C1
Eff[mR(C1;C2)](r) := (r-H(C1))∪{mR(C1;C2)(μ)| μ∈H(C1)∩r}

17. 8.3 Relational Update Transactions
Definition 8.1 IDM Transaction
An IDM transaction over a database schema D is a finite sequence of Update operations over D.
If t=u1…um is an IDM transaction over a given database, the effect of t, written eff(t), is defined as
eff(t) := eff[u1] о eff[u2] о … о eff[um]
where о denotes function composition.
Definition 8.2 Transaction Equivalence
Two IDM transactions t and t’ over the same database schema are equivalent, written t ≈ t’, if eff(t) = eff(t’), i.e., if t and t’ have the same effect.
Equivalence of IDM transactions is decided in polynomial time.

18. 8.3 Relational Update Transactions
Commutativity Rules : Let C1, C2, C3, C4 be sets of conditions describing pairwise disjoint hyperplanes:
i(C1) i(C2) ≈ i(C2) i(C1)
d(C1) d(C2) ≈ d(C2) d(C1)
d(C1) i(C2) ≈ i(C2) d(C1) if C1 <> C2
m(C1; C2) m(C3; C4) ≈ m(C3; C4) m(C1; C2) if C3 <> C1, C2 and C1 <> C4
m(C1; C2) i(C3) ≈ i(C3) m(C1; C2) if C1 <> C3
m(C1; C2) d(C3) ≈ d(C3) m(C1; C2) if C3 <> C1, C2

19. 8.3 Relational Update Transactions
Simplification Rules : Let C1, C2, C3, be sets of conditions describing pairwise disjoint hyperplanes:
i(C1) i(C1) => i(C1)
d(C1) d(C1) => d(C1)
i(C1) d(C1) => d(C1)
d(C1) i(C1) => i(C1)
m(C1; C1) => ε
m(C1; C2) i(C2) => d(C1) i(C2)
i(C1) m(C1; C2) => m(C1; C2) i(C2)
m(C1; C2) d(C1) => m(C1; C2)
m(C1; C2) d(C2) => d(C1) d(C2)
d(C1) m(C1; C2) => d(C1)
m(C1; C2) m(C1; C3) => m(C1; C2) if C1 <> C2
m(C1; C2) m(C2; C3) => m(C1; C3) m(C2; C3)
These rules can be used for transaction optimization.

20. 8.3 Relational Update Transactions
Example 8.3
Let T = {t1, t2} with t1 = d(3)m(1;2)m(3;4) and t2 = d(3)m(2;3). Then
s = d2(3)d1(3)m1(1;2)m2(2;3)m1(3;4)
is a history for T.
With applying some simplification rules to s in order to obtain the following history:
s’ = d(3)m(1;4)m(2;4)m(3;4)
It is eff(s) = eff(s’), but it became hard to distinguish where it came from.

21. 8.3 Relational Update Transactions
Definition 8.3 Final State Serializability
A history s for a set T = { t1 , ... tn } of IDM transactions is final state serializable if s ≈ s‘ for some serial history s‘ for T.
Let FSRIDM denote the class of all final state serializable histories (for T).
Example 8.4
Consider again Example 8.3. It is s is not equivalent to t1t2, and t2t1. Thus, s is not FSRIDM.
However, by simplifying t1 ≈ t1’ = d(3)m(1;2), new history s’ becomes:
s’ = d2(3)d1(3)m1(1;2)m2(2;3) ≈ t1t2
Thus s’ is FSRIDM.
Theorem 8.1
The problem of testing whether a given history is in FSRIDM is NP complete.

22. 8.3 Relational Update Transactions
Definition 8.4 Conflict Serializability
A history s for a set T of n transactions is conflict serializable if the equivalence of s to a serial history can be proven using the commutativity rules alone.
Let CSRIDM denote the class of all conflict serializable histories (for T).
Definition 8.5 Conflict Graph
Let T be a set of IDM transactions and s a history for T. The conflict graph G(s) = (T, E) of s is defined by: (ti, tj) is in E if for transactions ti and tj in V, i <> j, there is an update u in ti and an update u‘ in tj s.t. u <s u‘ and uu‘ is not equivalent to u‘u (i.e., uu‘ ≈ u‘u does not hold).
Theorem 8.2:
Let s be a history for a set T of transactions. Then s is in CSRIDM iff G(s) is acyclic.

23. 8.3 Relational Update Transactions
Example 8.6
Let s = m2(1;2)m1(2;3)m2(3;2). Here G(s) is cyclic, so s is not CSRIDM. On the other hand, s ≈ m1(2;3)m2(1;2)m2(3;2), and hence s is FSRIDM.
It shows that CSRIDM is a strict subset of FSRIDM.

24. 8.3 Relational Update Transactions
Definition 8.6 Extended Conflict Graph / Serializability
Let s be a history for a set T = { t1 , ... tn } of transactions.
(i) The extended conflict graph EG(s) = (T, E) of s is defined by:
(ti, tj) is in E if there is an update u in tj s.t. s = s‘ u s‘‘ and u does not commute with the projection of s‘ onto ti.
(ii) s is extended conflict serializable if EG(s) is acyclic.
Let ECSRIDM denote the class of all extended conflict serializable histories.

25. 8.3 Relational Update Transactions
Example 8.7
Let s = d1(0) m1(0; 1) m2(1; 2) m1(2; 3).
Then, G(s) is cyclic, but s ≈ m2(1; 2) d1(0) m1(0; 1) m1(2; 3) ≈ t2 t1
(because d1(0), m1(0;1) does not have an effect).
Thus, s is ECSRIDM.
Example 8.8
Consider s = m1(0;1)m2(1;2)m1(2;3)d1(1)d1(3). Then s is not ECSRIDM, but FSRIDM.
Theorem 8.3
For every database schema, CSRIDM ⊂ ECSRIDM ⊂ FSRIDM.

26. Index 8.1 Goals and Overview
8.2 Predicate-Oriented Concurrency Control
8.3 Relational Update Transactions
8.4 Exploiting Transaction-Program Knowledge
8.5 Lessons Learned

27. 8.4 Exploiting Transaction-Program Knowledge
In spite of sophisticated interpretation of isolation, this section will preserve serializability.
Following example is about motivation.
Example 8.11
Bank allows customers to withdraw day from their accounts.
At night, an update transaction inspects each account, updates its balance, and then updates the corresponding branch total.
The update transaction will be of long duration.
Due to account accessibility through the Internet, the bank wants to move away from running the update transaction only at night.
In order to improve the service :
Replace the single large transaction with many small ones.
Each small transactions can be divided into two :
updating the customer’s account, and updating the corresponding branch total.

28. 8.4 Exploiting Transaction-Program Knowledge
Example 8.12
From the previous example, there should be three kinds of transactions.
Transaction that updates a single customer’s account and corresponding branch balance.
Transaction that reads customer’s account balance.
Transaction that compares grand total of all account balances with the sum of the branch balances.

29. 8.4 Exploiting Transaction-Program Knowledge
Assume that A1, A2, A3 belong to branch B1, and A4, A5 belong to B2. Let the transactions be as follow : <Updating customer’s account> t1 = r1(A1)w1(A1)r1(B1)w1(B1) t2 = r2(A3)w2(A3)r2(B1)w2(B1) t3 = r3(A4)w3(A4)r3(B2)w3(B2) <Reading customer’s balance> t4 = r4(A2) t5 = r5(A4) <Comparing the sum of customer’s and the sum of branch’s> t6 = r6(A1)r6(A2)r6(A3)r6(B1)r6(A4)r6(A5)r6(B2) Then, how do we chop down those long transactions?

30. 8.4 Exploiting Transaction-Program Knowledge
Assumption :
all potentially concurrent app programs are known in advance and their structure and resulting access patterns can be precisely analyzed
Definition 8.8 Transaction Chopping
A chopping of transaction ti is a decomposition of ti into pieces ti1, ..., tik s.t. every step of ti is contained in exactly one piece and the step order is preserved.
Definition 8.9 Chopping Graph
Let T be a given set of transactions, and let a chopping of the transactions in T be given.
A chopping graph C(T) is an undirected graph such that :
The nodes of C(T) are the transaction pieces occurring in the chopping.
Let p, q be pieces from two different transactions. If p and q contain operations that are in conflict, C(T) contains an undirected edge between p and q labeled with a c (for “conflict”).
If p and p’ are pieces from the same transaction, C(T) contains an undirected edge between p and p’
labeled with an s (for “sibling”).

31. 8.4 Exploiting Transaction-Program Knowledge
Example 8.13
Consider the following three transactions :
t1 = r1(x)w1(x)r1(y)w1(y)
t2 = r2(x)w2(x)
t3 = r3(y)w3(y)
If t1 is divided into t11 and t12, then
t11 = r11(x)w11(x)
t12 = r12(y)w12(y)
The corresponding chopping graph has no cycle.
Definition 8.10 Correct Chopping
A chopping of T={t1, ..., tn} is correct if every execution of the transaction pieces is conflict-equivalent to a serial history of T under a protocol with
Rule1 : Transaction pieces obey the execution precedence of the original programs.
Rule2 : Each piece is executed as a unit under a CSR scheduler.

32. 8.4 Exploiting Transaction-Program Knowledge
Theorem 8.5
A chopping is correct it f the associated chopping graph does not contain an sc cycle.

33. 8.4 Exploiting Transaction-Program Knowledge
Example 8.14
From the Example 8.12, we made transactions :
t1 = r1(A1)w1(A1)r1(B1)w1(B1)
t2 = r2(A3)w2(A3)r2(B1)w2(B1)
t3 = r3(A4)w3(A4)r3(B2)w3(B2)
t4 = r4(A2)
t5 = r5(A4)
t6 = r6(A1)r6(A2)r6(A3)r6(B1)r6(A4)r6(A5)r6(B2)
We can chop t1 and t6 into :
t61 = r61(A1)r61(A2)r61(A3)r61(B1)
t62 = r62(A4)r62(A5)r62(B2)
Its chopping graph is acyclic. Thus chopping is correct. If we additionally chop down t1, then :
t11 = r11(A1)w11(A1)
t12 = r12(B1)w12(B1)
Its chopping graph has sc cycle. Thus chopping is incorrect.
t12 t3
t61
t62 c s t2 t5 t4
t11

34. 8.4 Exploiting Transaction-Program Knowledge
Directly applicable to straight-line, parameter-less SQL programs with predicate locking.
If there exists parameter, if-then-else and loops, conservatively (about c edges) derive covering program.
Example:
Select AccountNo From Accounts
Where AccountType=‘savings‘ And City = :x;
if not found then
Where AccountType=‘checking‘ And City = :x
fi;
Following can be derived from the above.
Where AccountType=‘savings‘;
Where AccountType=‘checking‘;

35. Index 8.1 Goals and Overview
8.2 Predicate-Oriented Concurrency Control
8.3 Relational Update Transactions
8.4 Exploiting Transaction-Program Knowledge
8.5 Lessons Learned

36. 8.5 Lessons Learned
Predicate locking is an elegant method for concurrency control on relational databases, but has non-negligible overhead.
→ Record locking (plus index key locking) for 2-level schedules remains the practical method of choice.
• Concurrency control may exploit additional knowledge about limited operation types, integrity constraints, and program structure.
• Transaction chopping is an interesting tuning technique that aims to exploit such knowledge