Ieee icde 98 tutorial mobile computing and databases
1 / 94

IEEE ICDE - PowerPoint PPT Presentation

  • Uploaded on

IEEE ICDE ‘98 Tutorial: Mobile Computing and Databases. Margaret H. Dunham Southern Methodist University Dept of Computer Science and Engineering Dallas, Texas 75275 [email protected] Outline. Introduction & Data Management Issues Query Processing Caching

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IEEE ICDE ' - Angelica

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ieee icde 98 tutorial mobile computing and databases l.jpg

IEEE ICDE ‘98 Tutorial:Mobile Computing and Databases

Margaret H. Dunham

Southern Methodist University

Dept of Computer Science and Engineering

Dallas, Texas 75275

[email protected]

Outline l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data Broadcasting

  • Transaction Processing

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Terminology l.jpg

  • Fixed Network (FN)

  • Base Station (BS) (Mobile Support Station - (MSS))

  • Fixed Hosts (FH)

  • Cell - Area covered by BS (1-2 miles)

  • Handoff - Changing BS by intercell move

  • Mobile Host (MH) (Mobile Unit (MU))

ICDE/SMU - Dunham

Wireless networks l.jpg
Wireless Networks

  • Cellular

    • High Cost

    • Scalability Issue

    • Limited Bandwidth: 10 Kbps

  • Wireless LAN

    • Traditional LANs with wireless interface

    • Low Cost

    • Limited range: 10-100 meters

    • Bandwidth: 10Mbps

    • NCR Wavelan, Motorola ALTAIR

ICDE/SMU - Dunham

Wireless networks cont d l.jpg
Wireless Networks (cont’d)

  • Satellite Services

    • Wide Coverage

    • Very Expensive

    • Low Bandwidth: 1-2Mbps

  • Paging Networks

    • Wide Coverage

    • Sky Tel, Motorola

  • Slow: (Ethernet: 10Mbps; FDDI or switched Ethernet: 100Mbps; ATM: 155Mbps)

ICDE/SMU - Dunham

Handoff l.jpg

  • Changing BS due to movement between cells

  • State information transferred

  • Current handoffs in cellular phones may take up to a few seconds with breaks in conversation of 100-300 ms.

  • Soft - Temporarily connected to two BSs

  • Hard - Only connected to one BS

ICDE/SMU - Dunham

Location management l.jpg
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 [11,14]

    • Triangle Routing

    • Route Optimization

    • Location Control (Routing Agent)





ICDE/SMU - Dunham

Location management cont d l.jpg
Location Management (cont’d)

  • Active Badge (Cambridge,[2])

    • Track employees and route telephone calls

    • Unique code emitted every 15 seconds

    • Sensors placed in offices and corridors

  • Location Information Replications

    • No HLR

    • Hierarchy of Location Servers

    • Each server maintains information about its subtree

ICDE/SMU - Dunham

Mobile applications l.jpg
Mobile Applications

  • Information Services (Yellow Pages)

  • Law Enforcement and Medical Emergencies

  • Sales and Mobile Offices

  • Weather, Traffic, Sports, Entertainment

  • Trucking

  • Cellular Subscribers in the United States:

    • 90,000 in 1984;4.4 million in 1990;13 million in 1994

    • Handheld computer market will grow to $1.77 billion by 2002

ICDE/SMU - Dunham

Technology push l.jpg
Technology Push

  • Internet: ftp, telnet, email, http,html

  • Advancing Wireless Communication Technologies

  • Laptop, Notebook, and Palmtop Computers

ICDE/SMU - Dunham

Data management issues l.jpg
Data Management Issues

  • Speed of wireless link

  • Scalability

  • Mobility

  • Location dependent data; Location specific queries

  • Limited by battery power

  • Disconnection (Voluntary, Involuntary)

  • Replication/Caching

  • Handoff

ICDE/SMU - Dunham

Insurance example l.jpg
Insurance Example

