Transaction Models To Improve Data Availability in Mobile Computing

1. References: A Transaction Model to Improve Data Availability in Mobile Computing Sanjay Kumar Madria(madrias@umr.edu) Bharat Bhargava(bb@cs.purdue.edu) Multi-version Transaction Model to Improve Data Availability in Mobile Computing Presented by, Mohammed Abdul Baseer Transaction Models To Improve Data Availability in Mobile Computing

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 MT’s results are made visible at MH and MSSs before the final commit • Shifts the resource consuming part of the MT’s 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-read Read Pre-write Write Pre-read Yes Yes No Yes Read Yes Yes Yes No Pre-write No Yes No Yes Write Yes No Yes No 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 doesn’t 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 Tjwhich 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 Ri[X] 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) > 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 T­k at MSS holding vlk(X) lock, then timestamp(Tk) < 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