Concurrency Control in Mobile Database Systems

1
Concurrency Control in Mobile Database Systems

• Indrakshi Ray
• Computer Science
• Colorado State University
• iray_at_cs.colostate.edu

2
Outline of the talk

• Introduction to mobile environment
• Problems of using traditional concurrency control
  mechanism (CCM) in mobile environments
• Our concurrency control mechanism
• Performance analysis
• Conclusion

3
Mobile Database system(MDS)

• MDS is built on PCS or on GSM platform
• Database servers (DBS) manage all transactional
  and database activities.
• Broadcast server continuously broadcasts data
  from the database.
• Broadcast server is present in the base station
  (BS)
• Each BS has a communication region which is
  referred to as cell (Cn)
• BS can communicate with a mobile unit (MU) as
  long as it is in its cell.

4
Limitations of Mobile environment

• Asymmetric communication
• Low uplink bandwidth
• High downlink bandwidth
• Disconnections from the network
• Mobile units have
• Low processing power
• Limited battery power

5
Traditional concurrency control schemes in MDS

• Traditional schemes such as 2PL
• Use serializability as the correctness criteria
• Maintain high degree of consistency
• Does not use any semantic information
• Problems with traditional scheme
• Requires excessive uplink communication
• Introduces resource blocking due to
  disconnections
• Causes large number of transaction aborts
• Is resource intensive

6
Requirement for CCM in MDS

• Avoid excessive communication to the server on
  low bandwidth uplink channel
• We use broadcast feature of mobile environment
• Allow bounded inconsistency in data
• We use epsilon serializability
• Accommodate frequent disconnection
• We use timeout based approach

7
Data Broadcasting- Introduction

• Data broadcast
• Satisfies multiple requests for the same data
  item at once
• Leads to efficient bandwidth utilization
• Broadcast tick
• Time taken to broadcast a data item

8
Data Broadcasting- Introduction

• Broadcast cycle
• Every data item in the database is broadcasted at
  least once in a broadcast cycle
• We assume that every data item is broadcast
  exactly once in a broadcast cycle
• Broadcast period (T)
• Time taken by the broadcast cycle
• Every data item is repeatedly broadcasted after
  an interval T.

9
Epsilon serializability (ESR)

• We use ESR which tolerates a limited amount of
  inconsistency specified by e (epsilon).
• When e?0, ESR reduces to conventional
  serializability.
• ESR requires database state space to be metric
• Many practical applications with different
  semantics such as bank accounts, seats in airline
  reservation are examples of metric state space.
• The CCM that we propose can also be applied on
  fragmentable, reorderable objects which include
  aggregate item, such as, sets, queues, and
  stacks.

10
Epsilon serializability (ESR)

• ESR is an abstract framework
• An instance of ESR is defined by concrete
  specification of tolerated inconsistency.
• Divergence control methods guarantee ESR the same
  way as concurrency control guarantee SR.
• Our CCM is a divergence control method to
  maintain ESR.

11
Two-Tier transaction model

• We use two-tier transaction model
• It contains two type of transactions
• Tentative transactions
• They are run on the mobile node,
• They make tentative updates on the local copy of
  the data
• Base transactions
• Base transactions are run on the server in wired
  network
• Committed tentative transactions are transformed
  to corresponding base transactions and
  re-executed at the servers.

12
Two-Tier transaction model

• Problem with two-tier model
• MU executes the transactions without the
  knowledge of what other transactions are doing.
• This can lead to a large number of rejected
  transactions
• Commit time of transactions that are committed at
  MU is very large
• Transaction knows its outcome (that is, committed
  or rejected) only after the base transaction has
  been executed and the result is reported back to
  the MU.
• We overcome these problems in our mechanism.

13
Our Scheme-notations

• D Di, data object Di ? S,S is a metric space.
  
• di be the current value of the data object Di.
• The data objects are replicated on the MUs
• ni be the number of replicas of Di in MDS.
• ?i denotes the total maximum change allowed in
  the each replica of the data object Di on the MU.
• T is the broadcast period.

14
Algorithm at DBS Initial steps

• ?i is calculated using the function ?i fi (di,
  ni)