ICDE/SMU - Dunham

Medical example l.jpg
Medical Example

  • 911 Call

  • Ambulance arrives/departs

  • Closest hospital

  • Access patient records

  • Send vital signs

  • Update patient records

  • Page hospital personnel

  • Order medical supplies

ICDE/SMU - Dunham

Mc db research l.jpg
MC/DB Research

  • Transaction Processing

  • Caching - Replication

  • Broadcast Disks

  • Agents

  • Mobility

  • Location Dependent Data

  • Recovery

  • ACID (?)

ICDE/SMU - Dunham

Outline17 l.jpg

  • Introduction & Data Management Issues

  • Query ProcessingLocation Dependent Queries and DataNew Query TypesQuery Optimization

  • Caching

  • Data Broadcasting

  • Transaction Processing

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Location dependent data l.jpg
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.

  • SMU/University of Missouri at Kansas City, [17]

ICDE/SMU - Dunham

Location dependent queries l.jpg
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 Dallas.”

  • Location constraints: “Find the nearest hotel (to me).”

ICDE/SMU - Dunham

Similarity to spatial queries l.jpg
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

  • PSQL - extend SQL, [18,20]

ICDE/SMU - Dunham

Differences from spatial queries l.jpg
Differences from Spatial Queries

  • Client is actually moving

  • Location of client may be part of the query itself

  • May depend on direction of movement

  • Data may not directly contain location information

  • Includes temporal features as well

Spatial data is dynamic

ICDE/SMU - Dunham

Querying moving objects l.jpg
Querying Moving Objects

  • Moving Objects Spatio-Temporal (MOST) data model

    • 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

  • University of Illinois, [20]

ICDE/SMU - Dunham

Query optimization l.jpg
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 disk.

ICDE/SMU - Dunham

Outline24 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • CachingOverviewTypesResearch

  • Data Broadcasting

  • Transaction Processing

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Caching l.jpg

  • 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

ICDE/SMU - Dunham

Caching functions l.jpg
Caching Functions

  • Data fetching

    • Granularity (Page, file, table, semantic)

  • Replacement

  • Coherency

    • Callback - Servers send invalidation messages to clients.

    • Detection - Clients send queries to servers to.

  • Updating during disconnect

  • Data integration when reconnected

ICDE/SMU - Dunham

Connectivity and file systems l.jpg
Connectivity and File Systems

Table 3.2 from [15]

ICDE/SMU - Dunham

Mu replica control protocols l.jpg
MU Replica Control Protocols

  • Traditional Replication Protocol problems:

    • May hinder mobility

    • Quorum Consensus: Can’t get quorum if disconnected; Avoid using MU replicas to make up quorum

  • Location information not always readily available

  • Primary Copy: Should not be stored at MU

  • First class/Second class replicas

ICDE/SMU - Dunham

Checkpointing l.jpg

Table 3.4 from [15]

ICDE/SMU - Dunham

Prefetching vs hoarding l.jpg
Prefetching vs.. Hoarding

  • Both prefetch data in anticipation of future use.

  • Prefetching

    • Objective is to improve performance (throughput or response time).

    • Cache miss not catastrophic.

  • Hoarding

    • 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

ICDE/SMU - Dunham

Hoarding spying l.jpg

  • Listening to and recording file accesses

  • Performed during a snapshot interval

  • May be combined with user profiles.

  • Results limited to the snapshot.

ICDE/SMU - Dunham

Disconnected issues l.jpg
Disconnected Issues

Table 3.1 from [15]

ICDE/SMU - Dunham

Slide33 l.jpg

  • First project to demonstrate disconnected operation.

  • Optimistic Locking

  • Granularity - sets of files.

  • Coherency - callbacks

  • Hoard Walking: Periodically (every 10 min) evaluate contents of cache. Recalculate priorities.

  • On a callback break, object is purged, refetching on demand or during next hoard walk.

  • Venus - cache manager at MU

