Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-11-17
2004-08-03
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C709S227000
Reexamination Certificate
active
06772176
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to providing atomicity of transactions on a database system, and in particular, coordinating a distributed transaction that involves participants unable to support a two-phase protocol to commit the transaction.
BACKGROUND OF THE INVENTION
One of the long standing challenges in distributed computing has been to maintain data consistency across all of the nodes in a network. Perhaps nowhere is data consistency more important than in distributed database systems, where a distributed transaction may specify updates to related data residing on different database systems. To maintain data consistency, all changes made in all database systems by the distributed transaction must be either committed or, in the event of an error, “rolled back”. When a transaction is committed, all of the changes to data specified by the transaction are made permanent. On the other hand, when a transaction is rolled back, all of the changes to data specified by the transaction already made are retracted or undone, as if the changes to the data were never made.
One approach for ensuring data consistency when processing distributed transactions is referred to as “two-phase commit”. According to the two-phase commit approach, one database system (the coordinating database system) is responsible for coordinating the commitment of the transaction on one or more other database systems. The other database systems that hold data affected by the transaction are referred to as participating database systems.
A two-phase commit involves two-phases, the prepare phase and the commit phase. In the prepare phase, the transaction is prepared in each of the participating database systems. When a transaction is prepared on a database system, the database is put into such a state that it is guaranteed that modifications specified by the transaction to the database data can be committed. When all participants involved in a transaction are prepared, the prepared phase ends and the commit phase may begin.
In the commit phase, the coordinating database system commits the transaction on the coordinating database system and on the participating database systems. Specifically, the coordinating database system sends messages to the participants requesting that the participants commit the modifications specified by the transaction to data on the participating database systems. The participating database systems and the coordinating database system then commit the transaction. Finally, the participating database systems transmit a message acknowledging the commit to the coordinating database system.
On the other hand, if a participating database system is unable to prepare, or the coordinating database system is unable to commit, then at least one of the database systems is unable to make the changes specified by the transaction. In this case, all of the modifications at each of the participants and the coordinating database system are retracted, restoring each database system to its state prior to the changes.
Changes made by a participating database system on behalf of a distributed database system are executed as a subtransaction. To commit a distributed transaction, a participating database commits its respective subtransaction of the distributed transaction.
The two-phase commit ensures data consistency while providing simultaneous processing of modifications to distributed databases. However, the two-phase commit does not achieve data consistency without cost. For example, participating database systems involved in a distributed transaction experience latency when waiting for other database systems to become prepared. While the participating database systems are waiting, resources affected by the distributed transaction are locked. The resources remained locked until all participating database systems are prepared, the coordinator transmits a message to the participating database systems to commit, and the participating systems commit their respective subtransactions. This leads to contention problems, because other processes waiting for the locked resources to become available are stalled until those resources are freed. A delay by any participating database system in preparing to commit increases the amount of time other processes will have to wait for locked resources.
Another problem stems from the use of two-phase commit communication protocols. A two-phase communication protocol is a set of rules, messages, and message formats followed by databases systems either coordinating or participating in a two-phase commit. One example of a two-phase commit communication protocol is LU6.2.
Many database systems do not support two-phase commit communication protocols that are compatible with those protocols used by other database systems, and are thus unable to participate with those other database systems in distributed transactions. When a database system does not support a protocol needed to participate in a distributed transaction, the database system is referred to herein as being “incompatible”. A database system that supports a protocol required to participate in a distributed transaction is referred to as being “compatible” relative to that transaction.
Because participating in a distributed transaction creates the potential for latency and resource contention, participating in a distributed transaction creates security risks for participating database systems. For a participating database system, the availability of resources tied up by a distributed transaction may depend on another participating database system. Thus, some database systems limit their participation in distributed transactions to only transactions that involve “trusted” database systems.
Based on the foregoing, it is clearly desirable to provide a method that allows participation in a distributed transaction for database systems unable to support a two-phase protocol needed to participate in the distributed transaction, to provide a method that reduces the potential for latency and resource contention for participating database systems, and that reduces security risk for participating database systems.
SUMMARY OF THE INVENTION
Described herein are techniques that may be used to coordinate the execution of a distributed transaction by a set of database systems, where the set of database systems includes at least one incompatible database system. The distributed transaction is executed as long as operations performed by the incompatible system on behalf of the distributed transaction are read-only operations. To commit the distributed transaction, the incompatible database system aborts the distributed transaction, while the remaining “compatible” database systems complete the distributed transaction using a two-phase commit.
REFERENCES:
patent: 5261089 (1993-11-01), Coleman et al.
patent: 5561797 (1996-10-01), Gilles et al.
patent: 5884327 (1999-03-01), Cotner et al.
patent: 5920863 (1999-07-01), McKeehan et al.
patent: 5924095 (1999-07-01), White
patent: 5953719 (1999-09-01), Kleewein et al.
patent: 6021443 (2000-02-01), Bracho et al.
patent: 6049809 (2000-04-01), Raman et al.
patent: 6101527 (2000-08-01), Lejeune et al.
patent: 6148299 (2000-11-01), Yoshimoto
patent: 6182080 (2001-01-01), Clements
patent: 6243715 (2001-06-01), Bogantz et al.
patent: 6247023 (2001-06-01), Hsiao et al.
patent: 6286004 (2001-09-01), Yoshiura et al.
patent: 6493726 (2002-12-01), Ganesh et al.
patent: 6510421 (2003-01-01), Ganesh et al.
Ganesh Amit
Saha Debashis
Bingham Marcel K.
Hickman Palermo & Truong & Becker LLP
Le Miranda
Oracle International Corporation
Robinson Greta
LandOfFree
Coordinating a distributed transaction between participants... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Coordinating a distributed transaction between participants..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Coordinating a distributed transaction between participants... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3298694