Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
An Approach For Designing Distributed Real Time Database

An Approach For Designing Distributed Real Time Database

Ratings: (0)|Views: 99 |Likes:
Published by ijcsis
Abstract- A distributed Real Time database system is a transaction processing system that is designed to handle workloads where transactions have service deadlines. The emphasis here is on satisfying the timing constraint of transactions (meet these deadlines, that is to process transactions before their deadlines expire) and investigating the distributed databases. This paper produces a proposed system named ADRTDBS. In this work a prototype of client/server module and server/server module for distributed real time database has been designed. Server gets the data from direct user or a group of clients connected with it, analyze the request; and broad updating to all servers using 2PC (Two Phase Commit) and executing the demand by using 2PL (Two Phase Locking). The proposed model does not concern with data only, but provide a synchronize replication, so the updating on any server is not saved unless broadening the updating on all servers by using 2PC, and 2PL protocols. The database on this proposed system is homogenous and depend on full replication to satisfy real time requirements. The transactions have been scheduled on the server by using a proposed algorithm named EDTDF (Earliest Data or Transaction Deadline First). This algorithm works to execute transactions that have smallest deadline at the beginning, either this deadline specific to the data or to the transaction itself. Implementing this algorithm helps to execute greater rate of transactions before their deadlines. In this work two measures of performance for this system (proposed model) were been conducted; first, computing the Miss Ratio (rate of no. of executing transactions that miss their deadline); second, computing the CPU utilization (CPU utilization rate), by executing a set of transactions in many sessions.

Keywords: real time, databases, distributed, replication, Scheduling
Abstract- A distributed Real Time database system is a transaction processing system that is designed to handle workloads where transactions have service deadlines. The emphasis here is on satisfying the timing constraint of transactions (meet these deadlines, that is to process transactions before their deadlines expire) and investigating the distributed databases. This paper produces a proposed system named ADRTDBS. In this work a prototype of client/server module and server/server module for distributed real time database has been designed. Server gets the data from direct user or a group of clients connected with it, analyze the request; and broad updating to all servers using 2PC (Two Phase Commit) and executing the demand by using 2PL (Two Phase Locking). The proposed model does not concern with data only, but provide a synchronize replication, so the updating on any server is not saved unless broadening the updating on all servers by using 2PC, and 2PL protocols. The database on this proposed system is homogenous and depend on full replication to satisfy real time requirements. The transactions have been scheduled on the server by using a proposed algorithm named EDTDF (Earliest Data or Transaction Deadline First). This algorithm works to execute transactions that have smallest deadline at the beginning, either this deadline specific to the data or to the transaction itself. Implementing this algorithm helps to execute greater rate of transactions before their deadlines. In this work two measures of performance for this system (proposed model) were been conducted; first, computing the Miss Ratio (rate of no. of executing transactions that miss their deadline); second, computing the CPU utilization (CPU utilization rate), by executing a set of transactions in many sessions.

Keywords: real time, databases, distributed, replication, Scheduling

More info:

Published by: ijcsis on Oct 10, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/09/2011

pdf

text

original

 
 
.
 
An Approach ForDesigning Distributed Real TimeDatabase
 
Dr. Dhuha Basheer AbdullahComputer Sciences Dept./Computers Sciences andMathematics College /Mosul UniversityMosul- IraqAmmar Thaher YaseenComputer Sciences Dept./Computers Sciences andMathematics College /Mosul UniversityMosul- Iraq
Abstract- A distributed Real Time database system is atransaction processing system that is designed to handleworkloads where transactions have service deadlines. Theemphasis here is on satisfying the timing constraint of transactions(meet these deadlines, that is to process transactions before theirdeadlines expire) and investigating the distributed databases. Thispaper produces a proposed system named ADRTDBS.In this work a prototype of client/server module andserver/server module for distributed real time database has beendesigned. Server gets the data from direct user or a group of clients connected with it, analyze the request; and broad updatingto all servers using 2PC (Two Phase Commit) and executing thedemand by using 2PL (Two Phase Locking). The proposed modeldoes not concern with data only, but provide a synchronizereplication, so the updating on any server is not saved unlessbroadening the updating on all servers by using 2PC, and 2PLprotocols. The database on this proposed system is homogenousand depend on full replication to satisfy real time requirements.The transactions have been scheduled on the server by using aproposed algorithm named EDTDF (Earliest Data or TransactionDeadline First). This algorithm works to execute transactions thathave smallest deadline at the beginning, either this deadlinespecific to the data or to the transaction itself. Implementing thisalgorithm helps to execute greater rate of transactions before theirdeadlines.In this work two measures of performance for this system(proposed model) were been conducted; first, computing the MissRatio (rate of no. of executing transactions that miss theirdeadline); second, computing the CPU utilization (CPU utilizationrate), by executing a set of transactions in many sessions.
 Keywords: real time, databases, distributed, replication, Scheduling
