Download Mobile Computing and Databases

Mobile Computing and
Databases - A Survey
A presentation by Dharmesh Thakkar based on
the publication by Daniel Barbara.
Outline





Introduction
Session Guarantees for Weakly Consistent
Replicated Data
Escrow Techniques for mobile sales and
inventory applications
The Dangers of Replication and a Solution
Questions??
Introduction



The VISION: “What when …”
The REALITY: Mobile computing is a fact of
life.
The REASON(S): Advent of


Powerful portable computers
Fast and reliable networks
Where are we?
A Mobile Network
Unique features of mobile computing

Asymmetry in the communications





Bandwidth(Downstream) >>
Bandwidth(Upstream)
Even the Bandwidth(Downstream) is limited.
Frequent disconnections & Roaming
Power limitations
Screen Size limitation
Transaction Management
ACID – Attributes ensured to each
transaction by any TM. Recap time??
 Atomicity
 Consistency
 Isolation
 Durability
Session Guarantees for
Weakly Consistent
Replicated Data
Douglas B. Terry Alan J. Demers
Karin Petersen
Mike J. Spreitzer
Marvin M. Theimer
Brent B. Welch
Data storage model



Data is stored and controlled by multiple
database servers (Usually fixed).
Clients (Usually mobile) run application that
desire access to these database servers.
Two main operations on a database are
considered: Read and Write. Each of these
could be performed on a server or set of
servers.
Assumptions



Weakly consistent replicated storage system
i.e. database copies at different servers may
vary.
Weakly consistent systems often allow
conflicting Writes to occur.
Each Read or Write is executed against a
single server's copy of the database.
Problem Definition


A mobile client may choose servers based on
which ones are available in its region and can
be accessed most cheaply.
This with weakly consistent replication model
could confuse the user.
Session guarantees
A session is an abstraction for the sequence of read and
write operations performed during the execution of
an application
 Read Your Writes - read operations reflect previous
writes.
 Monotonic Reads - successive reads reflect a nondecreasing set of writes.
 Writes Follow Reads - writes are propagated after
reads on which they depend.
 Monotonic Writes - writes are propagated after
writes that logically precede them
RYW-guarantee example

Without RYW guarantee




User logs in to ACADEMIC domain.
Changes password & Logs out.
Logs in again with the new password – Access
Denied
By performing updates and checks of
password within the session (lifetime of the
user’s account) user can use the new password
anytime.
MR-guarantee example

Without MR-guarantee




User’s mail client retrieves all new mail messages and
displays summaries of these to the user.
User issues a request to display one of these messages.
User gets a message saying the message does not exist.
The MR-guarantee can be used by the mail reader to
ensure that the second Read is issued to a server that
holds a copy of the message.
WFR-guarantee example
Consider a weakly consistent replicated bulletin
board system where users can post articles or
replies.
WFR-guarantee : Could be used to ensure that
replies to an article can be posted only after the
article has been Read in the session.
MW-guarantee example

Without MW-guarantee




User edits a file and saves it (Version N at Server S1).
User appends contents and saves again (Version N+1 at
Server S2).
User reads the file and observes his Version (N+1) does
not exist (Version propagation resulted in overwrite).
By performing a Write to a server copy only if the
copy includes all previous session Writes would
avoid such a problem.
Implementation overview



DB(S,t) : Ordered sequence of Writes that have been
received by server S at or before time t.
RYW-guarantee: If Read R follows Write W in a
session and R is performed at server S at time t, then
W is included in DB(S,t).
Specifically, a server must be willing to return:



Information about the unique identifier (WID) assigned to
a new Write,
The set of WIDs for Writes that are relevant to a given
Read
The set of WIDs for all Writes in its database.
Escrow Techniques for
mobile sales and inventory
applications
Narayanan Krishnakumar
Ravi Jain
Background




Transaction consists of series of reads and
writes.
In a TP environment, transactions can
concurrently access shared data and hence
correctness needs to be preserved.
Traditional Notion of correctness??
Serializability.
Serializability or Concurrency control


One traditional concurrency control
protocol??
Two-Phase Locking



Transaction acquire read (write) lock on an item
before reading (writing) to it.
Two locks are conflicting if either is write-lock in
which case the transaction aborts or waits.
Transaction cannot acquire a lock after it releases
a lock.
Correctness in replicated scenario


One-copy serializability : The effect of execution of
a set of transactions on the replicated data is
equivalent to some serial execution of the
transactions on a single copy. How can we ensure
this??
Quorum consensus:

A read (write) operation on a data item locks the data item
in a subset of replicas, called read (write) quorum. One
copy serializability is guaranteed if read and write
quorums intersect.
Two-phase commit
Process:
 Coordinator sends prepare message upon which each replica
votes if they can commit or not.
 If all votes are affirmative the transaction is carried out else
aborted.
Disadvantages:
 All participants to be present (Unlikely for mobile).
 It is a blocking protocol. (Coordinator may be mobile).
 At least two rounds of messages between coordinator and
replicas. (Power consumption is an issue.)
Sales Application Details




Totalm - Total # of instances of item m in
stock.
Salesm- Total # of instances of item m sold.
Constraint to be maintained while sales are
made: Salesm <= Totalm
Updates to Salesm will be made as operational
updates instead of value updates.
Traditional Ways



