US20040083225A1 - Method and apparatus for handling failures of resource managers in a clustered environment - Google Patents
Method and apparatus for handling failures of resource managers in a clustered environment Download PDFInfo
- Publication number
- US20040083225A1 US20040083225A1 US10/688,323 US68832303A US2004083225A1 US 20040083225 A1 US20040083225 A1 US 20040083225A1 US 68832303 A US68832303 A US 68832303A US 2004083225 A1 US2004083225 A1 US 2004083225A1
- Authority
- US
- United States
- Prior art keywords
- resource manager
- transaction
- tmf
- detecting
- backup
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/006—Identification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Definitions
- the invention relates generally to a clustered processing system formed from multiple processor units with fault-tolerant capability. More particularly, the invention relates to a method, and apparatus for implementing that method, for handling, in a fault-tolerant manner, the failure of a resource manager in the context of a transaction executing on the system.
- a useful definition of a transaction is that it is an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection or database 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 (i.e., the transaction is “committed”) or none of the changes are made permanent (i.e., the transaction is “aborted”). If a failure occurs during the execution of a transaction, the transaction can be aborted and whatever partial changes were made to the collection can be undone to leave it in a consistent state.
- TMF transaction manager facility
- the TMF is “distributed” in the sense that each processor unit has its own TMF component to coordinate operations of a transaction conducted on that processor unit.
- the processor unit at which (or on which) a transaction begins is sometimes called the “beginner” processor.
- the TMF component of that processor unit operates to coordinate those transactional resources remote from its resident processor unit (i.e., resources managed by other processor units).
- Those TMF components running on processor units managing resources enlisted in a transaction are “participants” in the transaction. And, it is the TMF component of the beginner processor unit that initiates the steps taken.
- a preferred approach to concluding the transaction, and confirming that all participant resources employed in a transaction are able to participate in that conclusion, is to use the Two-Phase Commit (“2PC”) protocol.
- the beginner TMF component upon receipt of an “End Transaction” request from the application process that requested the transaction, broadcasts a “Prepare” signal to all processor units of the cluster.
- the processor units upon receipt of the Prepare signal, notify their (local) participant resources to perform as necessary (e.g., completing writes to disk storage, clearing memory, etc.) for effecting the change in state of the database and, if the necessary operation succeeds, respond with a “Ready” signal.
- the beginner TMF component If all participants of the transaction respond with an affirmative, i.e., a “Ready” signal (and “Not Involved” signals received from any processor units not participating in the transaction), the beginner TMF component notifies a transaction monitor process (TMP), running on one of the processor units, to “commit” the change to an audit log.
- TMP transaction monitor process
- the TMP tells the beginner TMF component that the transaction is committed, and the beginner TMF component then broadcasts a “Commit” signal to the participant processor units. At this point the change is considered permanent.
- Fault tolerance is another important feature of transaction processing. Being able to detect and tolerate faults allows the integrity of the information collection being managed by the system to be protected.
- one particularly effective fault tolerant technique is the “process-pair” technique, as it is sometimes called. (This technique is also sometimes referred to as “fail-over” capability.)
- an application program is instantiated as two separate processes, a primary process resident on one processor unit of the cluster, and a backup process resident on another processor unit. If the primary process, or the processor unit upon which it is running, fails, that failure brings into operation the backup process to take over the operation of the lost (primary) process.
- the backup decides whether or not to notify the beginner processor unit to abort the transaction and begin over again. In this way the state of the collection managed by the system remains consistent.
- An example of the process-pair or fail-over technique can be found in U.S. Pat. No. 4,817,091.
- An alternative approach one used for example by the software applications that use object linking and embedding (OLE), is to create a backup process only after the primary process is detected as having failed.
- the state needed by the newly-created backup is transferred after creation.
- One problem with this approach is that the state needed by the backup is often retained by the node or processor unit on which the primary was running. If it happens that the primary process has failed because the processor unit on which it was running failed, or it has lost the capability to communicate with the transaction manager, that state can be lost.
- a certain state is written to the audit log maintained by the TMF when a point (using a two-phase or 2PC commit operation) in a transaction is reached beyond which participation of the resources used in the transaction are required.
- the point is when the Ready signal is received in response to the Prepare signal broadcast by the beginner TMF.
- the Ready signal is accompanied by state information from which the state needed by that participant can be recreated, and written to an audit log by the beginner TMF. If the participant fails, or is otherwise made unavailable, a backup participant is created—preferably on another node—and provided with the same identifier of the now-failed participant.
- the backup participant queries TMF to determine if any transactions are outstanding and associated with the identifier. Responding, the TMF supplies the backup participant with the retained state information previously stored in the audit log, thereby allowing the backup participant to complete as necessary the transaction previously involving the failed participant.
- a significant advantage of the invention is to allow OLE compliant applications, such as the Microsoft SQL Server (e.g., the Microsoft SQL Server 6.5) or the Microsoft Message Queue Server, to be ported to a foreign platform and yet keep their fault tolerant capability which relies upon detection of a failure of a process before a backup of that process is created.
- Microsoft SQL Server e.g., the Microsoft SQL Server 6.5
- Microsoft Message Queue Server e.g., the Microsoft Message Queue Server
- FIG. 1 is an illustrative diagram of a multiple processor cluster or system
- FIG. 2 is a flow diagram illustrating creation and migration of a resource manager process
- FIG. 3 is flow diagram broadly illustrating the steps a conventional two-phase commit protocol modified according to an implementation of the present invention.
- the present invention is advantageous in that it permits OLE compliant applications and resources to be ported to a transaction processing system and to participate in transactions with a minimum of re-work of the application or process for the porting process.
- the techniques used by the present invention can be readily employed in other systems (i.e., non-OLE systems).
- the present invention is designed to operate with a transaction processing facility that runs under the aegis of the NonStop operating system available from the assignee of the invention, the Compaq Computer Corporation, Cupertino, California.
- the invention allows OLE applications to conduct transactions under the Nonstop operating system Transaction Manager Facility (TMF) and/or use such OLE compliant resource manager processes as Microsoft SQL Server 6.5 (a high performance database management system for Windows NT-based systems) or the Microsoft Message Queue Server (a transactional support facility that allows message queues to participate in Microsoft Transaction Server transactions).
- TMF Transaction Manager Facility
- resource managers are constructed to operate in the context of another transaction manager.
- the present invention allows their use in the context of a foreign transaction manager and foreign operating system, yet still employ the fault tolerant techniques originally designed for them.
- Microsoft, Microsoft Windows NT are registered trademarks of Microsoft Corporation of Redmond, Wash., and Microsoft SQL Server, and Microsoft Transnational Server are believed to be trademarks of Microsoft Corporation.
- the transaction processing system 10 includes central processor units (CPUs) 12 ( 12 a , 12 b , . . . , 12 d ) and peripheral devices 14 ( 14 a , 14 b , . . . , 14 d ) interconnected by a communication fabric 14 that provides both interprocessor and input/output (I/O) communication.
- CPUs central processor units
- peripheral devices 14 14 a , 14 b , . . . , 14 d
- the communication fabric 14 is constructed as is taught in U.S. Pat. No. 5,751,932.
- the transaction processing system 10 also includes the necessary hardware, software, procedures, rules, and users needed to implement and operate a transaction processing application, including the NonStop or other operating system.
- a distributed transaction manager facility comprising a transaction manager process (TMP) 24 resident on one of the CPUs 12 (in FIG. 1, CPU 12 c ), and TMF components 26 each allocated to an individual processor 12 ; that is, each of the processors 12 has a TMF component 26 ( 26 a , 26 b , . . . , 26 n ) that operates to manage and track the local resource managers (RMs) running on that CPU (e.g., RM(1) on CPU 12 b or RM(2) on CPU 12 d ).
- RMs local resource managers
- the system 10 includes a fail-over capability, such as that provided by the NonStop operating system in the form of the “process pair” technique discussed above.
- a Microsoft Cluster Service (MSCS) 28 for the OLE compliant processes there is provided a Microsoft Cluster Service (MSCS) 28 .
- FIG. 1 also shows each CPU 12 having a component of MSCS 28 .
- MSCS 28 operates to provide a fault tolerance capability by detecting failure of a process, or CPU 12 on which a process is running, and creating replacement or backup process on another CPU for taking over the function and operation of the failed process.
- the present invention provides the means to allow this “failover” to take place with a minimum of effort.
- a distributed transaction coordinator gateway (DTC-GW) 30 Since applications and resource managers, including those that are the OLE compliant, need a resource that provides an efficient communication link to TMF 26 there is provided a distributed transaction coordinator gateway (DTC-GW) 30 . Although there needs to be only one DTC-GW 30 running on one of the CPUs 12 , it is more efficient to have each CPU 12 to include at least one DTC-GW as FIG. 1 illustrates. Not only is the efficiency improved (by avoiding having processes use a DTC-GW on a CPU 12 different from its own), but, as will be seen, the failover capability provided by the MCSC 28 for fault tolerance is made more effective.
- DTC-GW distributed transaction coordinator gateway
- each DTC-GW 30 is communicatively coupled to the TMF component 26 of its particular CPU 12 .
- FIG. 2 shows a flow chart 40 that broadly illustrates the steps taken to create a process such as RM(1).
- a dynamic-linked library DLL
- DLL dynamic-linked library
- the RM(1) is assigned a globally unique identifier (GUID).
- GUID globally unique identifier
- This GUID uniquely identifies the resource to the TMF 26 , distinguishing it from all other processes (e.g., APP 29 ).
- a connection, including a driver 32 is provided the resource to the local DTC-GW 30 .
- RM(1) then, at step 48 , queries TMF 26 to determine if there is any transaction it should be aware of. Since the resource has been created as a primary resource, there is no such transaction. If, on the other hand (as discussed further below) the RM(1) was created to replace a failed resource, and that failed resource was a participant in a transaction when it failed, TMF 26 could respond in the affirmative. This feature is discussed further below.
- APP 29 Assume the APP 29 is requested to perform some operation or operations that requires the state of a database to be changed, and to perform that operation or operations the application (APP) 29 must use the resource(s) managed by resource managers of the system 10 such as RM(1).
- the APP 29 makes a “Start Transaction” call to its local TMF component 26 a to register the transaction
- the TMF component 26 a now, the beginner TMF component
- APP 29 sends a request for the resource manager RM(1) to modify the database maintained by the system 10 .
- RM(1) When RM(1) receives this request, it first contacts its local DTC-GW to notify its local TMF component 26 b that it is a participant in the transaction started by the APP 29 .
- the DTC-GW first opens a logical connection between it and the TMF 26 for this transaction, and communicates the notification from the RM(1). All communication with the TMF components by the APP 29 and the RM(1) is through the local DTC-GW 30 (i.e., DTC-GW 30 a and 30 b ).
- FIG. 3 broadly illustrates, by the flow diagram 60 , the major steps taken to make permanent the change or modification.
- the request for work has been sent by the APP 29 , and APP 29 has nothing else to do, it then makes, in step 62 , an “End Transaction” call to the beginner TMF component 26 a
- the beginner TMF component 26 a performs the necessary operations to make the change or modification permanent and consistent.
- the conventional two-phase commit (presumed abort) protocol is used in which, at step 64 , the beginner TMF component 26 a broadcasts a “Prepare” signal to all CPUs 12 .
- step 70 If, on the other hand, there are no Abort signals (step 70 ); and all participants of the transaction respond with an affirmative, i.e., a “Ready” signal (step 74 and “Not Involved” signals received from any CPUs 12 not participating in the transaction) the beginner TMF component 26 a passing from step 74 to step 80 (bypassing here, for the moment, step 76 ) notifies the TMP 24 to “commit” the change to an audit log.
- the TMP 24 tells the beginner TMF component 26 b that the transaction is committed.
- the beginner TMF component 26 b at step 80 , then broadcasts a “Commit” signal to the participant CPUs 12 . At this point the change is considered permanent.
- the RM(1) cleans up whatever state is left from the operation(s) it performed in connection with the transaction.
- the conventional 2PC procedure is modified to include step 76 .
- the TMF components receive, at step 68 , state information from the corresponding DTC-GW 30 , piggy-backed on the Ready signal. Then, at step 76 , the state information is written to an audit log (not shown).
- the MSCS 28 creates a copy of RM(1), RM(2), on the CPU 12 d (FIG. 1) as a backup, following the same steps illustrated in FIG. 2 and described above.
- the P 14 (2) When the P 14 (2) is up and running, it (step 46 ; FIG. 2) establishes a connection, through a driver 32 , with the local DTC-GW, DTC-GW 30 d in order to be able to communicate with TMF (i.e., the TMF 26 d component for that CPU).
- TMF i.e., the TMF 26 d component for that CPU.
- the backup resource manager to RM(1), RM(2) queries the TMF 26 d component, using the GUID formally identifying the RM(1), in effect asking if there are any outstanding transactions in which RM(1) was a participant.
- TMF 26 d responds in the affirmative by accessing the audit log for the state information originally sent it with the Ready signal from the RM(1), recreates that state from the state information, and forwards it to RM (2).
- RM(2) sees that it (through RM(1)) is a participant in a transaction corresponding to the state data it received, and queries TMF 26 d about that transaction.
- TMF 26 d replies, telling RM(2) that it has committed the transaction.
- RM(2) then takes steps to commit the transaction.
Abstract
Description
- This application is a continuation of copending U.S. utility application entitled, “METHOD AND APPARATUS FOR HANDLING FAILURES OF RESOURCE MANAGERS IN A CLUSTERED ENVIRONMENT,” having Ser. No. 09/267,032, filed Mar. 11, 1999, now issued as U.S. Pat. No. ______, which is entirely incorporated herein by reference.
- The invention relates generally to a clustered processing system formed from multiple processor units with fault-tolerant capability. More particularly, the invention relates to a method, and apparatus for implementing that method, for handling, in a fault-tolerant manner, the failure of a resource manager in the context of a transaction executing on the system.
- A useful definition of a transaction is that it is an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection or database 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 (i.e., the transaction is “committed”) or none of the changes are made permanent (i.e., the transaction is “aborted”). If a failure occurs during the execution of a transaction, the transaction can be aborted and whatever partial changes were made to the collection can be undone to leave it in a consistent state.
- Typically, transactions are performed under the supervision of a transaction manager facility (TMF). In geographically distributed systems, such as multiple processor unit systems or “clusters” (i.e., a group of independent processor units managed as a single system), the TMF is “distributed” in the sense that each processor unit has its own TMF component to coordinate operations of a transaction conducted on that processor unit. The processor unit at which (or on which) a transaction begins is sometimes called the “beginner” processor. The TMF component of that processor unit operates to coordinate those transactional resources remote from its resident processor unit (i.e., resources managed by other processor units). Those TMF components running on processor units managing resources enlisted in a transaction are “participants” in the transaction. And, it is the TMF component of the beginner processor unit that initiates the steps taken.
- A preferred approach to concluding the transaction, and confirming that all participant resources employed in a transaction are able to participate in that conclusion, is to use the Two-Phase Commit (“2PC”) protocol. According to this approach, the beginner TMF component, upon receipt of an “End Transaction” request from the application process that requested the transaction, broadcasts a “Prepare” signal to all processor units of the cluster. The processor units, upon receipt of the Prepare signal, notify their (local) participant resources to perform as necessary (e.g., completing writes to disk storage, clearing memory, etc.) for effecting the change in state of the database and, if the necessary operation succeeds, respond with a “Ready” signal. If all participants of the transaction respond with an affirmative, i.e., a “Ready” signal (and “Not Involved” signals received from any processor units not participating in the transaction), the beginner TMF component notifies a transaction monitor process (TMP), running on one of the processor units, to “commit” the change to an audit log. The TMP tells the beginner TMF component that the transaction is committed, and the beginner TMF component then broadcasts a “Commit” signal to the participant processor units. At this point the change is considered permanent.
- Fault tolerance is another important feature of transaction processing. Being able to detect and tolerate faults allows the integrity of the information collection being managed by the system to be protected. Although a number of different methods and facilities exist, one particularly effective fault tolerant technique is the “process-pair” technique, as it is sometimes called. (This technique is also sometimes referred to as “fail-over” capability.) According to this technique, an application program is instantiated as two separate processes, a primary process resident on one processor unit of the cluster, and a backup process resident on another processor unit. If the primary process, or the processor unit upon which it is running, fails, that failure brings into operation the backup process to take over the operation of the lost (primary) process. If that failure occurs during a transaction in which the lost process was a participant, the backup decides whether or not to notify the beginner processor unit to abort the transaction and begin over again. In this way the state of the collection managed by the system remains consistent. An example of the process-pair or fail-over technique can be found in U.S. Pat. No. 4,817,091.
- An alternative approach, one used for example by the software applications that use object linking and embedding (OLE), is to create a backup process only after the primary process is detected as having failed. The state needed by the newly-created backup is transferred after creation. One problem with this approach is that the state needed by the backup is often retained by the node or processor unit on which the primary was running. If it happens that the primary process has failed because the processor unit on which it was running failed, or it has lost the capability to communicate with the transaction manager, that state can be lost.
- Also, there are times when the failure of a process, and the subsequent fail-over of the failed process to another processor unit (i.e., to the backup process), tend to impede transactions. For example, a stage in a transaction may be reached such that the participants no longer are able to abort the transaction. Should a participant process, or the processor unit, or some other facility related to the participant process, fail, the transaction will not be committed, and state used by the failed process will be left to clutter the system.
- These problems normally do not occur in a coordinated system having component parts designed to work together. They most often appear when porting an application from one platform to another.
- Accordingly, it can be seen that there exists a need for being able to provide full fail-over capability in a transaction processing system in order to maintain fault-tolerance. It follows, therefore, that the state created and maintained by the primary process should be placed where it can be reached for use by the backup process when necessary, regardless of how the primary process fails or is lost.
- According to the present invention, in a transaction processing system using a transaction management facility (TMF) a certain state is written to the audit log maintained by the TMF when a point (using a two-phase or 2PC commit operation) in a transaction is reached beyond which participation of the resources used in the transaction are required. Typically, the point is when the Ready signal is received in response to the Prepare signal broadcast by the beginner TMF. According to the invention, the Ready signal is accompanied by state information from which the state needed by that participant can be recreated, and written to an audit log by the beginner TMF. If the participant fails, or is otherwise made unavailable, a backup participant is created—preferably on another node—and provided with the same identifier of the now-failed participant. The backup participant queries TMF to determine if any transactions are outstanding and associated with the identifier. Responding, the TMF supplies the backup participant with the retained state information previously stored in the audit log, thereby allowing the backup participant to complete as necessary the transaction previously involving the failed participant.
- A significant advantage of the invention is to allow OLE compliant applications, such as the Microsoft SQL Server (e.g., the Microsoft SQL Server 6.5) or the Microsoft Message Queue Server, to be ported to a foreign platform and yet keep their fault tolerant capability which relies upon detection of a failure of a process before a backup of that process is created.
- These and other advantages and aspects of the invention will become apparent to those skilled in this art upon a reading of the following detailed description of the invention, which should be taken in conjunction with the accompanying drawings.
- FIG. 1 is an illustrative diagram of a multiple processor cluster or system;
- FIG. 2 is a flow diagram illustrating creation and migration of a resource manager process; and
- FIG. 3 is flow diagram broadly illustrating the steps a conventional two-phase commit protocol modified according to an implementation of the present invention.
- The present invention is advantageous in that it permits OLE compliant applications and resources to be ported to a transaction processing system and to participate in transactions with a minimum of re-work of the application or process for the porting process. However, as those skilled in this art will see, the techniques used by the present invention can be readily employed in other systems (i.e., non-OLE systems). The present invention is designed to operate with a transaction processing facility that runs under the aegis of the NonStop operating system available from the assignee of the invention, the Compaq Computer Corporation, Cupertino, California. Thus, the invention allows OLE applications to conduct transactions under the Nonstop operating system Transaction Manager Facility (TMF) and/or use such OLE compliant resource manager processes as Microsoft SQL Server 6.5 (a high performance database management system for Windows NT-based systems) or the Microsoft Message Queue Server (a transactional support facility that allows message queues to participate in Microsoft Transaction Server transactions). These resource managers are constructed to operate in the context of another transaction manager. The present invention allows their use in the context of a foreign transaction manager and foreign operating system, yet still employ the fault tolerant techniques originally designed for them. (Microsoft, Microsoft Windows NT are registered trademarks of Microsoft Corporation of Redmond, Wash., and Microsoft SQL Server, and Microsoft Transnational Server are believed to be trademarks of Microsoft Corporation.)
- Turning now to the figures, and for the present FIG. 1, there is illustrated a multiple processor
transaction processing system 10 capable of employing the present invention. As FIG. 1 shows, thetransaction processing system 10 includes central processor units (CPUs) 12 (12 a, 12 b, . . . , 12 d) and peripheral devices 14 (14 a, 14 b, . . . , 14 d) interconnected by a communication fabric 14 that provides both interprocessor and input/output (I/O) communication. Preferably, the communication fabric 14 is constructed as is taught in U.S. Pat. No. 5,751,932. However, as will be evident to those skilled in this art, other multiprocessor architectures may be used, such as that taught in U.S. Pat. No. 4,228,496. As will also be evident to those skilled in this art, although only four CPUs are shown, the present invention may be used on any number of CPUs. - As conventional, the
transaction processing system 10 also includes the necessary hardware, software, procedures, rules, and users needed to implement and operate a transaction processing application, including the NonStop or other operating system. In addition, there is a distributed transaction manager facility (TMF), comprising a transaction manager process (TMP) 24 resident on one of the CPUs 12 (in FIG. 1, CPU 12 c), and TMF components 26 each allocated to an individual processor 12; that is, each of the processors 12 has a TMF component 26 (26 a, 26 b, . . . , 26 n) that operates to manage and track the local resource managers (RMs) running on that CPU (e.g., RM(1) on CPU 12 b or RM(2) on CPU 12 d). (The resource manager RM(2) is shown in phantom because, as will be seen in connection with the discussion below, it is created later as a backup to the resource manager RM(1).) - Preferably, the
system 10 includes a fail-over capability, such as that provided by the NonStop operating system in the form of the “process pair” technique discussed above. However, for the OLE compliant processes there is provided a Microsoft Cluster Service (MSCS) 28. FIG. 1 also shows each CPU 12 having a component of MSCS 28. MSCS 28 operates to provide a fault tolerance capability by detecting failure of a process, or CPU 12 on which a process is running, and creating replacement or backup process on another CPU for taking over the function and operation of the failed process. As will be seen, the present invention provides the means to allow this “failover” to take place with a minimum of effort. - Since applications and resource managers, including those that are the OLE compliant, need a resource that provides an efficient communication link to TMF26 there is provided a distributed transaction coordinator gateway (DTC-GW) 30. Although there needs to be only one DTC-GW 30 running on one of the CPUs 12, it is more efficient to have each CPU 12 to include at least one DTC-GW as FIG. 1 illustrates. Not only is the efficiency improved (by avoiding having processes use a DTC-GW on a CPU 12 different from its own), but, as will be seen, the failover capability provided by the MCSC 28 for fault tolerance is made more effective.
- Finally, communication between the applications (e.g., APP29) and resource managers (e.g., RM(1), R.M(2)) and the DTC-GW 30 of the particular CPU 12 is via a driver 32 (32 a, 32 b, . . . , 32 d). In addition, each DTC-GW 30 is communicatively coupled to the TMF component 26 of its particular CPU 12.
- FIG. 2 shows a
flow chart 40 that broadly illustrates the steps taken to create a process such as RM(1). Accordingly, when RM(1) is created, a dynamic-linked library (DLL) is loaded instep 42 to provide the RM(1) with various interfaces (e.g., procedure calls) required to communicate with the local transaction manager. Next, atstep 44, the RM(1) is assigned a globally unique identifier (GUID). This GUID uniquely identifies the resource to the TMF 26, distinguishing it from all other processes (e.g., APP 29). Then, atstep 46, a connection, including adriver 32, is provided the resource to the local DTC-GW 30. RM(1) then, atstep 48, queries TMF 26 to determine if there is any transaction it should be aware of. Since the resource has been created as a primary resource, there is no such transaction. If, on the other hand (as discussed further below) the RM(1) was created to replace a failed resource, and that failed resource was a participant in a transaction when it failed, TMF 26 could respond in the affirmative. This feature is discussed further below. - When a transaction is started in one CPU12, that CPU 12 is known as the “beginner” CPU, and the TMF component 26 of that CPU becomes the “beginner” TMF component. If the transaction involves an operation performed on or at a CPU 12 other than the beginner CPU 12, that other CPU and its TMF component 26 become “participants” of the transaction and subordinate to the beginner TMF component on the beginner CPU. This may be better understood with an example.
- Assume the
APP 29 is requested to perform some operation or operations that requires the state of a database to be changed, and to perform that operation or operations the application (APP) 29 must use the resource(s) managed by resource managers of thesystem 10 such as RM(1). TheAPP 29 makes a “Start Transaction” call to its local TMF component 26 a to register the transaction The TMF component 26 a (now, the beginner TMF component), by this call (as is conventional), receives the information it needs to track the transaction so that it can ensure that the transaction completes properly. To enlist the services of the resource manager RM(1), (probably in another CPU)APP 29 sends a request for the resource manager RM(1) to modify the database maintained by thesystem 10. When RM(1) receives this request, it first contacts its local DTC-GW to notify its local TMF component 26 b that it is a participant in the transaction started by theAPP 29. The DTC-GW first opens a logical connection between it and the TMF 26 for this transaction, and communicates the notification from the RM(1). All communication with the TMF components by theAPP 29 and the RM(1) is through the local DTC-GW 30 (i.e., DTC-GW 30 a and 30 b). - FIG. 3 broadly illustrates, by the flow diagram60, the major steps taken to make permanent the change or modification. When the request for work has been sent by the
APP 29, andAPP 29 has nothing else to do, it then makes, instep 62, an “End Transaction” call to the beginner TMF component 26 a The beginner TMF component 26 a, in turn, performs the necessary operations to make the change or modification permanent and consistent. Preferably, the conventional two-phase commit (presumed abort) protocol is used in which, atstep 64, the beginner TMF component 26 a broadcasts a “Prepare” signal to all CPUs 12. Those CPUs 12 having resource manager participants in the transaction—here RM(1)—perform as necessary (e.g., completing writes to disk storage) for effecting the change in state of the database and, if the necessary operation succeeds, atstep 68, respond with a “Ready” signal. If any participant responds with an “Abort” signal (step 70), or one or more participants fail to respond with the obligatory Ready signal (step 74), theprocedure 60 proceeds to step 72 to initiate a rollback of the transaction. - If, on the other hand, there are no Abort signals (step70); and all participants of the transaction respond with an affirmative, i.e., a “Ready” signal (
step 74 and “Not Involved” signals received from any CPUs 12 not participating in the transaction) the beginner TMF component 26 a passing fromstep 74 to step 80 (bypassing here, for the moment, step 76) notifies theTMP 24 to “commit” the change to an audit log. TheTMP 24 tells the beginner TMF component 26 b that the transaction is committed. The beginner TMF component 26 b, atstep 80, then broadcasts a “Commit” signal to the participant CPUs 12. At this point the change is considered permanent. Upon receipt of the Commit signal, the RM(1) cleans up whatever state is left from the operation(s) it performed in connection with the transaction. - Suppose, however, that during the transaction the RM(1) fails, or the communicative connection to its associated JJTC-GW30 b is lost. If this occurs before the Ready signal (step 68) is received from the RM(1), beginner TMF assumes (correctly) that either the CPU 12 b or the RM(1) has failed and abort the transaction. However, if the failure occurs after the Ready signal is received, beginner TMF can commit the transaction without knowing that RM(1) is unable to at least cleanup its state and complete the necessary operations. Even if a replacement is created for RM(1) by the MSCS 28 in the form of the RM(2) on CPU 12 d, RM(2) cannot complete what needs be done because the state is often located with the original CPU in the associated DTC-GW 30 b. The reason is that the necessary state associated with the RM(1) was not available to the replacement resource manager in prior systems because it is usually kept by the DTC-GW 30.
- Thus, according to the present invention, the conventional 2PC procedure, as described above, is modified to include
step 76. To that end, when all participants respond with Ready signals, the TMF components receive, atstep 68, state information from the corresponding DTC-GW 30, piggy-backed on the Ready signal. Then, atstep 76, the state information is written to an audit log (not shown). - Now, assume that after the RM(1) sends the responsive ready signal, accompanied by state information respecting the transaction to which the Ready signal pertains, the communicative connection P14(1) enjoyed with the DTC-GW 30 b fails, or RM(1) itself fails, or the CPU 12 b fails, the MSCS is then apprised of either of these facts and, in turn, notifies TMF 26. TMF 26, in turn, assumes that the associated logical connections for the P14(1) have been closed. This is necessary, as will be seen, to allow TMF 26 to respond to queries from resource managers identifying themselves with the same GUID as that used by the RM(1).
- Next, the MSCS28 creates a copy of RM(1), RM(2), on the CPU 12 d (FIG. 1) as a backup, following the same steps illustrated in FIG. 2 and described above. When the P14(2) is up and running, it (
step 46; FIG. 2) establishes a connection, through adriver 32, with the local DTC-GW, DTC-GW 30 d in order to be able to communicate with TMF (i.e., the TMF 26 d component for that CPU). Then, instep 48, the backup resource manager to RM(1), RM(2), queries the TMF 26 d component, using the GUID formally identifying the RM(1), in effect asking if there are any outstanding transactions in which RM(1) was a participant. Here, there is, assuming RM(1) was lost after RM(1) sent its Ready signal, but before it received the Commit signal. Accordingly, TMF 26 d responds in the affirmative by accessing the audit log for the state information originally sent it with the Ready signal from the RM(1), recreates that state from the state information, and forwards it to RM (2). RM(2) sees that it (through RM(1)) is a participant in a transaction corresponding to the state data it received, and queries TMF 26 d about that transaction. TMF 26 d, replies, telling RM(2) that it has committed the transaction. RM(2) then takes steps to commit the transaction.
Claims (14)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/688,323 US20040083225A1 (en) | 1999-03-11 | 2003-10-17 | Method and apparatus for handling failures of resource managers in a clustered environment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/267,032 US6671704B1 (en) | 1999-03-11 | 1999-03-11 | Method and apparatus for handling failures of resource managers in a clustered environment |
US10/688,323 US20040083225A1 (en) | 1999-03-11 | 2003-10-17 | Method and apparatus for handling failures of resource managers in a clustered environment |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/267,032 Continuation US6671704B1 (en) | 1999-03-11 | 1999-03-11 | Method and apparatus for handling failures of resource managers in a clustered environment |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040083225A1 true US20040083225A1 (en) | 2004-04-29 |
Family
ID=29735661
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/267,032 Expired - Fee Related US6671704B1 (en) | 1999-03-11 | 1999-03-11 | Method and apparatus for handling failures of resource managers in a clustered environment |
US10/688,323 Abandoned US20040083225A1 (en) | 1999-03-11 | 2003-10-17 | Method and apparatus for handling failures of resource managers in a clustered environment |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/267,032 Expired - Fee Related US6671704B1 (en) | 1999-03-11 | 1999-03-11 | Method and apparatus for handling failures of resource managers in a clustered environment |
Country Status (1)
Country | Link |
---|---|
US (2) | US6671704B1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7730489B1 (en) * | 2003-12-10 | 2010-06-01 | Oracle America, Inc. | Horizontally scalable and reliable distributed transaction management in a clustered application server environment |
US20100146345A1 (en) * | 2008-12-08 | 2010-06-10 | Fujitsu Limited | Information processing apparatus, recording medium including program for information processing apparatus, and method of controlling information processing apparatus |
US20110178984A1 (en) * | 2010-01-18 | 2011-07-21 | Microsoft Corporation | Replication protocol for database systems |
US20110191299A1 (en) * | 2010-02-01 | 2011-08-04 | Microsoft Corporation | Logical data backup and rollback using incremental capture in a distributed database |
US9667475B2 (en) | 2014-02-28 | 2017-05-30 | Red Hat, Inc. | Systems and methods for communicating information of participants registered with a sub-coordinator during distributed transaction processing |
US9858136B2 (en) | 2014-09-30 | 2018-01-02 | International Business Machines Corporation | Resource manager failure handling in a multi-process transaction environment |
Families Citing this family (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6671704B1 (en) * | 1999-03-11 | 2003-12-30 | Hewlett-Packard Development Company, L.P. | Method and apparatus for handling failures of resource managers in a clustered environment |
JP4131781B2 (en) * | 2001-03-30 | 2008-08-13 | 株式会社東芝 | Distributed processing database management system |
US7685126B2 (en) | 2001-08-03 | 2010-03-23 | Isilon Systems, Inc. | System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system |
US7146524B2 (en) | 2001-08-03 | 2006-12-05 | Isilon Systems, Inc. | Systems and methods for providing a distributed file system incorporating a virtual hot spare |
JP2003076592A (en) * | 2001-09-04 | 2003-03-14 | Hitachi Ltd | Data storage system |
US7814050B2 (en) * | 2002-10-22 | 2010-10-12 | Brocade Communications Systems, Inc. | Disaster recovery |
US7937421B2 (en) | 2002-11-14 | 2011-05-03 | Emc Corporation | Systems and methods for restriping files in a distributed file system |
US7424653B2 (en) | 2003-05-09 | 2008-09-09 | Hewlett-Packard Development Company, L.P. | System and method for error capture and logging in computer systems |
US7120828B2 (en) * | 2003-05-09 | 2006-10-10 | Hewlett-Packard Development Company, L.P. | System and method for in-order queue draining |
US8074220B2 (en) * | 2004-05-21 | 2011-12-06 | Computer Associates Think, Inc. | System and method for interfacing an application to a distributed transaction coordinator |
EP1800442B1 (en) * | 2004-10-12 | 2012-11-14 | NetSocket, Inc. | A resilience solution for top tier bandwidth managers |
US8055711B2 (en) * | 2004-10-29 | 2011-11-08 | Emc Corporation | Non-blocking commit protocol systems and methods |
US8238350B2 (en) | 2004-10-29 | 2012-08-07 | Emc Corporation | Message batching with checkpoints systems and methods |
US8051425B2 (en) | 2004-10-29 | 2011-11-01 | Emc Corporation | Distributed system with asynchronous execution systems and methods |
US7917474B2 (en) | 2005-10-21 | 2011-03-29 | Isilon Systems, Inc. | Systems and methods for accessing and updating distributed data |
US7551572B2 (en) | 2005-10-21 | 2009-06-23 | Isilon Systems, Inc. | Systems and methods for providing variable protection |
US7788303B2 (en) | 2005-10-21 | 2010-08-31 | Isilon Systems, Inc. | Systems and methods for distributed system scanning |
US7797283B2 (en) | 2005-10-21 | 2010-09-14 | Isilon Systems, Inc. | Systems and methods for maintaining distributed data |
US7848261B2 (en) | 2006-02-17 | 2010-12-07 | Isilon Systems, Inc. | Systems and methods for providing a quiescing protocol |
US7756898B2 (en) | 2006-03-31 | 2010-07-13 | Isilon Systems, Inc. | Systems and methods for notifying listeners of events |
US8539056B2 (en) | 2006-08-02 | 2013-09-17 | Emc Corporation | Systems and methods for configuring multiple network interfaces |
GB0616068D0 (en) * | 2006-08-12 | 2006-09-20 | Ibm | Method,Apparatus And Computer Program For Transaction Recovery |
US7752402B2 (en) * | 2006-08-18 | 2010-07-06 | Isilon Systems, Inc. | Systems and methods for allowing incremental journaling |
US7953704B2 (en) | 2006-08-18 | 2011-05-31 | Emc Corporation | Systems and methods for a snapshot of data |
US7680842B2 (en) | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7590652B2 (en) | 2006-08-18 | 2009-09-15 | Isilon Systems, Inc. | Systems and methods of reverse lookup |
US7676691B2 (en) | 2006-08-18 | 2010-03-09 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7899800B2 (en) | 2006-08-18 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7822932B2 (en) | 2006-08-18 | 2010-10-26 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7882071B2 (en) | 2006-08-18 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7680836B2 (en) | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US8286029B2 (en) | 2006-12-21 | 2012-10-09 | Emc Corporation | Systems and methods for managing unavailable storage devices |
US7593938B2 (en) | 2006-12-22 | 2009-09-22 | Isilon Systems, Inc. | Systems and methods of directory entry encodings |
US7509448B2 (en) | 2007-01-05 | 2009-03-24 | Isilon Systems, Inc. | Systems and methods for managing semantic locks |
US8966080B2 (en) | 2007-04-13 | 2015-02-24 | Emc Corporation | Systems and methods of managing resource utilization on a threaded computer system |
US7779048B2 (en) | 2007-04-13 | 2010-08-17 | Isilon Systems, Inc. | Systems and methods of providing possible value ranges |
US7900015B2 (en) | 2007-04-13 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods of quota accounting |
US7949692B2 (en) | 2007-08-21 | 2011-05-24 | Emc Corporation | Systems and methods for portals into snapshot data |
US7966289B2 (en) | 2007-08-21 | 2011-06-21 | Emc Corporation | Systems and methods for reading objects in a file system |
US7882068B2 (en) | 2007-08-21 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for adaptive copy on write |
WO2009042874A1 (en) | 2007-09-27 | 2009-04-02 | Tyco Healthcare Group Lp | I.v. catheter assembly and needle safety device |
US7984324B2 (en) | 2008-03-27 | 2011-07-19 | Emc Corporation | Systems and methods for managing stalled storage devices |
US7953709B2 (en) | 2008-03-27 | 2011-05-31 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US7949636B2 (en) | 2008-03-27 | 2011-05-24 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US7870345B2 (en) | 2008-03-27 | 2011-01-11 | Isilon Systems, Inc. | Systems and methods for managing stalled storage devices |
US7925761B2 (en) * | 2009-06-30 | 2011-04-12 | Novell, Inc. | System and method for implementing a dead man dependency technique for cluster resources |
US9152327B2 (en) * | 2013-05-28 | 2015-10-06 | Netapp, Inc. | System and method for detecting failure of storage object images on a storage system and initiating a cleanup procedure |
US9152340B2 (en) * | 2013-05-28 | 2015-10-06 | Netapp, Inc. | System and method for managing and producing a dataset image across multiple storage systems |
US9524186B2 (en) * | 2014-04-28 | 2016-12-20 | Oracle International Corporation | System and method for supporting common transaction identifier (XID) optimization based on resource manager (RM) instance awareness in a transactional environment |
US11314544B2 (en) | 2015-02-09 | 2022-04-26 | Red Hat, Inc. | Transaction log for audit purposes |
US10579489B2 (en) * | 2015-07-30 | 2020-03-03 | Mitsubishi Electric Corporation | Program execution device, program execution system, and program execution method |
Citations (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4228496A (en) * | 1976-09-07 | 1980-10-14 | Tandem Computers Incorporated | Multiprocessor system |
US5428771A (en) * | 1991-09-18 | 1995-06-27 | International Business Machines Corporation | Transparent transaction coordination between distributed networks having different communication protocols |
US5504900A (en) * | 1991-05-21 | 1996-04-02 | Digital Equipment Corporation | Commitment ordering for guaranteeing serializability across distributed transactions |
US5680610A (en) * | 1995-01-19 | 1997-10-21 | Unisys Corporation | Method and apparatus for testing recovery scenarios in global transaction processing systems |
US5751932A (en) * | 1992-12-17 | 1998-05-12 | Tandem Computers Incorporated | Fail-fast, fail-functional, fault-tolerant multiprocessor system |
US5768587A (en) * | 1996-08-31 | 1998-06-16 | International Business Machine Corp. | Operating a transaction manager with a non-compliant resource manager |
US5835766A (en) * | 1994-11-04 | 1998-11-10 | Fujitsu Limited | System for detecting global deadlocks using wait-for graphs and identifiers of transactions related to the deadlocks in a distributed transaction processing system and a method of use therefore |
US5920863A (en) * | 1997-05-31 | 1999-07-06 | International Business Machines Corporation | System and method for supporting transactions for a thin client lacking a persistent store in a distributed object-oriented environment |
US5923833A (en) * | 1996-03-19 | 1999-07-13 | International Business Machines Coporation | Restart and recovery of OMG-compliant transaction systems |
US5926463A (en) * | 1997-10-06 | 1999-07-20 | 3Com Corporation | Method and apparatus for viewing and managing a configuration of a computer network |
US5960194A (en) * | 1995-09-11 | 1999-09-28 | International Business Machines Corporation | Method for generating a multi-tiered index for partitioned data |
US6101527A (en) * | 1996-11-18 | 2000-08-08 | Bull S.A. | System for managing and processing distributed object transactions and process implemented by said system |
US6105147A (en) * | 1997-04-16 | 2000-08-15 | Compaq Computer Corporation | Using process pairs as transaction-coordinated resource managers |
US6115711A (en) * | 1989-09-28 | 2000-09-05 | Sterling Software, Inc. | Method and apparatus for generating transactions and a dialog flow manager |
US6173313B1 (en) * | 1998-06-24 | 2001-01-09 | Oracle Corporation | Methodology for hosting distributed objects at a predetermined node in a distributed system |
US6205464B1 (en) * | 1994-09-16 | 2001-03-20 | International Businesss Machines Corporation | System for building optimal commit trees in a distributed transaction processing system |
US6209038B1 (en) * | 1999-01-13 | 2001-03-27 | International Business Machines Corporation | Technique for aggregate transaction scope across multiple independent web requests |
US6266698B1 (en) * | 1998-07-31 | 2001-07-24 | Compaq Computer Corporation | Logging of transaction branch information for implementing presumed nothing and other protocols |
US6272675B1 (en) * | 1998-10-01 | 2001-08-07 | Unisys Corporation | Development system for automatically enabling a server application to execute with an XATMI-compliant transaction manager managing transactions within multiple environments |
US6286110B1 (en) * | 1998-07-30 | 2001-09-04 | Compaq Computer Corporation | Fault-tolerant transaction processing in a distributed system using explicit resource information for fault determination |
US6295548B1 (en) * | 1999-03-12 | 2001-09-25 | Compaq Computer Corporation | Detection of an imported transaction for finding the global transaction identifier |
US6338146B1 (en) * | 1997-09-30 | 2002-01-08 | Compaq Computer Corporation | Method and apparatus for fault-tolerant, scalable and non-blocking three-phase flushing for committing database transactions in a cluster of multiprocessors |
US6411981B1 (en) * | 1999-03-12 | 2002-06-25 | Compaq Computer Corporation | Method and apparatus for conducting a transaction between homogeneous and/or heterogeneous transaction processing systems using asynchronous pull of a transaction transfer |
US6625643B1 (en) * | 1998-11-13 | 2003-09-23 | Akamai Technologies, Inc. | System and method for resource management on a data network |
US6671704B1 (en) * | 1999-03-11 | 2003-12-30 | Hewlett-Packard Development Company, L.P. | Method and apparatus for handling failures of resource managers in a clustered environment |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5319774A (en) * | 1990-05-16 | 1994-06-07 | International Business Machines Corporation | Recovery facility for incomplete sync points for distributed application |
US5327532A (en) * | 1990-05-16 | 1994-07-05 | International Business Machines Corporation | Coordinated sync point management of protected resources |
US5504899A (en) * | 1991-10-17 | 1996-04-02 | Digital Equipment Corporation | Guaranteeing global serializability by applying commitment ordering selectively to global transactions |
US5701480A (en) * | 1991-10-17 | 1997-12-23 | Digital Equipment Corporation | Distributed multi-version commitment ordering protocols for guaranteeing serializability during transaction processing |
-
1999
- 1999-03-11 US US09/267,032 patent/US6671704B1/en not_active Expired - Fee Related
-
2003
- 2003-10-17 US US10/688,323 patent/US20040083225A1/en not_active Abandoned
Patent Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4228496A (en) * | 1976-09-07 | 1980-10-14 | Tandem Computers Incorporated | Multiprocessor system |
US4817091A (en) * | 1976-09-07 | 1989-03-28 | Tandem Computers Incorporated | Fault-tolerant multiprocessor system |
US6115711A (en) * | 1989-09-28 | 2000-09-05 | Sterling Software, Inc. | Method and apparatus for generating transactions and a dialog flow manager |
US5504900A (en) * | 1991-05-21 | 1996-04-02 | Digital Equipment Corporation | Commitment ordering for guaranteeing serializability across distributed transactions |
US5428771A (en) * | 1991-09-18 | 1995-06-27 | International Business Machines Corporation | Transparent transaction coordination between distributed networks having different communication protocols |
US5751932A (en) * | 1992-12-17 | 1998-05-12 | Tandem Computers Incorporated | Fail-fast, fail-functional, fault-tolerant multiprocessor system |
US6205464B1 (en) * | 1994-09-16 | 2001-03-20 | International Businesss Machines Corporation | System for building optimal commit trees in a distributed transaction processing system |
US5835766A (en) * | 1994-11-04 | 1998-11-10 | Fujitsu Limited | System for detecting global deadlocks using wait-for graphs and identifiers of transactions related to the deadlocks in a distributed transaction processing system and a method of use therefore |
US5680610A (en) * | 1995-01-19 | 1997-10-21 | Unisys Corporation | Method and apparatus for testing recovery scenarios in global transaction processing systems |
US5960194A (en) * | 1995-09-11 | 1999-09-28 | International Business Machines Corporation | Method for generating a multi-tiered index for partitioned data |
US5923833A (en) * | 1996-03-19 | 1999-07-13 | International Business Machines Coporation | Restart and recovery of OMG-compliant transaction systems |
US5768587A (en) * | 1996-08-31 | 1998-06-16 | International Business Machine Corp. | Operating a transaction manager with a non-compliant resource manager |
US6101527A (en) * | 1996-11-18 | 2000-08-08 | Bull S.A. | System for managing and processing distributed object transactions and process implemented by said system |
US6105147A (en) * | 1997-04-16 | 2000-08-15 | Compaq Computer Corporation | Using process pairs as transaction-coordinated resource managers |
US5920863A (en) * | 1997-05-31 | 1999-07-06 | International Business Machines Corporation | System and method for supporting transactions for a thin client lacking a persistent store in a distributed object-oriented environment |
US6338146B1 (en) * | 1997-09-30 | 2002-01-08 | Compaq Computer Corporation | Method and apparatus for fault-tolerant, scalable and non-blocking three-phase flushing for committing database transactions in a cluster of multiprocessors |
US5926463A (en) * | 1997-10-06 | 1999-07-20 | 3Com Corporation | Method and apparatus for viewing and managing a configuration of a computer network |
US6173313B1 (en) * | 1998-06-24 | 2001-01-09 | Oracle Corporation | Methodology for hosting distributed objects at a predetermined node in a distributed system |
US6286110B1 (en) * | 1998-07-30 | 2001-09-04 | Compaq Computer Corporation | Fault-tolerant transaction processing in a distributed system using explicit resource information for fault determination |
US6266698B1 (en) * | 1998-07-31 | 2001-07-24 | Compaq Computer Corporation | Logging of transaction branch information for implementing presumed nothing and other protocols |
US6272675B1 (en) * | 1998-10-01 | 2001-08-07 | Unisys Corporation | Development system for automatically enabling a server application to execute with an XATMI-compliant transaction manager managing transactions within multiple environments |
US6625643B1 (en) * | 1998-11-13 | 2003-09-23 | Akamai Technologies, Inc. | System and method for resource management on a data network |
US6209038B1 (en) * | 1999-01-13 | 2001-03-27 | International Business Machines Corporation | Technique for aggregate transaction scope across multiple independent web requests |
US6671704B1 (en) * | 1999-03-11 | 2003-12-30 | Hewlett-Packard Development Company, L.P. | Method and apparatus for handling failures of resource managers in a clustered environment |
US6295548B1 (en) * | 1999-03-12 | 2001-09-25 | Compaq Computer Corporation | Detection of an imported transaction for finding the global transaction identifier |
US6411981B1 (en) * | 1999-03-12 | 2002-06-25 | Compaq Computer Corporation | Method and apparatus for conducting a transaction between homogeneous and/or heterogeneous transaction processing systems using asynchronous pull of a transaction transfer |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7730489B1 (en) * | 2003-12-10 | 2010-06-01 | Oracle America, Inc. | Horizontally scalable and reliable distributed transaction management in a clustered application server environment |
US20100146345A1 (en) * | 2008-12-08 | 2010-06-10 | Fujitsu Limited | Information processing apparatus, recording medium including program for information processing apparatus, and method of controlling information processing apparatus |
US20110178984A1 (en) * | 2010-01-18 | 2011-07-21 | Microsoft Corporation | Replication protocol for database systems |
US20110191299A1 (en) * | 2010-02-01 | 2011-08-04 | Microsoft Corporation | Logical data backup and rollback using incremental capture in a distributed database |
US8825601B2 (en) | 2010-02-01 | 2014-09-02 | Microsoft Corporation | Logical data backup and rollback using incremental capture in a distributed database |
US9667475B2 (en) | 2014-02-28 | 2017-05-30 | Red Hat, Inc. | Systems and methods for communicating information of participants registered with a sub-coordinator during distributed transaction processing |
US9858136B2 (en) | 2014-09-30 | 2018-01-02 | International Business Machines Corporation | Resource manager failure handling in a multi-process transaction environment |
US9864648B2 (en) | 2014-09-30 | 2018-01-09 | International Business Machines Corporation | Resource manager failure handling in a multi-process transaction environment |
Also Published As
Publication number | Publication date |
---|---|
US6671704B1 (en) | 2003-12-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6671704B1 (en) | Method and apparatus for handling failures of resource managers in a clustered environment | |
EP1099164B1 (en) | Method and program for processing administrative requests of a distributed network application executing in a clustered computing environment | |
US7085956B2 (en) | System and method for concurrent logical device swapping | |
US7392421B1 (en) | Framework for managing clustering and replication | |
US7194652B2 (en) | High availability synchronization architecture | |
US7076689B2 (en) | Use of unique XID range among multiple control processors | |
US6003075A (en) | Enqueuing a configuration change in a network cluster and restore a prior configuration in a back up storage in reverse sequence ordered | |
US5822531A (en) | Method and system for dynamically reconfiguring a cluster of computer systems | |
EP1533701B1 (en) | System and method for failover | |
US6145089A (en) | Server fail-over system | |
US5941999A (en) | Method and system for achieving high availability in networked computer systems | |
US7234072B2 (en) | Method and system for making an application highly available | |
US6952766B2 (en) | Automated node restart in clustered computer system | |
US8615578B2 (en) | Using a standby data storage system to detect the health of a cluster of data storage servers | |
US20040083358A1 (en) | Reboot manager usable to change firmware in a high availability single processor system | |
US20030149735A1 (en) | Network and method for coordinating high availability system services | |
US8504873B1 (en) | Method and apparatus for providing in-memory checkpoint services within a distributed transaction | |
JPH11328139A (en) | Method and device for providing transparent server failover for highly available object | |
JP2001518660A (en) | Method of sequentially and reliably starting and / or reloading multiprocessor nodes in a multinode cluster | |
US20080196029A1 (en) | Transaction Manager Virtualization | |
US6629260B1 (en) | Automatic reconnection of partner software processes in a fault-tolerant computer system | |
US8031637B2 (en) | Ineligible group member status | |
US7120821B1 (en) | Method to revive and reconstitute majority node set clusters | |
US20070011328A1 (en) | System and method for application deployment service | |
US6286110B1 (en) | Fault-tolerant transaction processing in a distributed system using explicit resource information for fault determination |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GONDI, ALBERT C.;KLEIN, JOHANNES;DE ROO, JOHN S.;AND OTHERS;REEL/FRAME:014627/0924;SIGNING DATES FROM 19990326 TO 19990804 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: CHANGE OF NAME;ASSIGNOR:COMPAQ INFORMATION TECHNOLOGIES GROUP LP;REEL/FRAME:014628/0103 Effective date: 20021001 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |