1

Mobile Database Systems (MDS)

Objective
To build a truly ubiquitous information processing system by overcoming the inherent limitations of wireless architecture.

MDS Issues

Data Management

Hoarding Data Caching Adaptation

Transaction Management

Transaction processing Query processing

2

Database recovery

Mobile Database Systems (MDS)

A Reference Architecture (Client-Server model)
PSTN DB DB HLR MSC BSC Fixed host Fixed host BS MU MU MU BS MU BS MU
3

VLR MSC BSC

DBS DBS

Mobile Database Systems (MDS)

MDS Applications

Insurance companies Emergencies services (Police, medical, etc.) Traffic control Taxi dispatch E-commerce Etc.

Mobile Database Systems (MDS)

MDS Limitations

Limited wireless bandwidth Wireless communication speed Limited energy source (battery power) Less secured Vulnerable to physical activities

Hard to make theft proof.

Mobile Database Systems (MDS)

MDS capabilities

Can physically move around without affecting data availability Can reach to the place data is stored Can process special types of data efficiently Not subjected to connection restrictions

Very high reachability

Highly portable
6

hoarding - learning sequences

Web-based materials are generally highly interlinked a net of links The user browsing path over a web-based material can be viewed as a hierarchy structure Depends on users learning style, natural learning habits and abilities
3
...

Starting Page
1 8 9
...

depth level 1

depth level 2

hoarding what is it? why we need it?

Hoarding is a technique for selecting set of documents to be uploaded and used when disconnected.

To allow any time, anywhere access to the learning materials to support offline access of learning content Often the memory available on the device is not large enough to contain all material of a system a decision should be made what to put on the device To free the user from annoying procedures of pre-fetching content decide automatically what the user will need
9

the hoarding process

1. 2. 3. Decide (predict) what material the learner will start from; From the materials that are linked to this start point generate a candidate set; Predict which will be the learning sequence or set, that is of interest for the user at next depth level and discard the items that are not of interest from the set (this step is called pruning) loop until the deepest level; Set priorities to the materials in the hoarding set, based on their predicted priority of importance for the next session (higher if the probability the object will be used soon is high);

4.

5.

Pre-fetch, starting from the beginning of the ordered list, putting on the device those objects with bigger priority, until available memory is filled in.
10

hoarding - the starting step

Starting Point from site structure Based on observations on all previous users the system can estimate the average (or max.) browsing depth and session length Maximize the hit rate
Set of LO, selected by the hoarding algorithm Set of LO, used by the student in one session

Number of hits divided on number of uploaded items

Minimize the miss rate

percentage of ineffective requests
Set of LO, selected by the hoarding algorithm Set of LO, used by the student in one session
11

12

Caching is an important technique in the computing world. Most of us are familiar with cache used for a single processor computer, as illustrated in Figure

In distributed systems and network computing environments, cache management schemes need to handle two different scenarios.
13

In the first scenario, the data in the shared memory or the server can be read/written by different processors or clients concurrently, as shown in Figure 15.2

In the second scenario the data is read-only for the clients, as shown in Figure 15.3.

14

In these environments (distributed systems and network computing ), when a client accesses a cached data item, the server or another client could have just modified that data item. Hence, in distributed and network computing environments, the most crucial problem for caching is how to maintain data consistency among the clients and the servers?

15

To maintain cache consistency in distributed or network computing environment, different approaches have been developed. These approaches include polling-every-time, adaptive time-to-live (TTL) , invalidation based mechanisms.

Poll every time

16

For polling-every-time and TTL-based caching strategies, the client side initiates the consistency verification: that is, the client is responsible for verifying the data consistency before using it. For the TTL-based caching strategy, every cached data item is assigned a TTL value, which can be estimated based on the data items update history. For example, the adaptive TTL approach in estimates TTL based on the age of a data item. When the user request arrives for a data item x, if data item xs residence time has exceeded its TTL value, the client sends a message to the server to ask if x has changed. Based on the servers response, the client may get a new copy of x from the server (if the data item x has changed since the last time the client cached x) or just use the cached copy to answer the user's request (if the data item x has not been modified since the last time the client received a copy of x).
17

For the polling-every-time approach, every time the data is requested, the clients need to send requests to the server to verify if the cached data has changed. The polling-every-time caching strategy can be thought of as a special type of TTL-based scheme, with the TTL field equal to zero for every data item. Polling-everytime and TTL-based approaches are used in many existing Web caches.

18

On the other hand, for the invalidation-based strategies, the cache consistency verification is initiated by the server. Invalidation-based cache strategies are further classified into stateless and stateful approaches

19

