Mobile database

MOBILE DATABASE
4.1 Location and Handoff Management
Prepared by R. Arthy, AP/IT

4.1.1 Location Management
 The location of the mobile unit is
recorded to HLR and VLR
 Mobility Management has two main
task:
 Location Management
 Handoff Management

I Introduction to Location Management
 Objective:
 To minimize the communication overhead due to database
updates
 Three tasks:
 Location Lookup
 Location Update
 Paging
 Cost of update and paging increases as the cell size
increases
 Solution: Location area and paging areas

(contd…)
 Three modes that the mobile node can
operate
 Active mode
 Doze mode
 Power down mode

II Location Lookup

Steps
1. The caller dials a number. To find the location of the called number, the
caller unit sends a location query to its base station source base station
2. The source base station sends the query to the S – LS fro location
delivery
3. S – LS first looks up the VLR to find the location.
4. IF VLR search fails, then the location query is sent to the HLR
5. HLR finds the location of D – LS
6. The search goes to D – LS
7. D – LS finds the address of D – BS
8. Address of D – BS is sent to be HLR
9. HLR sends the address of D – BS to S – LS
10. The address of D – BS is sent to the source base station, which sets up
the communication session

III Location Update

Steps
1. The mobile unit moves to a new registration area which is serviced by a
new location server
2. The new base station sends the update query to new LS
3. The new LS searches the address of the HLR in its local database
4. The new location of the mobile unit is sent to HLR
5. The old location of the mobile unit is replaced by the new location
6. The HLR sends user profile and other information to new LS
7. The new LS stores the information it received from HLR
8. The new LS informs the new base station that location update has been
completed
9. The HLR also sends a message about this location update to the old LS.
The old LS deletes the old location information
10. The old LS sends a confirmation message to the HLRPrepared by R. Arthy, AP/IT

III.1 Forward Pointer Location
Management Scheme
 Objective:
 To minimize network overhead due to HLR
updates
 The pointer at the previous location of the
mobile unit which points to its current location
 The pointer is a descriptor which stores mobile
unit identity and its current location.
 The revisit to a registration area creates a
transient loop

(contd…)

III.1.a Updates using Forward
Pointers
 When MU2 leaves the R1 and moves to R2
then,
 The user profile and the number of forward
pointers created so far by MU2 is transferred
from R1 to R2
 A forward pointer is created at R1 which points to
R2
 This forward pointer can be stored in any of
the BS

(contd…)
 Heuristic based update approach
 Number of pointers created
 Number of search requests
 Based on constant update time

III.1.b Location Search using
Forward Pointer

Steps
 The caller dials the number of destination user
 The source base station sends the query to the source LS for location discovery
 Source LS first looks up the VLR to find the location. If the called number is a
visitor to the source base station, then the location is known and the connection is
setup
 If VLR search fails, then the location query is send to the HLR
 The destination HLR finds the location of destination location server
 The destination HLR sends the location of destination location server to the
source LS
 The source LS finds the first forward pointer and traverse the chain of forward
pointer and reaches the destination server
 The location of current base station is forward to the source LS
 Source Ls transfers the address of current base station and the call is set up

III.1.c. Forward Pointer Maintenance
 Need:
 To remove pointer which have not been used for
some time
 To delete dangling pointers
 Ways to remove pointers:
 Timestamp
 Directed graph
 Dangling pointer – If redundant pointers are
not removed in correct order

Example
R2 – R3
R3 – R4
R4 – R3
R3 – R5

4.1.2 Handoff Management
 Objective:
 To provide continuous connectivity
Degradation Interval

I Introduction
 Types of handoff
 Intra system
 Inter system
 Three steps
 Handoff detection
 Assignment of channels
 Transfer of radio link

II Handoff Detection
 Must properly detect genuine and false
handoff (which occurs because of signal
fading)
 Three approaches
 Mobile – Assisted Handoff (MAHO)
 Mobile – Controlled Handoff (MCHO)
 Network – Controlled Handoff (NCHO)

II.1. Mobile – Assisted Handoff
 Every mobile unit continuously measures the
signal strength data from the surrounding base
station
 And notifies the strength data to the serving base
station
 The strength of these signals are analyzed
 And a handoff is initiated, when the strength of the
neighbor BS > strength of the serving BS

II.2. Mobile – Controlled Handoff
 Mobile unit is responsible for detecting a
