1. Transactions – T4.3 Title: Concurrency Control Performance Modeling: Alternatives and Implications Authors: R. Agarwal, M. J. Carey, M. Livny ACM TODS, 12(4), 1987

2. Outline Problem –Problem Statement –Why is this problem important? –Why is this problem hard? Approaches –Approach description, key concepts –Contributions (novelty, improved) –Assumptions

3. Problem Statement Given –Alternative Concurrency Control Algorithms (CCAs) –Transaction Processing Systems Find –Relative performance of CCAs, e.g. dominance zones Objective –Compare CCAs on throughput, response time Constraints –Transaction conflicts –Database system’s resources, models of transaction restarts –Amount of information about transaction reference strings

4. Why is this problem important? –Applications: Transaction Processing – online, batch Airline reservation system Banking ATM E-commerce Why is this problem hard? –CCA performance depends on many issues Workload – degree of conflict among transactions Resources, e.g. CPUs, I/O architecture –Seemingly contradictory results in prior work, p. 610 para 2 Blocking vs. restarts - [2, 15] vs. [6, 50, 51] Locks vs. optimistic – [20] vs. [2, 15]

5. Key Concepts - CCAs BlockingLocks – read lock, write lock Block a transaction if lock request is denied Deadlock detection and resolution – wait-for graphs Ex. – Dynamic two-phase locking Immediate Restart Locks – read lock, write lock Abort and restart a transaction if lock request is denied Restart delay = O(expected transaction response time) OptimisticValidate only after commit point Restart transaction if validation fails, e.g. if a transaction read an object written by another transaction committed during its lifetime

6. Key Concepts – Queueing Model

7. Experiment Design - Parameters

8. Contributions – Experimental Results 1. Infinite Resources –Optimistic >> Blocking Blocking thrashes (Fig. 5) as multi-programming increases increase in number of times a transaction blocks –Standard deviation (response time) less for Blocking (Fig. 7) Lock waiting time << Restart time 2. Resource-Limited Situation (1 CPU, 2 Disks) –All exhibit thrashing (Fig. 8) as multi-programming increases Disk is the bottleneck (Fig. 9) –Blocking CCA has highest throughput (Fig. 8) And lowest mean response time (Fig. 10) 3. Multiple (5 – 50) Resources –5 – 10 resources – behavior similar to resource limited –25 resources – Optimistic has max. throughput (Fig. 18, 19) Disk utilization is better for optimistic (80%) than Blocking (35%) –50 resources – similar to infinite resources

9. Contributions – Experimental Results 4. Interactive Workloads – read; think; write –Large think time => low resource contention –Optimistic >> Blocking –Behavior similar to infinite resources Summary Conclusions Based on Resources –Resource Level Medium to High resource utilization – Blocking (2PL) is better Low utilization – Restart methods are better –Control Multi-programming level To avoid thrashing

10. Validation Methodology –Simulation using a queueing model of transaction processing –A large number of parameters –Characterize dominance zones Validation of Simulation Results –Physical justification of queueing model –Experimental results Comparison with previous work Explanation including alternative causes –Further experiments to identify causes

11. Assumptions Queueing model is a accurate model of OLTP systems Parameter Choices –CCAs Write locks are acquired only after read locks (promotion) –Parameters

12. Rewrite today Update with current benchmarks, e.g. TPC –Parameter values – e.g. reflect current database sizes –Throughput  TPS including response time constraint –Candidates  Newer locking protocols, e.g. granularity –Transactions  Use DebitCredit, TPC-A, TPC-C, … –Queueing model  Complete OLTP systems Consider Alternatives –Analytical solutions –Trace driven workload characterization and simulation See page 79 of A. Thomasian, Concurrency control: methods, performance, and analysis, ACM Computing Surveys, March 1998.A. Thomasian, Concurrency control: methods, performance, and analysis, ACM Computing Surveys, March 1998.