A Transaction Model for Mobile Computingpeople.cs.vt.edu/~irchen/6204/paper/MAD98-slide.pdfA...

1

1

A Transaction Model for Mobile Computing

S. K. Madria and B. Bhargava

Presented byWeiping He, Yunxian Zhou, Dazhi Jiao

2

Introduction

This paper presents a prewriteoperation before a write operation in mobile transactions to improve data availability during disconnectionIt is difficult to maintain shared data

consistency in mobile computing because of limitations of wireless communications .

2

3

Difference of transactions in mobile and common environment

Some operations execute on MH while others on fixed host. A transaction share their states and partial results with other transactions due to disconnection and mobility.The transactions need fixed hosts’ computations and communications support.

4

Difference of transactions in mobile and common environment(cont’d)

The states of transaction, states of accessed data objects, and the location information move with MHs.Due to the mobility of both data and users, due to frequent disconnections, the transactions need be long-lived.

3

5

Difference of transactions in mobile and common environment(cont’d)

The mobile transactions should support and handle concurrency, recovery, disconnection and mutual consistency of the replicated data objects.

6

Limitations of Mobile Computing

Unreliable communication, Limited battery life, Low band-width communication,Reduced storage capacity .

4

7

Objective of Transaction Processing Models

Minimize aborts due to disconnection.Ensure shared data correctness on both stationary and mobile hosts.Minimize the blocking of transactions on either the stationary or mobile hosts.

8

Objective of Transaction Processing Models (cont’d)

Allow transactions to be processed and committed on the MH despite temporary disconnection.Increase data availability at mobile and stationary hosts.

5

9

Main features of the proposed transaction model

Prewrite operation before write operation.The transaction precommits at MH after all the prewrites have been processed. The precommitted results are visible at mobile and stationary hosts before the final commit, which can minimize the blocking of other transactions and increase concurrency.

10

Main features of the proposed transaction model (cont’d)

After announcing prewrite values, MHsshift resource consuming part to fixed host to reduce computing cost on MHs.A pre-committed transaction is guaranteed to commit to avoid an undo or compensating transaction.

6

11

Main features of the proposed transaction model (cont’d)

Pre-read returns prewrite value while read returns write value.The transactions are serialized based on their pre-commit order. Transactions which can not be serialized or deadlocked are aborted before precommit.The model deals efficiently with the constrained resources in mobile environment.

12

Mobile ArchitectureData Managers

Transaction Managers

Mobile Support Stations

Mobile Hosts

Wireless Link

7

13

Existing Mobile TransactionProcessing Models

Extended semantic processing modelUsing fragmentability of data objects to

facilitate semantic based transaction. The scheme fragments data objects and caches them independently and manipulate them synchronously.

14

Existing Mobile TransactionProcessing Models (cont’d)

Extended semantic processing model (cont’d)

Suitable for: data objects can be fragmented. (stack, queue).

Shortcoming: require caching large portion of database or maintain multiple copies of many data items.

8

15


optimistic concurrency control based schemescached objects on MHs can be updated without coordination but the updates need to be propagated and validated at the servers for the commitment of transactions.

16


optimistic concurrency control based schemes (cont’d)Shortcoming: leading to aborts of transactions if there is a conflicts.

9

17


pessimistic schemescached objects can be locked exclusively

and transactions can be committed locally.

18


pessimistic schemes (cont’d)Shortcoming:(1) Can lead to unnecessary blocking since MH

can not release any cached objects while it is disconnected.

(2) Caching of large objects over low bandwidth channels can result in network congestion and high communication cost.

10

19


pessimistic schemes (cont’d)Shortcoming:(3) The objects to be cached can exceed

the memory size of MH.

20


Dynamic object clusteringUsing weak-read, weak-write, strict-read

and strict-write.Strict-read and strict-write are the same

as normal transactions satisfying ACID properties .

A (Atomicity) C (consistency)I (Isolation) D (Durability)

11

21


Dynamic object clustering (cont’d)A weak-read returns a locally cached object

written by a strict-write or a weak-write.A weak-write only updates a locally cached

object, it can become permanent on cluster merging if the weak-write does not conflict with any strict-read or strict-write.

22


Dynamic object clustering (cont’d)Local commit < --- > pre-commitGlobal commit < --- > final-commitShortcoming: a weak transaction after

local commit can abort and is compensated. While the proposed model does not.

12

23


Isolation-only transactions (IOT).It can detect and resolve read/write

conflicts and provide isolation.Shortcoming: not guarantee failure

atomicity and only conditionally guarantee permanence.

24


Open nested transaction modelModel transaction as a set of

subtransactions.Allow transactions to be executed on

disconnection.Support one-side commitment of

subtransactions and compensating transactions.

13

25


Open nested transaction model (cont’d)

Shortcoming: 1. Not all the operation are

compensated.2. Compensation is costly.

26


kangaroo transaction (KT) modelwhen a hop occurs, The transaction is

