Mobile Computing and Databases - A SurveyA 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 ManagementACID – 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 guaranteesA 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 non-decreasing 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 exampleConsider 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 applicationsNarayanan 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 commitProcess: 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 EscrowProcess:

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 SolutionJim 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.

ScalabilityUpdate-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 replicationTwo 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 replicationReplicated 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 replicationTwo 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??