handoff
 The MU continuously monitors the signal
strength from neighboring BS and identifies
if a handoff is necessary

II.3. Network – Controlled Handoff
(NCHO)
 The BS monitors the signal strength
used by MU
 If it falls below a threshold value,
the BS initiates handoff

III Assignment of Channels
 Objective:
 To achieve a high degree of channel utilization
 To minimize chances of dropping connection due to
unavailability of channel
 Schemas
 Nonprioritized Schema
 Reserved Channel Schema
 Queuing Priority Schema
 Subrating Schema

III.1. Nonprioritized Schema

III.2. Reserved Channel Schema

III.3. Queuing Priority Schema

III.4. Subrating Schema

IV Radio Link Transfer
 Five link transfer cases for which the
handoff has to be processed
 Intracell handoff
 Intercell or Intra BS handoff
 Inter BS handoff or Intra MSC handoff
 Intersystem or Inter MSC handoff

Intra cell handoff

Inter cell / Intra BS

Inter BS / Intra MSC

Intersystem / Inter MSC

IV.1. Types of Handoff
 Hard Handoff
 Soft Handoff

Mobile Database
4.2. Effect of Mobility on Data Management

Introduction
 Continuous connectivity in mobile space
 Example
 In busy city traffic, carpoolers usually end up
spending a significant amount of time on the
road. Instead of waiting, they can use their mobile
gadget to connect to their corporate database
servers and begin their work. This facility will
minimize the negative effect of communication
delay on productivity

4.2.1 Effect of mobility on the
management of data
 In conventional database and distributed
database the data’s are stationary
 Integration of geographical mobility will
reduce the traveling time

I Data Categorization
 The data distribution in conventional
distributed database systems can be done in
three ways:
 Partitioned
 Partial replication
 Full replication
 In mobility, additionally we have Location –
Dependent Data (LDD)

Location – Dependent Data (LDD)
 It is a class of data values are tightly linked to
specific geographical location
 Example: city, telephone code area, ….
 LID example: Social Security Number (SSN)
 Two types of Query
 Location Dependent Query
 Location Aware Query

Location Dependent Query
 For computing the result
 Example: what is the distance between the
railway station to here?
where I am?

Location – Aware Query
 Includes reference to a particular location
either by name or by suitable geographical
coordinates
 Example: what is the distance between VNR
to MDU?

II Location Dependent Data
Distribution
Data Partitioning

Data Region
 A data region is a geographical region or a
geographical cell and every geographical
point of this region satisfies 1:1 mapping with
data
 Example:
 Hotel chain – same hotel different branch –
different cost

(contd…)
Partial Replication

Effect of Mobility in Atomicity
 Guarantees that partial results of a
transaction do not exist in the database
 Logging approach is not used – several
server is available

Effect of Mobility on Consistency
 Only one correct value for each data object
 Mutual consistency – indicates that all values
of the same data item converge to this one
correct value

Effect of Mobility on Isolation
 Ensures that a transaction does not interfere
with the execution of another transaction
 Fragmentation – ensure isolation
 Data regions – ensure isolation

Effect of Mobility on Durability
 Guarantees the persistence of
committed data items in the DB

Effect of Mobility on Commit
 Location Commit – binds a transaction
commit to a region
 Example:
 Reserve 5 seats in a vegetarian restaurant located
1 mile from here

Effect of Connectivity on
Transaction Processing
 Continuously Connected mode
 Disconnected mode
 Intermittent Connected mode

Mobile Database
4.3. Mobile Transaction Model

4.3.1 Mobile Database System
 It provides full database and mobile
communication functionalities
 It allows a mobile user to initiate transactions
from anywhere and of anytime
 It guarantees their consistency preserving
execution
 It guarantees database recovery

I Properties
 Geographical Mobility
 Connection and Disconnection
 Data Processing Capability
 Wireless communication
 Transparency
 Scalability

II Reference Architecture of a Mobile
Database System

Different Replication Types

III Transaction Execution in MDS
 Parallel processing – to improve system
performance
 Leads to fragmenting a transaction
 Coordinator – manages the set of activities
 3 main ways to implement a coordinator
 Centralized
 Partially replicated
 Totally replicated

Identification of Coordinator in MDS
 A coordinator must have:
 Direct and continuous communication with other
nodes
 Theoretically unlimited and continuous power
and large storage space
 High reliability and availability