In a stateless approach, the server does not maintain information about the cache contents of the clients (i.e., the server does not know what data is cached or how long it has been cached by a particular client). The stateless-based approach can be further categorized into synchronous and asynchronous approach. In the asynchronous approach, invalidation reports are sent out upon data modification. In the synchronous approach, the server periodically sends out invalidation reports, which may overlap with the previous invalidation.

EX: State less synchronous approaches are (namely TS (time stamps), AT (amnesic terminals) ,and SIG (signatures)

20

In the TS (time stamps) approach, the server periodically broadcasts the invalidation reports, which consist of data item IDs and their last update times during the last w (where w is the invalidation window size) seconds. Then, based on the invalidation reports, the MH will purge the data item from its cache or update the data items time stamp. The MH also maintains a variable to record the last time it received a report. If the difference between the current report time stamp and this variable is greater than w, the MH should drop the entire cache.

The AT (amnesic terminals) approach is similar to the TS approach, but the invalidation reports are the data item IDs that have changed since the last invalidation report. Similarly in the SIG (signatures) method, the difference is that the server periodically broadcasts the signatures of the data items.
21

In case of the stateful approach, the server keeps track of the information of the cache contents. These approaches can also be categorized into synchronous and asynchronous approaches. There are hardly any schemes in the stateful synchronous category. One example for stateful asynchronous approach is proposed is AS algorithm. In that approach, a Home Location Cache (HLC) is maintained for every client and is used to record the data items cached by that client and their last modification time. Based on the information, the server can generate invalidation reports dedicated to a particular client cache.

22

TS/AT Server is stateless (no information about client cache is maintained) Invalidation reports sent regardless of whether clients have any data in cache. Invalidation reports sent periodically at rate L (synchronous). Average cache latency is L/2 plus network queuing delay. Traffic on the network is bursty as queries are aggregated for a period of time L. Mobility is supported by assuming a replication of data across all stationary nodes (not scalable)

AS Server is stateful (HLC maintained) Invalidation report broadcast only if any client has valid data in cache. Invalidation reports sent as and when data changes (asynchronous)

Latency is governed only by the queuing delay on the network

Queries are answered as they are generated Mobility can be transparently supported by using a mobility aware network layer ex: mobileIP 23

24

25

A Glimpse of the Future

Imagine you are a tourist in Paris
with a wearable computer
wireless access to remote services unobtrusive heads-up display, microphone, earphones speech for computer interactions

online language translation

26

What Makes This Science Fiction?

Lack of hardware? No! We have what we need. Lack of applications? Nope - we have those too. Need a system capable of coping with the problems of mobility

Odyssey to the rescue...

27

Problems with Mobility

Mobile elements are resource-poor
relative to static elements of same era weight, power, size constraints

Mobility leads to communication uncertainty

enormous variation in bandwidth & latency intermittent connectivity

Power management is a concern

actions may have to be slowed or deferred communication costs energy

need to rely on resources of remote servers, but may not be able to reach them!

28

Adaptation is Key
Highly dynamic environment adaptation key to good performance Who adapts?
System?
take advantage of good times Behave ok during bad times CODA

This paper: applications also must adapt

Change expectations depending on surrounding state 29 End to end argument?

Client Adaptation

Make mobile clients more robust by offering adaptation rely on servers when possible function autonomously if needed monitor and adjust to current conditions Change application expectations

30

Adaptive Applications

applications consume resources

network bandwidth, CPU cycles, battery power, disk space, $$$

resources are variable so applications adapt use of resources as resource quality changes
31

Who Controls Adaptation

The Operating System? Individual applications? Both!

Application-Aware Adaptation
32

Application-Aware Adaptation
Application only (laissez faire) What if different applications compete for the resources? OS only (application-transparent) Does not differentiate between applications (student viewing a video of a lecture vs. a video teleconference) Joint responsibility in Odyssey (application-aware) Several ways to divide the functionality odyssey only one
33

Odyssey
A Platform for adaptive mobile data access

Built a prototype for Un*x as OS extension Provides a small API to the application
Implementation: Need a central component for resource monitoring and management (Viceroy) Need data aware components that offer fidelity choices (Wardens)

34

Odyssey Architecture
Application
Odyssey runtime

Web Warden viceroy Video warden

Upcalls
Sys calls

Odyssey calls

kernel

Interceptor

Tsop, request

35

Operational Model
Control loop: Select fidelity (application) Place request (system call)

Detect change

Notify application
36

Agility
An Odyssey client must estimate the quality of network paths used by various applications. Odyssey records:
Round-trip time Throughput

Odyssey updates its estimates of latency and bandwidth once every half second. Aside, Nobles group followed up with agility estimation work for ad hoc networks

37

Agility (cont.)

38

Agility (cont.)

39

Stability
Pursuing agility while completely sacrificing stability can be counterproductive. Rapidly switching Low-fidelity Variable latency Stability is properly incorporated by individual application. When notifying an application , the viceroy can include information about the expected 40

41

Context-aware Computing
Beyond application-aware adaptation Instead of adapting only to resource levels, adapt to contexts Context:
Enumeration-based (categories) Role-based (roles of context in building mobile applications)
42

Types of Context
Computing context includes network connectivity, communication costs, communication bandwidth, and local resources, such as printers, displays, and workstations User context includes user profiles, location, and people in the vicinity of the user Physical context includes lighting and noise levels, traffic conditions, and temperature Temporal context includes time of day, week, month, and season of the year Context history is the recording of computing, user, and physical context over time
43

The 5 Ws
Who is the user? Who are the people with which the user is interacting, or who is nearby? What is the user doing? Where is the user? Home? Work? Bathroom? Familiar coffee shop? When? What time is it? Why? Why is the user performing a certain task? What is the tasks priority in the grand scheme? Low-level vs. High-level details
44

Context Overview

45

Context-aware Requirements
Contextual sensing
detection of environmental states

Contextual adaptation
capability of the system to adapt its behavior by using contextual information

Contextual resource discovery

capability to discover available resources in an environment

Contextual augmentation
capability to associate contextual information with some digital data Example: association of a particular meeting place and attendees with a set of minutes Example: association of a digital photo with a specific location
46

Designing CA Applications
Build list of relevant contexts
e.g., home, office, traveling, sleeping,

Specify context-aware behaviors

Presentation of context-sensitive information Automatic discovery of relevant objects (e.g., nearby people for transmission of business cards) Modification of the physical and digital environments

Integration of application with methods for sensing context

47

Simple Example: stick-e notes

Context-aware Post-it notes Build list of relevant contexts
Based on location (latitude/longitude via GPS) Temperature, whatever else can be sensed

Specify context-aware behaviors

stick-e notes pop up on a PDA when contextual info is appropriate Reminder to return a library book when near the library Reminder to buy a new winter jacket when temperature drops below 60F

Integration of application with methods for sensing context

Most difficult part Ubiquitous sensing of environmental characteristics, such as location, temperature, number of human beings nearby, the cat is near, not widespread
48

Where Does Context Come From?

Returning to the difficulty point on the previous slide Environmental sensors
Temperature, humidity, location, noise, motion Cat sensor Potential need for multiple types of sensors GPS vs. indoor location sensors

History
Recording user actions and previous contexts

Users personal computing environment

Schedules, notes, address books, financial info

Need real-time analysis to provide context

49

Example: Location
Indoor locating systems
e.g., infrared or ultrasound

Wireless nanocell communication activity

Association with short-range base stations

GPS Associations with nearby computers Motion sensors and cameras, computer vision Ask the user!
50

Service-oriented Architecture
Provide services to context-aware applications Context subscription and delivery service
Delivers contextual information as available

Context query service

Delivers contextual information on-demand

Context transformation and synthesis services

Transforms low-level contextual information (location, temperature, lighting levels) into high-level (YOURE IN THE CLOSET IN YOUR BEDROOM)

Service discovery
Discovery of nearby services Well examine service discovery protocols next!
51

52

MDS Transaction Management

A Database transaction is defined as unit of processes which change a database from one consistent state to another

consistent state. Normally a flat transaction follows the basic properties named as ACID (Atomicity, Consistence, Isolation, Durability) properties. In the case of Mobile Transactions, to cope with the problems of mobile environment like handoffs, disconnections etc, ACID properties are generally relaxed. A basic way to relax the ACID property is to divide the transaction into various sub transactions which can be further nested.
53

Transaction fragments for distribution.

PSTN DB DBS DB DBS HLR MSC BSC Fixed host Fixed host BS MU MU MU BS MU BS MU VLR MSC BSC

Execution scenario: User issues transactions from his/her MU and the final results comes back to the same MU. The user transaction may not be completely executed at the MU so it is fragmented and distributed among database servers for execution. This creates a Distributed mobile execution.
54

Definition: A mobile transaction is a transaction of nondeterministic lifetime submitted from a mobile capable node in a mobile environment. The mobile transaction, in general, can be considered to consist of two components a MU component and a fixed network component. The fixed network component of the mobile transaction may have to be partially or completely relocated as the MU moves.

Mobile environments can be considered to be similar to highly distributed environments in many respects. But unlike in distributed environments, locations of some hosts are not permanent in mobile environments. This along with the low communication bandwidth, frequent disconnections, and high vulnerability throws up many challenges to researchers
55

A mobile transaction (MT) can be defined as

Ti is a triple <F, L, FLM>; where F = {e1, e2, , en} is a set of execution fragments, L = {l1, l2, , ln} is a set of locations, and

FLM = {flm1, flm2, , flmn} is a set of fragment location mapping where j, flmi (ei) = li

56

Applicable Transaction Models I. Open Nested Transactions II. Split transactions III. Saga compensating transactions I. Open Nested Transactions Open Nested Transaction Model is designed for long duration activities. These transactions typically consist of a set of sub transactions, which can be structured as a transaction tree. The Open Nested Transaction Model provides better support for long duration activities. These are also ideally suited for conversational transactions. Ex: a. Reporting and Co-Transactions approach b. The Clustering Model etc..
57

a). Reporting and Co-Transactions: The parent transaction (workflow) is represented in terms of reporting and cotransactions which can execute anywhere. A reporting transaction can share its partial results with the parent transaction anytime and can commit independently. A co-transaction is a special class of reporting transaction, which can be forced to wait by other transaction.

b). Clustering: A mobile transaction is decomposed into a set of weak and strict transactions. The decomposition is done based on the consistency requirement. The read and write operations are also classified as weak and strict.

58

II. Split Transactions

Split transactions or dynamically restructured transactions split a transaction into two independent serializable transactions. The transactions could be committed or aborted independent of each other. The operation split-transaction can be used to split a transaction into two. The split transactions are combined together by an inverse operation termed Join Transaction. Split transactions are mainly designed for user controlled open-ended transactions. Ex: Kangaroo Transaction model

59

Split Transaction Semantics

Split transaction the split-transaction operation is used to split a transaction into a set of independent entities. It takes theread and write sets as the input and produces a split: split-transaction ( Read(A), Write(A), Read(B), Write(B) ) Join transaction the join-transaction operation is the inverse of the split-transaction operation. It takes the target transaction to which the current transaction is to be joined as the input. Let T be the current transaction to be joined with S. The operation join-transaction(S) joins T with S. All data items of T are available to S after this operation. T may be committed or aborted depending on the fate ( Commit Or abort) of S. The join transaction can also be extended so that the join is done only if the target agrees on the operation too.
60

ex: Kangaroo Transaction: It is requested at a MU but processed at DBMS on the fixed network. The management of the transaction moves with MU. Each transaction is divided into subtransactions. Two types of processing modes are allowed, one ensuring overall atomicity by requiring compensating transactions at the subtransaction level.

61

III. Sagas Sagas are defined as a set of relatively independent transactions. The transactions in a saga are termed as component transactions. Each component transaction has a dual termed compensating transaction. A predefined order can be defined for the execution of the saga. The transactions belonging to different sagas can be interleaved in any fashion.

62

63

Approaches to Mobile Transaction Models

Reporting and cotransaction Clustering Kangaroo MDSTPM Pro-Motion Prewrite Semantic Time-based Mobile Transaction Two-Tier Replication IOT Bayou New Transaction Management System
64

65

66

67

Snapshot vs. Continuous Query Processing

Traditional (Snapshot) Queries
Answer
Data Query

Continuous Queries
Answer Query Query Data

68 Data

Mobile Database Systems (MDS)

MDS Query processing
Query types

Location dependent query Location aware query

Location independent query

69

Variety of Location-aware Queries

Continuously report the number of cars in the freeway Type: Range query Query: Stationary Time: Present Object: Moving Duration: Continuous What are my nearest McDonalds for the next hour? Type: Nearest-Neighbor query Query: Moving Time: Future Object: Stationary Duration: Continuous Send E-coupons to all cars that I am their nearest gas station Type: Reverse NN query Query: Stationary Time: Present Object: Moving Duration: Snapshot What was the closest dist. between Taxi A & me yesterday? Type: Closest-point query Query: Moving Time: Past Object: Moving 70 Duration: Snapshot

Location dependent query

A query whose result depends on the geographical location of the origin of the query. Example What is the distance of Pune railway station from here?

The result of this query is correct only for here.

Situation: Person traveling in the car desires to know his progress and continuously asks the same question. However, every time the answer is different but correct. Requirements: Continuous monitoring of the longitude and latitude of the origin of the query. GPS can do this. 71

Query Translation Steps in LDQ Processing 1. Determine the validity (and type) of the query and request the location service to provide a location to which the LDQ is to be bound. 2. Find the appropriate level of the location granularity, which will be used by the target content provider, and convert the query into the correct format. 3. If needed, decompose the query for different servers and send each to the target server for processing.

4. Receive the query results and perform any needed filtering to reduce the result set size.
5. Combine results from multiple servers and put into a format 72 desired by user.

73

Agenda
Introducing fundamentals of database recovery and conventional recovery protocols Identifying those aspects of a mobile database system which affect recovery process Discussing recovery approaches which have appeared in the literature
74

Agenda (Cont.)
Similar to other areas such as transaction modeling, concurrency control, etc., database recovery is also in the development stage, so the coverage here is mostly limited to state-of-the art research and little on commercial products
75

Introduction
Database recovery protocols recover a database from transaction or system failures
They store the database to a consistent state from where transaction processing resumes

These failures may occur due to a number of reasons

Addressing error , wrong input, RAM failure, etc.
76

Introduction (Cont.)

In a concurrent execution environment when a failure occurs then a transaction may be Active Blocked Being rolled back In the middle of a commit The task of a recovery protocol is to identify the right operation for each transaction 1. Roll forward or Redo 2. Roll backward or Undo
77

Introduction (Cont.)
To implement these operations, Transaction log is required This log file is generated and maintained by the system The log contains Committed values of data items (Before Image - BFIM) Modified values of data items (After Image - AFIM) The log is a crucial document for recovery It is generated and maintained by a protocol called Write Ahead Logging WAL The protocol guarantees that the content of a log is reliable and can be used for Undo and Redo operations

78

Introduction (Cont.)
After a failure the database system reboots and, by using log, applies Redo and Undo operations on transactions which where in the system when it failed
A Redo completes the commit operation for a transaction, and an Undo rolls back a transaction to maintain atomicity
79

Four different recovery protocols

Undo - Redo This protocol applies Redo and Undo to recover the database systems During transaction execution it can write to the database intermediate values of its data items If the transaction was active when the system fails, then the transaction is Undone It is Redone if the transaction was ready to commit Undo - No Redo Does not support Redo and recovers the database by applying Undo operation only 80

Four different recovery protocols (Cont.)

No Undo Redo Makes sure that no intermediate results of a transaction are installed in the database
No Undo No Redo This protocol does not apply Redo and Undo and recovers the database by using the shadow copy of data items During execution a transaction creates a show copy of data items it modified
81

 Recovery is a time-consuming and resource-intensive operation. The most expensive operation is managing the log This operation is essential for recovery A Mobile Database System (MDS) is a distributed system based on client server paradigm, but it functions differently than conventional centralized or distributed systems.

82

 In any database management system, distributed or centralized, the database is recovered in a similar manner and the recovery module is as an integral part of the database system. Database recovery protocols, are not tampered with user level applications. A system which executes applications, in addition to database recovery protocol, requires efficient schemes for Application recovery.

83

 Application recovery is relatively more complex than database recovery because of

The large numbers of applications required to manage database processing Presence of multiple application states The absence of the notion of the last consistent 84 state

 This gets more complex in MDS because of Unique processing demands of mobile units The existence of random handoffs the presence of operations in connected, disconnected, and intermittent connected modes Location-dependent logging The presence of different types of failure. There are types of failures Hard failure (Can not be easily repaired) Soft failure (Recoverable)
85

 An application can be in any execution state blocked, executing, receiving data slowly, and so on The application may be under execution on stationary units (base station or database server) or on mobile units or on both These processing units(especially the mobile unit), may be Going through a handoff Disconnected In a doze mode Turned off completely
86

 The application may be processing a mobilaction or reading some data or committing a fragment, and so on
If a failure occurs during any of these tasks, the recovery system must bring the application execution back to the point of resumption 87

 In application recovery, unlike data consistency, the question of application consistency does not arise because the application cannot execute correctly in the presence of any error The most important task for facilitating application recovery is the management of log What is needed is an efficient logging scheme

88

Log management in mobile database systems

Log is a sequential file where information necessary for recovery is recorded Each log record represents a unit of information The position of a record in the log identifies the relative order of the occurrence of the event the record represents

89

Log management in mobile database systems (Cont.)

In legacy systems (centralized or distributed) the log resides at fixed locations which survive system crashes This persistence property of log is achieved through the protocol called Write Ahead Logging (WAL) The logging becomes complex because the system must follow the WAL 90 protocol while logging records at various

Log management in mobile database systems (Cont.)

An efficient application recovery scheme for MDS requires that
The log management must consume minimum system resources Must recreate the execution environment as soon as possible after MU reboots

The mobile units and the servers must build a log of the events that change the execution states of mobilaction