ICDE/SMU - Dunham

Coda cont d l.jpg
Coda (cont’d)

  • Venus states: hoarding,emulating,write disconnected (earlier reintegrating).

  • Cache misses during disconnection are treated as failures.

  • During disconnection, a log (Change Modify Log) of operations is created.


Strong Connection

Weak Connection







ICDE/SMU - Dunham

Adapted from Fig 2 in [34]

Coda cont d35 l.jpg
Coda (cont’d)

  • During integration, log applied. Conflicting updates are determined and user assists in resolution

  • Timestamps at volume and object level used to determine conflicts.

  • Trickle Reintegration used to asynchronously propagate updates.

  • Hoard Profile - list of files and priorities.

  • Lowest priority objects chosen for replacement.

  • Weak Connectivity - low bandwidth, high latency, high cost, or intermittent

  • CMU, [29,34]

ICDE/SMU - Dunham

Little work l.jpg
Little Work

  • Disconnected AFS

  • Cache operations depends on type of connection

    • Connected - Continuous; High bandwidth; Normal operation

    • Partially Connected - Continuous; Dialup; Delayed writes

    • Fetch Only - On demand; Cellular; Optimistic replication

  • Disconnected - Fail if cache miss

ICDE/SMU - Dunham

Little work cont d l.jpg
Little Work (cont’d)

  • Caches 64KB chunks of files

  • Fetch only mode

  • Modifications sent back to primary file server

  • Conflicts stored separately and user notified

  • Michigan, [25,26]

ICDE/SMU - Dunham

Slide38 l.jpg

  • Ficus

  • Uses semantic information to determine contents of cache.

  • Semantic distance between files measured in number of file accesses on average between two files.

  • Access is defined as open-close.

  • Distance measure used to cluster files. Fetching of a cluster based on user hints and LRU information.

  • UCLA, [24,30]

ICDE/SMU - Dunham

Summary l.jpg

Table 3.1 from [15]

ICDE/SMU - Dunham

Sleepers and workaholics l.jpg
Sleepers and Workaholics

  • Cache invalidation report

  • Periodically (synchronous) the server broadcasts report of changed data.

  • MU waits for next report prior to answering query.

  • Sleepers - frequently disconnected; cache invalidation based on signatures.

  • Workaholics - rarely disconnected; periodic broadcast of changes.

  • False Invalidation

  • MITL and Rutgers, [21]

ICDE/SMU - Dunham

Transparent analytic spying l.jpg
Transparent Analytic Spying







Access Tree

  • File Working Sets

  • Continually observe and record (in a log) file access. At hoard time, reference the log to determine hoard.

  • Trees for a process are created reflecting file access pattern. One tree per program execution is generated.

ICDE/SMU - Dunham

Transparent analytic spying cont d l.jpg
Transparent Analytic Spying (cont’d)

  • Hoard all files or only those in in the most recent execution.

  • Tracing adds about 2% CPU overhead. Average space for file log record is 100 bytes.

  • Implemented on Unix, NFS, Mach

  • Cache miss rate over wireless slightly higher than on wired.

  • Prefetching overall reduced cache misses and elapsed time

  • Columbia, [36]

ICDE/SMU - Dunham

Predictive file caching l.jpg
Predictive File Caching

  • Analyze file access patterns in different environments: Personal productivity, Programming, Commercial

  • Working Set Statistics: Mean working-set sizes small (18MB per day)

  • Attention Shift Statistics: 0.6 per user per week

  • Conflict Statistics: Depends on environment

  • Conclusion:

    • Hoarding is possible due to small working set size

    • LRU caching insufficient

  • UCLA, [31]

ICDE/SMU - Dunham

Virtual primary copy l.jpg
Virtual Primary Copy

  • Mobile Primary Copy (MPC) at MU

  • Virtual Primary Copy (VPC) at BS

  • Global transactions access VPC

  • Consistency of VPC maintained by BS

  • BS monitors MU disconnect

  • Multilayered approach is transparent to other sites

  • Monash, [23]

ICDE/SMU - Dunham

Slide45 l.jpg

  • MC Replication System

  • MU Peer to Peer communication allowed

  • Ward Model:

    • Ward: Grouping of replicas for locations that frequently communicate

    • Ward Set: Set of replicated data stored in a ward.

    • Ward Master: Doorway into ward. Maintains consistency between wards.

ICDE/SMU - Dunham

Roam cont d l.jpg
Roam (cont’d)

  • Ward members are “close”

  • No “pre-motion” operations

  • Intra-ward synchronization easier than inter-ward

  • Reconciliation- Synchronization process

  • Selective replication at file level

  • Scales well

  • UCLA, [33]

ICDE/SMU - Dunham

Semantic cache l.jpg
Semantic Cache

  • Caching granularity at a predicate level

  • SPJ query - Materialized view

  • Advantages: reduces network overhead, reduces cache space

  • Disadvantages: Indexing, query trimming

  • Semantic Cache - C = {Si}

  • Semantic Segment - Si=<Sr,Sa,Sp,Sc>

  • SMU

ICDE/SMU - Dunham

Outline48 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data BroadcastingOverviewIndexingResearch

  • Transaction Processing

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Data broadcasting l.jpg
Data Broadcasting

  • Server continually broadcasts data to MUs.

  • Scalability: Cost does not depend on number of users listening.

  • Mobile Unit may/may not have cache.

  • Facilitates data access during disconnected periods.

  • Allows location dependent data access.

  • No need to predict with 100% accuracy the future data needs.

  • Broadcast based on probability of access.

  • Periodic broadcasting of all data.

ICDE/SMU - Dunham

Data broadcasting cont d l.jpg
Data Broadcasting (cont’d)

  • Classification:

    • Coverage - Everything, Subset

    • Content - Static, Dynamic

    • Indices - Index, Self Descriptive

    • Data Stream - Flat, Skewed, Multiple Disks

    • Client - Passive, Active

  • For uniform page access, flat disk has best expected performance.

  • With skewed page access, nonflat disks are better.

  • Push based.

ICDE/SMU - Dunham

Broadcast disks l.jpg
Broadcast Disks

  • Simulate multiple disks of varying sizes and speeds. Data of higher interest on smaller faster disks (broadcast more frequently).

  • Each “disk” contains data with similar access behavior.

  • Combination of caching and broadcast disks.

Figure 4.1 from [15]

ICDE/SMU - Dunham

Broadcast disks cont d l.jpg
Broadcast Disks (cont’d)

  • Don’t want to store hottest pages. They may be broadcast frequently.

  • Store in cache if probability of access (P) is greater than the frequency of broadcast (X).

  • Cost based page replacement.

  • Replace cache page with smallest P/X - PIX. Too expensive to implement.

  • LIX - PIX approximation. Works well particularly with noise.

  • Brown, MITL, Maryland, [37,38,39]

ICDE/SMU - Dunham

Air cache l.jpg

  • Dynamic - Adapts to system workload.

  • Define temperature of data:

    • Vapor (Steamy) Hot - Accessed frequently and broadcast.

    • Liquid Warm - Accessed often, not broadcast, but kept in server’s main memory.

    • Frigid (Icy) Cold - Accessed infrequently and stored on secondary storage.

ICDE/SMU - Dunham

Air cache cont d l.jpg
Air-Cache (cont’d)

  • Three level memory hierarchy based on temperature.

  • Sparks (access) to data can increase temperature. No sparks, results in a reduction of temperature.

  • Simulation results predict very good performance.

  • Maryland, [43]

ICDE/SMU - Dunham