Transaction Processing in MDS
 A transaction in MDS can be initiated from a
DBS or from a MU or from both
 When there are more than one nodes involved
in the execution, then the following situation
may arise:
 Origin at MU
 Origin at DBS

(contd…)
 Local execution (MU) – if it cannot be executed at
MU, then there are two option:
 Transfer required data items from DBS to MU
 Distribute transaction to a set of nodes
 Mobility of MU is difficulty task for a coordinator
which requires coordinating and movement of the
MU correctly
 With mobility the following scenarios are possible:
 MU does not move
 MU moves
 Distributed processing and MU moves

(contd…)
 Link can be maintained in two ways:
 Static method
 Dynamic method

IV Need for Mobile Transaction
Model
 Handoff
 The presence of doze mode, disconnected
mode, forced disconnection
 Lack of necessary resources – memory &
wireless channel
 Presence of location data

Execution Model Based on ACID
Transaction Framework
 A transaction is a collection of operations on the
physical and abstract application state
 Geographic Domain:
 The Geographic Domain, G, is the total geographical area
covered by all mobile units of a cellular system
 G = (C1+C2+C3+….+Cn), Ci – area of the cell
 Location:
 A location is a premise point within the Geographical
Domain.
 It represents the smallest identifiable position in the
domain.
 Each location is identified by a specific id, L
 G=Union(L)

Mobile Transaction Model
 HiCoMo: High Commit Mobile Transaction
Model
 Moflex Transaction Model
 Kangaroo Mobile Transaction Model
 MDSTPM Transaction Execution Model
 Mobilaction – A Mobile Transaction Model

HiCoMo: High Commit Mobile
Transaction Model
 It is mobile transaction execution model
 It is mainly for processing aggregate data
stored in a data warehouse which resides in
mobile units
 It is always initiated on mobile units
 They are processed in a disconnection mode
 The results of these transactions are then
installed in the database upon reconnection

(contd…)
 The base database resides on the fixed
network
 It is manipulated by transactions called base
or source transactions
 These transactions are initiated at the fixed
network
 The transaction which is initiated at mobile
units are called HiCoMo

(contd…)
 It is based on the following assumptions:
 The data warehouse stores aggregate data of the
following types: average, sum, minimum and
maximum
 Operations such as subtraction, addition and
multiplication are allowed with some constraints
on their order of application
 The model allows some margin of errors

(contd…)
 The structure of HiCoMo transaction is
based on nested transaction model
 Consistency is satisfied through
convergence criteria
 when the states of the base database and
the data warehouse in mobile units are
identical

(contd…)
 Transaction Transformation Function
 Converts install updates by source transaction.
 Working:
 Conflict Detection
 Base Transaction Generation
 Alternates Base Transaction Generation

Moflex Transaction Model
 It is based on a flexible transaction model
 7 components
 T = {M, S, F, D, H, J, G}
 M = {t1, t2, …, tn}
 S = set of success dependencies between ti and tj
 F = set of failure dependencies
 D = set of external dependencies
 H = set of handoff control rules
 J = set of acceptable join rules
 G = set of all acceptable states of T

(contd…)
 A moflex transaction can be
 Not submitted for execution - N
 Currently under execution – E
 Successfully completed – S
 Failed - F
 An execution of T is regarded as being
complete if its current state exists in set G
 When this satisfied, then T can commit else
can abort

(contd…)
 Location Dependent Query in Moflex
 Example -

Kangaroo Mobile Transaction Model
 It captures both data and the movement of
mobile units
 It is based on split transaction model
 Joey Transaction
 Compensating or split mode

(contd…)
 A KT is initiated by a mobile unit is assigned
with a unique identity
 The initial BS immediately creates a JT with
a UID and becomes responsible for execution
 If handoff – KT is split into two transaction
(JT1, JT2)
 JTs are executed in sequential

MDSTPM Transaction Model
 Multi database Transaction Processing
Manager (MDTPM)
 It supports transaction initiation from mobile
unit
 Uses messaging and queue facilities to
establish necessary communication

(contd…)
 Components:
 Global Communication Manage (GCM)
 Global Transaction Manager (GTM)
 Local Transaction Manager (LTM)
 Global Recovery Manager (GRM)
 Global Interface Manager (GIM)

Mobilaction
 It is capable of processing location –
dependent data in the presence of spatial
replication
 It is composed of a set of sub transactions –