91

Log management in mobile database systems (Cont.)

The exact write events dependon the application type the mobile unit records events like
The arrival of a mobilaction The fragmentation of mobilaction The assignment of a coordinator for mobilaction The mobility history of the mobile unit (handoffs, current status of the log, its storage

92

Where to Save the Log?

Schemes that provide recovery in the PCS (Personal Communication System), saves the log at the BS where the mobile unit currently resides
Managing log for PCS failure is relatively easy because it does not support transaction processing The concept can be used to develop 93 efficient logging schemes for MDS

Where to Save the Log? (Cont.)

There are three places the log can be saved:
(a) MSC (Mobile Switching Center) (b) Base Station (BS) (c) Mobile Unit (MU)

The reliability and availability of mobile units, make it a less desirable place to save the log 94 MSC and BS are suitable places

Where to Save the Log? (Cont.)

An MSC may control a large number of BSs in the event of a failure, accessing and processing the log for specific transaction may be time-consuming An MSC is not directly connected to database servers BSs, are directly connected to DBSs and 95

Where to Save the Log? (Cont.)

96

Where to Save the Log? (Cont.)

From connectivity and availability aspects, BSs are comparatively better candidates for saving an application log
Under this setup a mobile unit can save log at the current BS and the BS then can archive it on DBSs
97

Effect of Mobility on Logging

In conventional database systems, the log generation and its manipulation are predefined and fixed A mobiluction may be executed at a combination of mobile units, base stations and fixed hosts If a fragment of mobilaction happens to visit more than one mobile unit, then its log 98 may be scattered at more than one base

Logging schemes
Centralized logging-Saving of log at a designated site A base station is designated as logging site where all mobile units from all data regions save their log Since the logging location is fixed and known in advance, and the entire log is stored at one place, its management (access, deletion, etc.) becomes easier This scheme works, but it has the following

99

Logging schemes (Cont.)

Home logging Every mobile unit stores its log at the base station it initially registers
This scheme has the following limitations: Under this scheme the entire log of mobiluction may be scattered over a number of base stations if its fragments are processed by different mobile units with different base stations It may not work for spatial replicas (location-dependent data) 100

Logging schemes (Cont.)

At a designated base station Under this scheme a mobile unit locally composes the log and, at some predefined intervals, saves it at the designated base station At the time of saving the log a mobile unit may be in the cell of the designated base station or at a remote base station In the second case, the log must travel through a chain of base stations, ending up at the designated base station This will work as long as there is no communication 101 failure anywhere in the chain of base stations

Logging schemes (Cont.)

At all visited base stations In this scheme a mobile unit saves the log at the base station of the cell it is currently visiting The entire application log is stored in multiple base stations, and at the time of recovery all log portions are unified to create the complete log It is possible that two or more portions of the entire log may be stored at one base station if the mobile unit revisits the station

102

Logging schemes (Lazy Scheme)

In lazy scheme, logs are stored on the current base station and if the mobile unit moves to a new base station, a pointer to the old base station is stored in the new base station These pointers are used to unify the log distributed over several base stations This scheme has the advantage that it incurs relatively less network overhead during handoff as no log information needs to be transferred This scheme has a large recovery time because it requires unification of log portions (disadvantage)
103

Logging schemes (Lazy Scheme log unification)

a) distance-based scheme
the log unification is initiated as soon as the mobile unit covers the predefined distance

b) frequency-based scheme
log unification is performed when the number of handoffs suffered by the MU increases above a predefined value

After unifying the log, the distance or

104

Logging schemes (Pessimistic scheme)

The entire log is transferred at each handoff from old to new base station This scheme, combines logging and log unification The recovery is fast, but each handoff requires large volumes of data transfer
105

Mobile Database Recovery Schemes (A Three-Phase Hybrid Recovery Scheme )

All base stations use coordinated checkpointing communication-based checkpointing is used between mobile units and base stations Following steps briefly describe the working of the algorithm The algorithm uses mobile units MU1, MU2, MU3, and MU4, as well as base stations MSS1. MSS2, and MSS3, for describing message traffic

106

Mobile Database Recovery Schemes (A Three-Phase Hybrid Recovery Scheme )

Initially, a coordinator (base station) MSS1 broadcasts a request message with a checkpoint index to MSS2 and MSS3 Each MSS sets up a timer Tlazy. It uses a lazy coordination scheme to reduce the number of messages, therefore, it is especially suitable for mobile database systems. In this approach, infrequent snapshots are taken which only occasionally impose high checkpoint overheads of coordinated snapshots on the low-bandwidth network connecting all mobile units. This approach also prevents the global snapshot from getting out of date; as a result, the amount of computation for recovery from failure is minimized Mobile unit MU2 or MU3, whichever is active, takes a checkpoint before message m2 or m3 arrives from MSS2 or MSS3 during Tlazy
107

