AN OPTIMISTIC CONCURRENCY CONTROL ALGORITHM FOR MOBILE ADHOC

AN OPTIMISTIC CONCURRENCY CONTROL ALGORITHM FOR MOBILE AD-HOC NETWORK DATABASES Brendan Walker

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

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 �

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

Sequential Order with Dynamic Adjustment (SODA) Authors propose SODA algorithm for missioncritical 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

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 (S 2 PL)

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

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

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

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 prevalidation 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

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

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

MANET Database Architecture

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

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)

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.

SODA Description We need a dynamic order among committed transactions other than the validation order. Sequential Order (SO) of committed transactions is maintained as {T 1, T 2, …, 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: {T 1, T 2, …, low, … T, up, . . . , Tn}

SODA Description

SODA and MANET Transaction Flow in a clustered MANET

SODA and MANET Coordinating server is combined with cluster head, elected by the PMW algorithm Participating server functionality: � Maintains sequential order of committed subtransactions � 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

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.

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 subtransactions and requests timestamps of read set � Once it receives all successful messages of a global transaction, begins to validate this transaction globally using SODA

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 If checks its power level is below predefined threshold, resigns its cluster head status and elects new one

Correctness Proof and Time Complexity Theorem 1 � If S is a schedule produced by SODA, then S is serializable. Theorem 2 � The n time complexity of SODA is O(p*n^2 + 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)

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

Performance Evaluation

Bibliography Zhaowen Xing, Le Gruenwald, and Seokil Song. 2010. An optimistic concurrency control algorithm for mobile ad-hoc network databases. In Proceedings of the Fourteenth International Database Engineering & 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