Concurrency control

1

• Concurrency control
• and Deadlock Handling
• in MDAS with SSM structure
• By Alan (Xing) Gao
• Directed by Prof. Ali. R. Hurson
• Apr. 14, 2003

2
I-1 Background brief.

• Traditional Database System.
• ? Multi-database System
• ? Distributed Database system
• ? Mobile Database System

3
I-2 Background brief. MDBS

• Multi-database
• Integrate individual databases to form a sharing
  system to improve the overall performance.

4
I-3 Background brief. MDBS

• MDBS (or MDBMS)
• provides a transparent and efficient mapping of
  local data representation to global system, and a
  mapping of the users global requests to the
  access terms in the local database.

5
I-4 Background brief. DDBS

• Distributed Database
• Given a collection of data, distribute the
  data into local databases so that the data is
  close to its user, and then improve the overall
  performance.

6
I-5 Background brief. MDBS

• Issues in Multi-database
•  
• Local site autonomy
• Heterogeneous data access
• Query resolution
• Transaction management
• Concurrency control
• Intelligent search and browsing of data.

7
I-6 Background brief. MDBS
Global Transactions
Global MDBS Manager
Global Sub-transaction

Local DBMS 1
Local DBMS 2
Local DBMS 3
Local DBMS m
Local Transactions
Local Transactions
Local Transactions
Local Transactions
8
II-1 MDAS with SSM structure

• Bottleneck.
• Centralized manager is the bottleneck in the
  MDBS.
• SSM
• In order to distribute the workload of the
  central manage, we employ the SSM(Summary Schema
  Model).

9
II-2 MDAS with SSM structure

• SSM
• Hierarchical structure that provides
  incrementally concise view of data.
• An efficient way to access data in a
  heterogeneous multi-database, and in a mobile
  database system.

10
II-3 MDAS SSM hierarchy
11
II-3 MDAS SSM nodes

• SSM node contains the exact data or abstraction
  of the data contained in its children nodes.
• The higher an SSN node is, the more general
  the data entry it contains.
• Less memory requirement than global scheme.
• Global access with imprecise knowledge of local
  access term.

12
II-4 MDAS Global Transaction

• Global transaction
• Transaction that involves more than one
  databases.
• The user may submit the global transaction to
  any
• node within the SSM hierarchy root SSM node,
  internal
• SSM node, or DB nodes.
• MDAS automatically resolves the transaction and
  find
• the coordinator node to manage the transaction.
• Coordinator node
• The lowest level SSM node that semantically
  covers
• all required the data in the global transaction.

13
II-5 MDAS Global Sub Transaction

• Execution
• 1. Maps the global transaction into a set of sub
  transaction, one for each DB involved.
• 2. Get the global locks for the sub transactions
  then submit it to DB. (May go through other SSM
  nodes.)
• 3. Wait for reply from each DB. (Two Phase
  Commit.)
• 4a. If all DB can commit, the commit globally
• 4b. If any DB aborts the sub transaction, the
  coordinator will abort the whole transaction.

14
III-1 Concurrency Control

• Why concurrency control is needed?

15
III-2 Concurrency

• Concurrency Control
• Very low concurrency degree results in a low
  throughput.
• Very high concurrency degree leads to more
  network traffic, longer waiting queue, longer
  response time, lower completion rate, and lower
  throughput.
• Adjust the concurrency degree and maximize the
  overall performance, in terms of throughput,
  response time, completion rate.

16
III-3 Concurrency issues

• Deadlock handling
• Abort/restart
• Concurrency adjustion.
• and more

17
III-4 Concurrency Locking table

• Global locking table in SSM
• Each SSM node maintains a global locking table
  for all data items it covers.
• Each locking entry corresponds to the exact data
  item or its hypernym. I.e. multiple data items at
  local database may share the same locking entry
  at a high level SSM node.
• An SSM node needs to get locks for a sub
  transaction from its lock table before it submits
  it to DB or low level SSM nodes.

18
III-5 Concurrency Example

• Example Local database has 40 data items, but
  there are only 4 locking entries at the SSM node
  covering the DB.
• Locking table at SSM
• Locking table at local DB

19
III-7 Concurrency Acquiring locks

• Submit a sub transaction
• From the coordinator node to the local database
  node.
• All SSM nodes on the path need to do
• 1.Gets global locks (at this level) for the sub
  transaction.
• 2. Keeps track of Acknowledgement received
  later.
• 3. Checks possible deadlock and breaks it if
  any, after the sub transaction is timed out after
  a threshold.

20
III-8 Deadlock - With direct conflict

