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

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

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.

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.

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

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.

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.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)

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.

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.

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}

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)≠∅

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

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)

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

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}

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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?

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”).

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.

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.

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

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‘;

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

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