Execution Fragments
 To manage location – based processing, a
new fundamental property called “location
(L)” – it is managed by a location mapping
function

Mobile Database
4.4. Concurrency Control

4.4.1 Introduction
 Need for Concurrency control mechanism
 Data Sharing
 Serializing
 Two – phase locking protocol
 Approaches
 Locking
 Nonlocking

Ways of Locking Data Items
 Locking protocol supports two basic operations:
 Locking
 Unlocking
 Two phases:
 Growing phase
 Shrinking phase
 Three phase for managing two – phase locking
 Locking
 Execution
 Unlocking

(contd…)
 Four different combinations for managing
two – phase locking:
 Simultaneous Locking and Simultaneous Release
 Incremental Locking and Simultaneous Release
 Simultaneous Locking and Incremental release
 Incremental Locking and Incremental Release

(contd…)
 Simultaneous and Simultaneous Release
 Locking, execution and unlocking are applied
atomically
 Next phase begin only when the last phase
competes successfully
 Start and end locking ------> start and end of
transaction ------ start and end of unlocking
 The failure of one phase do not affect other
phase

(contd…)
Simultaneous Locking and Simultaneous Release Protocol

(contd…)
 Incremental Locking
and Simultaneous
Release
 Locking and execution
phases are interleaved
and precede the entire
unlocking phase
 Lock ------ process
-------- lock ----
process ----- unlock
 Deadlock

(contd…)
 Simultaneous Locking and
Incremental Release
 Growing phase is atomic
 Unlock phase is
interleaved with execution
phase
 Locking ---- execution
------ unlock------
execution ------ unlock
 Expensive to manage
cascading than deadlock

(contd…)
 Incremental Locking
and Incremental
Release
 Execution phase is
interleaved with both
locking and release
phase
 Suffers from deadlock
and cascading
 Objective to minimize
transaction waiting time

4.4.2 Multigranularity Locking
 Locking units are of different sizes
 This diversity defines a hierarchy of lockable
granularity
 In this scheme a transaction Ti locks data
items in a hierarchical manner in different
locking modes
 Use – transactions which access and modify
large amount of data

(contd…)
 Five different lock modes
 Read
 Write
 Intention Read – IR
 Intention Write - IW
 Read Intention Write - IRW

(contd…)
Example:

(contd…)
 Suppose a transaction Ti wants to read file3 and
Tj wants to write to R32 . The execution Ti and Tj
goes as follows
 Ti intends to re4ad File3, which a node of the root
database so it applies ir lock to database
 It applies ir lock to Area1
 Finally it applies a r lock to File3
 Tj applies iw lock to database successfully

(contd…)
 It applies iw lock to Area1 successfully
 It cannot apply iw to File3 becase the lock
conflicts with Ti’s lock r
 Ti releases r from File3
 Tj now sets iw on File3 and applies won R32
 Tk wants to read Area1 so it successfully sets ir
on database
 It tries to set r lock on Area 1 but it conflicts with
Tj’s lock (iw)
 It waits for Tj to release its iw lock on Area 1

4.4.3 Heuristic Approach
 Locking protocol – conflict occurs when the
transaction requesting the same data item is
blocked
 Incremental Approach – Deadlock
 Solution – Rollback – increases transaction
waiting time
 Solution – immediately rollback

a. Cautious Waiting
 Improvement over Wound wait (WW) and
Wait – Die mechanism
 Conflict is resolved by rolling back / blocking
one of the conflicting transaction
 Rollback is down based on the transaction
status
 Rollback only when the holder is in a blocked
state

(contd…)
 Properties
 It is non preemptive- it never aborts during the
conflict
 The wait – for graph can have a queue length
greater than one
 It is deadlock free
 It can be optimized if in the conflict transaction,
the amount of resource utilized by the conflicting
transaction is taken into consideration

b. Running Priority
 Blocks if the transaction of holder is running
 Conflict transaction aborts (waits) – others
continue

c. Krishna
 Uses dynamic attributes of conflicting
transactions to resolve conflict
 Transactions during their execution life
inherits a number of attributes
 Example attributes: # of conflicts suffered by
a transaction, # of entities locked by the
transaction, duration the transaction waited
for the desired data time,…

