Distributed Optimistic Concurrency Control for Real-Time Database ...
An Optimistic Concurrency Control Algorithm for Mobile Ad-hoc Network Databases
description
Transcript of An Optimistic Concurrency Control Algorithm for Mobile Ad-hoc Network Databases
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