Transactions%20

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 systems 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

Blocking Locks 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)
Optimistic Validate 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 gtgt 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 ltlt 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 gt low resource contention
• Optimistic gtgt 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.