Overview of multidatabase transaction management

Yuri Breitbart, Hector Garcia-Molina, Avi Silberschatz
1992 The VLDB journal  
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, globaltransactions are executed under the control of the MDBS. Independently, localtransactions 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)
more » ... ing 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. Patter~n Office Tower, Lexington, ICY 40506.-00227, USA.) each local DBMS uses some form of recovery scheme (e.g., write-ahead log scheme; Bernstein et al., 1987) . The MDBS considers each local DBMS as a black box that operates autonomously, without the knowledge of either other local DBMSs or the MDBS system. Local autonomy is the main feature that distinguishes the multidatabase systems from conventional distributed database systems. There are three main types of autonomy: Design autonomy: No changes can be made to the local DBMS software to accommodate the MDBS system. Making changes to the existing software of the DBMS is expensive, may result in performance degradation and, further, may render pre-existing applications inoperative. Execution autonomy: Each local DBMS should retain complete control over the execution of transactions at its site. An implication of this constraint is that a local DBMS may abort a transaction executing at its site at any time during its execution, including the time when a global transaction is in the process of being committed by the MDBS. Communication autonomy: Local DBMSs integrated by the MDBS are not able to coordinate the actions of global transactions executing at several sites. This constraint implies that local DBMSs do not share their control information with each other or with the MDBS system. Participating DBMSs may have different autonomy levels. For example, some sites may be willing to participate in the coordination of a global transaction (low communication autonomy) while others may not (high communication autonomy). One way to characterize the autonomy levels of sites is to define the interface that each local data source offers to user transactions. For example, no airline, bank, or car agency would allow external users' transactions to access their data using SQL statements. On the other hand, internal users' transactions will be allowed to do so. The interfaces can be categorized by the operations they accept from the MDBS. Here, we illustrate some of the operations that may be available at a site (black box). We partition these operations into two sets. The first one deals with transaction operations, while the second one deals with status information.
doi:10.1007/bf01231700 fatcat:2bcf7gkjdna2tlpdfd2fhi57hy