An Optimistic Concurrency Control Algorithm for Mobile Ad-hoc Network Databases

1. An Optimistic Concurrency Control Algorithm for Mobile Ad-hoc Network Databases Brendan Walker

2. Mobile Ad-Hoc Network (MANET) • Made up of wireless devices • Mobile database built on MANET = MANET database system • No fixed infrastructure • Concurrency control (CC) techniques must be incorporated

3. Concurrency Control • Activity of preventing transactions from destroying the consistency of the database • Allows transactions to run concurrently, so that: • The throughput and resource utilization of database systems are improved • Waiting time of concurrent transactions are reduced

4. CC techniques for cellular mobile databases cannot be directly applied in MANET environments • Constraints: • Mobility • Low Bandwidth • Multi-hop Communication • Limited Battery Power • Frequent Disconnections • Long-lived Transactions

5. Sequential Order with Dynamic Adjustment (SODA) • Authors propose SODA algorithm for mission-critical MANET databases • All characteristics are put into consideration • Nodes are divided into clusters • Each cluster has one cluster head that is responsible for the processing of all the nodes in the cluster

6. Other Proposed CC Techniques • Semantic Serializability Applied to Mobility (SESAMO) • Multi-Version Optimistic Concurrency Control for Nested Transactions (MVOCC-NT) • Look-Ahead Protocol (LAP) • Strict 2-Phase Locking (S2PL)

7. SESAMO • Based on semantic serializability • Assumes that databases are disjoint • Updates only depend on the values of data of the same database • Transaction atomicity and global serializability can be relaxed

8. SESAMO • However: • Global transactions still need to be serialized at each site using strict 2PL • Each site must maintain the consistency of its own local database

9. LAP • Proposed to maintain data consistency of broadcast data in mobile environments • Update transactions are classified into hopeful or hopeless transactions • Hopeless transactions cannot commit before their deadline; aborted as earlier as possible to save system resources • Hopeful transactions can continue to execute their read and write operations

10. MVOCC-NT • Processes mobile real-time nested transactions using multi-versions of data in mobile broadcast environments • Adopts the timestamp interval with dynamic adjustment (avoids unnecessary aborts) • Mobile Clients: • All active transactions perform backward pre-validation against transactions committed (in last broadcast cycle at the fixed server) • Surviving update transactions have to be transferred to the fixed server for the final validation

11. Except for SESAMO, the other techniques are designed for cellular mobile databases that rely on broadcast techniques and powerful, static servers • Not suitable for MANET databases • SESAMO proposed for MANET databases • However: • MANET databases for mission-critical applications cannot relax the atomicity and global serializability • Each database depends on the other

12. MANET Database Architecture • Clients • Only query processing modules that allow them to submit transactions and receive results are installed • Servers • Complete database management system is installed • Coordinating servers – divide global transactions into sub-transactions, forward them to appropriate participating servers; maintain ACID properties of global transactions • Participating servers – process sub-transactions; preserve ACID properties

13. MANET Database Architecture

14. MANET Database Architecture • Database partitioned into local databases, distributed at different servers • No Caching or replication technique involved for simplicity • Cluster Architecture • Many applications in the literature use grouped or clustered architectures • Every node is mobile in MANET

15. MANET Database Architecture • Power, Mobility, and Workload (PMW) • Weighted algorithm to form and maintain stable clusters • Weight is calculated by: • Remaining power • Mobility prediction (to check if a node moves along with all its one-hop neighbors) • Workload (represented by power decrease rate)

16. SODA Description • Assume that Ti’s (i = 1, …, n) are committed transactions, and T is a validating/committing transaction. If we simply let the validation/commit order be the serialization order like traditional OCC, and if there is a read-write conflict between T and Ti, i.e., T reads a common data item d before Ti updates d, then T is aborted because two orders are different. Such aborts should be avoided if possible.

17. SODA Description • We need a dynamic order among committed transactions other than the validation order. • Sequential Order (SO) of committed transactions is maintained as {T1, T2, …, Ti, ..., Tn} (also called a history list, which is ordered from left to right) and can be dynamically adjusted • Complex case: • The sequential order must be adjusted before the insertion of T • Simple case: • Validating transaction T can be directly inserted into the maintained sequential order without adjustment, and the final sequential order will be: {T1, T2, …, low, … T, up, ..., Tn}

18. SODA Description

19. SODA and MANET • Transaction Flow in a clustered MANET

20. SODA and MANET • Coordinating server is combined with cluster head, elected by the PMW algorithm • Participating server functionality: • Maintains sequential order of committed sub-transactions • Processes sub-transactions • When it receives the request about the status of a sub-transaction, runs SODA locally based on local sequential order of committed transaction

21. SODA and MANET • Participating server functionality (continued) • Sends final result to the requesting cluster head. If it passes the validation, timestamp of the read set is also sent to the cluster head • If sub-transaction commits, rebuilds the local latest sequential order of committed transactions by running update_sequential_order(); adds the read set, write set, and timestamps of both sets • Once a sub-transaction commits, tries to remove committed transactions which are not serialized after any committed transaction from the local sequential order of committed transactions.

22. SODA and MANET • Cluster head functionality • Maintains sequential order of committed global transaction • Receives global transactions from clients; divides them into sub-transactions which are sent to appropriate participating servers • Runs 2-Phase Commit to request status of sub-transactions and requests timestamps of read set • Once it receives all successful messages of a global transaction, begins to validate this transaction globally using SODA

23. SODA and MANET • Cluster head functionality (continue) • When global transaction commits: • Updates its sequential order • Tries to remove committed transactions which are not serialized after any committed transaction • Periodically checks its power level • If level is below predefined threshold, resigns its cluster head status and elects new one

24. Correctness Proof and Time Complexity • Theorem 1 • If S is a schedule produced by SODA, then S is serializable. • Theorem 2 • The time complexity of SODA is O(p*n^2 + n) • n : # of committed transaction in the sequential order • p : probability of a committing transaction conflicting with both transactions low and up and SO(low) >= SO(up)

25. Performance Evaluation • Simulation experiments used to compare the performance of SODA, SESAMO, and S2PL • Simulation model consists of a transaction generator, real-time scheduler, and deadlock manager (SESAMO and S2PL) • Simulation model for SESAMO and S2PL are different than the one for SODA: • SODA is applied locally and globally to validate transactions • SESAMO and S2PL use coordinating servers, not cluster heads

26. Performance Evaluation

27. Performance Evaluation

28. Performance Evaluation

29. Bibliography • Zhaowen Xing, Le Gruenwald, and Seokil Song. 2010. An optimisticconcurrency control algorithm for mobile ad-hoc network databases. InProceedings of the Fourteenth International Database Engineering\&\#38; Applications Symposium (IDEAS '10). ACM, New York, NY, USA,199-204. DOI=10.1145/1866480.1866509 • Found at: http://doi.acm.org/10.1145/1866480.1866509