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

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)

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 2PL  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 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

 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

 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 {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}

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

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

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

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)

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

Performance Evaluation

Bibliography  Zhaowen Xing, Le Gruenwald, and Seokil Song An optimistic concurrency control algorithm for mobile ad-hoc network databases. In Proceedings of the Fourteenth International Database Engineering \&\#38; Applications Symposium (IDEAS '10). ACM, New York, NY, USA, DOI= /  Found at: