Transaction Models To Improve Data Availability in Mobile Computing

1
Transaction Models To Improve Data Availability
in Mobile Computing

• References
• A Transaction Model to Improve Data Availability
  in Mobile Computing
• Sanjay Kumar Madria(madrias_at_umr.edu)
• Bharat Bhargava(bb_at_cs.purdue.edu)
• Multi-version Transaction Model to Improve Data
  Availability in Mobile Computing
• Presented by,
• Mohammed Abdul Baseer

2
Overview

• Mobile Architecture
• Constraints in Mobile Computing
• Transactions in Mobile Environment
• Requirements for transaction model in Mobile
  Environment
• Pre-Write Transaction Model
• Multi-version Transaction Model
• Conclusions

3
Mobile Architecture
4
Constraints of Mobile Computing

• Wireless communication
• Low bandwidth
• Frequent disconnections voluntary,not failure
• High bandwidth variability
• Monetarily expensive
• Asymmetric communication between MH and MSS

5
Constraints of Mobile Computing (contd..)

• Unreliable communication
• Mobility
• MH has the ability to move
• MSS is overloaded
• Address migration,hands-off process
• Termination of communication with current MSS
• Establishment of communication with new MSS
• Changing the N/W routing to reflect new MSS

6
Transactions in Mobile Environment

• Mobile transactions are different from their
  counterparts in centralized or distributed
  environments

7
Transactions in Mobile Environment (contd..)

• Long lived transactions- mobility of users, data
  and frequent disconnections
• Might have to split- some operations need to be
  executed at MH and some at MSS
• Need to share their states and partial results,
  hands-off process
• Require communications and computations to be
  supported by MSS

8
Transactions in Mobile Environment (contd..)

• As MH moves from one cell to another, the states
  of transaction, states of previously accessed
  data, location information etc.. Also move
• Need to support and handle concurrency,
  recovery, disconnection and mutual consistency of
  replicated data.

9
Requirements for Transaction Model in Mobile
Environment

• Support the limitations of mobile computing
• Minimize transaction aborts due to disconnection
• Ensure the correctness of operations on shared
  data both at MH and MSS
• Minimize blocking transactions, to reduce
  concurrency and communication cost rise

10
Different Scenarios for Executing Mobile
Transactions

• Mobile transaction processing can be structured
  in one of the three ways
• Mobile host (MH) as I/O device
• Mode of operation MH submits transaction, MSS
  executes and sends back results
• Complete Database Server (DBS) on the MH
• Unrealistic
• Data inconsistent with that present on MSS
• Mobile host with Cached data

11
Pre-Write Transaction Model

• A transaction is a partial order of some read and
  write operations on different data items. Mobile
  transactions are no exception
• Introduce a prewrite operation before a write
  operation makes visible (the exact or abstract)
  the value that data object will have after the
  commit of the transaction

12
Pre-Write Transaction Model

• pre-committed MT has announced all the
  prewrites values and read all the required data
  objects, but has not been finally committed
  (updates on database are not performed).
• A pre-read returns a prewrite value of the data
  object whereas a read returns the result from a
  write operation

13
Pre-Write Transaction Model

• A pre-committed MTs results are made visible at
  MH and MSSs before the final commit
• Shifts the resource consuming part of the MTs
  execution (updates of the database on disk) to
  the MSS
• Pre-committed avoids costly undo or compensating
  action
• MTs are serialized based on their pre-commit
  order.

14
Pre-Write Transaction Model (Few Examples)

• Example1 Long duration transaction application
• House-Construction and House-Buying
  transactions
• Model of House as a prewrite
• Example2 Data Structure Application
• Record delete operator in Hashing
• Storage allocator and de-allocator to work
  concurrently

15
Mobile Transaction Processing with Prewrites

• Case1 MH has limited server capability
• Start___Reads/Prewrite___Pre-commit____Writes____
  _Commit
• Part of transaction Part of
  transaction
• executed at MH
  executed at MSS
• Example News-reporter Transaction (real-time)

16
Mobile Transaction Processing with Prewrites

• Case2 MH has very slow CPU and small memory
  I/O device only
• Examples Image Retrieval Transaction, Stock
  buying and selling transactions

17
Pre-Write Transaction Model(Operation
Compatibility Matrix)

18
Pre-Write Transaction Model( Concurrent
Operations)

• Case 1 Suppose a pre-read is currently being
  executed at MH and at the same time, the
  transaction that has announced the prewrite
  values finally commits at MSS
• T1__________r(x),pw(x)_______pc_______
  w(x)_______c At MSS
• 
  T2____ pr(x) __________ c At MH
• Time

19
Pre-Write Transaction Model( Concurrent
Operations)

• Case 2 Consider a case where a read transaction
  commits at MH after the transaction that
  announced the prewrite operation, has been
  pre-committed.