• Trans 1 Trans 2
• ST10 (1) ST20 (3, 4)
• ST11 (22,26) ST21 (23, 25)
• ST10 ?ST20 while ST21?ST11. Deadlock!
• T1 or T2 aborts!
• ST10 ST20
• ST21 ST11

21
III-9 Deadlock with indirect conflict

• SSM locking table is not enough to detect a
  deadlock with the indirect conflict.
• Trans 1 Trans 2 ST10
• ST10(1) ST20(13, 14) ST20
• ST11(22,26) ST21(32, 35) ST11
• ST12
• St10 Lt1 Lt2 St11
• Lt1 St20 St21 Lt2
• ST10 ?Local Trans 1?ST20 at DB1 (data 019)
• ST21?Local Trans 2 ? ST11 at DB2 (data 2039)

22
III-10 Concurrency - ACKs

• Acknowledgements from DBs.
• Due to the local site autonomy, the SSM node has
  no control on the locking table within local DBs.
  
• The only information available is whether the
  lock
• request for an operation is granted or not.
• The sub transaction will send ACKs back to SSM
  modes.
• Lock_ack if get the desired lock.
• Block_ack if blocked for a threshold.

23
III-11 Concurrency SSMs record

• Update SSMs record for this subtransaction.
• SSM node keeps track of each operations.
• Ack acked or pending
• Status lock, block, or unknown.
• Meanwhile we update the locking status for the
  sub-transaction as a whole
• None_acquired, Partially_acquired, or
  All_acquired.

24
III-12 Concurrency - Wait-For-Graph

• Each SSM node maintains a wait-for-graph showing
  the potential indirect conflict of sub
  transaction on a DB.
• Waiter sub_trans? DBi-1 ? holder sub_trans
• Waiter sub_trans? DBi ? holder sub_trans
• Waiter sub_trans? Dbi1 ? holder sub_trans
• Waiter if a sub transaction waits for more local
  locks.
• Holder if a sub transaction holds any local
  locks.
• Possible for a sub trans be both a holder and
  waiter to a DB.
• False abort

25
III-13 Concurrency - False abort

• A cycle between transaction in the wait-for graph
  may not necessary be a deadlock.
• So some cycle will be mistaken as a deadlock and
  it leads to false abort.
• T1 ST10 10, 11 ST11 25, 26
• T2 ST20 13, 14 ST21 21,22
• ST10 ST20
• ST21 ST11
• Cycle but not deadlock.

26
III-14 Concurrency - False abort

• Solution wait for a long time before break a
  cycle.
• (X) Can not break the real deadlock in time.
• Reduce false abort, choose a reasonable threshold
  .
• If all sub transactions involved in a cycle has
  acked as being LOCKed or BLOCKed. We treat it as
  a deadlock and break it.
• If some sub transaction in the cycle has not
  acked back, wait for a longer time before break
  it.

27
III-15 Concurrency - Trade off

• More acks, more accurate, and less false
  deadlock.
• More acks, more bandwidth requirement, and more
  traffic brought to the network.

28
IV-1 Simulation.

• Global system.
• Local DB system.

29
IV-2 Simulation - Global system
30
IV-3 Simulation - Local system
31
IV-4 Simulation parameters

• Global system parameters.
• 10 local databases
• 100 data record per local database
• Up to 8 operations in a transaction.
• CPU process time for each op 0.005 sec
• IO time for each op 0.010 sec.
• Two messages for each operation
• Comm time fore each message 0.100 sec

32
IV-5 Simulation parameters

• Local Database parameters.
• At most 5 local/sub transactions at a time.
• Up to 8 operations in a transaction.
• CPU process time for each op 0.005 sec
• IO time for each op 0.010 sec.
• Two messages for each operation
• Comm time fore each message 0.100 sec

33
IV-6 Simulation result

• Completion rate

34
IV-7 Simulation result

• Global throughput

35
IV-8 Simulation result

• Response Time

36
IV-9 Simulation result

• CPU utilization at local DB.

37
IV-9 Simulation result

• IO utilization at local DB.

38
IV-9 Simulation result

• Communication utilization at local DB.

39
IV-9 Simulation effect of parameters

• System parameters have much stronger effects on
  the performance then the local parameters.
• Concurrency_degree of global transactions in
  parallel.
• Deadlock_threshold Length of cycle before we
  break it.
• Trans_timeout Patience a user has for a
  transaction.
• subtrans_timeout
• Lock_timeout

40
V Future work

• 1. Analyze the effect of parameters
• 2. Consider the disconnection ratio.
• 3. Handling of burst transaction request.
• 4. Duplicate of data for mobile databases.