Mobile Computing and Databases - A Survey

1
Mobile Computing and Databases - A Survey

• A presentation by Dharmesh Thakkar based on the
  publication by Daniel Barbara.

2
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??

3
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

4
Where are we?
5
A Mobile Network
6
Unique features of mobile computing

• Asymmetry in the communications
• Bandwidth(Downstream) gtgt Bandwidth(Upstream)
• Even the Bandwidth(Downstream) is limited.
• Frequent disconnections Roaming
• Power limitations
• Screen Size limitation

7
Transaction Management

• ACID Attributes ensured to each transaction by
  any TM. Recap time??
• Atomicity
• Consistency
• Isolation
• Durability

8
Session Guarantees for Weakly Consistent
Replicated Data

• Douglas B. Terry Alan J. Demers
• Karin Petersen Mike J. Spreitzer Marvin M.
  Theimer Brent B. Welch

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

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

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

12
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
  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

13
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 users
  account) user can use the new password anytime.

14
MR-guarantee example

• Without MR-guarantee
• Users 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.

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

16
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
  N1 at Server S2).
• User reads the file and observes his Version
  (N1) 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.

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

18
Escrow Techniques for mobile sales and inventory
applications

• Narayanan Krishnakumar Ravi Jain

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

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

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

22
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.)

23
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 lt Totalm
• Updates to Salesm will be made as operational
  updates instead of value updates.

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

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

26
Transaction Escrow An example

• Initial conditions Total 50 Sales 20 Escrow
  Log T1 1 T21
• Let Transaction T3 want to reserve 10 items.
• Sales Escrow.t1 Escrow.t2 T3 lt Total
• gt 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.

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

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

29
The Dangers of Replication and a Solution

• Jim Gray
• Pat Helland
• Patrick ONeil
• Dennis Shasha

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

31
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 spouses checkbook and the bank ledger.
• 2 Transactions You and your spouse both write a
  1000 check. Problem??
• Easy solution and morale Dont share a bank
  account with your spouse.

32
Replication example (contd.)

• Eager Replication would not permit the account to
  be overdrawn and one of the transactions (your
  or your spouses) 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
  banks copy and bank would reject the update
  causing the overdraft.
• But you have to reconcile on your own.

33
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 gt More
  frequent reconciliation for lazy replication.

34
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).

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

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

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

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

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

40
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 (Balancegt0) and hence the
  transaction fails (dishonored).

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

42
Thank You

• Questions??