Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-03-12
2001-09-25
Lim, Krisna (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06295548
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the xerographic reproduction by anyone of the patent document or the patent disclosure in exactly the form it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
The present invention relates generally to transaction processing, and more particularly to techniques for marking a transaction as an imported transaction, and including information about the parent transaction when exporting a transaction branch for the imported transaction. The techniques of the present invention are useful to ensure that two different subordinate transactions will not be created at any given transaction processing node for the same parent transaction.
A transaction is most often defined as an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection (e.g., database or databases) from one consistent state to another. Changes are treated as a single unit in that all changes of a transaction are formed and made permanent (the transaction is “committed”) or none of the changes are made permanent (the transaction is “aborted”). If a failure occurs during the execution of a transaction, resulting in the transaction being aborted, whatever partial changes were made to the collection are undone to leave it in a consistent state.
A transaction processing system typically includes a transaction manager; a collection of subsystems, called resource managers (RMs), which are essentially abstractions of available services, such as database systems; application programs; and the like. The transaction processing system provides a way to interconnect applications and resource managers while maintaining data integrity and transactional consistency.
The application process initiating a transaction invokes various services and/or resource managers to perform various operations and tasks necessary to complete the transaction. All services and resource managers invoked to perform operations for the transaction register with a transaction manager, stating that they are joining the transaction. A transaction manager typically provides transaction management functions, such as monitoring the progress of the transaction and coordinating the commit processing and rollback of the transaction, and protects the integrity of user data. When all operations, or work, have completed, the initiating application process notifies the transaction manager of this fact. The transaction manager then initiates an agreement protocol to coordinate commitment processing among all services and resource managers (including foreign transaction managers) participating in the transaction. In transaction processing the standard agreement protocol is the two-phase commitment (2PC) protocol. A description of the 2PC protocol, as well as a detailed overview of transaction processing, is presented in J. Gray et al.,
Transaction Processing Concepts and Techniques,
Morgan Kauffman, 1993, the contents of which are herein incorporated by reference.
Briefly, in phase one of the 2PC protocol, the transaction manager issues a request prepare signal to each participant (i.e., the transaction manager asks each participating service or resource manager if it believes the operations it performed to be a consistent and complete transformation). If any participant votes no, the commit fails and the transaction is aborted and rolled back; if all participating resource managers vote yes (ready to commit), the transaction is a correct transformation and phase two commences. In phase two of the 2PC protocol, the transaction manager issues a commit request signal informing each participant that the transaction is complete, and records this fact in the transaction's log. After all participants acknowledge the commit request, the transaction manager records this fact and forgets about the transaction.
Recently, a Transaction Internet Protocol (TIP) that uses the 2PC paradigm has been proposed by the Internet Engineering Task Force (IETF). Attached hereto, as Appendix A, is the final version of the IETF paper describing TIP and its requirements. The IETF paper describes a simple 2PC protocol applicable to transactions involving resources in a distributed, Internet-connected transaction. Basically, two models are described: a “Push” model and “Pull ” model.
In the Push model, an application on a first transaction processing system requests that the transaction manager of that system “export ” a transaction, T
1
, to a second transaction monitoring system to perform some work on behalf of the application. The transaction manager of the first system “pushes ” transaction T
1
to the second system by sending a message to the transaction manager of the second system. The message requests that the second system start a local transaction associated with transaction T
1
as a subordinate of the first system, and return the name, for example “T
2
”, for that local (imported) transaction branch on the second system together with the Internet address of the local transaction branch. The transaction manager forwards to the application the name, T
2
, and the internet address of the transaction on the second system associated with transaction T
1
. The application then sends a message to the desired application on the second system, asking it to “do some work, and make it part of the transaction that your transaction manager already knows of by the name of T
2
.” Additionally, the first and second transaction managers each update a global map by associating the global transaction T
1
initiated on the first system with the transaction branch T
2
. The global map is a data structure that is typically maintained by a transaction manager maintains in order to associate any and all remote transaction branches, such as T
2
, with associated global transactions, such as T
1
. Because the first system's transaction manager knows that it sent the transaction to the second system's transaction manager, the first system's transaction manager knows to involve the second system's transaction manager in the 2PC process.
In the Pull model, an application on the first system merely sends a message to an application on the second system, requesting that it “do some work, and make it part of a transaction that my transaction manager knows by the name of T
1
.” The application on the second system then requests that its transaction manager enlist in the transaction T
1
. The second system's transaction manager “pulls ” transaction T
1
over from the first system and initiates a local transaction, T
2
, associated with transaction T
1
. Also, both transaction managers update their system's global map. As a result of the pull, the first system's transaction manager knows to involve the second system's transaction manager in the 2PC process.
In both the push model and the pull model, it is a common occurrence for a transaction processing system or node to receive two different work requests associated with the same parent transaction. That is, two different transaction branches for the same parent transaction may be sent to the same node. For example,
FIG. 1
shows a first transaction processing system
10
exporting a transaction branch for a first transaction T
1
to both a second remote transaction processing node
20
and a third remote transaction processing node
30
. In the TIP model, the work request sent to both remote nodes includes a TIP uniform resource locator (TIP URL) created by the transaction manager
15
of the exporting system. The TIP URL includes the internet address of the transaction T
1
, a global transaction identifier (G
1
), which uniquely identifies the transaction, and a local transaction identifier (L
1
). In most cases, because the transaction was initiated at first transaction processing
Gondi Albert C.
Hansen Roger J.
Klein Johannes
Lanka Sitaram V.
Compaq Computer Corporation
Lim Krisna
Oppenheimer Wolff & Donnelly LLP
Sherry Leah
LandOfFree
Detection of an imported transaction for finding the global... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Detection of an imported transaction for finding the global..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Detection of an imported transaction for finding the global... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2449381