Mobile Database Recovery Schemes (A Three-Phase Hybrid Recovery Scheme )

MU1 or MU4 takes a checkpoint when Tlazy has expired, and it receives a checkpoint request from MSS1 or MSS3 MSS2 and MSS3 responds (send a response message) to MSS1 MSS1 broadcasts a commit message to all MSSs after receiving response messages from other base stations MU3 migrates from MSS3 to MSS2 and sends a message to wake MU4 if it is in doze mode MU2 takes a checkpoint before it disconnects itself from the network. If MU2 is already in disconnected mode, then it does not take any checkpoint
108

Mobile Database Recovery Schemes (A Three-Phase Hybrid Recovery Scheme )

In case MU1 fails, it stops executing and sends a recovery message to MSS1 MSS1 broadcasts a recovery messages to all MSSs Each MSS sends recovery message to all its MUs . These MUs roll back to their last consistent state

109

A Mobile Agent-Based Log Management Scheme

A mobile agent is an autonomous program that can move from machine to machine in a heterogeneous network under its own control It can suspend its execution at any point, transport itself to a new machine, and resume execution from the point it stopped execution An agent carries both the code and the application state Actually a mobile agent paradigm is an extension of the client/server architecture with code mobility

110

A Mobile Agent-Based Log Management Scheme (Cont.)

Some of the advantages of mobile agents:
Protocol Encapsulation
Mobile agents can incorporate their own protocols in their code instead of depending on the legacy code provided by the hosts

Robustness and fault-tolerance

When failures are detected, host systems can easily dispatch agents to other hosts

Asynchronous and autonomous execution

Once the agents are dispatched from a host, they can make decisions
111

A Mobile Agent-Based Log Management Scheme (Cont.)

Agents do have disadvantages, and the one which is likely to affect the logging scheme is its high migration and machine load overhead The present scheme uses agent services with the only when needed approach It is not possible to develop a scheme, which optimizes the performance at all 112 levels and in all different situations

A Mobile Agent-Based Log Management Scheme (Cont.)

Recovery schemes improve the performance by targeting to
Minimize the communication overhead Minimize the total recovery time Optimizing storage space So on
113

A Mobile Agent-Based Log Management Scheme (Cont.)

In MDS, the coordinator module resides in the base station It splits mobilaction into fragments if necessary, and it sends some of them to a set of DBSs Mobilactian initiated by mobile unit may use different kinds of commit protocols like 2phase commit or 3-phase commit or TCOT (Transaction Commit on Timeout)
The coordinator module needs to support all of 114 these

A Mobile Agent-Based Log Management Scheme (Cont.)

Some recovery schemes specify that the logs move along with the mobile unit through a multitude of base stations The new base stations should be able to handle the logs in the same way as the previous one did or log inconsistency might result The code which are necessary for recovery and coordination can be embedded in the mobile agents

115

A Mobile Agent-Based Log Management Scheme (Cont.)

The coordinator can be modeled as a mobile agent and can be initiated by the mobile unit itself if necessary If during a handoff the new base station does not support a specific logging scheme, then the agent in the previous base station which supports this can clone itself and the new replica can migrate to the current base station without any manual intervention
116

Architecture of Agent-Based Logging Scheme

An architecture is presented where mobile agents are used to provide a platform for managing logging The architecture supports the independent logging mechanisms It is assumed that each base station supports the functionality of mobile agents

117

Architecture of Agent-Based Logging Scheme

The main components of the architecture are: Bootstrap agent (BsAg): Any agent that wishes to recover should register with the bootstrap agent The base station initiates the bootstrap agent Once loaded, this agent starts all the agents that have registered with it Base Agent (BaAg): This agent decides which logging scheme to use in the current environment Such functionality can be decided by its own 118 intelligence or can be given as an input

Architecture of Agent-Based Logging Scheme (Cont.)

Home Agent (HoAg): This agent handles mobilactions for each mobile unit It is responsible for maintaining log and recovery information on behalf of the mobile unit The mobile unit sends log events to this agent The HoAg is a base station interface to the mobile unit for Mobilactions Coordinator Agent (CoAg): This agent resides at base station and acts as the coordinator for all mobilactions
119

Architecture of Agent-Based Logging Scheme (Cont.)