Concurrency control would lock Salesm.
Replicated system: Use Quorum locking
followed by two-phase commit.
Escrow Technique avoids locking the variable
for the entire transaction.
Transaction Escrow



Transaction executes an escrow operation to
reserve the resources it will potentially use.
All successful escrow operations are put in
escrow log.
Before executing an escrow operation the
transaction accesses the escrow log and makes
a worst-case decision to determine if it can
proceed.
Transaction Escrow – An example
Initial conditions [Total = 50; Sales =20] Escrow
Log [T1 =1; T2;1]
 Let Transaction T3 want to reserve 10 items.
 Sales + Escrow.t1 + Escrow.t2 + T3 < Total
=> T3 can proceed.
T3 only obtains a short-term lock on the escrow log to
access and update the log and does not lock the
critical resource for the entire duration of the
transaction.

Site Escrow



Totalm is partitioned across sites (servers).
A transaction T, launched by a user runs only at
one site and can successfully complete if the # of
items required for T does not exceed the #
available at the site escrow.
Each operation of T acquires a lock at site but



The lock is local
Lock can be released after the operation completes.
Traditional locks are released only after transaction
completes.
Reconfiguration protocol could be used to
redistribute the unused instances when required.
Site-Transaction Escrow
Process:


Totalm is partitioned across sites.
Each site uses transactional escrow to allocate &
deallocate instances.
Advantages:



Server allocates locally: Saves time and power
Service handoffs with site escrow require less context
information to be transferred than traditional systems.
In case of limited-bandwidth, the mobile might escrow
instances to a local copy and can perform transactions
safely even in disconnected mode.
The Dangers of
Replication and a Solution
Jim Gray
Pat Helland
Patrick O’Neil
Dennis Shasha
Replication Background

Motivational factors for replication??



Performance
Availability
Types of Replication:

Eager replication :
+
-

No concurrency anomaly
Reduces Update performance
Increases response times
Lazy replication
+
-
-
Improves response times
Stale data versions
Manual reconciliation as no automatic way to reverse committed
transactions.
Replication Example




Joint checking account you share with your
spouse and it has $1000 in it.
It is replicated in 3 places: your checkbook,
your spouse’s checkbook and the bank ledger.
2 Transactions: You and your spouse both
write a $1000 check. Problem??
Easy solution and morale – Don’t share a
bank account with your spouse.
Replication example (contd.)
Eager Replication would not permit the account to
be overdrawn and one of the transaction’s (your or
your spouse’s) would be aborted.
 Lazy replication allows both transactions to occur
but later someone needs to reconcile the accounts.
Wish it was automated??
 Bank uses the master replication scheme. The only
updates that matter to them are the ones on the
bank’s copy and bank would reject the update
causing the overdraft.
But you have to reconcile on your own.

Scalability
Update-anywhere-anytime-anyway replication is
unstable because
 If the number of checkbooks per account
grow by a factor of ten the deadlock or
reconciliation rates rises by a factor of
thousand.
 Disconnected operation and message delays
=> More frequent reconciliation for lazy
replication.
Ideal replication scheme




Provides availability and scalability while avoiding
instability.
Provides mobility i.e. mobile nodes read/update data
while disconnected.
Provides single-copy serializable transaction
execution.
Provides convergence to avoid system-delusion
(Database is inconsistent and there is no way to fix
it).
Two-Tier replication
Two kinds of nodes:
 Mobile nodes – may be disconnected. Store a
replica of the database, may originate
tentative transactions and may be the master
of some data item
 Base Nodes – always connected. Most data
items are mastered at base nodes.
Two-Tier replication
Replicated data items have 2 versions at mobile
nodes
 Master version – Most recent value received
from the object master. May be stale.
 Tentative version – Local object may be
updated by tentative transactions. The most
recent value due to local update is the
tentative value.
Two-Tier replication
Two types of transactions
 Base Transaction – Only on master data and
they produce new master data. Involve at
most 1 connected-mobile node and may
involve several base nodes.
 Tentative Transaction – Work on local
tentative data to produce new tentative
version. Also produces a base transaction to
be run at a later time on the base nodes.
Two-Tier replication



Tentative transactions must follow a Scope Rule:
they may involve objects mastered at the mobile
node originating the transaction or the base nodes.
Local transactions that read/write only local data can
be designed in any way. They cannot read/write
tentative data.
Base transactions generated by tentative transactions
has an acceptance criterion: a test the resulting
outputs must pass for slightly different base
transaction results. E.g. The balance must not go
negative.
Transactions - Connected



A transaction that wants to update an object
makes a lock call to the node owning the
object.
Once the master transaction commits, relica
updates are broadcasted to the slave replicas.
These updates could be time-stamped or sent
in order to avoid stale data updates.
Transactions – Disconnected Example
revisited


Two mobile nodes {you and your spouse}
make tentative transactions of $1000 and the
checks reaching the banks is a request for
tentative update.
The first transaction (check) is committed
(honored). The second transaction (check)
fails the acceptance criteria (Balance>0) and
hence the transaction fails (dishonored).
Key properties of two-tier replication





Mobile nodes may make tentative updates.
Base transactions execute with single copy
serializability hence no system delusion.
A transaction becomes durable when the base
transaction completes.
Replicas at all nodes converge to the base system
state.
If all transactions commute there are no
reconciliations.
Thank You

Questions??