1 Multiversion Reconciliation for Mobile Databases Shirish Hemanath Phatak & B.R.Badrinath Presented By Presented By Md. Abdur Rahman Md. Abdur Rahman Abu Hossain

2 Table of Contents u Objectives u Introduction u Relevant Terms R u Database Model for Mobile Database D u Multiversion Reconciliation Algorithm M u Phenomena and Anomalies P u Practical Implementation P u Drawbacks D u New Research Thought u Conclusion

3 Objective and IntroductionObjective: Multiversion concurrency control schemes on a server with reconciliation of updates from disconnected clients. Introduction: u Reconcile transactions in the past. u Snapshot isolation. u Optimistic replication –Locally replicate and perform local updates – Disconnected –Propagate local updates to the system – Reconnection –Conflict detection and resolution scheme

4 Scenario

5 Two Tier Replication u Two kinds of nodes: –Base nodes always connected, always up –Mobile nodes occasionally connected u Data mastered at base nodes u Mobile nodes –Have stale copies –Make tentative updates –Have shared database replica

6 Mobile Node Makes Tentative Updates u Ability to access information from anywhere, any time u Full database system capability u Expensive, low bandwidth connectivity u Updates local database while disconnected u When Mobile node reconnects: Tentative transactions re-done u Saves transactions u Some may be rejected

7 Multiversion & Reconciliation u u Retains multiple versions of each persistent object. u u Maintains the current value of each object as well previous values that it has held. u u Transaction can read previous values of objects if required. u u Reconciliation – –The process of testing serializabilty, conflict resolution, and serialization

8 Snapshot Isolation u u Used in multi-version concurrency control. u T1 executing under SI reads data from a snapshot of the (committed) data as of time start (T1) and holds the results of its own writes in local memory store so if it reads data a second time it will read its own output u An incomplete transaction cannot reveal its results to other transactions before its commitment.

9 Serializability u u The results of running transactions concurrently must be equal to a result gained by running those transactions one at a time in a serial fashion (in any order). u u The simplest way to support transaction semantics is to require that each transaction run to completion before the next one begins. u u This is sub-optimal. Response times get long; short transactions must wait for long ones.

10 Benefits of Multiversioning u Server: w 0 [x 0 ] = 1, w 0 [y 0 ] = 1, c 0, r 1 [x 0 ] = 1, r 1 [y 0 ] = 1, w 1 [x 1 ] = 2, c 1 u Client: downloaded x=1, y=1: r 1 ’[x] = 1, r 1 ’[y] = 1, w 1 ’[y] = 3, c 1 ’, reconcile T 1 ’ u Reintegration: Single version: database state {x=2, y=1} is not consistent with the readset of T1’ {x=1, y=1), server rejects T1’ Single version: database state {x=2, y=1} is not consistent with the readset of T1’ {x=1, y=1), server rejects T1’ Multi version: database state {x 0 =1, y 0 =1}, {x 1 =2, y 0 =1} Multi version: database state {x 0 =1, y 0 =1}, {x 1 =2, y 0 =1} u Here the first snapshot {x0=1, y0=1} is in the past, and consistent with the readset of T 1 ’. So T 1 ’ can now be serialized on this first snapshot. The sample history: The sample history: u Server: w 0 [x 0 ] = 1, w 0 [y 0 ] = 1, c 0, r1’[x 0 ] = 1, r 1 ’[y 0 ] = 1, r 1 [x 0 ]=1, r 1 [y 0 ]=1, w 1 ’[y 1 ’] = 3, c 1 ’, w 1 [x 1 ]=2, c 1