Adaptive protocols l.jpg
Adaptive Protocols

  • Dynamically modify broadcast contents.

  • Constant Broadcast Size (CBS) Server Protocol:

    • Limited size and periodic

    • Priority

    • Popularity Factor (PF)

    • Ignore Factore (IF)

  • Variable Broadcst Size (VBS) Server Protocol:

    • Aperiodic

    • All data above threshold PF included.

  • Arizona and UMKC, [40]

ICDE/SMU - Dunham

Outline56 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data BroadcastingTransaction ProcessingOverviewTransaction ModelConcurrencyRecoveryResearch

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Mobile transaction mt l.jpg
Mobile Transaction (MT)

  • Database transaction requested from a MU. May execute in FN or MU

  • Issues

    • Disconnect/Handoff

    • Mobility

    • Location Dependent Data

    • Error Prone

    • MU Resources/ Power

    • Recovery/Restart

    • Management

ICDE/SMU - Dunham

Mt requirements l.jpg
MT Requirements

  • Keep autonomy of local DBMS

  • LLT

  • Interactive

  • Advanced transaction models

    • Nested

    • Multidatabase

  • Request from MU

  • Execute anywhere

  • Capture movement

  • ACID (?)

ICDE/SMU - Dunham

Mt approaches l.jpg
MT Approaches

  • No consensus on accepted approach

  • MU may not have primary copy of data [45]:

    • Transaction Proxy: MU does no transaction processing

    • 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

  • First class and second class transactions

ICDE/SMU - Dunham

Mt recovery l.jpg
MT Recovery

  • Transaction, site, media, network failure - More frequent than in wired network.

  • Different types of failures (partial)

    • Handoff

    • Voluntary disconnection

    • Battery problems

    • Lose computer??

  • Checkpoint data at MU to BS

  • Checkpoint at handoff

  • Database log plus transaction log

  • May need compensating transactions

ICDE/SMU - Dunham

Atomicity for mt l.jpg
Atomicity for MT

  • Weaken or provide different types of atomicity

  • May decompose transaction into subtransactions

  • May require atomicity at lower than transaction level

  • Atomic commitment difficult (expensive)

  • Global commit/Local Commit

ICDE/SMU - Dunham

Consistency for mt l.jpg
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

ICDE/SMU - Dunham

Isolation for mt l.jpg
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

ICDE/SMU - Dunham

Durability for mt l.jpg
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

ICDE/SMU - Dunham

Mt concurrency control l.jpg
MT Concurrency Control

1) T1: Lock(Xa);


2) T1 moves to B

Server A

Cell A



3) T1: Lock(Yb);


Server B

Cell B

6) T1: Unlock(Yb);




4) T1 moves to C




5) T1: Lock(Zc);




Server C

Cell C

  • Mobility of MUs may increase message traffic for lock management

  • MU failure may leave some data locked /unlocked

6) T1: Unlock(Xa);


Fig 2 from [48]

ICDE/SMU - Dunham

Revised optimistic locking l.jpg
Revised Optimistic Locking

  • O2PL-MT

  • Read locks may be executed at multiple servers.

  • Read unlock can be executed at any site

  • Benefit shown using analytic model

  • Purdue, [48]

Figure 3 from [48]

ICDE/SMU - Dunham

Kangaroo transaction kt l.jpg
Kangaroo Transaction (KT)

  • Built on top of global transactions

  • Captures data and movement behavior

  • DAA as BS - Maintains logging and transaction status

  • Logging at BS

  • Flexible atomicity

  • Restart after disconnect

  • Management moves

ICDE/SMU - Dunham

Kangaroo transaction cont d l.jpg
Kangaroo Transaction (cont’d)

  • Local Transaction - Sequence of read and write operations ending in commit or abort

  • Global Transaction - Sequence of global or local transactions

  • 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 abort. All earlier end in split

  • SMU, [47]

ICDE/SMU - Dunham

Kt and movement l.jpg
KT and Movement

ICDE/SMU - Dunham

Reporting and co transactions l.jpg
Reporting and Co-Transactions

  • Mobile transaction is a special type of multidatabase transactions.

  • GDMS exists at each base station.

  • Subtransactions of the mobile transaction will commit or abort independently.

  • Atomic and non-compensatable transactions.

  • Reporting and co-transactions.

  • Pittsburgh, [46]

ICDE/SMU - Dunham

Clustering model l.jpg
Clustering Model

  • Views mobile transaction as beginning on mobile and nonmobile hosts.

  • Transaction migration

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

ICDE/SMU - Dunham

Clustering model cont d l.jpg
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 profile.

  • Transaction Proxy: dual transaction of one executed at mobile host which includes only the updates.

  • Purdue, [51,52]

ICDE/SMU - Dunham

Mobile transactions and ambulatory care l.jpg
Mobile Transactions and Ambulatory Care

  • Medical Personal Digital Assistant (MPDA)

  • Battlefield - Cache copy of soldiers’ medical records in MPDA

  • Distributed Medical Database - EMT obtains patient’s medical record and updates.

  • BSA (Base Station Agent) is responsible for logging and recovery.

  • Recovery based on sagas with save-points.

  • Mailboxes used to save information.

  • Purdue, [49,50]

ICDE/SMU - Dunham

Semantics based mobile transaction processing l.jpg
Semantics-Based Mobile Transaction Processing

  • Views mobile transaction processing as a concurrency and cache coherency problem.

  • A stationary database server dishes out the fragments of an object on a request from a Mobile Unit.

  • On completion of the transaction, the Mobile Units return the fragments to the server.

  • These fragments are put together again by the merge operation at the server.

  • Pittsburgh, [54]

ICDE/SMU - Dunham

Multidatabase transaction processing manager l.jpg
Multidatabase Transaction Processing Manager

  • Mobile transactions built on top of multidatabase global transactions.

  • Timestamps used to enforce ordering

  • Allows voluntary disconnections.

  • MU part of MDS

  • Message Queuing Facility (MQF)

  • MU sends request to designated coordinating node on FN.

  • Monash, [56]

ICDE/SMU - Dunham

Pro motion l.jpg

  • MC/Database Transaction Processing approach

  • Multiple transaction types

    • Controlled divergence

    • ACID

    • Update cache and later DB at FH

  • Compact - Compact Agent at MU, Mobility Manager at BS, Compact Manager at Server

  • Pittsburgh, [55]

ICDE/SMU - Dunham

Mt research limitations l.jpg
MT Research Limitations

  • Architectural Assumptions

  • No support for location dependent data

  • Few Implementations

ICDE/SMU - Dunham

Mt management options l.jpg
MT Management Options

  • MU

  • BS

  • Combination

  • Fixed/Relocatable/Moving

  • Agent

ICDE/SMU - Dunham

Outline79 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data Broadcasting

  • Transaction Processing

  • AgentsOverviewClient-Agent-Server ModelMobile Agent

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Agent l.jpg






  • Application dispatched by and working for the client.

  • Agent:

    • Solves disconnect problem

    • Solves slow bandwidth problem

  • Client-Agent-Server

  • Agent Classification:

  • Type - Client,Server,Application,User

    • Movement - Static, Relocatable, Migrating (Mobile)

    • Number - Single, Multiple, Clonable

ICDE/SMU - Dunham

Itinerant agent mobile agent l.jpg
Itinerant Agent (Mobile Agent)

  • Program dispatched from mobile unit that roams through the fixed network to satisfy client’s data request.

  • At a server the agent is sent to an Agent Meeting Point (AMP) where desired server functions are determined and requested.

  • Client, Migrating, Single

  • IBM, [58]

ICDE/SMU - Dunham

Migrating user agent l.jpg
Migrating User Agent

  • User process that mimics MU.

  • Process migrates as user moves.

  • Client, Migrating, Single

  • Massachusetts, AT&T, [63]

ICDE/SMU - Dunham

