1. Lecture 6 Lecture06 Mobile Database and Transactions 第 6 讲 移动数据库与事务 §6.1 Mobile Database §6.2 Mobile Transactions §6.3 Mobile Database Products

2. Lecture 6 What’s Mobile Database?  Two meanings to mobile database  Access to database from mobile clients: more common meaning Access from mobile clients to fixed centralized database, perhaps via a base station or proxy. Capable of reusing much existing technology.  A database system that is itself moving: more challenging A powerful mobile client may carry a database with it. That is possible since even a SmartPhone can have a storage of 32GB. Smart cards may also have their record storage systems associated that support simple SQL-like query.

3. Lecture 6 Mobile Database – g eneralizing:  A mobile database system is a distributed system that support connectivity from mobile clients, with full database system capability, allows mobile units complete their spatial mobility using wireless communication technology.  A database is available that mobile clients can access, even when they are moving.  The database may reside on a mobile client.  Connection is made via wireless links.

4. Lecture 6 Mobile Database web server computer system database server database server base station base station wired link wireless link mobile client local database

5. Lecture 6 Transaction  A transaction is ensuring that the updates to a shared data structure are done in a way that appears to be mutually exclusive, even though the updates may be executed interleaved.  A transaction is a sequence of code in execution (i.e., a process), such that The code, when executed alone (without any other concurrent process), will transform a database (or server state) from one consistent state to another consistent state. In other words, if a single transaction is allowed to complete, it has an atomic effect on the database or server state. Saving := Saving – 1000; Checking := Checking + 1000; Transaction

6. Lecture 6 ACID 1.Atomicity: all-or-none. Either the whole transaction is executed and the changes completely reflected in the database, or no part is executed and the database remains unchanged. 2.Consistency: correctness. If executed alone, a transaction must bring the database from one consistent state to another consistent state. 3.Isolation: non-interference. Each transaction appears to be indivisible with respect to one another. Even if several transactions are executing concurrently, they will not interfere with one another. 4.Durability: permanence. The effects of all committed (completed) transactions must remain in the database.

7. Lecture 6 Transaction  A transaction is an instance of the execution of a transaction program.  A transaction is composed of a sequence of operations, some of them taking effect on the database state.  Two outcomes are possible from the execution of a transaction: commit and abort. Commit means successful installation of effects for all operations in an atomic step. Abort means something bad has happened and none of the operations takes effect.  Client may unilaterally kill a transaction, thereby abolishing all partial results.

8. Lecture 6 Transaction  An example of a transaction T for withdrawal: T: begin bal := read(account); newbal := bal  amt; write(account, newbal); dispense money; end; Note that except account, all other variables are temporary variables or parameters. The only changes that are visible after the execution of the transaction are the changes on the database item account. Here, T will be abbreviated as T: read(account); write(account);  Unimportant information will be left out.  We only consider read and write operations.

9. Lecture 6 Serializability  The execution of one or more transactions is called a schedule, also known as a history, e.g. H 1 = read 1 (account 1 ) read 2 (account 2 ) write 2 (account 2 ) write 1 (account 1 )  A history is serial if all operations of one transaction either appear before/after all operations of another transaction.  In other words, a serial history corresponds to a non- interleaving execution of transactions.

10. Lecture 6 Distributed Transaction  Transactions executed by different hosts/processes Need to access data/objects owned by different hosts  Key issues Concurrency control To ensure the execution of any allowed (interleaved) history to be correct  Isolation and Consistency Distributed commit To ensure the execution at different nodes take effect consistently  Atomicity, Consistency and Durability

11. Lecture 6 Concurrency Control  To allow the concurrent execution of transactions in a controlled manner, such that the final outcome of the concurrent execution is equivalent to a serial history  Serializability A serial history is always correct in transaction processing  Different methods Two phase locking protocol Optimistic Protocol Timestamp ordering protocol