Event Agent (EvAg): registration of a mobile unit failure of a mobile unit handoff of a mobile unit This approach abstracts away the core base station functions from application recovery support Driver Agent (DrAg): The migration of a mobile agent during a handoff involves the movement of its code and the actual data This might generate considerable overhead, even if the 120 actual log transfer is not much

Interaction Among Agents for Log Management

Interaction of CoAg and HoAg An MU sends Mobilaction to its HoAg, which forwards it to the corresponding CoAg. If the CoAg needs to contact the MU, it does so through the MUS corresponding HoAg. When CoAg sends a write event to the HoAg, it stores it in its local store before sending it to the MU. If any events come to the MU through user input, MU sends the corresponding log messages to the HoAg.

121

Interaction Among Agents for Log Management (Cont.)

Action of agents when handoff occurs The HoAg moves along with the mobile unit to the new base station in a handoff When a handoff occurs, a driver agent (DrAg) is sent along with the necessary log information to the new base station instead of the whole HoAg with all its intelligence for log unification The DrAg has a very light code whose main function is to see whether the code for HoAg is present in the new base station If so, it requests the resident BaAg in the new base station to create an instance of the HoAg for the mobile unit If any compatible code is not present, then the DrAg sends a request to the previous base stations BaAg, which clones the necessary HoAg and sends the copy to the new base station
122

Forward Log Unification Scheme

Since the trace information contains the size of the log stored at different base stations, the HoAg can estimate the time for log unification based on the network link speed and the total log size (Estimated Log Unification Time ELUT) This scheme concentrates on such scenarios where the EFT is not so trivial that the recovery occurs instantaneously Base station detects the failure of a mobile unit and agents do not play any part in such detection

123

Forward Log Unification Scheme (Cont.)

Log unification is started if ( * ELUT) EFT The Unification factor describes what fraction of the log unification will be done by the time the failure time of the mobile unit comes to an end The default value can be kept as 1
124

Forward Notification Scheme

This scheme addresses the issue of time spent in getting the previous base station information from the HLR To minimize this time, a scheme involving forward notifications is proposed When a mobile unit fails in a particular base station and if the actual failure time is not too high, then there is a high probability that the mobile unit will recover in the same VLR or in 125 a BS that is in adjacent VLRs

Forward Notification Scheme (Cont.)

If the mobile unit happens to restart in a non-adjacent VLR, then it must have been extremely mobile and most of the recovery schemes are not designed for such unrealistic situation It is likely that the coordinator could have decided to abort the mobilaction When a mobile unit fails, its corresponding HoAg informs the VLR about this failure

126

 The VLR first changes the status of the mobile unit in its database from normal to failed The VLR then issues a message containing its own identity The adjacent VLRs store these messages until explicit denotify messages are received 127

 Case 1-The mobile unit reboots in the same base station where it crashed :
In this scenario, the HoAg informs the VLR that the mobile unit has recovered The VLR then issues a denotify message to all the adjacent VLRs indicating that the forward notification information is no longer valid The status of the mobile unit is changed back to normal from failed
128

 Case 2-The mobile unit reboots in a different base station but in the same VLR: First the mobile unit registers with the base station and the registration message is logged on to the corresponding VLR This VLR identifies the status of the mobile unit as failed, and then it proceeds as in case 1 and sends denotify messages to the adjacent VLRs The status of the mobile unit is changed back to normal from failed The new base station then proceeds to perform log 129 unification from the previous base station

 Case 3-The mobile unit reboots in a different base station and a different VLR: The mobile unit requests for registration The corresponding VLR identifies the mobile unit as a forward notified mobile unit and returns the identity of the previous base station and the identity of the VLR to the HoAg of the mobile unit in the recovered base station The base station then proceeds to perform log unification from the previous base station Simultaneously, the new VLR sends a recovered message to the previous VLR regarding the recovered status of the mobile unit and also sends a registration message to the HLR regarding the registration of the mobile unit in the new location
130

 The status of the mobile unit is changed to normal from forwarded in the new VLR Upon receiving the recovered message, the previous VLR sends a denotify message to all adjacent VLRs except the one in which the mobile unit recovered and removes the registration of the mobile unit from itself as well In the situation where the mobile unit recovers in a nonadjacent VLR that has not received the forward notifications, the new base station has to get the previous base station information from the HLR and then send the previous VLR a recovered message Upon receiving this message, the previous VLR acts similar to the previous VLR of case 2 The forward notification scheme is unsuitable if the mobile unit suffers failures with a very small EFT
131

SUMMARY
the entire process of chekpointing and logging for recovery are comparatively complex than conventional database recovery There are still quite a few research problems need innovative solutions Until they are resolved the mobile database system will continue to remain in research domain
132

133