1. Transaction Processing in Mobile Distributed Databases Sherida Jacob CSC 536 5/2/2005

2. Distributed Database • Client/Server type controlled by a central DBMS • Portions of the DB stored on multiple computers • Users can access data without interfering with each other • DBMS operates like there is only one computer

3. Mobile Distributed Database DDB used by wireless devices Focus is on location awareness as opposed to transparency Ex. Requesting a bus timetable from a laptop and having the result sent to your mobile phone via text message

4. Mobile Computing Environment WiredNetwork

5. Data Transmission Problems in a MC Environment • Battery power • Low bandwidth • Frequent disconnects – topology changes • Limited storage space • Location dependency – result changes as you move

6. Transaction Characteristics in a MC Environment • An interaction that can access or change the DB • Longer processing times • Execute on heterogeneous networks • Can execute when not connected to network

7. Transaction Characteristics in a MC environment cont’d • Do not strictly adhere to ACID rules • Atomicity – transactions are split up • Consistency – questionable atomicity and durability • Isolation – application specific • Durability – too many disconnections

8. Transaction Processing Problems • Deadlock detection – impedes, costly • Disconnections – identify fault tolerance levels • Recovery – isolation rule is relaxed, recovery may not be possible • Replication – costly, method needed • Validation – impedes, costly

9. Transaction Processing Problems cont’d • Concurrency – ability to handle multiple transactions • Security – use encrypting algorithms and data logs • Fragmentation – how and where

10. Transaction Management Models • No consensus on how to execute a mobile transaction • Many models to resolve some of the issues

11. Kangaroo Transaction Model • A kangaroo transaction is a global transaction • KT’s are split into Joey transactions • JT’s are executed independently at MSS’s • JT’s split as the MH moves to new cells

12. Kangaroo Model cont’d • Execution status and recovery info for the uncommitted transactions are forwarded to the MH as it moves • A KT is successful if the last order of execution of the JT commits • Ex. Airplanes communicating with air traffic control

13. Fixed Network Cluster Model • DB’s are grouped into clusters depending on their network links or mutually consistent data • Mobile transactions sent from the MH for processing are broken into 2 types – weak and strict • Strict trans can read/write data on any cluster while the MH is connected • Weak trans can only access data within their cluster.

14. Fixed Network Cluster Model • Proxies are used to mirror the trans. on MSS’s as the MH moves • Inconsistency is allowed between clusters but not within them • When the clusters are merged the weak transactions are committed across the clusters as long as they do not conflict with any strict transactions • Ex wireless subscribers, sports, word of the day

15. PRO-Motion (Pro-active Management) • Supports disconnected transaction processing • Can execute if it has the needed data and methods • Compacts enable local executions on the MH • Compacts provide support for dynamic replication for escrowable items and improved caching techniques for non-escrowable items

16. PRO-Motion (Pro-active Management) • While connected the MH identifies a group of compacts that are updated by locally committed sub-transactions • It caches the compacts it needs then disconnects to process the trans, it can be committed locally • When the MH reconnects to the network it resynchronizes with the FH • The compacts are sent back to the DBS • A commit/abort message is sent back to the MH • Ex. UPS deliveries

17. PRE-Write Model • Increases data availability at MH’s, good for MH’s with little processing power • Allows an MH to submit a pre-committed state of the trans to be executed at the FH or other MH’s at a later time • A pre-write op. announces the value or future state that the data object will have after the commit of the write op.

18. MH Start transaction Perform Reads/Pre-writes FH Pre-commit MSS Fixed Network Write Commit FH Pre-Write Model • Pre-committing makes all the data items that will be updated at the commit phase visible to other transactions • Permanent updates on the DB are performed later by the write operation at commitment time • Ex. Newspaper reporter

19. TCOT (Time out based commitment) PROTOCOL • Supports weakly connected less powerful MH’s • Assumes MH has cache transaction processing power • Guarantees the complete execution of fragments of a mobile transaction within in a predefined timeframe

20. TCOT Protocol t1 T • MH extracts a sub-transaction from the MT, estimates a timeout period, and sends the rest of the MT to the MSS • The MSS distributes it to a FH and other MH’s for further fragmentation • At the end of each timeout period the fragments can be committed independently • If the FH does not receive a message from the MH or other executing nodes it aborts the trans and sends an abort message to all the nodes T t2 T t3 MSS FH FH T t5 MSS Fixed Network MSS FH FH t6 T MSS T t4

21. MANET (Mobile Ad Hoc Network) Model • Self-organizing, infra-structureless, multi-hop network, uses spread spectrum techniques for security • Every MH acts like a router, has a radius of influence • If a route is broken a route error message is sent to the MH that uses that route • Uses three types of routing algorithms • Proactive – routes already known • Reactive – routes found only when needed • Hybrid – uses proactive and reactive techniques

22. MANET Model • Ex. Battle field surveillance

23. Reporting and Co-transactions Model • Assumes the MH never disconnects only moves from cell to cell, a GDBS exists at each MSS • Reporting trans are sub-transactions that are able to share their partial results at any time with the parent transaction • Co-trans are reporting trans that behave like co-routines • Reporting trans and Co- trans can exchange info with each other – parallel or step-wise • Able to relocate their executions to new MSS’s as the MH moves • MSS’s remain in the computation state to minimize costs

24. Reporting and Co-Transactions • Update commitments are dependent on the transaction receiver (MH) • If the MH commits or aborts the reporting action will either have its results permanently committed or aborted • Ex. Online insurance policies

25. Semantic Based Model • Assumes MT’s are long lived tasks plagued by frequent disconnections, network delays • Reduces demand on bandwidth, utilizes cache • Design Phase - at MH, defines applications and transaction model • Execution Phase - at FH, constructs the transaction model

26. Semantic Based Model • Queues and stacks are split into fragments • Split is based on selection criteria and consistency conditions • MH requests fragments from the server • Processed transaction is returned and then merged • Ex. Booking a vacation online