• T1__________r(x),pw(x)_______pc_______w(x)________
  c At MSS
• T2__________r(x)__________c
  At MH
• Time

20
Pre-Write Transaction Model( Multiversions
versus Prewrites)

• Two versions of data, Prewrite and Write, but
  different from multiversions of data
• Prewrite not a previous or old version, but is
  rather a copy or abstract value of the future
  write version
• Read returns the current or abstract of
  current, not the old version of data
• No Validation phase, but new pre-committed phase
  where transaction doesnt abort

21
Overview

• Mobile Architecture
• Constraints in Mobile Computing
• Transactions in Mobile Environment
• Requirements for transaction model in Mobile
  Environment
• Pre-Write Transaction Model
• Multi-version Transaction Model
• Conclusions

22
Multi-Version Transaction Model

• Mobile Transaction (MT) consists of three states
  of execution
• Start state
• Commit state
• Termination state

23
Multi-Version Transaction Model (contd..)

• Improve concurrency of MTs by making use of the
  time between the commitment of transaction at MH
  and the termination of transaction at MSS

24
Multi-Version Transaction Model (contd..)

• We make use of multiversions of data items, but
  only two versions
• X j0
• X kts(k)
• X j0 ,is the data version written by the mobile
  transaction Tj which has been terminated at MSS
• X kts(k),is the data version written by Tk that
  has been committed at MH but is yet to be
  terminated at MSS

25
Multi-Version Transaction Model (contd..)

• Two different cases of concurrency depending on
  the existence of versions of data items
• Case1 concurrent read-write access to increase
  availability
• Case2 concurrent write-write access to increase
  availability

26
Multi-Version Transaction Model (contd..)

• Case1 concurrent read-write access to increase
  availability

27
Multi-Version Transaction Model (contd..)

• Case2 concurrent write-write access to increase
  availability

28
Multi-Version Transaction Model (contd..)
29
Multi-Version Transaction Model (Locking Protocol)

• Different locks present for any particular data
  item are
• Two read locks
• Write lock , wl(x)
• Verified lock, vl(x)
• The two read locks are
• rl 0(x) , for terminated data item version X j0
• rl ?0(x), for committed data item version X kts(k)

30
Multi-Version Transaction Model (Locking Protocol
contd..)
31
Multi-Version Transaction Model (Locking Protocol
contd..)
32
Multi-Version Transaction Model (Locking Protocol
contd..)

• A read action RiX on a data item X in
  transaction Ti(either local on MSS or a remote
  one initiated by MH) follows the locking protocol
  as follows
• Ti requests a read lock on the data item X.
• MSS grants the rl0i(X) or rl?0i(X) read lock
  corresponding to whether the version Xj0 or
  version Xkts(k)
• Transaction Ti reads the selected version of X
  after obtaining the corresponding read lock
  version.

33
Multi-Version Transaction Model (Locking Protocol
contd..)

• The write action wi(X) on data item X in
  transaction Ti at MH follows the following
  locking protocol
• Ti requests a write lock on data item X
• MSS grants the wli(X), the write lock on data
  item X, if there are no conflicts
• Ti creates a new version Xits(i) for data item X

34
Multi-Version Transaction Model (Read and Write
Rule Constraints contd..)

• The constraints satisfaction is done at MSS each
  time a MH request for a read or writes lock on a
  data item.
• Constraint1
• The read lock request on data item X by the
  transaction Ti (at MH or at MSS) must satisfy
  If there is any other transaction Tj at MSS
  holding wlj(X) lock, then timestamp(Tj) gt
  timestamp (Ti).
• This condition checks for
• No read request is processed violating the Read
  rule.
• Results automatically in maintaining
  serializability of transaction execution at MSS
  and avoids cascade of aborts

35
Multi-Version Transaction Model (Read and Write
Rule Constraints)

• Constraint2
• The write lock request wli(X) or verified lock
  request vli(X) for transaction Ti (at MH or at
  MSS) must satisfy
• a)There does not exist any transaction at MSS
  holding wl(X) or vl(X) (verified lock) and for
  all transaction Tj at MH that holds rl0j(X), the
  timestamp(Ti) ? timestamp(Tj).
• b)If there is any other transaction Tk at MSS
  holding vlk(X) lock, then timestamp(Tk) lt
  timestamp (Ti), where Ti is a requesting verified
  or write-lock on X
• Transactions already having the read locks on
  previous version of data items are not made void
  by assigning a write lock or verified lock to
  another transaction that comes after these
  transactions, thus avoiding transaction aborts

36
Conclusions

• Use of multiversions of data items to improve
  data availability
• Constraint checking before obtaining locks
• Avoids the deadlocks
• Avoids cascade of aborts
• Avoids compensating transactions for recovery
• Working on the Simulation of the proposed model
  to obtain real-time performance statistics

37
Any Questions