8/3/2019 Unit-5 Mobile Computing
1/133
1
8/3/2019 Unit-5 Mobile Computing
2/133
2
Mobile Database Systems (MDS)
MDS Issues Data Management
Hoarding
Data Caching
Adaptation
Transaction Management
Transaction processing
Query processing
Database recovery
To build a truly ubiquitous information processing
system by overcoming the inherent limitations of
wireless architecture.
Objective
8/3/2019 Unit-5 Mobile Computing
3/133
3
Mobile Database Systems (MDS)
A Reference Architecture (Client-Server model)
MSC MSC
DB DB HLR VLR
BSC BSC
DBS DBS
MUBS
MU
MU
BS
MU
BS
MU
Fixed host
Fixed host
PSTN
8/3/2019 Unit-5 Mobile Computing
4/133
4
Mobile Database Systems (MDS)
MDS Applications
Insurance companies
Emergencies services (Police, medical, etc.)
Traffic control
Taxi dispatch
E-commerce
Etc.
8/3/2019 Unit-5 Mobile Computing
5/133
5
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.
8/3/2019 Unit-5 Mobile Computing
6/133
6
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
8/3/2019 Unit-5 Mobile Computing
7/133
7
8/3/2019 Unit-5 Mobile Computing
8/133
8
hoarding - learning sequences
depth level 2
depth level 1
...
Starting
Page1
2
3 4
5 6 7
8 9
Web-based materials are
generally highly interlinkeda net of links
The user browsing path over a
web-based material can beviewed as a hierarchy structure
Depends on users learning
style, natural learning habitsand abilities
...
8/3/2019 Unit-5 Mobile Computing
9/133
9
hoardingwhat 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 learningmaterials
to support offline access of learning content
Often the memory available on the device is not large enoughto 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-fetchingcontent
decide automatically what the user will need
8/3/2019 Unit-5 Mobile Computing
10/133
10
the hoarding process1. Decide (predict) what material the learner will start from;
2. From the materials that are linked to this start pointgenerate a candidate set;
3. Predict which will be the learning sequence or set, that is ofinterest for the user at next depth level and discard the items
that are not of interest from the set (this step is calledpruning)loop until the deepest level;
4. Set priorities to the materials in the hoarding set, based ontheir predicted priority of importance for the next session(higher if the probability the object will be used soon is
high);5. Pre-fetch, starting from the beginning of the ordered list,
putting on the device those objects with bigger priority, untilavailable memory is filled in.
8/3/2019 Unit-5 Mobile Computing
11/133
11
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
Set of LO,
used by the student
in one session
Set of LO,
selected by the
hoarding algorithm
Set of LO, used by the
student in one session
Set of LO, selected by
the hoarding algorithm
Maximize the hit rateNumber of hits divided on number of uploaded
items
Minimize the miss ratepercentage of ineffective requests
8/3/2019 Unit-5 Mobile Computing
12/133
12
8/3/2019 Unit-5 Mobile Computing
13/133
13
Caching is an important technique in the computing world. Most of
us are familiar with cache used for a single processor computer, asillustrated in Figure
In distributed systems and network computing environments, cache
management schemes need to handle two different scenarios.
8/3/2019 Unit-5 Mobile Computing
14/133
14
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.
8/3/2019 Unit-5 Mobile Computing
15/133
15
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 andnetwork computing environments, the most crucial problem for caching
is how to maintain data consistency among the clients and the servers?
8/3/2019 Unit-5 Mobile Computing
16/133
16
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 everytime
8/3/2019 Unit-5 Mobile Computing
17/133
17
For the TTL-based caching strategy, every cached data item isassigned a TTL value, which can be estimated based on thedata items update history. For example, the adaptive TTLapproach in estimates TTL based on the age of a data item.When the user request arrives for a data item x, if data item xsresidence time has exceeded its TTL value, the client sends amessage to the server to ask if x has changed. Based on theservers response, the client may get a new copy of x from the
server (if the data item x has changed since the last time theclient cached x) or just use the cached copy to answer the user'srequest (if the data item x has not been modified since the lasttime the client received a copy of x).
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.
8/3/2019 Unit-5 Mobile Computing
18/133
18
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-every-
time and TTL-based approaches are used in many existing Web
caches.
8/3/2019 Unit-5 Mobile Computing
19/133
19
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
8/3/2019 Unit-5 Mobile Computing
20/133
20
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 datamodification. 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)
8/3/2019 Unit-5 Mobile Computing
21/133
21
The AT (amnesic terminals) approach is similar to theTS approach, but the invalidation reports are the data itemIDs that have changed since the last invalidation report.
Similarly in the SIG (signatures) method, the differenceis that the server periodically broadcasts the signatures of thedata items.
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 invalidationwindow 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.
8/3/2019 Unit-5 Mobile Computing
22/133
22
In case of the stateful approach, the server keeps track of theinformation of the cache contents. These approaches can
also be categorized into synchronous and asynchronousapproaches. There are hardly any schemes in the statefulsynchronous category. One example for statefulasynchronous approach is proposed is AS algorithm. In that
approach, a Home Location Cache (HLC) is maintained forevery client and is used to record the data items cached bythat client and their last modification time. Based on theinformation, the server can generate invalidation reportsdedicated to a particular client cache.
8/3/2019 Unit-5 Mobile Computing
23/133
23
Server is stateless (noinformation about client
cache is maintained) Invalidation reports sentregardless of whether clientshave any data in cache.
Invalidation reports sent
periodically at rate L(synchronous).
Average cache latency is L/2plus network queuing delay.
Traffic on the network is
bursty as queries areaggregated for a period oftime L.
Mobility is supported byassuming a replication ofdata across all stationarynodes (not scalable)
TS/AT
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 aregenerated
Mobility can be transparently
supported by using a mobility aware
network layer ex: mobileIP
AS
8/3/2019 Unit-5 Mobile Computing
24/133
24
8/3/2019 Unit-5 Mobile Computing
25/133
25
8/3/2019 Unit-5 Mobile Computing
26/133
26
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
8/3/2019 Unit-5 Mobile Computing
27/133
27
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...
P bl i h M bili
8/3/2019 Unit-5 Mobile Computing
28/133
28
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!
8/3/2019 Unit-5 Mobile Computing
29/133
29
Adaptation is Key
Highly dynamic environmentadaptationkey 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
End to end argument?
8/3/2019 Unit-5 Mobile Computing
30/133
30
Client Adaptation
Make mobile clients more robust by offeringadaptation
rely on servers when possible
function autonomously if needed
monitor and adjust to current conditionsChange application expectations
8/3/2019 Unit-5 Mobile Computing
31/133
31
Adaptive Applications
applications consume resourcesnetwork bandwidth, CPU cycles, battery power, disk space,
$$$
resources are variable
so
applications adapt use of resources as resource
quality changes
8/3/2019 Unit-5 Mobile Computing
32/133
32
Who Controls Adaptation
The Operating System?
Individual applications?
Both!
Application-Aware Adaptation
8/3/2019 Unit-5 Mobile Computing
33/133
33
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 functionalityodyssey only
one
8/3/2019 Unit-5 Mobile Computing
34/133
34
OdysseyA 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 fidelitychoices (Wardens)
8/3/2019 Unit-5 Mobile Computing
35/133
35
Odyssey Architecture
Upcalls
Interceptor
Odyssey runtime
Application
kernelTsop,
request
Video
warden
WebWarden
viceroy
Sys calls
Odyssey calls
8/3/2019 Unit-5 Mobile Computing
36/133
36
Operational Model Control loop:
Select fidelity
(application)
Place request
(system call)
Detect change
Notify application
8/3/2019 Unit-5 Mobile Computing
37/133
37
Agility
An Odyssey client must estimate the quality ofnetwork paths used by various applications.
Odyssey records:
Round-trip time
Throughput
Odyssey updates its estimates of latency andbandwidth once every half second.
Aside, Nobles group followed up with agility
estimation work for ad hoc networks
8/3/2019 Unit-5 Mobile Computing
38/133
38
Agility (cont.)
8/3/2019 Unit-5 Mobile Computing
39/133
39
Agility (cont.)
8/3/2019 Unit-5 Mobile Computing
40/133
40
Stability Pursuing agility while completely
sacrificing stability can be
counterproductive.
Rapidly switching
Low-fidelity
Variable latency
Stability is properly incorporated byindividual application.
When notifying an application , the viceroy
can include information about the expected
8/3/2019 Unit-5 Mobile Computing
41/133
41
8/3/2019 Unit-5 Mobile Computing
42/133
42
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 mobileapplications)
8/3/2019 Unit-5 Mobile Computing
43/133
43
Types of Context
Computing context includes network connectivity,communication costs, communication bandwidth, and localresources, 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 historyis the recording of computing, user, and
physical context over time
8/3/2019 Unit-5 Mobile Computing
44/133
44
The 5 Ws
Who is the user? Who are the people with whichthe 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
8/3/2019 Unit-5 Mobile Computing
45/133
45
Context Overview
8/3/2019 Unit-5 Mobile Computing
46/133
46
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 digitaldata
Example: association of a particular meeting place and attendeeswith a set of minutes
Example: association of a digital photo with a specific location
8/3/2019 Unit-5 Mobile Computing
47/133
47
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., nearbypeople for transmission of business cards)
Modification of the physical and digital environments
Integration of application with methods forsensing context
8/3/2019 Unit-5 Mobile Computing
48/133
48
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 dropsbelow 60F
Integration of application with methods for sensing context Most difficult part
Ubiquitous sensing of environmental characteristics, such aslocation, temperature, number of human beings nearby, the cat isnear, not widespread
8/3/2019 Unit-5 Mobile Computing
49/133
49
Where Does Context Come From?
Returning to the difficulty point on the previousslide
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
8/3/2019 Unit-5 Mobile Computing
50/133
50
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!
8/3/2019 Unit-5 Mobile Computing
51/133
51
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 THECLOSET IN YOUR BEDROOM)
Service discovery Discovery of nearby services
Well examine service discovery protocols next!
8/3/2019 Unit-5 Mobile Computing
52/133
52
8/3/2019 Unit-5 Mobile Computing
53/133
53
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 MobileTransactions, 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.
Transaction fragments for distribution
8/3/2019 Unit-5 Mobile Computing
54/133
54
MSC MSC
DB DB HLR VLR
BSC BSC
DBS DBS
MUBS
MU
MU
BS
MU
BS
MU
Fixed host
Fixed host
PSTN
Transaction fragments for distribution.
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.
D fi i i A bil i i i f
8/3/2019 Unit-5 Mobile Computing
55/133
55
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 anda 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
8/3/2019 Unit-5 Mobile Computing
56/133
56
A mobile transaction (MT) can be defined as
Tiis a triple ; 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
A li bl T ti M d l
8/3/2019 Unit-5 Mobile Computing
57/133
57
Applicable Transaction Models
I. Open Nested Transactions
II. Split transactionsIII. 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 forconversational transactions.
Ex: a. Reporting and Co-Transactions approach
b. The Clustering Model etc..
8/3/2019 Unit-5 Mobile Computing
58/133
58
a). Reporting and Co-Transactions: The parent transaction
(workflow) is represented in terms of reporting and co-
transactions 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 operationsare also classified as weak and strict.
8/3/2019 Unit-5 Mobile Computing
59/133
59
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 atransaction 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
8/3/2019 Unit-5 Mobile Computing
60/133
60
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 writesets as the input and produces a split:
split-transaction ( Read(A), Write(A), Read(B), Write(B) )
Join transactionthe join-transaction operation is the inverse of thesplit-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. Tmay 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.
8/3/2019 Unit-5 Mobile Computing
61/133
61
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.
8/3/2019 Unit-5 Mobile Computing
62/133
62
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 compensatingtransaction. A predefined order can be defined for the execution
of the saga. The transactions belonging to different sagas can be
interleaved in any fashion.
8/3/2019 Unit-5 Mobile Computing
63/133
63
A h t M bil T ti M d l
8/3/2019 Unit-5 Mobile Computing
64/133
64
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
8/3/2019 Unit-5 Mobile Computing
65/133
65
8/3/2019 Unit-5 Mobile Computing
66/133
66
8/3/2019 Unit-5 Mobile Computing
67/133
67
Snapshot vs. Continuous Query
8/3/2019 Unit-5 Mobile Computing
68/133
68
Continuous Queries
DataQuery
p Q y
Processing
Traditional (Snapshot) Queries
Data
Query
Answer
Query
Answer
Data
8/3/2019 Unit-5 Mobile Computing
69/133
69
Mobile Database Systems (MDS)
MDS Query processing
Query types
Location dependent query
Location aware query
Location independent query
Variety of Location aware Queries
8/3/2019 Unit-5 Mobile Computing
70/133
70
Variety of Location-aware Queries
Query: Stationary
Object: Moving
Continuously report the number of cars in the freeway
Type: Range query
Time: Present
Duration: ContinuousWhat are my nearest McDonalds for the next hour?
Type: Nearest-Neighbor query
Time: Future
Duration: Continuous
Query: Moving Object: Stationary
Send E-coupons to all cars that I am their nearest gas station
Type: Reverse NN query
Time: Present Duration: Snapshot
Query: Stationary
Object: Moving
What was the closest dist. between Taxi A & me yesterday?
Type: Closest-point query
Time: Past
Duration: Snapshot
Query: Moving
Object: Moving
8/3/2019 Unit-5 Mobile Computing
71/133
71
Location dependent query
A query whose result depends on thegeographical 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 theanswer is different but correct.
Requirements: Continuous monitoring of the longitude and latitude
of the origin of the query. GPS can do this.
Query Translation Steps in LDQ Processing
8/3/2019 Unit-5 Mobile Computing
72/133
72
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 toreduce the result set size.
5. Combine results from multiple servers and put into a format
desired by user.
8/3/2019 Unit-5 Mobile Computing
73/133
73
8/3/2019 Unit-5 Mobile Computing
74/133
74
Agenda
Introducing fundamentals of databaserecovery 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
Agenda (Cont )
8/3/2019 Unit-5 Mobile Computing
75/133
75
Agenda (Cont.)
Similar to other areas such as transaction
modeling, concurrency control, etc.,
database recovery is also in thedevelopment stage, so the coverage here
is mostly limited to state-of-the art
research and little on commercialproducts
Introduction
8/3/2019 Unit-5 Mobile Computing
76/133
76
Introduction
Database recovery protocols recover adatabase from transaction or system
failures
They store the database to a consistent state
from where transaction processing resumes
These failures may occur due to anumber of reasons
Addressing error , wrong input, RAM failure,
etc.
Introduction (Cont.)
8/3/2019 Unit-5 Mobile Computing
77/133
77
( )
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
Introduction (Cont.)
8/3/2019 Unit-5 Mobile Computing
78/133
78
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 LoggingWAL
The protocol guarantees that the content of a log is
reliable and can be used for Undo and Redo operations
8/3/2019 Unit-5 Mobile Computing
79/133
79
Introduction (Cont.)
After a failure the database system
reboots and, by using log, applies Redo
and Undo operations on transactionswhich 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
8/3/2019 Unit-5 Mobile Computing
80/133
80
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
diff l
8/3/2019 Unit-5 Mobile Computing
81/133
81
Four different recovery protocols
(Cont.) No UndoRedo
Makes sure that no intermediate results of a transaction
are installed in the database
No UndoNo 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
8/3/2019 Unit-5 Mobile Computing
82/133
82
Recovery is a time-consuming and resource-intensive
operation.
The most expensive operation is managing the log
This operation is essential for recovery
AMobile Database System (MDS) is a distributed system
based on client server paradigm, but it functions differently
than conventional centralized or distributed systems.
8/3/2019 Unit-5 Mobile Computing
83/133
83
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 forApplication recovery.
8/3/2019 Unit-5 Mobile Computing
84/133
84
Application recovery is relatively more
complex than database recovery becauseof
The large numbers of applications required to
manage database processingPresence of multiple application states
The absence of the notion of the last consistent
state
8/3/2019 Unit-5 Mobile Computing
85/133
85
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)
8/3/2019 Unit-5 Mobile Computing
86/133
86
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
8/3/2019 Unit-5 Mobile Computing
87/133
87
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 theapplication execution back to the point of
resumption
8/3/2019 Unit-5 Mobile Computing
88/133
88
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
8/3/2019 Unit-5 Mobile Computing
89/133
89
Log management in mobile database
systems
Log is a sequential file where
information necessary for recovery is
recorded Each log recordrepresents a unit of
information
The position of a record in the logidentifies the relative order of the
occurrence of the event the record
re resents
8/3/2019 Unit-5 Mobile Computing
90/133
90
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
rotocol while lo in records at various
i bil d b
8/3/2019 Unit-5 Mobile Computing
91/133
91
Log management in mobile database
systems (Cont.)
An efficient application recovery scheme
for MDS requires that
The log management must consume minimumsystem 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 ofmobilaction
L i bil d b
8/3/2019 Unit-5 Mobile Computing
92/133
92
Log management in mobile database
systems (Cont.)
The exact write events dependon the
application type
the mobile unit records events likeThe arrival of a mobilaction
The fragmentation ofmobilaction
The assignment of a coordinator formobilaction
The mobility history of the mobile unit
(handoffs, current status of the log, its storage
8/3/2019 Unit-5 Mobile Computing
93/133
93
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
efficient lo in schemes for MDS
8/3/2019 Unit-5 Mobile Computing
94/133
94
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 mobileunits, make it a less desirable place to
save the log
MSC and BS are suitable laces
8/3/2019 Unit-5 Mobile Computing
95/133
95
Where to Save the Log? (Cont.)
An MSC may control a large number of
BSs
in the event of a failure, accessing andprocessing the log for specific transaction
may be time-consuming
An MSC is not directly connected todatabase servers
BSs, are directly connected to DBSs and
8/3/2019 Unit-5 Mobile Computing
96/133
96
Where to Save the Log? (Cont.)
8/3/2019 Unit-5 Mobile Computing
97/133
97
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 canarchive it on DBSs
8/3/2019 Unit-5 Mobile Computing
98/133
98
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 ofmobilaction happens to
visit more than one mobile unit, then its log
may be scattered at more than one base
8/3/2019 Unit-5 Mobile Computing
99/133
99
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 oneplace, its management (access, deletion, etc.)
becomes easier
This scheme works, but it has the following
8/3/2019 Unit-5 Mobile Computing
100/133
100
Logging schemes (Cont.)
Homelogging
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 ofmobiluction may be
scattered over a number of base stations if its fragments
are processed by different mobile units with differentbase stations
It may not work for spatial replicas (location-dependent
data)
8/3/2019 Unit-5 Mobile Computing
101/133
101
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 achain of base stations, ending up at the designated
base station
This will work as long as there is no communication
failure anywhere in the chain of base stations
8/3/2019 Unit-5 Mobile Computing
102/133
102
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 basestations, 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 unitrevisits the station
8/3/2019 Unit-5 Mobile Computing
103/133
103
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 informationneeds to be transferred
This scheme has a large recovery time because it requires
unification of log portions (disadvantage)
Logging schemes (Lazy Scheme
8/3/2019 Unit-5 Mobile Computing
104/133
104
Logging schemes (Lazy Scheme
log unification)
a) distance-based scheme
the log unification is initiated as soon as
the mobile unit covers the predefineddistance
b) frequency-based scheme
log unification is performed when thenumber of handoffs suffered by the MU
increases above a predefined value
After unif in the lo the distance or
Logging schemes (Pessimistic
8/3/2019 Unit-5 Mobile Computing
105/133
105
Logging schemes (Pessimistic
scheme) The entire log is transferred at each
handoff from old to new base station
This scheme, combines logging and logunification
The recovery is fast, but each handoff
requires large volumes of data transfer
M bil D b R S h (A Th Ph
8/3/2019 Unit-5 Mobile Computing
106/133
106
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 thealgorithm
The algorithm uses mobile unitsMU1,MU2,MU3, and
MU4, as well as base stationsMSS1.MSS2, andMSS3,
for describing message traffic
M bil D t b R S h (A Th Ph
8/3/2019 Unit-5 Mobile Computing
107/133
107
Mobile Database Recovery Schemes (A Three-Phase
Hybrid Recovery Scheme )
Initially, a coordinator (base station)MSS1broadcasts a request
message with a checkpoint index toMSS2 andMSS3
EachMSS 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 aretaken 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 unitMU2 orMU3, whichever is active, takes a checkpoint
before message m2 or m3 arrives fromMSS2 orMSS3 during Tlazy
M bil D t b R S h (A Th Ph
8/3/2019 Unit-5 Mobile Computing
108/133
108
Mobile Database Recovery Schemes (A Three-Phase
Hybrid Recovery Scheme )
MU1 orMU4 takes a checkpoint when Tlazy has expired,
and it receives a checkpoint request fromMSS1orMSS3
MSS2 andMSS3 responds (send a response message) to
MSS1
MSS1 broadcasts a commit message to allMSSs after
receiving response messages from other base stations
MU3 migrates fromMSS3 toMSS2 and sends a message to
wakeMU4 if it is in doze mode MU2 takes a checkpoint before it disconnects itself from
the network. IfMU2 is already in disconnected mode, then
it does not take any checkpoint
M bil D t b R S h (A Th Ph
8/3/2019 Unit-5 Mobile Computing
109/133
109
Mobile Database Recovery Schemes (A Three-Phase
Hybrid Recovery Scheme )
In caseMU1 fails, it stops executing and sends a recovery
message toMSS1
MSS1 broadcasts a recovery messages to allMSSs
EachMSS sends recovery message to all itsMUs . These
MUs roll back to their last consistent state
A Mobile Agent Based Log
8/3/2019 Unit-5 Mobile Computing
110/133
110
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 toa 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 theclient/server architecture with code mobility
A Mobile Agent Based Log
8/3/2019 Unit-5 Mobile Computing
111/133
111
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
A Mobile Agent-Based Log
8/3/2019 Unit-5 Mobile Computing
112/133
112
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 machineload 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
levels and in all different situations
A Mobile Agent-Based Log
8/3/2019 Unit-5 Mobile Computing
113/133
113
A Mobile Agent-Based Log
Management Scheme (Cont.)
Recovery schemes improve the
performance by targeting toMinimize the communication overhead
Minimize the total recovery time
Optimizing storage space
So on
A Mobile Agent-Based LogManagement Scheme (Cont.)
8/3/2019 Unit-5 Mobile Computing
114/133
114
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 2-
phase commit or 3-phase commit or TCOT(Transaction Commit on Timeout)
The coordinator module needs to support all of
these
A Mobile Agent-Based Log
8/3/2019 Unit-5 Mobile Computing
115/133
115
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 inconsistencymight result
The code which are necessary for recovery and
coordination can be embedded in the mobile agents
A Mobile Agent-Based Log
8/3/2019 Unit-5 Mobile Computing
116/133
116
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 tothe current base station without any manual
intervention
Architecture of Agent-Based Logging
8/3/2019 Unit-5 Mobile Computing
117/133
117
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 stationsupports the functionality of mobile
agents
Architecture of Agent-Based Logging
8/3/2019 Unit-5 Mobile Computing
118/133
118
Architecture of Agent Based Logging
SchemeThe 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
intelligence or can be given as an input
Architecture of Agent-Based Logging
8/3/2019 Unit-5 Mobile Computing
119/133
119
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
forMobilactions
Coordinator Agent (CoAg):
This agent resides at base station and acts as the
coordinator for all mobilactions
Architecture of Agent-Based Logging
8/3/2019 Unit-5 Mobile Computing
120/133
120
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
actual log transfer is not much
Interaction Among Agents for Log
8/3/2019 Unit-5 Mobile Computing
121/133
121
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 eventto 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.
Interaction Among Agents for Log
8/3/2019 Unit-5 Mobile Computing
122/133
122
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
Forward Log Unification
8/3/2019 Unit-5 Mobile Computing
123/133
123
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 agentsdo not play any part in such detection
Forward Log Unification
8/3/2019 Unit-5 Mobile Computing
124/133
124
o wa d og U cat o
Scheme (Cont.)
Log unification is started if(* ELUT)
EFT
The Unification factor describes whatfraction 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
F d N tifi ti S h
8/3/2019 Unit-5 Mobile Computing
125/133
125
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
a BS that is in adjacent VLRs
Forward Notification Scheme
8/3/2019 Unit-5 Mobile Computing
126/133
126
(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
8/3/2019 Unit-5 Mobile Computing
127/133
127
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 messagesuntil explicit denotify messages are
received
8/3/2019 Unit-5 Mobile Computing
128/133
128
Case 1-The mobile unit reboots in the
same base station where it crashed :
In this scenario, the HoAg informs the VLRthat 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
8/3/2019 Unit-5 Mobile Computing
129/133
129
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 thecorresponding 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
unification from the previous base station
Case 3-The mobile unit reboots in a different base stationand a different VLR:
The mobile unit requests for registration
8/3/2019 Unit-5 Mobile Computing
130/133
130
The mobile unit requests for registration
The corresponding VLR identifies the mobile unit as a
forward notified mobile unit and returns the identity ofthe 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 logunification 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 registrationmessage to the HLR regarding the registration of the
mobile unit in the new location
The status of the mobile unit is changed to normal from
forwarded in the new VLR
U i i h d h i
8/3/2019 Unit-5 Mobile Computing
131/133
131
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 andremoves 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 forwardnotifications, 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 actssimilar to the previous VLR of case2
The forward notification scheme is unsuitable if the
mobile unit suffers failures with a very smallEFT
SUMMARY
8/3/2019 Unit-5 Mobile Computing
132/133
132
the entire process of chekpointing andlogging 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 mobiledatabase system will continue to remain
in research domain
8/3/2019 Unit-5 Mobile Computing
133/133
Top Related