(contd…)
 Dynamic attribute set can be represented as
 DAS = {a1, a2, …
 Conflicting resolution scheme
 Computes priorities of conflicting transaction –
uses this to resolve conflict
 DASj = {a1, a2, …, an}
 DASk = {b1, b2, …, bn}
 Pj and Pk = priorities of Tj and Tk

4.4.4 Non – Locking Based Schema
 To lock or unlock an data item, detection of
deadlock an preventing
 a few thousand instructions have to be
executed each time
 To eliminate these overheads, timestamp
based schemes were used

(contd…)
 Simple timestamping scheme:
 TS(Q)>TS(Ti) = transaction came too late and the
access is not allowed
 Rollback
 Higher timestamp
 Problem: can’t differentiate read and write locks

(contd…)
 Basic Timestamping Scheme:
 Each data items have two timestamp – to resolve
read – write and write – write conflicts
 RTS(Q) compared WTS(Q)

4.4.5. Concurrency Control
Mechanism
 Need for maintaining database consistency
 Mechanism
 Locking – Based CCM
 CCM Based on Epsilon Serializability
 Relationship with ESR

a. Locking – Based CCM
 Two – phase incremental locking and
simultaneous release
 Three different ways:
 Centralized two – phase locking
 Primary copy locking
 Distributed two – phase locking

a. i. Centralized Two – Phase
Locking
 One node is responsible for managing all
locking activities
 Locking request traffic is very high – central
node should be always available
 In a mobile database system, this requirement
limits the choice of central node

(contd…)
 A mobile unit cannot be a central node
because:
 It is a kind of personal processing unit
 It is not powerful enough to manage locking
requests
 It cannot maintain the status of data items
 It is not fully connected to other nodes in the
network
 Its mobility is unpredictable

(contd…)
 Base station is the next choice but there is
problems related mainly with functionality
issues
 A fixed station is attached with the BS
 Problem – Single point failure

a. ii. Primary Copy Two – Phase
Locking
 Eliminates a single point of failure
 Each lock manager is now responsible fir a
subset of data items
 The node executing a part is the transaction
sends lock request to appropriate lock
manager
 Problem – identifying suitable sited for
distributing locking responsibility
 Choice – BS or FH or both

a. iii. Distributed Two – Phase
Locking
 Maximized the extent of lock distribution
 All nodes can serve as a lock manager

a (contd…)
 Include separate database servers connected
to base stations through wired network
 Communication overhead for managing
locking and unlocking requests is another
problem

a. (contd…)
 If a mobile unit makes a lock request on
behalf of a transaction, it executed and then
 It will send the request to lock manager site
 The lock manager will decide to grant or to refuse
the lock and send the result to the mobile unit
 The mobile unit makes the decision to continue
with forward processing or block or rollback
depending upon lock manager’s decision

Distributed HP – 2PL CCM
 Based on two phase locking and extension of
HP – 2PL CCM
 Uses conflict resolution scheme of caution
waiting mechanism to reduce the degree of
transaction roll – backs
 Each BS – lock scheduler

Steps
 On a conflict check the priority of the holder and the requestor
 It Priority (Tr) > Priority (Th) then check the status of (Th). If (Th) is
not committing then check if it is a local transaction
 It (Th) is a local transaction then restart it locally
 If (Th) is a global transaction the restart it globally
 If (Th) is in committing process then it is not restarted rather the (Tr)
is forced to wait until (Th) commits and releases all its lock
 Adjust its Priority of (Th) as follows
 Priority (Th) := Priority (Tr) + some fixed priority level
 If Priority (Tr) <= Priority (Th) then block (Tr) until (Th) commits
and release its locks

b. CCM Based on Epsilon
Serializability
 Tolerates limited amount of inconsistency
 Based on two –tier replication scheme
 Advantage – availability, accommodates the
disconnection problem and is scalable
 Reduces transaction commit time and number of
transaction rejections
 Metric space S is defined as a state space having
the following properties”
 Distance function dist(u,v)
 Triangular inequality
 Symmetry

(contd…)
 BS can broadcast information to all the MUs
I its cell
 A central server holds and manages the
database D = {Di}, i Є N and Di Є S
 di – current value of the data object D
 ni – number of replicas of Di in MDS
 ∆ - amount of change can occur on each
replica at each MU

Steps at a DBS
 ∆i is calculated for each object Di
 A timeout value r is linked with ∆i values of the data
item
 DBS broadcasts the values if (di, ∆i) for each data
item and a timeout r for these values at the beginning
of the broadcast cycle
 The DBS either receives pre – committed
transactions or can receive request transactions
 The DBS serializes the pre – committed transactions
according to their order of arrival

Steps at MU
 MU has the value of (di, ∆i) and the timeout r for
every data item Di it has cached
 MU executes transaction ti. It changes the current
value of Di by ∆i-ti.
 The value ∆i-ti is added ∆i-e. The following cases
are possible depending in the value of ∆i-ti and ∆i-e
 If ∆i-ti <= ∆i and ∆i-e <= ∆i, then ti is committed at MU
and it is sent to DBS for re – execution
 If ∆i-ti <= ∆i and ∆i-e > ∆i, then ti is blocked at MU until
new set of (Di, ∆i) is broadcasted by the server
 If ∆i-ti > ∆i then ti is blocked at MU and submitted to the
server as a request transaction

c. Relationship with ESR
 The mechanism for maintaining ESR has two
methods:
 Divergence Control (DC)
 Consistency Restoration (CR)

Mobile Database
4.5. Transaction Commit Protocol

Introduction
 The entire process of commit has two
phases:
 Checking the intention of each node
participating in the execution of a
transaction
 Collecting the intensions of
participants and committing the
transaction

Two – Phase Commit Protocol –
Centralized 2PC
 Assumption – a distributed database system with
multiple nodes
 Coordinator fragments Ti and distributes then to a
set of participants
 The coordinator may or may not keep the fragments
for itself
 The protocol makes sure of the following:
 Participants’ decision
 Decision change
 Coordinator’s decision
 No Failure
 With failure

(contd…)
 Steps:
 Transaction fragmentation and distribution
 Voting Phase
 Voting
 Participants’ vote
 Decision Phase
 Commit decision and dispatch
 Participants decision

Node Failure and Timeout Action
 Occurrences of infinite wait because of node
failure
 One scheme – timeout action
 How long a participant to wait
 Coordinator sent commit – reaches subset of
participants
 To handle immature abort by a timeout,
cooperative termination protocol can be used

Cooperative Termination Protocol
 Two options:
 Ask the coordinator about its last message
 Ask one of its neighbor participants
 To evaluate the cost of communication, two
parameters are used
 Time complexity
 Message complexity

Linear or Nested 2PC
 In linear 2PC the message complexity is
reduced by collecting votes serially

Mobile Database
4.6. Mobile Database Recovery

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 occurrences of the
event the record represents
 Property – Write Ahead Logging (WAL)

Where to Save the Log?
 MSC
 BS
 MU

Logging Scheme
 Centralized Logging – Saving of log at a designated
site
 Drawback
 It has very low reliability
 Logging may become a bottleneck
 Home Logging
 Drawback
 Scattered over a number of base stations
 It may not work for Location dependent data
 Poor availability

(contd…)
 At all visited base stations
 Log is saved at the BS of the cell it is currently
visiting
 Lazy scheme
 Pessimistic scheme
 Logs are stored on the current BS and if the MU
moves to a new BS, a pointer to the old BS is
stored in the new BS
 It has a large recovery time because it require
unification of log portions

Mobile Database Recovery Schemes
 Three – phase Hybrid Recovery Scheme
 Low – Cost Checkpointing and Failure Recovery
 A Mobile Agent – Based Log Management Scheme
 Architecture of Agent – Based Logging Scheme
 Interaction among agents for log management
 Forward strategy
 Forward Log Unification Scheme
 Forward Notification Scheme

Three – Phase Hybrid Recovery
Scheme

Low – Cost Checkpointing and
Failure Recovery

A Mobile Agent – Based Log
Management Scheme
 Mobile agent is used
 MA – is an autonomous program that can
move from machine to machine in a
heterogeneous network under its own control
 Advantages of MA
 Protocol Encapsulation
 Robustness and fault – tolerance
 Asynchronous and autonomous execution

Architecture of Agent – Based
Logging Scheme
 Components
 Bootstrap Agent
 Base Agent
 Home Agent
 Coordinator Agent
 Event Agent
 Driver Agent

Interaction Among Agents for Log
Management
 Interaction of CoAg and HoAg
 Action of agent when handoff occurs

Mobile database

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mobile database

Similar to Mobile database (20)

More from ArthyR3

More from ArthyR3 (20)

Recently uploaded

Recently uploaded (20)

Mobile database