12. Lecture 6 Two Phase Locking Protocol  The execution of a transaction using the 2PL protocol is composed of two phases (two phase rule): growing phase in which locks are acquired. shrinking phase in which locks are released.  A transaction cannot release a lock in growing phase.  A transaction cannot acquire a lock in shrinking phase.  The point between the growing phase and shrinking phase is called the lock point. number of locks held time growing phase shrinking phase lock point

13. Lecture 6 Distributed Commit  Definition Having an operation being performed by each member of a group, or none at all  Usually solved via coordinator-participant mode  One-phase commit protocol The coordinator tells all processes whether or not to (locally) perform the operation. Over!

14. Lecture 6 Two-Phase Commit (2PC) Protocol  Blocking at coordinator (waiting for votes) Vote abort, send Global-abort to all  Blocking at participant Waiting for INIT: vote abort, send Vote-abort to coordinator Waiting for Global-?: go ahead to abort? NO! Query others’ state. (a) The coordinator (b) A participant. Contact another participantREADY Make transition to ABORTINIT Make transition to ABORTABORT Make transition to COMMITCOMMIT Action by PState of Q

15. Lecture 6 Three-Phase Commit (3PC) (a) The finite state machine for the coordinator in 3PC. (b) The finite state machine for a participant.

16. Lecture 6 Mobile Transaction  Definition Transactions executed at mobile devices A kind of distributed transactions Part at mobile device and part at server  两种发起方式 一次发送一个事务的全部操作 简单；移动支持差 分多次发送一个事务的操作 灵活；复杂（切换与协调）

17. Lecture 6 Mobile Transaction  Characteristics and challenges Long link delay, disconnections  long transaction Mobile host failures  transaction failure Mobility of clients/servers  handoff Distributed databases  heterogeneity  How to handle these challenges

18. Lecture 6 Key Technologies  Keep data copy at mobile devices To handle disconnection To reduce communication cost  Two parts Temporary transaction: executed at mobile device Data update can be executed at mobile device temporarily Base transaction: executed at the server Finally committed after base transaction is committed.

19. Lecture 6 Concurrency Control in Mobile Environments  2PL is not practical, if mobile clients also process updates. The cost of getting locks from server is too expensive. The transactions are executed for long period. Items can be locked and then the client moves away (becomes disconnected) without being unlocked. Clients can get items from the broadcast.

20. Lecture 6 Concurrency Control in Mobile Environments  In a mobile environment, there are normally many read-only transactions and only few update transactions. The chance of having two transactions conflicting on the same data item is very small.  It would be better to make optimistic assumption that there is usually no conflict in operations. Transactions will back off in case there is a problem  Optimistic control

21. Lecture 6 Optimistic Protocol  The execution of a transaction is divided into three phases: read, validate, write phases. Read phase can be done without any restriction. Validate and write phases are often assumed to be atomic for simplicity.  Validation: testing of possible conflicts. If a transaction T is found to be non-conflicting with all active (executing) transactions, T is allowed to commit after installing its updates to the database in the write phase. If T conflicts with some transactions, either T or other offending ones are aborted.  Write: installing the new data values into the database, without the violation of data consistency or transaction serializability.

22. Lecture 6 Optimistic Protocol  Validation in conventional OCC in a distributed system involves testing of the Bernstein’s condition: 1. read-set(T 1 )  write-set(T 2 ) =  2. write-set(T 1 )  read-set(T 2 ) =  3. write-set(T 1 )  write-set(T 2 ) =   Note that this testing is a bit pessimistic, since even if the sets overlap, there may not be a real conflict.  The test is performed for a validating transaction T against all transactions that are concurrent.  Both backward and forward validation can be performed in a distributed system, by checking against recently validated transactions or future validating transactions.

23. Lecture 6 Optimistic Protocol T1T1 T2T2 T T a4 T a5 read validate write backward validation forward validation Check whether readset is valid Check whether writeset is valid

