MDAS

1
MDAS

• Concurrency control
• in MDAS (mobile data source)
• By Alan (Xing) Gao
• Advised by Prof. Ali R. Hurson
• March 14th 2002

2
MDAS

• Topic covered today.
• Background brief.
• SSM
• Concurrency control
• Global/local system
• Issues that I am working on.

3
I Background brief. (1)

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

4
I Background brief. MDBS(2)

• Multi-database
• From individual databases to a sharing system to
  improve the overall performance.
• Connect the islands of information with bridges
  and a global control center.
• Key integration.

5
I Background brief. MDBS(3)

• MDBS
• provides a transparent and efficient mapping of
  local to global data representation and a mapping
  of the user requests to the local system's access
  terms.

6
I Background brief. DDBS(4)

• 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.
• Key distribution.

7
I Background brief. MDBS(5)

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

8
I Background brief. MDBS(6)

• Local autonomy
• Local control over resources and data.
• As few restrictions to local Database as
  possible.
• In multi-database
• Not in distributed database
• Key distinction between the two systems.

9
I Background brief. MDBS(7)
Global Transactions
Global MDBMS Manager
Global Sub-transaction

Local DBMS 1
Local DBMS 2
Local DBMS 3
Local DBMS m
Local Transactions
Local Transactions
Local Transactions
Local Transactions
10
I Background brief. MDAS(8)

• MDAS
• Shared issues between MDBMS
•       
• Site autonomy
• Heterogeneous interoperability
•  Transaction management and concurrency control

11
I Background brief. MDAS(9)

• New environment
• Wireless communication
• Mobility
• Portability

12
I Background brief. MDAS(10)

• New challenges. -- Wireless communication
• Limited bandwidth
• Disconnection
• high bandwidth variability

13
I Background brief. MDAS(11)

• New challenges.
• -- Mobility (move while keeping connected.)
• New protocol and interface
• Location dependency
• Distribution transparency
• Security

14
I Background brief. MDAS(12)

• New challenges. -- Portability
• Low power
• Limited User Interface
• Limited Storage capacity

15
I Background brief. MDAS(13)

• Other issues involved
• Query Processing and Optimization
• Impression, energy, cost.
• Transaction Processing
• Disconnection tolerance.
• Local autonomy during disconnection.
• Transaction Failure and Recovery

16
I Background brief. MDAS(14)

• As the focus, more words are on the concurrency
  control
• Road map
• SSM
• Concurrency control.
• Global/local systems, previous vs new.
• Protocols that I am working on.

17
II Summary Scheme Model (1)

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

18
II Summary Scheme Model (2)

• 3 links in the system corresponding to
• terms of semantic distance relations.
• Synonym similar (or same) definition.
• Hyponym more precise definition
• Hypernym more comprehensive, general
• definition
• Hypernym and hyponym links are used between
  parent and child nodes in SSM structure.

19
II Summary Scheme Model (3)

• Benefits of SSM
• Less memory requirement than global scheme.
• Global access to data with imprecise knowledge
  of local access term.

20
II Summary Scheme Model (4)

• More words on handling the imprecise query
  resolution later on.
• Search/check the synonym of an access term.
• If no match, search the hypernym of the term.
• If match, reduce the semantic distance and
• search for the hyponym of the tem.

21
II Summary Scheme Model (5)

• Clustering
• Logical vs Physical
• We cluster the nodes based on the logical
  relation.
• No change is on the SSM if the data sources are
  mobile.

22
II Summary Scheme Model (6)
23
II Summary Scheme Model (7)

• SSM maintaining.
• SSM nodes are logically separated from DB nodes.
  
• SSM nodes and local DBs on same host.
• SSM nodes on one host.

24
II Summary Scheme Model (8)

• SSM maintaining. (Cont.)
• Required when add/remove leaf nodes, or change
  the scheme of any nodes.
• Adding a new leaf.
• Changes on its ancestor up to the SSM ancestor
  node that
• already has the hypernym.
• Deleting a leaf nodes
• Ancestors delete hypernyms up to the point where
  the hypernym represents a term from another lower
  schema, as well as the deleted term

25
II Summary Scheme Model (9)

• SSM maintaining. (Cont.)
• Address the disconnection with mobile data
  source
• Maintain a log in mobile database
• Keep a queue in the mobile DB for global
  requests
• Queue the global queries in the first-level
  internal SSM that covers the mobile DB.

26
III Concurrency Control (1)

• Transaction with ACID.
• Atomicity
• Consistency.
• Isolation.
• Durability.

27
III Concurrency Control (2)

• Challenges
• Interference between transactions.
• Lost update A Rc, Wc B Wc, Rc
• A_Rc -gt B_Wc -gt A_Wc -gt B_Rc
• Dirty read A Wc, Wc B Rc, Wc
• A_Wc -gt B_Rc -gt A_Wc -gt B_Wc
• Unrepeatable read ARc, Wc B Rc, Rc
• A_Rc -gt B_Rc -gt A_Wc -gt B-gtRc

28
III Concurrency Control (2)

• Conflict between two operations.
• Access the same shared data and one is write
  operation.
• Direct conflict
• Ti ? Tj
• Indirect conflict
• Ti - -gt Tj if
• Ti?T1?T2??Tn?Tj

29
III Concurrency Control (3)

• If the 3 cases are prevented, we can interleave
  the transactions in any manner.
• Transaction serializability if we ensure the
  transactions are conflict-free.
