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

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

Performance Evaluation

Performance Evaluation

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