24. Lecture 6 Optimistic Protocol  Assuming that the server processes updates from mobile clients in a batched sequential manner, there would not be multiple concurrent transactions at the same time. We only validate against values used/changed in a serial manner.  Write phase after successful validation must be done atomically. This can be achieved via a simple critical section. Since there may still be concurrent transactions executing at server (not those coming from mobile clients), critical section may be an overkill. Simple 2PL can be used to ensure serializability in update. Considering the write phase of OCC as an update transaction at server. We use a special 2PL that acquires locks at transaction start (i.e. during the write phase of OCC). It has the advantage that it would not be deadlocked.

25. Lecture 6 Optimistic Protocol  As an example, assume 3 mobile transactions, T A, T B and T C being executed at mobile clients A, B and C.  All of them read data items from the broadcast. T A tries to commit first, then T B and finally T C. A transaction tries to commit by sending the updates to server for validation and if successful, install the updates within a critical section. Can these transactions be committed based on OCC? Ar(x)r(x)r(y)r(y)w(y)w(y)c Br(y)r(y)r(z)r(z)w(a)w(a)c Cr(x)r(x)r(z)r(z)r(a)r(a)w(b)w(b)c

26. Lecture 6 Optimistic Protocol  Assume that there is no transaction executed at server, T A can be committed.  When T B is submitted to server, OCC validation is performed for T B on T A. Read-set(T B )  write-set(T A )   (T B reads old value of y). T B cannot be committed.  When T C is submitted to server, OCC validation is performed for T C on T A only (since T B was aborted). Empty intersection property is satisfied. T C can be committed.  Which transactions can be committed if the order of commit request submission is T B, T A and then T C ? Ar(x)r(x)r(y)r(y)w(y)w(y)c Br(y)r(y)r(z)r(z)w(a)w(a)c Cr(x)r(x)r(z)r(z)r(a)r(a)w(b)w(b)c

27. Lecture 6 Optimistic Protocol in Mobile Environments  OCC should NOT be directly employed, because  Reading may NOT be known by the server Read from broadcast Read from cached data items  Mobile clients may be disconnected for a period.  The set of active transactions could be large.  Validation phase may be delayed due to congested uplink or disconnection.

28. Lecture 6 Optimistic Protocol in Mobile Environments  Read phase A mobile transaction T executes by reading data items from cache or from the server, making changes to local copies first. Transaction manager at client records data items read by and written by T, stored in read-set(T) and write-set(T). If a data item x is written by client, keep the old version of the value for rollback.

29. Lecture 6 Optimistic Protocol in Mobile Environments  Validate phase When T is ready to commit, the read-set, write-set and updated data values will be sent as a log to the server. Validation is performed by checking for consistency of values in the log for T against values in server in an atomic step: For all items x in log(T), check whether log.x.oldversion = server.x.verison (to handle W/W or W/R conflict). In other words, check whether the values of all items used in client have not been changed in the server (backward validation).  Write phase After passing validation, data item updates are installed atomically to the database. T can commit only when this write phase is successful.

30. Lecture 6 Case Study – Oracle Lite 10g  Temporary copy at clients  Target devices: laptops, smartphones, etc.  Programming languages ： Java,.net, C/C++  Database Interfaces ： ODBC, JDBC

31. Lecture 6 Architecture of Oracle Lite

32. Lecture 6 Case Study – Oracle Lite  Concurrency control Optimistic protocol  Mobile Sync: 负责管理客户端的副本  基本步骤 客户端提交更新事务 客户端生成事务日志 客户端重连服务器：上传日志到 MGP （ Message Generator Processor ） MGP 进行冲突检测和消除 消除规则由管理员配置：服务器优先、客户端优先、 时间戳优先等。

33. Lecture 6 The Synchronization Procedure

34. Lecture 6 Development Model

35. Lecture 6 小结  Concepts Mobile database Mobile transaction Concurrency control Distributed commit  Characteristics of mobile transactions  Concurrency control in mobile environments  Case study Oracle 10g Lite

36. Lecture 6 课后作业  相比传统的网络环境，分布式提交（ Distributed Commit ）协议在移动环境下应该有哪些改进？