Mobile Databases
Two aspects of mobility:

 user mobility: users communicate (wireless)
  “anytime, anywhere, with anyone”
 device portability: devices can be connected
  anytime, anywhere to the network
  Wireless vs. mobile

                      stationary computer
                      notebook in a hotel
                      wireless LANs in historic buildings
                      Personal Digital Assistant (PDA)
The demand for mobile communication creates the
 need for integration of wireless networks into existing
 fixed networks:
  local area networks: standardization of IEEE 802.11,
  Internet: Mobile IP extension of the internet protocol IP
  wide area networks: e.g., internetworking of GSM and ISDN
Mobile Computing Architecture

Fixed Network (FN)
Base Station (BS) (Mobile Support Station -
Fixed Hosts (FH)
Cell - Area covered by BS (1-2 miles)
Handoff - Changing BS by intercell move
Mobile Host (MH) (Mobile Unit (MU))
Location Management

Tracking mobile user
User associated with home
 location server (Home Agent)
May augment by searching in local
 area first
May augment with user profiles
Mobile IP
  Triangle Routing
  Route Optimization
  Location Control (Routing Agent)
Mobile Applications

Information Services (Yellow Pages)
Law Enforcement and Medical
Sales and Mobile Offices
Weather, Traffic, Sports, Entertainment
Technology Push

Internet: ftp, telnet, email, http,html
Advancing Wireless Communication
Laptop, Notebook, and Palmtop Computers
Data Management Issues

Speed of wireless link
Location dependent data; Location specific
Limited by battery power
Disconnection (Voluntary, Involuntary)
Medical Example

Ambulance arrives/departs
Closest hospital
Access patient records
Update patient records
Hospital personnel
Order medical supplies
Mobile DB Research

Transaction Processing
Caching - Replication
Broadcast Disks
Location Dependent Data
ACID (?)
Location Dependent Data
Value of data depends on location
Temporal Replication - One consistent value at
 one time
Spatial Replication - Multiple different correct
 data values at one time
Temporal Consistency - All data objects satisfy
 a given set of integrity constraints.
Spatial Consistency - Consistency constraints
 satisfied within Data Region.
Location Dependent Queries

Result depends on location
Different from traditional distributed goal of
 location independence
Ex: Yellow Pages, Directions, Map
Predicates based on location: “Find the
 cheapest hotel in Chennai.”
Location constraints: “Find the nearest hotel (to
Similarity to Spatial Queries

Spatial Data: Data associated with space
 occupied by object.
Types of spatial queries: contains,
 contained in, intersects, neighboring, east
 of, etc.
Spatial data structures
Spatial operators
Spatial selects and joins
Differences from Spatial Queries

Client is actually moving
Location of client may be    Spatial data is dynamic
 part of the query itself
May depend on direction of movement
Data may not directly contain location
Includes temporal features as well
Querying Moving Objects

Moving Objects Spatio-Temporal (MOST) data
  Dynamic Attributes - Change over time
  Queries over temporal history:
     Instantaneous - Ex: “Find all restaurants I’ll reach in the
      next half hour. ”
     Continuous - Ex: “Find all restaurants within 5 miles.” The
      answer continuously changes as the MU moves.
     Persistent - Ex: “Find the cars that travel greater than 10
      miles in the next half hour.”
Future Temporal Logic (FTL) language
Query Optimization

How best to satisfy the information request
 made by the client?
Different Cost Factors: I/O, network
Different Access Options: cache, FN, broadcast
Dynamic and Adaptable - environment changes
Alternative plans include deciding (based on
 state of MH and environment) whether to
 access in the cache at the MH, to request a
 mobile transaction, or to obtain from a broadcast

Placing data at MU. Usually on disk.
Faster to access from MU than from DBMS in
 fixed network.
Facilitates disconnected operation.
Adaptive to connection mode.
Not just another replica
Pull based
Most work on files not databases
Caching Functions

Data fetching
  Granularity (Page, file, table)
  Callback - Servers send invalidation messages to
  Detection - Clients send queries to servers to.
Updating during disconnect
Data integration when reconnected
Prefetching vs.. Hoarding

Both prefetch data in anticipation of future use.
  Objective is to improve performance (throughput or
   response time).
  Cache miss not catastrophic.
  Objective is to fetch all needed data into MU cache
   prior to disconnect. Thus the goal is to facilitate
   disconnected operation.
  Cache miss is catastrophic.
  OK to overfetch
Mobile Transaction (MT)

Database transaction requested from a MU.
 May execute in FN or MU
     Location Dependent Data
     Long lived
     MU Resources/ Power
MT Requirements
Keep autonomy of local DBMS
Advanced transaction models
Request from MU
Execute anywhere
Capture movement
ACID (?)
MT Approaches

No consensus on accepted approach
MU may not have primary copy of data
  Transaction Proxy: MU does no transaction
  Read Only Transaction: MU only reads data
  Weak Transaction: Read and update cached data;
   Must synchronize updates with primary copy on FN.
MU may have primary copy of data
MU may access data on other MUs
MT Recovery
Transaction, site, media, network failure - More
 frequent than in wired network.
Different types of failures (partial)
  Voluntary disconnection
  Battery problems
  Lose computer??
Database log plus transaction log
May need compensating transactions
Atomicity for MT

Weaken or provide different types of atomicity
May decompose transaction into
May require atomicity at lower than transaction
Atomic commitment difficult (expensive)
Global commit/Local Commit
Consistency for MT

Weakening isolation and atomicity may weaken
 this as well.
May divide data into clusters with consistency
 within clusters.
Reintegration of updates after reconnect may
 cause many conflicts.
May use bounded inconsistency.
Impacted by location dependent data
Isolation for MT

May be too restrictive
Can’t always do at MU (disconnection)
Isolation at lower levels in transaction
Commitment at different levels of transaction
Cooperating transactions
Durability for MT

Durability for partial results
May want durability for parts of transactions.
Due to conflicts at reconnect, even durability of
 subtransactions may not be guaranteed.
Local commit vs.. Global commit
MT Concurrency Control

                    1) T1: Lock(Xa);

Mobility of MUs           Read(Xa)                                        Server B
                                              2) T1 moves to B              Cell B
                        Server A
 may increase            Cell A                                                Xb
 message traffic            Xa
                                               3) T1: Lock(Yb);
 for lock
 management                                6) T1: Unlock(Yb);