Remote programming l.jpg
Remote Programming

  • Language for communication required.

  • User and server communication without using network.

  • Places - Meeting points for agents and servers

  • Agents - Application is set of agents. Agent is either at a place or travelling between places.

  • Travel - Go instruction

  • Meetings - Agents communicating at a place.

  • General Magic Telescript, [59]

ICDE/SMU - Dunham

Concordia l.jpg














Adapted from Fig 6 in [61]

  • Mitsubishi Electra ITA

  • Java Objects; JDBC

  • Collaborating Agents

  • Agent Server - FN

  • User Agent - MU to BS

  • Query Agents- BS to Server

  • Collaborator - BS

  • Mitsubishi Electric ITA, [60,61]

ICDE/SMU - Dunham

Outline85 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data Broadcasting

  • Transaction Processing

  • Agents

  • Projects & Products

  • Conclusion

ICDE/SMU - Dunham

Some db mc projects urls l.jpg
Some DB/MC Projects URLs

  • MobiDick - Monash Univ. (Australia);

  • Mobisaic - Univ. of Washington;

  • Purdue;

  • SMU;

  • MCC - Collaboration Managment Infrastructure;

  • University of Ioanina;

  • Michigan - CITI;

  • UCLA - Ficus;

  • Columbia;

ICDE/SMU - Dunham

Rover l.jpg

  • Figure 6.1 from [15]

ICDE/SMU - Dunham

Oracle mobile agent l.jpg
Oracle Mobile Agent

Message Manager

  • Commercial Product

  • Application, Static, Multiple

  • Message Manager - MU

  • Message Gateway - BS

  • Agent - FN (Server)

  • [67,69]





Database Server

ICDE/SMU - Dunham

Sybase sql anywhere l.jpg
Sybase - SQL Anywhere

Remote Database

SQL Anywhere standalone engine

Message agent

Consolidated Database

SQL Anywhere network server

Message agent

  • Designed for Windows, (95, 3.x, NT), OS/2, DOS

  • Limited memory requirements

  • Full TP capabilities

  • Includes SQL Remote

  • Compatible with Sybase SQL Server

  • [68]

ICDE/SMU - Dunham

Sybase cont d sql remote l.jpg
Sybase (cont’d) - SQL Remote



Remote Databases

  • Two way replication based on message passing.

  • Remote database are synchronized with consolidated DB

  • Message Agent required at DB server

  • Replication of subscribed fragments

  • Periodic changes sent from consolidated DB to remote DBs

  • Updates from committed transactions at remote submitted to consolidated database.

  • Conflicts: Consolidated is master; Triggers used.

ICDE/SMU - Dunham

Informix l.jpg

  • I-Mobile 1.0 discontinued:

    • No replication

    • Three tier approach appropriate for long term, but in the short term users wanted to be able to use existing client-server applications (not rewrite).

    • Small DBMS server to run on mobile client

    • Only dial up needed for now

  • Informix Dynamic Server/Personal Edition (IDS/PE) for Windows 95/NT. Mobiles and desktop clients

  • [64,66]

ICDE/SMU - Dunham

Outline92 l.jpg

  • Introduction & Data Management Issues

  • Query Processing

  • Caching

  • Data Broadcasting

  • Transaction Processing

  • Agents

  • Products

  • Conclusion

ICDE/SMU - Dunham

Future l.jpg

  • Combine different approaches

  • Semantic caching

  • Query Optimization

  • Adaptive Data Broadcasting

  • Performance Benchmarks

  • Security

  • Location Dependent Queries

ICDE/SMU - Dunham

Acknowledgements and url bibliographies l.jpg
Acknowledgements and URL Bibliographies

  • Earlier version of this tutorial presented at the 1996 Brazilian Database Symposium.

  • We particularly want to thank Evaggelia Pitoura for providing several tables and figures from her recent book [15].

  • Some slide information obtained from slides presented at a database class at the University of Massachusetts,

  • Online bibliographies



ICDE/SMU - Dunham