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

14. MR-guaranteeexample • 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.

15. WFR-guaranteeexample 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-guaranteeexample • 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.

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 <= 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; 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.

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 O’Neil 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 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.

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

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 => 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 (Balance>0) 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??