11 The Database Model u Database – collection of data items with versions Definition 1 (Database state and value function): –Database state, D  X x Ž + (X = finite number of versions of data items. –Value function, D  U x  X (maps data items and versions to the actual data items) Definition 2 (Version snapshot function): –Version snapshot function, S: Ž +  D, maps an non negative integral timestamp into a snapshot of the database

12 The Database Model (cont..) u Properties: 1.S(v)  D: every snapshot is a subset of database state 2.  x, v   D   x, v>  S(v), If the data item was written by transaction with timestamp v, then version v of the data item is in S(v). 3.  x, v’   S(v)  v  v’, No data item in S(v) can have version number greater than v  v,v’:  x, v’   S(v)   x, v”   S(v)  v’=v”, Only one version of a data item can be present in a snapshot 5.  v’,v”: v’>v”   x, v’  S(v)   y, v”   S(v)  [  v”’  Ž + :  y, v”’   D  v”’ v’], S(v) has the latest versions of the data items that are less than equal to v.  [  v”’  Ž + :  y, v”’   D  v”’ v’], S(v) has the latest versions of the data items that are less than equal to v.

13 The Database Model (cont..) u u Example: – –Database state D={x0,x1,x2,y2,z0,z1} and – –Value= {  x0, 1 ,  x1, 2 ,  x2, 3 ,  y2, 10 ,  z0, 2 ,  z1, 3  } – –Version snapshot at timestamp 1, S(1)={x1,z1} – –Value snapshot at time stamp 1, Sv(1)=value(S(1))={  x, 2 ,  z, 3  } – –Version snapshot at timestamp 2, S(2)={x2,y2,z1} – –Value snapshot at time stamp 2, Sv(2)=value(S(2))={  x, 3 ,  y, 10 ,  z, 3  }

14 The Database Model (cont..) u Definition 3 (Read, Write, Read-Write Sets): For each transaction T we define three partial value snapshot : RSET V (T) - all data items which were read but not written by T RWSET V (T) - all data items which were read and then written by T WSET V (T) - all data items which were written before they are read by T READSET V (T)= RSET V (T)  RWSET V (T), WRITESET V (T)= RWSET V (T)  WSET V (T)

15 The Database Model (cont..) u Definition 4 (Default Cost Function) C Tc (READSET V (T c ), WRITESET V (T c ), S v in ) = u Definition 5 (Default Conflict Resolution Function) C Tc (READSET V (T c ), WRITESET V (T c ), S v in ) = 0 if READSET V (T c )  S v in  Otherwise WRITESET V (T c ) if READSET V (T c )  S v in Undefinedotherwise

16 Algorithm 1: Multiversion Reconciliation Algorithm

17 Algorithm 1: Multiversion Reconciliation Algorithm Contd. Algorithm 2: The Reintegration Algorithm

18 Phenomena and Anomaly u Phenomena P0 (Dirty Write) Transaction T1 modifies a data item. Another transaction T2 then modifies that data item before T1 performs a COMMIT or ROLLBACK. If T1 or T2 then performs a ROLLBACK, it is unclear what the correct data value should be. u Phenomena P1 (Dirty Read) T1 modifies a data item X. T2 then reads X before T1 COMMIT or ROLLBACK. If T1 then ROLLBACK, T2 has read a data item that was never really existed. u Phenomena P2 (Fuzzy Read) T1 reads a data item X. T2 then modifies or deletes X and commits. If T1 then attempts to reread X, it receives a modified value or discovers that X has been deleted.

19 Phenomena and Anomaly (Cont..) u Phenomena P3 (Phantom) T1 reads a set of data items satisfying some. T2 then creates data items that satisfy T1’s and commits. If T1 then repeats its read with the same, it gets a set of data items different from the first read. u Phenomena P4 (Lost Update) The lost update anomaly occurs when transaction T1 reads a data item and then T2 updates the data item (possibly based on a previous read), then T1 (based on its earlier read value) updates the data item and commits.

20 Phenomena and Anomaly (Cont..) u Anomaly A5 (Data Item Constraint Violation) Suppose C() is a database constraint between two data items x and y in the database. Here are two anomalies arising from constraint violation. u Anomaly A5A (Read Skew) Suppose transaction T1 reads x, and then a second transaction T2 updates x and y to new val­ues and commits. If now T1 reads y, it may see an inconsistent state, and therefore produce an inconsistent state as output. u Anomaly A5B (Write Skew) Suppose T1 reads x and y, which are consistent with C(), and then a T2 reads x and y, writes x, and commits. Then T1 writes y. If there were a constraint between x and y, it might be violated

21 Practical Implementation u u Implemented by Microsoft Exchange Server, Oracle, Borland’s InterBase 4 and PostgreSQL.

22 Drawbacks u System throughput decreases. u Loss of parallelism. u Serialized write transactions (Timestamp based) may be aborted if its write set conflict with other active transactions. u Does not support Distributed Database Concept. u Cascading Rollback. u How many previous snapshots are to be saved not defined.

23 New Research Thought u Can Distributed Database architecture replace the Client-Server architecture ??

24 Conclusion u Conflict Resolution and Detection are decoupled. u Server detects conflicts on reconciling clients by performing serializability testing on locally committed transactions. u Conflict resolution (Conflict Resolution and Cost Function) is the responsibility of the client. u If client does not provide these functions, the server guarantees snapshot isolation to “unmodified” client transactions.

25 Acknowledgement Prof. Iluju Kiringa Thank you Everybody