11

Multiversion Reconciliation for Mobile Databases

Shirish Hemanath Phatak & B.R.BadrinathShirish Hemanath Phatak & B.R.Badrinath

Presented ByPresented By

Md. Abdur RahmanMd. Abdur Rahman

Abu HossainAbu Hossain

22

Table of Contents ObjectivesObjectives IntroductionIntroduction RRelevant Termselevant Terms DDatabase Model for Mobile Databaseatabase Model for Mobile Database MMultiversion Reconciliation Algorithmultiversion Reconciliation Algorithm PPhenomena and Anomalieshenomena and Anomalies PPractical Implementationractical Implementation DDrawbacksrawbacks New Research ThoughtNew Research Thought ConclusionConclusion

33

Objective and Introduction

Objective:Objective: Multiversion concurrency control schemes on a server with Multiversion concurrency control schemes on a server with reconciliation of updates from disconnected clients.reconciliation of updates from disconnected clients.

Introduction:Introduction: Reconcile transactions in the past.Reconcile transactions in the past. Snapshot isolation.Snapshot isolation. Optimistic replicationOptimistic replication

– Locally replicate and perform local updates – DisconnectedLocally replicate and perform local updates – Disconnected

– Propagate local updates to the system – ReconnectionPropagate local updates to the system – Reconnection

– Conflict detection and resolution schemeConflict detection and resolution scheme

44

Scenario

55

Two Tier Replication

Two kinds of nodes:Two kinds of nodes:– Base nodes always connected, always upBase nodes always connected, always up

– Mobile nodes occasionally connectedMobile nodes occasionally connected

Data mastered at base nodesData mastered at base nodes

Mobile nodesMobile nodes – Have stale copiesHave stale copies

– Make tentative updatesMake tentative updates

– Have shared database replicaHave shared database replicaBaseNode

Mobile

66

Mobile Node Makes Tentative Updates

Ability to accessAbility to access information information from anywherefrom anywhere, , any timeany time Full database system capabilityFull database system capability Expensive, low bandwidth connectivityExpensive, low bandwidth connectivity Updates local database while disconnectedUpdates local database while disconnected When Mobile node reconnects: When Mobile node reconnects:

Tentative transactions re-doneTentative transactions re-done Saves transactions Saves transactions Some may be rejectedSome may be rejected

tentativetransactions

base updates &failed base transactions

BaseNode

Mobile

77

Multiversion & Reconciliation

Retains multiple versions of each persistent object.

Maintains the current value of each object as well previous values that it has held.

Transaction can read previous values of objects if required.

Reconciliation– The process of testing serializabilty, conflict resolution,

and serialization

88

Snapshot Isolation

Used in multi-version concurrency control.

