Extending Multidatabase Transaction Management Techniques to Software Development Environments
|
|
|
- Bertha Owens
- 9 years ago
- Views:
Transcription
1 Purdue University Purdue e-pubs Computer Science Technical Reports Department of Computer Science 1993 Extending Multidatabase Transaction Management Techniques to Software Development Environments Aidong Zhang Omran Bukhres Report Number: Zhang, Aidong and Bukhres, Omran, "Extending Multidatabase Transaction Management Techniques to Software Development Environments" (1993). Computer Science Technical Reports. Paper This document has been made available through Purdue e-pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information.
2 EXTENDIDNG MULTIDATABASE TRANSAcrlON MANAGEMENT TECBNIQUES TO SOFTWARE DEVELOPMENT ENVIRONMENTS Aidong Zhang Omran Bukhres CSD-TR-93-l181 December 1993
3 Extending M ultidatabase Transaction Management Techniques to Software Development Environments Aidong Zhang and Omran Bukhres Department of Computer Science Purdue University West Lafayette, IN USA Abstract A multidatabase system integrates a set of autonomous local databases that can be accessed as a single unit. Such a. multidatabase environment is actually a special case of a more general software development environment in which local components may be either database systems or file systems. This paper discusses the new issues that arise in such software development environments and presents some initial solutions for these issues by extending multidatabase transaction management techniques. 1 Introduction A software development environment (SDE) is a distributed heterogeneous software system in which local components can be either database systems or file systems. These local systems originally ran in isolation to support their individual applications. It then became evident that more complex applications involving multiple systems could be supported through intersystem cooperation. Consider an example at BNR [4]. A group of engineers at corporate headquarters is responsible for maintaining switching-system quality. An application software package, the Statistical Analysis System (SAS), is used to analyze available data. From the SAS output, they develop perforn:ance and reliability graphs, which are stored in a DB2 database on an IBM mainframe. This informa.tion is then be used by design engineers to improve the switching-system design. The integration of these systems must, however, be accomplished without the disruption of loca.l system autonomy. 1
4 Such an autonomy feature has been recognized and studied in multidatabase systems. A multidatabase system (MDBS) serves to integrate a set of local database systems at various locations (sites). The central concern of such an integration is the preservation of the local autonomy of the component database systems. Aspects of autonomy such as design, execution, and control have been studied in [7, 2, 5, 12]. MDBSs process two varieties of transactions. Each local transaction accesses a local database only and is submitted directly to a local database system. Global transactions, in contrast, may simultaneously access several local databases and are submitted to an integration phase, where they are parsed into a set of global subtransactions to be submitted to local database systems. Thus, a SDE is a generalized. case of an MDBS. The techniques developed in MDBSs may be extended to SDEs. The aspects of the integration on system and language designs have been studied in [11, 4]. In this paper, we investigate the application of multidatabase transaction management techniques to the decentralized software development environment. In such an environment, the conditions that can be placed on local sites must be more relaxed than those which may be in effect in a multidatabase environment. For example, there may be no concurrency control mechanisms in place at local sites, and prepare-tocommit states may also not be supported at local sites. We will discuss approaches that can be developed to ensure the correct execution of global and local applications in this less restrictive environment. 2 Decentralized Model As software development environments usually deal with a large number of local components, a decentralized approach to integration is essential for SDEs. Such a decentralized approach provides a high degree of fault-tolerance, and the system can be easily extended to accommodate new local sites. We therefore anticipate that the decentralized design of global application management will become an important feature of SDEs, particula.rly of those systems integrating a large number of participating local software systems. A SDE consists of a set of {local software systems, denoted LSS i, for 1 ::; i ::; m}, where each LSS i comprises an autonomous software system on a set D j of data at the local site LSi and a global application manager (GAM). The GAM is decentralized on all machines participating in the SDE. Each LSS is associated with a GAM server (GS), and all machines participating in the SDE can run the GAM interpreter (Gl). A global application is submitted by invoking a process of the GAM interpreter at its machine while a local application is 2
5 submitted directly to a LSS. All machines are connected by a computer network. Figure 1 illustrates this architecture. User User User G, LoooI :""PP lica1i0dli,,,, : D 1,, ~ Local SiteLS I LoooI v\ppligd.juns,.,,, : D 2,,, Local SiteLS 2 - : Da1a 3l1d comrnancl flows LoooI II\pplKatiollS,,,,,, : D m,, ~ Local Site LS m Figure 1: Decentralized SDE architecture The GAM interpreter manages the decomposition and execution of global applications. In particulari the execution of a global application Gj is controlled by the GAM interpreter process Gl i, which submits the subapplications of G; to the relevant GAM servers for execution. A GAM interpreter process can independently manage the execution of a global application without requiring any knowledge of the others' existence. A GAM server is responsible for the execution of global subapplications received from the GAM interpreter processes. It then submits for execution each global subapplication to the LSS at its associated site. The completion of each subapplication is acknowledged by the LSS to the GAM server, which, if necessary, returns these results to the GAM interpreter processes. Each GAM server runs independently from other GAM servers and coordinates only with the GAM interpreter processes froj!1 which it receives global subapplications. 3
6 3 Global Concurrency Control Issues Since some local software systems may not be database systems, they may not provide a.ny concurrency control mechanisms. Thus, the GAM must be equipped to handle the mixed situation in which some local sites provide concurrency control mechanisms, while others do not. Without loss of generality, we assume that serializabilityl is ensured in those local sites which have concurrency control mechanisms. A straightforward approach to controlling the execution of global applications is to ensure that all global applications run serially at the global level. In order to ensure the serial execution order of global applications at the global level, we must ensure that the execution orders of global subapplications at all local sites are relatively synchronized. That is, there exists a total order 0 on all global applications such that, at each local site, the execution order of its global subapplications is consistent with O. For those local sites which have no concurrency control mechanisms, both local applications and global subapplications must be executed serially. The execution order of global subapplications at the global level is obviously inherited at such local sites, and the effect of the execution ofglobal subapplications at the global level is equivalent to the effect of their execution at these local sites. It has been pointed out in [2, 5, 8] that the execution order of global subapplications at the global level may not be the same as their serialization order at a local site. Thus, even if the execution orders of global subapplications at all local sites are relatively synchronized, their execution orders at those local sites which have concurrency control mechanisms may not be identical to their serialization order. Consequently, the effect of the execution of global applications may not be serial. The enforcement of local conflicts [8, 13] has been proposed to force the execution order of global subapplications at the global level to conform to their serialization order at local sites. The remaining issue in the implementation of an efficient decentralized scheme for the serial execution of global applications is the synchronization of the relative execution orders (REOs) ofglobal subapplications at all local sites. Our method begins by numbering all GAM servers in an order 0, with each GAM server maintaining a site-lock. Prior to executing global application Gi, GAM interpreter Gl i must first request all necessary site-locks from the relevant GAM servers in an order consistent with O. The REO of G i is determined at all relevant sites only when Gli has acquired the necessary site-locks. After the REO of G i is determined, Gl i releases all held site-locks. During this process, if failures occur, lin this paper, 6erializability refers to conflict serializability [1]. 4
7 GI i will request all relevant GAM servers to remove G, from the pre-determined REOs and release all held site-locks. Because the site-locks are requested in an order consistent with 0 and the REO of G, is determined only after GI, holds all necessary site-locks, the correct synchronization of concurrent site-locks requests is ensured and correct REOs of global applications at all sites are thus guaranteed. After the REO of G i is determined, GI, sends subapplications of G j to the relevant GAM servers. Using the ticket method [8], these GAM servers can enforce conflicts among all subapplications at each local site where a concurrency control mechanism is used and submit the subapplications for execution according to the pre-determined REO. This synchronization approach permits each global application to be submitted for execution without waiting for the completion of a previously submitted global application. At this point, it is not clear to us whether more liberal approaches to controlling the execution of global applications at the global level will improve their execution performance. With the mixed situation in which some local sites provide concurrency control mechanisms, while others do not, those global subapplications which can be executed concurrently at some local sites may need to wait for the results of others which must be executed serially at other local sites. Depending on the load of data flow among global subapplications of each global application, those global correctness criteria, that permit global subapplications to run concurrently at the local sites which provide concurrency control mechanisms, may achieve better performance on the execution of global applications. Further investigation need be done to explore the effects of local concurrency control mechanisms on global concurrency control in SDEs. 4 Non-conventional Commit Protocols The global applications in SDEs may be more flexible than global transactions in MDBSs. In other words, some actions in a global applications may not have to be executed or may be replaced by other actions if they fail. For example, in a debugging global application, the failure (existing bugs) of one source code module may be replaced by other version of the same module and also, partial execution of all source code modules may be acceptable. This flexibility allows a global application to adhere to a weaker form of atomicity, which we term semi-atomicity, while still maintaining its correct execution in the SDE environment. Semiatomicity allows a global application to commit even if some subapplications fail, provided that either the failed subapplications are unnecessary to be executed or their alternative 5
8 subapplications complete. We are currently investigating non-conventional commit protocols for ensuring the semiatomicity of global applications. To preserve the semi-atomicity of global applications, given the assumption that LSSs can recover from failures, the GAM must ensure either that all global subapplications of a global application that must complete commit or that none of the effects of each global subapplication remain permanent. Preserving the atomicity [1] of global transactions in multidatabase systems has been recognized as an open and difficult issue [10]. Of particular concern is the fact that multidatabases cannot assume that the local databases support a visible prepare-ta-commit state for those subtransactions in which a subtransaction has not yet been committed but is guaranteed the ability to commit. This scenario clearly remains problematic in the SDE environment. In such situations, a local software system that participates in a SDE environment may unilaterally fail a global subapplication without agreement from the global level (termed a local unilateral faiq. As a result, it becomes difficult to ensure that a single complete logical action of the subapplications in a global application that must complete is consistently carried out at multiple local sites. The traditional two-phase commit (2PC) protocol developed in distributed database environments thus becomes inadequate to the preservation of the semi-atomicity of global applications in the SDE environment. Both forward and backward recovery approaches which utilize the redo, retry, and compensation techniques have been proposed [3, 9] for the preservation of the semantic atomicity [6] of global transactions. These techniques allow each global subtransaction to commit unilaterally, requiring either the redo or retrial of aborted global subtransactions or the undoing of tentatively committed global subtransactions by corresponding compensating transactions. Note that at most one subtransaction of each global transaction can be pivot. The compensatable subtransactions must be completed before the completion of the pivot subtransaction, which in turn must complete before the completion of the retriable subtransactions. The global complete/fail decision is determined by the outcome of the completion of the pivot subtransaction. If it fails, all of the compensatable subtransactions are compensated for; otherwise the retriable subtransactions are attempted until they complete. Semi-atomicity is also weaker than semantic atomicity. In order to utilize the above techniques in the SDE environment, we categorize each global subapplication as either retriable, compensatable, or pivot. We say that a subapplication is retriable if it is guaranteed to commit after a finite number of submissions when executed from any consistent database state. A subapplication is compensatable if the effects of its execution can be semantically undone 6
9 after commitment by executing a compensating subapplication. A compensating subapplication eti for a subapplication ti must be independent of the applications that execute between ti and Cti' This is because local database autonomy requires that arbitrary local applications be executable between the time tj is committed and the time Cti is executed, and these local applications can both see and overwrite the effects of tj during that time. A subapplication is a pivot subapplication if it is neither retriable nor compensatable. Our investigation starts with the construction ofglobal applications whose semi-atomicity can be maintained in the SDE environment. In general, the semi-atomicity of a global application may not be ensured without using local prepare-to-commit states. For example, the possession of two or more pivot subapplications that must be executed in a global application may render it difficult to determine a commit order among them which ensures that the global application can move either forward to the commitment of its subapplications or backward to the removal of any partial effects of the committed subapplications. However, if one pivot subapplication can be replaced by some other retriable subapplicatiod, then the global application may still proceed when the pivot subapplication fails. The establishment of the essential properties of global applications such that their semi-atomicity can be ensured provides a foundation for the design of an advanced global application language. We are also investigating the decentralized commit protocol for ensuring the semi-atomicity of such global applications. 5 Conclusions In this paper, we have discussed those issues that arise when the techniques of multidatabase transaction management are applied to the software development environment. Our investigation represents a first step toward global application management in SDEs, one which may be amplified in the future by additional refinement. The synchronization approach described above has been implemented in the context of our InterBase project, the design of the commit protocol is currently being investigated as part of that project. References [1] P. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Databases Systems. Addison-Wesley Publishing Co., [2] Y. Breitbart and A. Silberschatz. Multidatabase Update Issues. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages , June
10 [3] Y. Breitbart, A. Silberschatz, and G. Thompson. Reliable Transaction Management in a Multidatabase System. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages , May [4J O. A. Bukhres, J. Chen, W. Du, A. K. Elmagarmid, and R. Pezzoli.!nterBase: An Execution Environment for Heterogeneous Software Systems. IEEE Computer, 26(8):57-69, August [5] W. Du and A. Elmagarmid. Quasi Serializability: a Correctness Criterion for Global Concurrency Control in InterBase. In Proceedings-of the 15th International Conference on Very Large Data Bases, pages , Amsterdam, The Netherlands, Aug [6] H. Garcia-Molina. Using Semantic Knowledge for Transaction Processing in a Distributed Datahase. ACM Trans. Database Syst., 8(2): , June [7] H. Garcia-Molina and B. Kogan. Node Autonomy in Distributed Systems. In Proceedings ofthe First International Symposium on Databases for Parallel and Distributed Systems, pages , Austin, Texas, USA, Dec [8] D. Georgakopoulos, M. Rusinkiewicz, and A. Sheth. On Serializability of Multidatabase Transactions Through Forced Local Conflicts. In Proceedings of the 7th Intl. Con! on Data Engineering, pages , Kobe, Japan, Apr [9} S. Mehrotra, R. Rastogi, H. F. Korth, and A. Silberschatz. A transaction model for multidatabase systems. In Proceedings ofinternational Conference on Distributed Computing Systems, June [10] N. Soparkar, H. F. Korth, and A. Siberschatz. Failure-resilient transaction management in multidatabases. IEEE Computer, 24(12):28-36, December [11] P. Tarr and S. Sutton. Programming heterogeneous transactions for software development environments. In Proceedings of Fifteenth International conference on Software Engineering, pages , [12] J. Veijalainen. Transaction Concepts in Autonomous Database Environments. R.Oldenbourg Verlag, Germany, [13] A. Zhang and A. K. Elmagarmid. A theory of global concurrency control in multidatabase systems. The VLDB Journal, 2(3): , July
Transaction Management Overview
Transaction Management Overview Chapter 16 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Transactions Concurrent execution of user programs is essential for good DBMS performance. Because
Udai Shankar 2 Deptt. of Computer Sc. & Engineering Madan Mohan Malaviya Engineering College, Gorakhpur, India
A Protocol for Concurrency Control in Real-Time Replicated Databases System Ashish Srivastava 1 College, Gorakhpur. India Udai Shankar 2 College, Gorakhpur, India Sanjay Kumar Tiwari 3 College, Gorakhpur,
Transaction Processing Monitors
Chapter 24: Advanced Transaction Processing! Transaction-Processing Monitors! Transactional Workflows! High-Performance Transaction Systems! Main memory databases! Real-Time Transaction Systems! Long-Duration
(Pessimistic) Timestamp Ordering. Rules for read and write Operations. Pessimistic Timestamp Ordering. Write Operations and Timestamps
(Pessimistic) stamp Ordering Another approach to concurrency control: Assign a timestamp ts(t) to transaction T at the moment it starts Using Lamport's timestamps: total order is given. In distributed
A Multidatabase System as 4-Tiered Client-Server Distributed Heterogeneous Database System
A Multidatabase System as 4-Tiered Client-Server Distributed Heterogeneous Database System Mohammad Ghulam Ali Academic Post Graduate Studies and Research Indian Institute of Technology, Kharagpur Kharagpur,
A Rule-Oriented Concurrent Architecture to Effect Adaptiveness for Integrated Manufacturing Enterprises
A Rule-Oriented Concurrent Architecture to Effect Adaptiveness for Integrated Manufacturing Enterprises Cheng Hsu and Gilbert Babin Decision Sciences and Engineering Systems, Rensselaer Polytechnic Institute,
Recovery Theory. Storage Types. Failure Types. Theory of Recovery. Volatile storage main memory, which does not survive crashes.
Storage Types Recovery Theory Volatile storage main memory, which does not survive crashes. Non-volatile storage tape, disk, which survive crashes. Stable storage information in stable storage is "never"
Consistency Management for Multiple Perspective Software Development
Consistency Management for Multiple Perspective Software Development Wai Leung Poon Anthony Finkelstein Dept. of Computing, Dept. of Computer Science, Imperial College, City University, 180 Queen's Gate,
Distributed Databases. Concepts. Why distributed databases? Distributed Databases Basic Concepts
Distributed Databases Basic Concepts Distributed Databases Concepts. Advantages and disadvantages of distributed databases. Functions and architecture for a DDBMS. Distributed database design. Levels of
Database Concurrency Control and Recovery. Simple database model
Database Concurrency Control and Recovery Pessimistic concurrency control Two-phase locking (2PL) and Strict 2PL Timestamp ordering (TSO) and Strict TSO Optimistic concurrency control (OCC) definition
Distributed Architectures. Distributed Databases. Distributed Databases. Distributed Databases
Distributed Architectures Distributed Databases Simplest: client-server Distributed databases: two or more database servers connected to a network that can perform transactions independently and together
Database Tuning and Physical Design: Execution of Transactions
Database Tuning and Physical Design: Execution of Transactions David Toman School of Computer Science University of Waterloo Introduction to Databases CS348 David Toman (University of Waterloo) Transaction
Distributed Databases: what is next?
Distributed Databases: what is next? Massive distribution / replication Nested transactions Transactions and web services Summary and final remarks New Challenges DDB and transactions in the past - few
The Cost of Increased Transactional Correctness and Durability in Distributed Databases
The Cost of Increased Transactional Correctness and Durability in Distributed Databases Aspen Olmsted [email protected] Csilla Farkas [email protected] Center for Information Assurance Engineering Department
Transactions and the Internet
Transactions and the Internet Week 12-13 Week 12-13 MIE253-Consens 1 Schedule Week Date Lecture Topic 1 Jan 9 Introduction to Data Management 2 Jan 16 The Relational Model 3 Jan. 23 Constraints and SQL
Chapter 15: Recovery System
Chapter 15: Recovery System Failure Classification Storage Structure Recovery and Atomicity Log-Based Recovery Shadow Paging Recovery With Concurrent Transactions Buffer Management Failure with Loss of
Transactions. SET08104 Database Systems. Copyright @ Napier University
Transactions SET08104 Database Systems Copyright @ Napier University Concurrency using Transactions The goal in a concurrent DBMS is to allow multiple users to access the database simultaneously without
Chapter 10: Distributed DBMS Reliability
Chapter 10: Distributed DBMS Reliability Definitions and Basic Concepts Local Recovery Management In-place update, out-of-place update Distributed Reliability Protocols Two phase commit protocol Three
Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification
Introduction Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Advanced Topics in Software Engineering 1 Concurrent Programs Characterized by
Distributed Database Management Systems
Distributed Database Management Systems (Distributed, Multi-database, Parallel, Networked and Replicated DBMSs) Terms of reference: Distributed Database: A logically interrelated collection of shared data
Introduction to Database Systems. Module 1, Lecture 1. Instructor: Raghu Ramakrishnan [email protected] UW-Madison
Introduction to Database Systems Module 1, Lecture 1 Instructor: Raghu Ramakrishnan [email protected] UW-Madison Database Management Systems, R. Ramakrishnan 1 What Is a DBMS? A very large, integrated
Transactions and Recovery. Database Systems Lecture 15 Natasha Alechina
Database Systems Lecture 15 Natasha Alechina In This Lecture Transactions Recovery System and Media Failures Concurrency Concurrency problems For more information Connolly and Begg chapter 20 Ullmanand
Lecture 7: Concurrency control. Rasmus Pagh
Lecture 7: Concurrency control Rasmus Pagh 1 Today s lecture Concurrency control basics Conflicts and serializability Locking Isolation levels in SQL Optimistic concurrency control Transaction tuning Transaction
Distributed Data Management
Introduction Distributed Data Management Involves the distribution of data and work among more than one machine in the network. Distributed computing is more broad than canonical client/server, in that
The ConTract Model. Helmut Wächter, Andreas Reuter. November 9, 1999
The ConTract Model Helmut Wächter, Andreas Reuter November 9, 1999 Overview In Ahmed K. Elmagarmid: Database Transaction Models for Advanced Applications First in Andreas Reuter: ConTracts: A Means for
Byzantium: Byzantine-Fault-Tolerant Database Replication
Byzantium: Byzantine-Fault-Tolerant Database Replication Cristóvão Tavares Honorato INESC-ID and Instituto Superior Técnico [email protected] Abstract. Database systems are a key component behind
DISTRIBUTED AND PARALLELL DATABASE
DISTRIBUTED AND PARALLELL DATABASE SYSTEMS Tore Risch Uppsala Database Laboratory Department of Information Technology Uppsala University Sweden http://user.it.uu.se/~torer PAGE 1 What is a Distributed
Optimizing Concurrent Processing of Write-then-Read Transactions
Optimizing Concurrent Processing of Write-then-Read Transactions c Alexander Kalinin Institute for System Programming of the Russian Academy of Sciences [email protected] Abstract Write-then-read
Principles of Distributed Database Systems
M. Tamer Özsu Patrick Valduriez Principles of Distributed Database Systems Third Edition
Database Replication Techniques: a Three Parameter Classification
Database Replication Techniques: a Three Parameter Classification Matthias Wiesmann Fernando Pedone André Schiper Bettina Kemme Gustavo Alonso Département de Systèmes de Communication Swiss Federal Institute
Textbook and References
Transactions Qin Xu 4-323A Life Science Building, Shanghai Jiao Tong University Email: [email protected] Tel: 34204573(O) Webpage: http://cbb.sjtu.edu.cn/~qinxu/ Webpage for DBMS Textbook and References
Data Management in the Cloud
Data Management in the Cloud Ryan Stern [email protected] : Advanced Topics in Distributed Systems Department of Computer Science Colorado State University Outline Today Microsoft Cloud SQL Server
Segmentation in a Distributed Real-Time Main-Memory Database
Segmentation in a Distributed Real-Time Main-Memory Database HS-IDA-MD-02-008 Gunnar Mathiason Submitted by Gunnar Mathiason to the University of Skövde as a dissertation towards the degree of M.Sc. by
Implementing New Approach for Enhancing Performance and Throughput in a Distributed Database
290 The International Arab Journal of Information Technology, Vol. 10, No. 3, May 2013 Implementing New Approach for Enhancing Performance and in a Distributed Database Khaled Maabreh 1 and Alaa Al-Hamami
International Journal of Advanced Research in Computer Science and Software Engineering
ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: Transaction Management in Homogenous Distributed Real-Time Replicated
Applying the Saga Pattern. Caitie McCafffrey
Applying the Saga Pattern Caitie McCafffrey Caitie McCaffrey! Distributed Systems Engineer @Caitie CaitieM.com Why Sagas? Sagas Paper Distributed Sagas Sagas in Halo 4 Systems Used to Be Simple Serializability
A Review of Distributed Workflow Management Systems
A Review of Distributed Workflow Management Systems F. Ranno and S. K. Shrivastava Department of Computing Science, Newcastle University, Newcastle upon Tyne, NE1 7RU, UK. Abstract: An increasing number
Survey on Comparative Analysis of Database Replication Techniques
72 Survey on Comparative Analysis of Database Replication Techniques Suchit Sapate, Student, Computer Science and Engineering, St. Vincent Pallotti College, Nagpur, India Minakshi Ramteke, Student, Computer
TECHNIQUES FOR DATA REPLICATION ON DISTRIBUTED DATABASES
Constantin Brâncuşi University of Târgu Jiu ENGINEERING FACULTY SCIENTIFIC CONFERENCE 13 th edition with international participation November 07-08, 2008 Târgu Jiu TECHNIQUES FOR DATA REPLICATION ON DISTRIBUTED
Concurrency Control. Module 6, Lectures 1 and 2
Concurrency Control Module 6, Lectures 1 and 2 The controlling intelligence understands its own nature, and what it does, and whereon it works. -- Marcus Aurelius Antoninus, 121-180 A. D. Database Management
AN OVERVIEW OF DISTRIBUTED DATABASE MANAGEMENT
AN OVERVIEW OF DISTRIBUTED DATABASE MANAGEMENT BY AYSE YASEMIN SEYDIM CSE 8343 - DISTRIBUTED OPERATING SYSTEMS FALL 1998 TERM PROJECT TABLE OF CONTENTS INTRODUCTION...2 1. WHAT IS A DISTRIBUTED DATABASE
Course Content. Transactions and Concurrency Control. Objectives of Lecture 4 Transactions and Concurrency Control
Database Management Systems Fall 2001 CMPUT 391: Transactions & Concurrency Control Dr. Osmar R. Zaïane University of Alberta Chapters 18 and 19 of Textbook Course Content Introduction Database Design
How To Write A Transaction System
Chapter 20: Advanced Transaction Processing Remote Backup Systems Transaction-Processing Monitors High-Performance Transaction Systems Long-Duration Transactions Real-Time Transaction Systems Weak Levels
Applying Attribute Level Locking to Decrease the Deadlock on Distributed Database
Applying Attribute Level Locking to Decrease the Deadlock on Distributed Database Dr. Khaled S. Maabreh* and Prof. Dr. Alaa Al-Hamami** * Faculty of Science and Information Technology, Zarqa University,
SODDA A SERVICE-ORIENTED DISTRIBUTED DATABASE ARCHITECTURE
SODDA A SERVICE-ORIENTED DISTRIBUTED DATABASE ARCHITECTURE Breno Mansur Rabelo Centro EData Universidade do Estado de Minas Gerais, Belo Horizonte, MG, Brazil [email protected] Clodoveu Augusto Davis
Topics. Distributed Databases. Desirable Properties. Introduction. Distributed DBMS Architectures. Types of Distributed Databases
Topics Distributed Databases Chapter 21, Part B Distributed DBMS architectures Data storage in a distributed DBMS Distributed catalog management Distributed query processing Updates in a distributed DBMS
Workflow Management Design and Implementation
Distributed Global Transaction Support for Workflow Management Applications Jochem Vonk, Paul Grefen, Erik Boertjes, Peter Apers Center for Telematics and Information Technology (CTIT) University of Twente
Chapter 14: Recovery System
Chapter 14: Recovery System Chapter 14: Recovery System Failure Classification Storage Structure Recovery and Atomicity Log-Based Recovery Remote Backup Systems Failure Classification Transaction failure
A three-dimensional visualization of communications in distributed program environments
Engineering Industrial & Management Engineering fields Okayama University Year 2003 A three-dimensional visualization of communications in distributed program environments Mariko Sasakura Okayama University
Concurrency Control: Locking, Optimistic, Degrees of Consistency
CS262A: Advanced Topics in Computer Systems Joe Hellerstein, Spring 2008 UC Berkeley Concurrency Control: Locking, Optimistic, Degrees of Consistency Transaction Refresher Statement of problem: Database:
Chapter 18: Database System Architectures. Centralized Systems
Chapter 18: Database System Architectures! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems! Network Types 18.1 Centralized Systems! Run on a single computer system and
Centralized Systems. A Centralized Computer System. Chapter 18: Database System Architectures
Chapter 18: Database System Architectures Centralized Systems! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems! Network Types! Run on a single computer system and do
Distributed Databases
Distributed Databases Chapter 1: Introduction Johann Gamper Syllabus Data Independence and Distributed Data Processing Definition of Distributed databases Promises of Distributed Databases Technical Problems
Chapter Outline. Chapter 2 Distributed Information Systems Architecture. Middleware for Heterogeneous and Distributed Information Systems
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 [email protected] Chapter 2 Architecture Chapter Outline Distributed transactions (quick
Goals. Managing Multi-User Databases. Database Administration. DBA Tasks. (Kroenke, Chapter 9) Database Administration. Concurrency Control
Goals Managing Multi-User Databases Database Administration Concurrency Control (Kroenke, Chapter 9) 1 Kroenke, Database Processing 2 Database Administration All large and small databases need database
INTRODUCTION TO DATABASE SYSTEMS
1 INTRODUCTION TO DATABASE SYSTEMS Exercise 1.1 Why would you choose a database system instead of simply storing data in operating system files? When would it make sense not to use a database system? Answer
DATABASE REPLICATION A TALE OF RESEARCH ACROSS COMMUNITIES
DATABASE REPLICATION A TALE OF RESEARCH ACROSS COMMUNITIES Bettina Kemme Dept. of Computer Science McGill University Montreal, Canada Gustavo Alonso Systems Group Dept. of Computer Science ETH Zurich,
Distributed Databases
C H A P T E R19 Distributed Databases Practice Exercises 19.1 How might a distributed database designed for a local-area network differ from one designed for a wide-area network? Data transfer on a local-area
Modular Communication Infrastructure Design with Quality of Service
Modular Communication Infrastructure Design with Quality of Service Pawel Wojciechowski and Péter Urbán Distributed Systems Laboratory School of Computer and Communication Sciences Swiss Federal Institute
Chapter 10. Backup and Recovery
Chapter 10. Backup and Recovery Table of Contents Objectives... 1 Relationship to Other Units... 2 Introduction... 2 Context... 2 A Typical Recovery Problem... 3 Transaction Loggoing... 4 System Log...
Introduction to Database Systems CS4320. Instructor: Christoph Koch [email protected] CS 4320 1
Introduction to Database Systems CS4320 Instructor: Christoph Koch [email protected] CS 4320 1 CS4320/1: Introduction to Database Systems Underlying theme: How do I build a data management system? CS4320
Oracle Database Links Part 2 - Distributed Transactions Written and presented by Joel Goodman October 15th 2009
Oracle Database Links Part 2 - Distributed Transactions Written and presented by Joel Goodman October 15th 2009 About Me Email: [email protected] Blog: dbatrain.wordpress.com Application Development
COMP5426 Parallel and Distributed Computing. Distributed Systems: Client/Server and Clusters
COMP5426 Parallel and Distributed Computing Distributed Systems: Client/Server and Clusters Client/Server Computing Client Client machines are generally single-user workstations providing a user-friendly
Distributed Database Systems
Distributed Database Systems Vera Goebel Department of Informatics University of Oslo 2011 1 Contents Review: Layered DBMS Architecture Distributed DBMS Architectures DDBMS Taxonomy Client/Server Models
Concurrency Control. Chapter 17. Comp 521 Files and Databases Fall 2010 1
Concurrency Control Chapter 17 Comp 521 Files and Databases Fall 2010 1 Conflict Serializable Schedules Recall conflicts (WR, RW, WW) were the cause of sequential inconsistency Two schedules are conflict
Computer Network. Interconnected collection of autonomous computers that are able to exchange information
Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.
Introduction to Database Management Systems
Database Administration Transaction Processing Why Concurrency Control? Locking Database Recovery Query Optimization DB Administration 1 Transactions Transaction -- A sequence of operations that is regarded
Distributed Transactions
Distributed Transactions 1 Transactions Concept of transactions is strongly related to Mutual Exclusion: Mutual exclusion Shared resources (data, servers,...) are controlled in a way, that not more than
Locality Based Protocol for MultiWriter Replication systems
Locality Based Protocol for MultiWriter Replication systems Lei Gao Department of Computer Science The University of Texas at Austin [email protected] One of the challenging problems in building replication
IV Distributed Databases - Motivation & Introduction -
IV Distributed Databases - Motivation & Introduction - I OODBS II XML DB III Inf Retr DModel Motivation Expected Benefits Technical issues Types of distributed DBS 12 Rules of C. Date Parallel vs Distributed
Transaction Management in Distributed Database Systems: the Case of Oracle s Two-Phase Commit
Transaction Management in Distributed Database Systems: the Case of Oracle s Two-Phase Commit Ghazi Alkhatib Senior Lecturer of MIS Qatar College of Technology Doha, Qatar [email protected] and Ronny
Recovery and the ACID properties CMPUT 391: Implementing Durability Recovery Manager Atomicity Durability
Database Management Systems Winter 2004 CMPUT 391: Implementing Durability Dr. Osmar R. Zaïane University of Alberta Lecture 9 Chapter 25 of Textbook Based on slides by Lewis, Bernstein and Kifer. University
The Oracle Universal Server Buffer Manager
The Oracle Universal Server Buffer Manager W. Bridge, A. Joshi, M. Keihl, T. Lahiri, J. Loaiza, N. Macnaughton Oracle Corporation, 500 Oracle Parkway, Box 4OP13, Redwood Shores, CA 94065 { wbridge, ajoshi,
Transactions and Concurrency Control. Goals. Database Administration. (Manga Guide to DB, Chapter 5, pg 125-137, 153-160) Database Administration
Transactions and Concurrency Control (Manga Guide to DB, Chapter 5, pg 125-137, 153-160) 1 Goals Database Administration Concurrency Control 2 Database Administration All large and small databases need
Transaction-based Configuration Management for Mobile Networks
First Annual Workshop on Distributed Autonomous Network Management Systems, Dublin, June 2006 Transaction-based Configuration Management for Mobile Networks Henning Sanneck, Christoph Schmelz Siemens Communications