MU failure may
 leave some data                       7) T1: Unlock(Xa);
                                                                       4) T1 moves to C

 locked /unlocked                                Xc
                                                 Yc               5) T1: Lock(Zc);
                                                 Zc                     Write(Zc);
                                              Server C                   Commit
                                               Cell C
  Revised Optimistic Locking

                            LOCK   W_INTEND R_LOCK W_LOCK
 Read locks may be         HELD

  executed at multiple   LOCK
  servers.               W_Intend No       Yes    No

 Read unlock can be     R_Lock    No      Yes    No
  executed at any site
                         W_Lock    No      No     No
Kangaroo Transaction (KT)

Built on top of global transactions
Captures data and movement behavior
Data Access Agent in BS - Maintains
 logging and transaction status
Logging at BS
Flexible atomicity
Restart after disconnect
Kangaroo Transaction (cont’d)

Local Transaction - Sequence of read and write
 operations ending in commit or abort
Global Transaction - Sequence of global or local
Joey Transaction - Sequence of global and local
 transactions ending in commit, abort, or split
Kangaroo Transaction - Sequence of one or
 more Joeys with last one ending in commit or
KT and Movement
Clustering Model

Transaction model is designed to maintain
 consistency of the database.
Database is divided into clusters.
Data is divided into core and quasi copies.
Mobile transactions and operations are
 decomposed into a set of weak and strict
Clustering Model (cont’d)

Weak operations access only data in the same
 cluster. Strict operations allowed database wide
 access. Two copies of data can be maintained
 (strict and weak).
Clusters defined based on location and user
Transaction Proxy: updates the transaction
 which are executed at mobile host in the server.
MT Research Limitations

Architectural Assumptions
No support for location dependent data
Few Implementations

Application dispatched by and
 working for the client.                    Client   Server

  Solves disconnect problem
  Solves slow bandwidth problem   Client    Agent    Server

Type - Client,Server,Application,User
     Movement - Static,Dynamic
     Number - Single, Multiple

Combine different approaches
Semantic caching
Query Optimization
Adaptive Data Broadcasting
Performance Benchmarks
Location Dependent Queries

To top