Reliable transaction management in a multidatabase system
01 May 1990-Vol. 19, Iss: 2, pp 215-224
TL;DR: A fault tolerant transaction management algorithm and recovery procedures that retain global database consistency are designed and shown that their algorithms ensure freedom from global deadlocks of any kind.
Abstract: A model of a multidatabase system is defined in which each local DBMS uses the two-phase locking protocol Locks are released by a global transaction only after the transaction commits or aborts at each local site. Failures may occur during the processing of transactions. We design a fault tolerant transaction management algorithm and recovery procedures that retain global database consistency. We also show that our algorithms ensure freedom from global deadlocks of any kind.
Citations
More filters
01 Oct 1992
TL;DR: It is argued that the multidatabase research will become increasingly important in the coming years and basic research issues in multid atabase transaction management are outlined, followed by a discussion of open problems and practical implications.
Abstract: A multidatabase system (MDBS) is a facility that allows users access to data located in multiple autonomous database management systems (DBMSs). In such a system, global transactions are executed under the control of the MDBS. Independently, local transactions are executed under the control of the local DBMSs. Each local DBMS integrated by the MDBS may employ a different transaction management scheme. In addition, each local DBMS has complete control over all transactions (global and local) executing at its site, including the ability to abort at any point any of the transactions executing at its site. Typically, no design or internal DBMS structure changes are allowed in order to accommodate the MDBS. Furthermore, the local DBMSs may not be aware of each other and, as a consequence, cannot coordinate their actions. Thus, traditional techniques for ensuring transaction atomicity and consistency in homogeneous distributed database systems may not be appropriate for an MDBS environment. The objective of this article is to provide a brief review of the most current work in the area of multidatabase transaction management. We first define the problem and argue that the multidatabase research will become increasingly important in the coming years. We then outline basic research issues in multidatabase transaction management and review recent results in the area. We conclude with a discussion of open problems and practical implications of this research.
577 citations
Patent•
14 Apr 1993
TL;DR: In this article, the read-write transactions are serialized by maintaining and referencing a graph of conflicts among readwrite transactions, and read-only transactions areserialized by a timestamp mechanism for selection of the snapshots to be read.
Abstract: In a multi-version database, copies of prior committed versions (snapshots) are kept for access by the read-only transactions. The read-write transactions are selectively aborted to enforce an order of commitment of read-write transactions that is the same as an order of conflicts among the read-write transactions. In a preferred embodiment, the read-write transactions are serialized by maintaining and referencing a graph of conflicts among read-write transactions, and the read-only transactions are serialized by a timestamp mechanism for selection of the snapshots to be read. Each time that a read-write transaction is committed, the read-write transaction is assigned a unique timestamp that is used to timestamp all resources committed by the read-write transaction. Upon starting, each read-only transaction is also assigned a timestamp. Each read-only transaction reads only the latest committed versions of all resources, that are timestamped earlier than the timestamp of the read-only transaction. In a multiprocessing system, the timestamps are issued to global coordinators and distributed locally with atomic commit messages and global queries. Moreover, read-write transactions may selectively access a hierarchy of uncommitted versions to prepare for various possible commitment orders. The hierarchy defines a path for record access and for cascading aborts. A plurality of mutually-conflicting uncommitted versions may be prepared for each transaction to prepare for all possible commitment orders.
274 citations
TL;DR: The concept of distributed object management is described, and its role in the development of these open, interoperable systems being developed at GTE Laboratories is identified.
Abstract: Future information processing environments will consist of a vast network of heterogeneous, autonomous, and distributed computing resources, including computers (from mainframe to personal), information-intensive applications, and data (files and databases) A key challenge in this environment is providing capabilities for combining this varied collection of resources into an integrated distributed system, allowing resources to be flexibly combined, and their activities coordinated, to address challenging new information processing requirements In this paper, we describe the concept of distributed object management, and identify its role in the development of these open, interoperable systems We identify the key aspects of system architectures supporting distributed object management, and describe specific elements of a distributed object management system being developed at GTE Laboratories
192 citations
Cites background from "Reliable transaction management in ..."
...The basic problems in multidatabase recovery and corresponding solutions that address each of these problems are discussed in [ BREI90 , WOLS90, GEOR91b]....
[...]
08 Apr 1991
TL;DR: Both OTM and ITM achieve global serializability by controlling the commitment and thus the serialization order of multidatabase transactions and can be combined in a single comprehensive mechanism.
Abstract: A multidatabase transaction management mechanism called the optimistic ticket method (OTM) is introduced for enforcing global serializability. It permits the commitment of multidatabase transactions only if their relative serialization order is the same in all participating local database systems (LDBSs). OTM requires the LDBSs to guarantee only local serializability. The basic idea in OTM is to create direct conflicts between multidatabase transactions at each LDBS in order to determine the relative serialization order of their subtransactions. A refinement of OTM, called the implicit ticket method (ITM), is also introduced that uses implicit tickets and eliminates ticket conflicts but works only when the participating LDBSs use rigorous transaction scheduling mechanisms. ITM uses the local commitment order of each subtransaction to determine its implicit ticket value. It achieves global serializability by controlling the commitment (execution order) and thus the serialization order of multidatabase transactions. Both OTM and ITM do not violate the autonomy of the LDBSs and can be combined in a single comprehensive mechanism. >
174 citations
TL;DR: This paper outlines approaches to various aspects of heterogeneous distributed data management and describes the characteristics and architectures of seven existingheterogeneous distributed database systems developed for production use.
Abstract: It is increasingly important for organizations to achieve additional coordination of diverse computerized operations. To do so, it is necessary to have database systems that can operate over a distributed network and can encompass a heterogeneous mix of computers, operating systems, communications links, and local database management systems. This paper outlines approaches to various aspects of heterogeneous distributed data management and describes the characteristics and architectures of seven existing heterogeneous distributed database systems developed for production use. The objective is a survey of the state of the art in systems targeted for production environments as opposed to research prototypes.
170 citations
References
More filters
IBM1
TL;DR: It is argued that a transaction needs to lock a logical rather than a physical subset of the database, and an implementation of predicate locks which satisfies the consistency condition is suggested.
Abstract: In database systems, users access shared data under the assumption that the data satisfies certain consistency constraints. This paper defines the concepts of transaction, consistency and schedule and shows that consistency requires that a transaction cannot request new locks after releasing a lock. Then it is argued that a transaction needs to lock a logical rather than a physical subset of the database. These subsets may be specified by predicates. An implementation of predicate locks which satisfies the consistency condition is suggested.
2,031 citations
Book•
01 Jan 1980TL;DR: This acclaimed revision of a classic database systems text provides the latest information combined with real-world examples to help readers master concepts in a technically complete yet easy-to-understand style.
Abstract: From the Publisher:
This acclaimed revision of a classic database systems text offers a complete background in the basics of database design, languages, and system implementation It provides the latest information combined with real-world examples to help readers master concepts All concepts are presented in a technically complete yet easy-to-understand style with notations kept to a minimum A running example of a bank enterprise illustrates concepts at work To further optimize comprehension, figures and examples, rather than proofs, portray concepts and anticipate results
1,674 citations
IBM1
TL;DR: This paper is a compendium of data base management operating systems folklore and focuses on particular issues unique to the transaction management component especially locking and recovery.
Abstract: This paper is a compendium of data base management operating systems folklore. It is an early paper and is still in draft form. It is intended as a set of course notes for a class on data base operating systems. After a brief overview of what a data management system is it focuses on particular issues unique to the transaction management component especially locking and recovery.
1,635 citations
TL;DR: In this article, the authors present designs for several distributed concurrency controls and demonstrates that they work correctly and investigates some of the implications of global consistency of a distributed database and discusses phenomena that can prevent termination of application programs.
Abstract: A distributed database system is one in which the database is spread among several sites and application programs “move” from site to site to access and update the data they need. The concurrency control is that portion of the system that responds to the read and write requests of the application programs. Its job is to maintain the global consistency of the distributed database while ensuring that the termination of the application programs is not prevented by phenomena such as deadlock. We assume each individual site has its own local concurrency control which responds to requests at that site and can only communicate with concurrency controls at other sites when an application program moves from site to site, terminates, or aborts.This paper presents designs for several distributed concurrency controls and demonstrates that they work correctly. It also investigates some of the implications of global consistency of a distributed database and discusses phenomena that can prevent termination of application programs.
360 citations
01 Jan 2009
TL;DR: In this paper, the authors present designs for several distributed concurrency controls and demonstrates that they work correctly and investigates some of the implications of global consistency of a distributed database and discusses phenomena that can prevent termination of application programs.
Abstract: A distributed database system is one in which the database is spread among several sites and application programs “move” from site to site to access and update the data they need. The concurrency control is that portion of the system that responds to the read and write requests of the application programs. Its job is to maintain the global consistency of the distributed database while ensuring that the termination of the application programs is not prevented by phenomena such as deadlock. We assume each individual site has its own local concurrency control which responds to requests at that site and can only communicate with concurrency controls at other sites when an application program moves from site to site, terminates, or aborts.This paper presents designs for several distributed concurrency controls and demonstrates that they work correctly. It also investigates some of the implications of global consistency of a distributed database and discusses phenomena that can prevent termination of application programs.
340 citations