• fi (di, ni) depends on the application semantics
• Timeout value ? is associated with ?i
• ? I X T where I is an integer
• Server broadcasts (di, ?i,?) for each data object

15
Algorithm at MU

• For every Di , MU stores tuple (di,?i, ?i-c,?)
• ?i-c is keeps a record of the total change in the
  data object Di since the last broadcast of value
  ?i.
• The tuple is refreshed when MU receives new
  values of the tuple broadcasted by the server.

16
Algorithm at MU

• MU executes the transaction ti.
• ?i-ti be the change made by ti on data item Di .
• Case 1 ?i-ti lt ?i and ?i-c lt ?i
• ti is committed at MU and it is sent to the
  server for re-execution as a base transaction on
  the master copy.
• We refer to ti as precommitted transaction.
• Case 2 ?i-ti lt ?i and ?i-c gt ?i
• transaction ti is blocked at MU until new set of
  (di, ?i) is broadcasted by the server.
• Case 3 ?i-ti gt ?i
• ti is blocked at MU and submitted to the server
  as a request transaction.

17
Algorithm at DBS

• Server receives two types of transaction
• pre-committed transactions transactions which
  have made updates to the replicas on the MU and
  committed
• request transactions transactions which are
  directly sent to the DBS by the MU.
• Execution of transaction
• Pre-committed transactions
• Are executed immediately
• Serialized on the master copy in the order of
  their arrival on the DBS.
• Request transactions
• Are executed after the timeout ? for the data
  item expires,
• Reports to the MU whether the transaction was
  committed or aborted

18
Example

• Consider a data object X representing total
  number of movie tickets.
• X belongs to the metric state space.
• Let Nx be the number of replicas of X.
• Initially X 180 and Nx 3.
• X is replicated at MU1, MU2 and MU3. In this
  example the
• ?x fx (X, Nx) (X/2)/Nx X/2Nx 30.

19
Example
20
Performance study

• Simulation Parameters

21
Experiment Effect of transaction inter-arrival
time

• As mean inter arrival time of the transactions
  increase
• less number of transactions arrive in a given
  broadcast period.
• change in the delta value of the data item will
  be less
• More transactions will be pre committed, as the
  delta values of data item will not cross the
  limit ? assigned to the MU in the broadcast
  period.
• number of pre-committed transactions increase and
  request transactions decrease.

22
Experiment Effect of Broadcast rate

• As broadcast rate increases
• Period T of the broadcast cycle decreases.
• ? for each data item are refreshed at periodic
  interval of time T.
• ? for each data item are refreshed faster as T
  decreases
• Hence the chances of ? getting expired reduce and
  number of request transactions decrease.

23
Experiment Effect of MPL

• Observations
• After a certain MPL value (range 10-30) the
  number of request transactions remain constant. (
  that is higher MPL has no effect on the request
  transaction)
• That MPL value differs for every transaction
  inter arrival rate (iatm) and it depends on the
  period (T) of the Broadcast cycle.
• MPL is given by following equation MPL?T/iatm.

24
Experiment Effect of Disconnections

• As number of disconnection increases
• the MU will have more number of stale data items
  in the cache as MU cannot read from the broadcast
  
• timeout of ? value of the data items will be
  expired.
• transactions at the MU cannot update those data
  items whose timeouts have been expired and have
  to wait till the next broadcast cycle.
• Hence number of request transactions increase
  with increase in number of disconnections and
  also increase with increase in the disconnection
  duration.

25
Experiment Commit time of transactions

• Commit time of both Precommit and Request
  transaction decreases with increase in IATM
• At lower IATM,
• ? of data items expired faster and the
  transactions have to wait till new ? values are
  allocated in the next broadcast cycle. Hence
  commit time for precommit transaction is more at
  lower inter arrival time.
• number of request transactions are more, the load
  on the server increases and hence commit time of
  request transaction is also more as compared to
  at higher inter arrival time

26
Conclusion

• Mobile Database System cannot use traditional
  concurrency control mechanisms
• Our mechanism requires
• low bandwidth
• ensures availability
• accommodates disconnection problem
• is scalable.
• We studied the effects of factors on the
  performance of our concurrency control mechanism