splitted, a split transaction divides an ongoing transactions into serializable subtransactions. Earlier created subtransaction is committed and the second subtransaction continues execution.

14

27


kangaroo transaction(KT) model(cont’d)The model uses global and local

transactions to capture transactions’ data behavior and relies on compensating transaction in case a transaction aborts.

28

The proposed model compared with Kangaroo model

1. With the option of either using nested transactions or split transactions.

2. the save point or split point of a transaction is explictly defined by the use of precommit, Which allows the split point to occur in any of the cell.

15

29

The proposed model compared with Kangaroo model (cont’d)

3. the earlier subtransaction after pre-commit can still continue its execution with the new subtransaction since their commit orders are based on pre-commit point.

4. No need for compensatry transaction.

30


Some papers propose a new correctness criterion that are weaker than the serializability, which can cope more efficiently with wireless communications. (allows all the operations invoked by one transaction and not related to other transactions to be committed/aborted )

16

31


Some papers use prewrite operations in nested transaction environment to increase concurrency and to avoid undo or compensated operations. The notion of a recovery point subtransactionhas been introduced. In a nested transaction tree, if a recovery-point subtransactionexecuted successfully, its effects will not be discarded.

32

Prewrite Transaction Model

Features:

• Prewrite announce values to be committed

•Read all + prewrite all à precommit

•Prereadßprewrite; Readßwrite; No abortion of weak read

17

33

Prewrite Transaction ModelFeatures(cont’d):•Diff(Prewrite, write) = C where C >= 0 and small enough to be ignored.

Semantics of prewrites:•Simple data objects prewrite matches write values

•Database files prewrite only contains primary key and new record values•Design objects prewrite represents a design model, which may be slightly different from the final one

•Document Objects prewrite represents a document abstract.

34


Features(cont’d):•Two phase lockingàread all ahead;

Prewrites data in Transaction’s private workspace

Precommit data in Prewrite buffer

Prewrite&preread at Transaction Manager level(TM)

Physical writes and reads at Data Manager level(DM)

•Transaction commit order based on precommit action

18

35


•Prewrite lock write lockupon precommit

Features(cont’d):

•T: --- r(x) pw(x) pc --- --- --- cw(x)

No abortion of a precommitted transaction

( R-read; pw-prewrite; pc-precommit; w-write; pr-preread; c-commit )

36


Features(cont’d):T1___r(x), pw(x)__pc__w(x)_____c

T2____pr(x)___c

1) No abortion of precommited transaction, so if T1 aborts after T2 commits, there is no cascadingaborts or compensation transactions.

2)In case the abortion of precommited transaction forced by system reasons, prewrite and write logs are saved in the stable storage

19

37


Features(cont’d):Relax isolation property by data availability after precommit; Guaranteed prewrite durability at theprecommit point

38

MHMSS

1’ Read Cache

1.1 Request for reads

1.2 Prewrites or Writes

3 Precommited transaction

2 Declare all prewrites and precommits

4 Continue the left transaction

Prewrite Mobile Transaction ModelCase 1: MH has some power (concurrency control,

logging, precommit execution)

20

39

Reporter

MSS Fixed NetworkNewspaper Office

MHReporter

Reporter

SH/MH

SH/MH

SH/MH

1 Headline Report

2 Reservationsin hospital

2 Reservations in Airline 2 Other

Transactions

3’ Contact other Reporters to file the full story

3’ Contact other Reporters to file the full story

3.1 Complete the full story on disconnection

3.2 Send the full report upon reconnection

Example:

40

Prewrite Mobile Transaction Model

Case 2: MH has poor computing resource

MHMSS

1 Submit transaction

2.1 Required values2.2 Declare all prewrites and precommit

3 Prewrites or Writes

21

41

Mobile Transaction Model and Partially Replicated System

Cell1 x

Cell2 y

T: __r(x) r(y)pw(x) pw(y) pc____ w(x) w(y) c__

w(x)w(y) c__

Issue: MH does not precommit until it reaches Cell2, it will block other transactions in Cell1.

42


Cell1 x

Cell2 y


w(x) w(y) c__

Solution1: Get all the locks(r(x),pw(x),r(y),pw(y)) and then pc on cell1.

!Severe delay in case the link down after MH obtaining some locks.

22

43


Cell1 x

Cell2 y

Solution2: Nested transaction approach

T: __r(x) pw(x) r(y) pw(y) pc____ w(x) w(y) c__pc____ w(x) c__T:

r(y) pw(y) pc____ w(y) c__Tnew:

__w(x) c__ __w(y) c__

After hand-off

44


Cell1 x

Cell2 y

Solution3: Split transaction approach


T1: Operations on xT2: T – T1

Move to new cell

T1: operations on x T2: T – T1

23

45

Concurrent Operations and Locking

Operation-Compatibility Matrix.Case StudyThe Locking ProtocolMobile Transaction Processing Algorithm

