Extensible framework of key resource manager and transaction...

Details Extensible framework of key resource manager and transaction... Extensible framework of key resource manager and transaction...

1998-05-07

2001-05-15

Alam, Hosain T. (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000

Reexamination Certificate

active

06233587

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to resource managers and, more specifically, to an extensible framework of resource and transaction manager events being used to provide native support for foreign-initiated transactions.
BACKGROUND OF THE INVENTION
A resource manager is a set of one or more processes that manage access to a resource. A database server is one example of a resource manager. A database server manages access to the data stored in a database. In typical database systems, users store, update and retrieve information from a database by submitting commands to a database server. To be correctly processed, the commands must comply with the database language that is supported by the database server. One popular database language is known as Structured Query Language (SQL). A logical unit of work that is comprised of one or more database language statements is referred to as a transaction.
To ensure the integrity of resources, resources must show all of the changes made by a transaction, or none of the changes made by the transaction. Consequently, none of the changes made by a transaction are permanently applied to a database until the transaction has been fully executed. A transaction is said to “commit” when the changes made by the transaction are made permanent to the resources affected by the transaction.
There are two general categories of transactions: local transactions and distributed transactions. A local transaction is coordinated entirely within a single resource manager. Consequently, the resource manager knows when a local transaction has been fully executed, and is able to commit local transactions without any additional information from outside of the resource manager. A local transaction therefore goes directly from an active state to a committed state when the transaction is fully executed.
A distributed transaction is not performed entirely within a single resource manager. For example, a distributed transaction may require work to be performed by two resource managers. The first resource manager may execute one portion of the work required by the distributed transaction, while the second resource manager executes another portion.
Typically, a resource manager will use a local transaction to perform the portion of a distributed transaction for which it is responsible. The same resource manager may initiate a different local transaction each time it is asked to perform work associated with a foreign transaction.
A distributed transaction is not fully executed until all work associated with the distributed transaction has been fully executed. Consequently, when a resource manager completes the execution of a portion of the distributed transaction, it does not automatically commit the local transaction(s) that performed work. Rather, the resource manager places the work in a “prepared” state. The work remains in the prepared state until the resource manager is notified about whether the work should be committed or rolled back.
For example, when its portion of the distributed transaction is fully executed, the first resource manager mentioned above cannot commit the changes made to the resource it controls until the first resource manager is informed that the other portions of the distributed transaction are fully executed. Therefore, after fully executing its portion, the first resource manager places the work in a prepared state. Similarly, the second resource manager places its work in the prepared state when the second resource manager has fully executed its portion of the distributed transaction.
A transaction manager is a set of one or more processes that is responsible for coordinating a distributed transaction. Transaction managers may be part of a resource manager, or may reside external to the resource manager. Transaction managers that reside external to a particular resource manager are referred to herein as foreign transaction managers. A transaction manager that is foreign to one resource manager may actually reside in another resource manager. Foreign transaction managers are useful for coordinating the work associated with transactions that require operations to be performed by two or more different types of resource managers.
The transaction manager for a distributed transaction coordinates the work associated with the distributed transaction by interacting with the resource managers that are responsible for performing the work. There are multiple ways to make the transaction manager aware of the work being performed by resource managers. While coordinating the work associated with a distributed transaction, the transaction manager requests status updates from the resource managers. When the transaction manager has determined that all of the resource managers have prepared their respective portions of the distributed transaction, the transaction manager informs all of the resource managers to commit their work. If any resource manager is unable to complete its portion of the distributed transaction, then the transaction manager informs all of the resource managers to roll back their work.
Communication between a foreign transaction manager and resource managers is performed through an external interface. Currently, the most common interface for transaction manager-to-resource manager communications is the XA interface described in “Distributed Transaction Processing: The XA Specification”, available from X/Open Company Ltd., United Kingdom. To communicate through the XA interface, resource managers must implement certain functions dictated by the XA interface. Foreign transaction managers then interact with those resource manager by making calls to those functions.
The specific functions specified by the XA interface include:
1. Connection open
2. Transaction start
3. Transaction end
4. Transaction prepare
5. Transaction recovery
6. Transaction commit
7. Transaction rollback
8. Transaction forget
9. Connection close
The use of an interface, such as the XA interface, isolates foreign transaction managers from the resource managers with whom they interact. Thus, resource managers have no concept of the nature of the distributed transactions being managed by the foreign transaction manager other than the identification of the distributed transaction, nor of the data structures maintained by the foreign transaction manager for the transactions. Rather, the resource managers map the requests that come through the interface to their own native form and structure for transactions.
For example, a transaction manager may use data structures X to manage a distributed transaction, while a resource manager uses data structures Y to manage local transactions. On the other hand, the XA interface uses a data structure Z, referred to as an xid, to identify transactions. Consequently, in every call made by the transaction manager to the resource manager for a particular transaction, the transaction manager has to map the appropriate data structure X to the data structure Z, and pass the data structure Z. In every call received from the transaction manager, the resource manager maps the received data structure Z to the appropriate corresponding data structure Y.
Similarly, in every response made by the resource manager, the resource manager has to map the appropriate data structure Y to the data structure Z. In every message received by the transaction manager from the resource manager, the transaction manager maps the received data structure Z to the appropriate data structure X.
Based on the foregoing, it is desirable to tighten the integration between foreign transaction managers and the resource managers with which they interact by providing a framework that allows native resource manager support for transactions managed by foreign transaction managers.
SUMMARY OF THE INVENTION
An extensible framework of resource and transaction manager events is provided for allowing a resource manager to be more tightly integrated with foreign transaction managers with which it interacts. The tighter integration made possible by an extensible frame

Affiliated with

Also associated with

Rating

Extensible framework of key resource manager and transaction... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Extensible framework of key resource manager and transaction..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Extensible framework of key resource manager and transaction... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2555851