I. INTRODUCTIONAccording to the definition provided by Coulouris,Dollimore & Kindberg [4], a distributed system consists of a setof autonomous processing elements that are connected via acommunication network and interact via message passing.A database is a structured set of data maintained by adatabase management system (DBMS) that interfaces with a setof applications or clients that access and modify the data. In adistributed database system, the data is distributed amongautonomous DBMS instances (nodes or sites) that communicatevia a network. The nodes, potentially along with a centralcoordinator, are collectively referred to as a distributeddatabase management system (DDBMS) [1,7,8,15].In a distributed database, replication of data objects(Theterm object is used for the unit of replication; this could just aswell be a table in a relational database as an object) is oftenused to improve fault tolerance and availability in the systemby maintaining several copies of data objects and placing thosecopies close to the clients that want to use them [19].In a real-time system (RTS), the value of a performed task depends not only on its functional correctness, but also on thetime at which it is produced. For example, when anautonomous vehicle detects an obstacle in its intended path, it iscrucial that it changes its path before a collision occurs. Real-time systems are often embedded, meaning that they are a partof (and interact heavily with) a physical environment.Typically, embedded systems use specific-purpose rather thangeneral-purpose computers, such as in the embedded systemcontrolling fuel injection in a car engine [6,20].It is paramount that real-time systems have predictable,bounded and sufficiently low requirements on resources such asmemory, network bandwidth and processor execution time,since failures due to unpredictable behavior and/or overconsumption of available resources may cause unacceptabledamage to humans or equipment. Real-time systems also needto be highly and predictably available, meaning that when arequest is made to the system, it can be guaranteed that thesystem is available to service that request within a predictableand bounded time.A distributed real-time system (DRTS) combinescharacteristics of distributed and real-time systems. This meansthat in such a system, issues related to distribution (such asexecution of distributed algorithms and network communication) must be addressed with real-time requirementsin mind.Real-time database systems (RTDBS) are often used tomanage data in real-time systems, since traditional databasescannot meet the timeliness and predictability requirements of aRTS. As many embedded applications with real-timerequirements are inherently distributed, RTDBS are oftendistributed over a set of autonomous nodes, creating a need fordistributed real-time database systems (DRTDBS) [10,14,16].
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 201078http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
 
 
Replication in DRTDBSData replication can be used to increase availability,predictability, and reliability of transaction processing inDRTDBS. Common replication approaches for DRTDBS useeither a primary copy to deterministically apply updates toreplicated data, or use distributed concurrency control anddistributed commit protocols.The distributed algorithms required to implement, e.g.,distributed locking (to ensure serializability) and distributedcommit (to ensure mutual consistency and durability) are hardto make predictable and sufficiently efficient due to theirreliance on correct message delivery. Furthermore, dependingon the replication approach a transaction may be forced toeither wait or roll back and restart due to concurrent executionof transactions on remote nodes. Such behavior is problematicin real-time systems, since potential blocking times androllbacks must be considered when determining worst-caseexecution times of transactions. For this reason, optimisticreplication approaches, where transactions are allowed toexecute as if no concurrent transactions exist, are more suitablethan pessimistic replication approaches in real-time databases.Optimistic replication increase the availability, predictabilityand efficiency of transaction execution at the cost of transactionconflicts that must be resolved [2,9].II. RATED WORKIn 1994 the researcher Nandt Subakr and others discuss theways in which the Commit Protocol that could be adapted tothe environmental sensitivity of the cases required for real-time.This protocol depends on the strategies and the installationoptimistic on local compensation [13].In 1994 also provided a researcher Victor Fiy and otherresearchers produce the basic rules to support the necessaryqualities to the environment of the account distributed to RT,which is the modalities of distribution of time. It providesgeneral concepts to clarify the application of the expansion of CORBA [18].In 1998 the researcher Krayas Shihabi and others discussthe experience to implement the 2-Server have the same DBMSare linked through the Internet. Focusing on the intelligencelinking the researchers explained how the firm Optimal queryplan may choose the most expensive mistake. This takesprecedence over the lack of knowledge of the operationalenvironment [12].In 2003 the researcher Yuan Wei and others discussproduce a study on the extraction using real-time updating of data and strategies on demand in DRTDB and the definition of certain laws to choose the best policy of modernization. Basedon these laws, the researchers suggested an algorithm to derivethe updated data, the derivation policy of modernizationpractical data sets automatically [17].In 2005 the researchers Broheedi Marcos and steen Andlerillustrate how to bring forward the requirements in theDARTDBS. It is possible to use a model requirements of themodalities of information with RT[3].In 2006 also provided a researcher Benoi Ravindran andothers Where they distributed scheduling algorithm Call CUA.The parameters indicated it would satisfy for Thread time whenthere is failure. Algorithm is the Best-Effort and the Thread of the highest importance when they arrive at any time be thepossibility of implementing a very high [11].In 2008 the researcher Alexander Zharkov discuss how touse the material offers Materialized Views in DRTDBMSs. Theresearcher offers an algorithm for building dynamic andevaluation of the material cost. President difference thisalgorithm from its predecessors is taken into consideration thecharacteristics of time Temporal Properties of relationspresident and data processing [21].III. CONTRIBUTIONSADRTDBS is a real time distributed database managementsystem prototype that is designed to support distributedtransactions processing with timing constraints.The ADRTDBS offers many contributions listed below:
 
 Database in main memory