46

Operation Compatibility Matrix

NoYesNoYesWrite

YesNoYesNoPre-write

NoYes *YesYesRead

YesNoYesYesPre-read

WritePre-write

ReadPre-read

* No in the paper.

24

47

Case 1

A pre-read is currently being executed at MH At the same time, another transaction which has announced the pre-write values finally commits at MSS (final updates are performed).

T1

T2

------- r(x) pw(x) pc------- -------

pr(x)

w(x)

-------

-------

-------

c

c-----

Returns T1’s pw (x)

48

Case 2

In table 1, observe that a read operation is compatible with a pre-write. Consider a case where a read transaction commits at MH after the transaction who announced the pre-write operation has been pre-committed.

T1

T2

------- r(x) pw(x) pc------- -------

r(x)

w(x)

-------

-------

--------

c

c

25

49

Two-Phase Concurrency Control

First phase:Ø Controls Pre-read and Pre-write.Ø Performed at TM level.Ø At MH or MSS.Second Phase:Ø Controls Read and Write. Ø Performed at the DM levelØ At MSS.

50

The Locking Protocol

Pre-read-LockRead-LockPre-write-LockWrite-Lock

26

51

Pre-read-Lock(X)

Grant the requested preread-lock to a transaction T on X if no other transaction holds a pre-write-lock on X.

YesNoYesYesPre-read

WritePre-writeReadPre-read

52

Read-Lock(X)

Grant the requested read-lock to a transaction T on X if no other transaction holds a write-lock on X.

NoYesYesYesRead


27

53

Pre-write-Lock(X)

Grant the pre-write-lock to a transaction T on X if no other transaction holds a pre-write- or pre-read-lock on X.

YesNoYesNoPre-write


TM DM

54

Write-Lock(X)A request to update a pre-write- lock on X held by a transaction T to write- lock on X is granted as follows:

NoYesNoYesWrite


If the write-lock-wait queue for X is empty then

Begin

Begin

If the transaction T is pre -committed And no other transaction holds a read- or write-lock on X Then

convert pre-write-lock to write-lock;

End;End;

End;

put the transaction T in a write-lock-wait queue for X;

ElseBegin

28

55

Mobile Transaction Processing Algorithm

1. A transaction T is submitted to the mobile host.2. Mobile host analyzes the transaction T to find

out about its read and write requests (we assume here that MH has some server capability).(/*pre-commit part of the algorithm executed at MH*/)

56

Mobile Transaction Processing Algorithm (cont’)

3. If the transaction T has read and write operations thenBegin

For all reads and writes ∈ TMH sends a request to MSS for all the

required read values and request for pre-write- locks;After MSS acquires the necessary read-

locks, it returns read values to MH (return values will be pre-write value. If no pre-write value is found, the write values are returned

29

57


3. (Cont’)For all writes ∈ T

BeginAnnounce all the prewrite values at

MH (without waiting for prewrite- locks);Store the prewrite logs at MH;Write pre-commit log record and

destination move log record;Send prewrite values, prewrite logs

and other log records to MSS;

58


3. (Cont’)If MSS acquired all prewrite-locks for all the data objects

for which prewrite values have been announced thenBegin

MSS accepts the prewrite values and logs;MSS update the prewrite-lock to write-lock

provided no other transaction holds conflicting locks (see figure 5);End;

elsethe prewrite values and corresponding logs are

discarded at MH;End;

End;

30

59


4. For each prewrite announced (/*post pre-commit algorithm executed at MSS*/)

BeginUpdate those data objects in the

database for which prewrites have been announced;

Store necessary log records;End;

60

Mobile Transaction Processing Algorithm

MHMH MSSMSS

T Read: r(x)

Write: w(y)Request x, pw-L(y)

Acquires r-L(x)Returns x

Announce pw(y) /*without pw-L(y)*/

Logging:Øpw log Øpc log Ødestination move log

pw(y), logs

? pw-L(y) acquired

Analyzespw(x)

or w(x)

No! discard pw(y) & logs

Yes: Accepts pw(y)update pw-L(y) to w -L(y)

Update y in DB.Store log records.

For all Reads and Writes

For all Writes

31

61

Other Issues

No deadlocks after precommitting.pw ---- pc ---- wpw-L w-L

ReplicationDepends on replication algorithm.Ø ROWA (Read-One-Write-All)Ø Majority Consensus

Ordered!

62

Conclusion

A mobile transaction model using pre-write.Shift execution from the MH to MSS for database updates -- minimizes the computing expenses at MH.Transaction executed at MH and MSS during disconnection without blocking –increases availability.

32

63

Future Work

Crash recovery algorithm.Implementations issues.Formal correctness proof.

64

Thank you!

Date post:	20-May-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

A Transaction Model for Mobile Computingpeople.cs.vt.edu/~irchen/6204/paper/MAD98-slide.pdfA...

Documents