• Methods in MDBS
• Forced conflicts under full autonomy (ticket)
• Potential conflict graph (cycle - ? conflict)
• Locking 2PC, site graph

30
III Concurrency Control (4)

• Transaction management in MDAS.
• MDSTPM (Multi DBMS)
• (Multi-database Transaction Processing Manager)
  
• Kangaroo Transaction model ( DDBMS)
• V-lock algorithm (global lock table SSM)

31
III Concurrency Control (5)

• V-lock.
• Global lock table creates a global
  wait-for-graph.
• SSM is used to distribute the communication so
  that GLT
• is feasible.
• Dynamically adjusts (the frequency of
  acknowledgement) to changing communication
  requirements.

32
III Concurrency Control (6)

• V-lock
• Acknowledgement
• chosen based upon the available bandwidth
• Each operation.
• Write operation only.
• Commit or abort only.

33
III Concurrency Control (7)

• Cycle/deadlock detection in global
  wait-for-graph.
• For each cycle detected in the global lock table
• If all involved in cycle are exact data items
  AND acknowledged
• Choose victim and break deadlock
• Else If time_elapsed gt imprecise_data_time for
  all transactions
• in cycle AND All are acknowledged
• Choose victim and break deadlock
• Else time_elapse gt ACK_time for all
  non-acknowledged
• transactions in cycle
• Choose victim and break deadlock.
• End repeat.

34
III Concurrency Control (8)

• Extended algorithm.
• Give a longer Pcg_time, to avoid false deadlock.
• Repeat every chktime threshold
• Check for cycles in implied wait-for-graph
• /depth first search (DFS) used for cycle
  detection/
• For each cycle detected
• If time_elapsed gt pcg_time fro all transactions
  in cycle
• /victim is chosen based on progress/
• Choose victim and break deadlock.
• Else
• Continue to wait.

35
VI MDAS system (1)

• The MDAS system (V-lock and SSM)
• The local system
• The global system
• Flow of operations in the MU(mobile unit)
• The cache invalidation in MU
• The invalidation for the replicated data
• mobile database and the fixed network.

36
VI (2) Local system
37
VI (3) Global system
38
VI (4) Operations at MU
39
VI MDAS with mobile data source.

• New challenges.
• New disconnection
• New handoff.
• Overlap of BS(base station) cells.
• Locating the BS.
• Weak connection among BSs

40
VI (5)Global system new.
41
VI (6) Operations at MU new.
42
VI (7) Query resolution.

• If the hypernym in a SSM node with a
  hyponym link to the mobile DB which is
  disconnected from the fixed network.
• Message to user/DBA
• Data is temporarily inaccessible! Do you want
  to queue your query? 
•   If some exact matches is inaccessible in
  mobile DB (with Query Refinement Facilities)
• Message to user/DBA
• Some data is temporarily inaccessible! Do you
  want to queue your query?

43
VI (8) Query resolution on Mobile DB.

• Local query ? Execute the query locally.
• Global query
• If read only has all local copy connected
  ?submit
• If read only has all local copy
  disconnected
• ? Data may not be the latest! Execute
  locally.
• If read only miss local copy connected
• ? Some data is temporarily inaccessible! Do
• you want to queue the request ? 
• If yes ?Queue the requested If no ?Cancel
  the request.
• If write connected ? Submit the query to the
  ready queue.
• If write disconnected
• ? Data is not accessible temporarily! Do you
  want to
• queue the query?
• If yes ?Queue the request If no?Cancel
  the request.

44
VI (9) Query resolution on fixed DB.

• Local query ? Execute the query locally.
• Global query
• If no mobile database involved
  ? Submit the global query.
• If mobile DB read only has all
  local copy connected
• ? Send to global system with parity signature
• If mobile DB read only has all local copy
  disconnected ? Data may not be the
  latest! Execute the query.
• If mobile DB read only miss local copy
  connected  
• ? Submit the request to ready queue
• If mobile DB read only miss
  local copy connected  
• ? Some data is temporarily inaccessible! Queue
  the request?
• If yes ? Queue the requested to buffer If
  no ? Cancel the request.
• If write connected ? Submit the
  query to the ready queue.
• If write disconnected ?Data is
  not accessible temporarily! Queue the query?
• If yes ? Queue the request to the buffer.
  If no ? Cancel the request.

45
VI (10) imprecise query resolution

• Step 1) At query origin node parse query
• If all data references are precise THEN go to
  step 4)
• ELSE send query to next higher node in system
  hierarchy
• /Not all data references are precise/
• Step 2) At next higher node For each imprecise
  data reference DO
• Calculate SDM using imprecise data reference and
  local
• summary schema as inputs
• If any local term is within semantic distance
  Then
• Send message down the hierarchy to see if
  corresponding access
• terms from leaf node schema are within the
  semantic distance
• If so Then replace imprecise with precise
  reference
• ELSE reference is still imprecise
• /No terms in the lead node is within the SDM
  /

46
VI (11) imprecise query resolution

• Step 3) If all data references are precise THEN
  go to Step 4)
• ELSE IF this is the top level in the hierarchy
  THEN
• Reject the query because no data in the system
  within the specified semantic distance
• ELSE send query to next higher level node and
  continue with Step 2)
• Step 4) all data references are precise, so
  execute query with standard multi-database
  language facilities

47
V Issues that I am working on.

• Data Replication BUNQ AQ2
• Replication Invalidation Sequence at mobile
  Database
• Replication invalidation Sequence at Fixed
  Network
• Focus in after this semester
• Build up a simulation environment for later
  experiment