: disk access should be minimizein a RTS, since reading from disk is both unpredictable andorders of magnitude slower than memory access.ADRTDBS is built to keep the entire database resident inmain memory.
 
Full Replication:
 
times for network messages areunpredictable, and accessing data on remote nodes in muchslower than local access. So ADRTDBS employs a fullreplication scheme which ensures that local replicas existfor all objects accessed by a transaction removing the needfor remote object access.
 
 ADRTDBS Design and Implementation
:
 
A structure to add support of executing real timetransactions in distributed environment.
 
Providing scheduling algorithm named EDTDFEarliest Data or Transaction Deadline First for
 
Transaction execution.
 
Produce an approach for concurrency control by using2PL (Two Phase Locking) protocol to managingconcurrent execution of transactions.
 
Execute data shipping and transaction shipping.
 
Provide synchronize replication and synchronizationupdating by using 2PC (Two Phase Commit).
 
Provide backup and recovery approach to processfailure.
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 201079http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
 
IV. THE PROPOSED SYSTEMGiven the important developments in computer andsoftware industry databases and the increasing use in differentareas of life (such as the management of banks, libraries,companies, factories ... etc.) and because of its great importancein a systematic compilation of data and processing, updatingand retrieval with pinpoint accuracy, speed and the urgent needto provide such techniques in our country to keep pace with thisdevelopment software tremendous invaded the whole world,this system was built to be a first step in the application of modern techniques and contemporary distributed databaseenvironment in real time. It was named Approach for designingDistributed Real Time Database System (ADRTDBS). Thesystem ADRTDBS deals with Homogeneous distributeddatabases (i.e. all computers linked to the network is made of the same company (Pentium IIII) and contains the same versionof the operating system (Windows XP) as well as containingthe same version of the database management system ( DBMSOracle 9i), the same version of the program interfaces(Developer 6i). Has the capacity to implement Soft Real TimeTransactions.V. SYSTEM ARCHITECTUREThe system architecture consists of the following structureshown in the figure (1):
Figure (1) Architecture of ADRTDBS System
It contains two computers working as server having samedatabase, and two computers working as clients connected witheach server. Connection between computers is via HUB. Thedatabase resident in each server connected with the network and having same data and structure (replicas). The clientscontain interfaces that making connection with servers andretrieve updating database. Any transaction will be executed onthe database will have one of two cases: either local transaction,the implementation is the only current computer server. OrGlobal transaction, the implementation to all servers linked inthe network.VI. SYSTEM MODEL
Database ModelA real time distributed system consists of two autonomouscomputers system (sites) connected via a communicationnetwork. Each site maintains a copy of database. In order fortransactions to be applied consistently to all replicas and give aresult within deadline time, a prototype units runs at each site.Also this prototype architecture gives the distributed nature andthe increased communication burden of such a database system.The smallest unit of data accessible to the user is called dataobject. In this distributed database system with replicated dataobjects a logical data object is represented by a set of one ormore replicated physical data object. The database is fullyreplicated at all sites. The database consists of two types of dataobjects: temporal and non-temporal. Temporal data object areused to record the state of the object in the externalenvironment which its value changes frequently with time.- Shipping ApproachesTwo approaches for processing transactions in aADRTDBS system: query shipping and data shipping.
 
Data ShippingIn the data shipping approach, a transaction initiated by aclient will be processed at the client. While the transaction isprocessing, the client sends data requests, which are required bythe transaction, to the database server. The server responds tothe requests by sending the required data objects to the client.The processing of the transaction will be completed at theclient.
 
Query ShippingIn the query shipping approach, the client sends queries tothe database server for the transaction, instead of data requests.Once the server receives a query, it processes the query andsends the results back to the client. In the query shippingapproach, the communication cost and the buffer space requiredat the client side are smaller than that in the data shippingapproach. Also, the query shipping approach provides arelatively easy migration path from an existing single-sitesystem to the client-server environment since the databaseengine can have a process structure similar to that of a single-site database system. On the other hand, the data shippingapproach can off-load functionality from the server to theclients. This may improve the scalability of the system andbalance the workload in the system
.
Figure (2) illustratesflowcharts for query shipping from the point of view for serverand client.
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 201080http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->