T1 executing under SI reads data from a snapshot of the T1 executing under SI reads data from a snapshot of the (committed) data as of time start (T1) and holds the results of its (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 own writes in local memory store so if it reads data a second time it will read its own outputwill read its own output

An incomplete transaction cannot reveal itsAn incomplete transaction cannot reveal its results to other results to other transactions before itstransactions before its commitment.commitment.

99

Serializability

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

The simplest way to support transaction semantics is to require that each transaction run to completion before the next one begins.

This is sub-optimal.Response times get long; short transactions must wait for long

ones.

1010

Benefits of Multiversioning

ServerServer:: w w00[x[x00] = 1, w] = 1, w00[y[y00] = 1, c] = 1, c00, r, r11[x[x00] = 1, r] = 1, r11[y[y00] = 1, w] = 1, w11[x[x11] = 2, c] = 2, c11 Client:Client: downloaded x=1, y=1: r downloaded x=1, y=1: r11’[x] = 1, r’[x] = 1, r11’[y] = 1, w’[y] = 1, w11’[y] = 3, c’[y] = 3, c11’, reconcile T’, reconcile T11’’

Reintegration:Reintegration:

Single version:Single version: database state {x=2, y=1} is not consistent with the readset of database state {x=2, y=1} is not consistent with the readset of T1’ {x=1, y=1), server rejects T1’T1’ {x=1, y=1), server rejects T1’

Multi version:Multi version: database state {x database state {x00=1, y=1, y00=1}, {x=1}, {x11=2, y=2, y00=1}=1}

Here the first snapshot {x0=1, y0=1} is in the past, and consistent with the readset Here the first snapshot {x0=1, y0=1} is in the past, and consistent with the readset of Tof T11’. So T’. So T11’ can now be serialized on this first snapshot. ’ can now be serialized on this first snapshot.

The sample history:The sample history: Server:Server: w w00[x[x00] = 1, w] = 1, w00[y[y00] = 1, c] = 1, c00, r1’[x, r1’[x00] = 1, r] = 1, r11’[y’[y00] = 1, r] = 1, r11[x[x00]=1, r]=1, r11[y[y00]=1, w]=1, w11’[y’[y11’] ’]

= 3, c= 3, c11’, w’, w11[x[x11]=2, c]=2, c11

1111

The Database Model

Database – collection of data items with Database – collection of data items with versionsversions

Definition 1 (Database state and value function):Definition 1 (Database state and value function):

– Database state, D Database state, D X x X x ŽŽ++ (X = finite number of versions of (X = finite number of versions of data items.data items.

– Value function, D Value function, D U UxxX X (maps data items and versions to (maps data items and versions to

the actual data items)the actual data items)

Definition 2 (Version snapshot function):Definition 2 (Version snapshot function):– Version snapshot function, S: Version snapshot function, S: ŽŽ++ D, maps an non negative D, maps an non negative

integral timestamp into a snapshot of the databaseintegral timestamp into a snapshot of the database

1212

The Database Model (cont..) Properties:Properties:

1.1. S(v) S(v) D: every snapshot is a subset of database state D: every snapshot is a subset of database state

2.2. x, v x, v D D x, v> x, v> S(v), If the data item was written by S(v), If the data item was written by

transaction with timestamp v, then version v of the data item is in transaction with timestamp v, then version v of the data item is in

S(v).S(v).

3.3. x, v’x, v’ S(v) S(v) v vv’, No data item in S(v) can have version v’, No data item in S(v) can have version

number greater than vnumber greater than v

v,v’: v,v’: x, v’ x, v’ S(v) S(v) x, v” x, v” S(v) S(v) v’=v”, Only one version v’=v”, Only one version

of a data item can be present in a snapshotof a data item can be present in a snapshot

5. 5. v’,v”: v’>v” v’,v”: v’>v” x, v’ x, v’ S(v) S(v) y, v” y, v” S(v) S(v)

[[v”’v”’ ŽŽ++: : y, v”’ y, v”’ D D v”’< v” v”’< v” v”’ >v’], S(v) has the latest v”’ >v’], S(v) has the latest

versions of the data items that are less than equal to v.versions of the data items that are less than equal to v.

1313

The Database Model (cont..)

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}

1414

The Database Model (cont..)

Definition 3 (Read, Write, Read-Write Sets):Definition 3 (Read, Write, Read-Write Sets):

For each transaction T we define three partial value snapshotFor each transaction T we define three partial value snapshot::

RSETRSETVV(T) -(T) -all data items which were read but not written by Tall data items which were read but not written by T

RWSETRWSETVV(T) -(T) -all data items which were read and then written by Tall data items which were read and then written by T

WSETWSETVV(T) -(T) -all data items which were written before they are read by Tall data items which were written before they are read by T

READSETREADSETVV(T)= RSET(T)= RSETVV(T)(T) RWSET RWSETVV(T), (T),

WRITESETWRITESETVV(T)= RWSET(T)= RWSETVV(T)(T) WSET WSETVV(T)(T)

1515

The Database Model (cont..)

Definition 4 (Default Cost Function)Definition 4 (Default Cost Function)CCTcTc(READSET(READSETVV(T(Tcc), WRITESET), WRITESETVV(T(Tcc), S), Svv

inin))

==

Definition 5 (Default Conflict Resolution Definition 5 (Default Conflict Resolution Function)Function)CCTcTc(READSET(READSETVV(T(Tcc), WRITESET), WRITESETVV(T(Tcc), S), Svv

inin))

==

0 if READSETV(Tc) Svin

Otherwise

WRITESETV(Tc) if READSETV(Tc) Svin

Undefined otherwise

1616

Algorithm 1: Multiversion Reconciliation Algorithm

1717

Algorithm 1: Multiversion Reconciliation AlgorithmContd.

Algorithm 2: The Reintegration Algorithm

1818

Phenomena and Anomaly Phenomena P0 (Dirty Write)Phenomena P0 (Dirty Write)

Transaction T1 modifies a data item. Another transaction T2 then Transaction T1 modifies a data item. Another transaction T2 then modifies that data item before T1 performs a COMMIT or modifies that data item before T1 performs a COMMIT or

ROLLBACK. If T1 or T2 then performs a ROLLBACK, it is ROLLBACK. If T1 or T2 then performs a ROLLBACK, it is unclear unclear what the correct data value should be. what the correct data value should be.

Phenomena P1 (Dirty Read)Phenomena P1 (Dirty Read)T1 modifies a data item X. T2 then reads X before T1 COMMIT or 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 ROLLBACK. If T1 then ROLLBACK, T2 has read a data item that was never really existed.was never really existed.

Phenomena P2 (Fuzzy Read)Phenomena P2 (Fuzzy Read)T1 reads a data item X. T2 then modifies or deletes X and commits. T1 reads a data item X. T2 then modifies or deletes X and commits.

If If T1 then T1 then attempts to reread X, it receives a modified value or attempts to reread X, it receives a modified value or discovers discovers that X has been that X has been deleted.deleted.

1919

Phenomena and Anomaly (Cont..)

Phenomena P3 (Phantom)Phenomena P3 (Phantom)

T1 reads a set of data items satisfying some <search condition>. T2 T1 reads a set of data items satisfying some <search condition>. T2 then creates data items that satisfy T1’s <search condition> and commits. If then creates data items that satisfy T1’s <search condition> and commits. If T1 then repeats its read with the same <search condition>, it gets a set of T1 then repeats its read with the same <search condition>, it gets a set of data items different from the first read.data items different from the first read.

Phenomena P4 (Lost Update)Phenomena P4 (Lost Update)

The lost update anomaly occurs when transaction T1 reads a data 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), item and then T2 updates the data item (possibly based on a previous read), then T1 (based on then T1 (based on its earlier read value) updates the data item and its earlier read value) updates the data item and

commitscommits..

2020

Phenomena and Anomaly (Cont..)

Anomaly A5 (Data Item Constraint Violation)Anomaly A5 (Data Item Constraint Violation)

SupposeSuppose C() C() is a database constraint between two data items x and y in is a database constraint between two data items x and y in the the database. Here are two anomalies arising from constraint violation.database. Here are two anomalies arising from constraint violation.

Anomaly A5A (Read Skew)Anomaly A5A (Read Skew)

Suppose transaction T1 reads x, and then a second transaction Suppose transaction T1 reads x, and then a second transaction T2 T2 updates x updates x and y to new val ues and commits. If now T1 reads y, it may and y to new val ues and commits. If now T1 reads y, it may see an see an inconsistent state, and therefore produce an inconsistent state as output.inconsistent state, and therefore produce an inconsistent state as output.

Anomaly A5B (Write Skew)Anomaly A5B (Write Skew)

Suppose T1 reads x and y, which are consistent with Suppose T1 reads x and y, which are consistent with C()C(), and then a T2 , and then a T2 reads x and y, writes x, and commits. Then T1 writes y. If there were a 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 constraint between x and y, it might be violated

2121

Practical Implementation

Implemented by Microsoft Exchange Server, Oracle, Borland’s InterBase 4 and PostgreSQL.

2222

Drawbacks

System throughput decreases.System throughput decreases.

Loss of parallelism.Loss of parallelism.

Serialized write transactions (Timestamp based) may be Serialized write transactions (Timestamp based) may be

aborted if its write set conflict with other active transactions. aborted if its write set conflict with other active transactions.

Does not support Distributed Database Concept.Does not support Distributed Database Concept.

Cascading Rollback.Cascading Rollback.

How many previous snapshots are to be saved not defined.How many previous snapshots are to be saved not defined.

2323

New Research Thought

Can Distributed Database architecture replace Can Distributed Database architecture replace

the Client-Server architecture the Client-Server architecture ????

2424

Conclusion

Conflict Resolution and Detection are decoupled.Conflict Resolution and Detection are decoupled.

Server detects conflicts on reconciling clients by performing Server detects conflicts on reconciling clients by performing serializability testing on locally committed transactions.serializability testing on locally committed transactions.

Conflict resolution (Conflict Resolution and Cost Function) is Conflict resolution (Conflict Resolution and Cost Function) is the responsibility of the client.the responsibility of the client.

If client does not provide these functions, the server guarantees If client does not provide these functions, the server guarantees snapshot isolation to “unmodified” client transactions.snapshot isolation to “unmodified” client transactions.

2525

Acknowledgement

Prof. Iluju Kiringa Prof. Iluju Kiringa

Thank youThank you

EverybodyEverybody