Restart and recovery of OMG-compliant transaction systems

• US 5,923,833 A
• Filed: 03/14/1997
• Issued: 07/13/1999
• Est. Priority Date: 03/19/1996
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Freund, Thomas, Storey, Robert Anthony, Holdsworth, Simon, Houston, Iain
• Primary Examiner(s): Palys, Joseph E.
• Assistant Examiner(s): Baderman, Scott T.
• Application Number:
  US08/818,482
• Time in Patent Office: 851 Days
• Field of Search: 395/182.17, 395/182.16, 395/182.18, 395/182.13, 395/182.14, 395/182.15, 707/202
• US Class Current: 714/19
• CPC Class Codes: G06F 11/1438 Restarting or rejuvenating
• CPC Class Codes: G06F 11/1482 by means of middleware or OS functionality
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

A method and system for implementing a Restart Service for the Object Transaction Service are described. The present invention provides a method and system which trigger restart of an OTS instance upon system recovery or upon system failure. The Restart Service runs independently of the client or server processes which it restarts. When a client or server enters a pending state for a transaction, a permanent record containing information to allow the OTS instance to be restarted is stored in a Restart Repository. In the event of system recovery being needed, or of a system failure, a Restart Daemon reads information from the Restart Repository and recreates the process context. The Recovery Service is initialized and log data replayed to a Transaction Manager to determine the outcome of pending transactions. Failed objects and instances of the OTS are restarted.

Claims

1. A method for restart and recovery of an OMG-compliant transaction system comprising the steps of:

providing a client process having a unique identifier;

executing a transaction, by said client process, said execution including the invocation of requests on processes running in a remote system;

logging, with a Recovery Service, of recovery information for the client process in a log file; and

committing of the transaction, resulting in the transaction going into a "prepared" state;

characterised in that, the method further comprises the steps of;

monitoring, by a restart process, said client process and providing an indication if said client process fails;

after said transaction goes into a "prepared" state, registering by said client process with a Restart Service by the addition of restart information to a Restart Repository; and

wherein, in response to said indication that said client process has failed, after said transaction goes into a "prepared" state, but before said transaction goes into a "committed" state, the method further comprises the steps of;

recreation, by said restart process, of the process context associated with said client process;

recreation of said Recovery Service, associated with said client process;

determination of the outcome of any in-doubt transactions using data from said log file;

for each of said in-doubt transactions having their outcome determined, executing commit or rollback operations on the participants corresponding to the outcome of the transactions.

2. A method as claimed in claim 1 wherein the recovery information is a list of all transactions which are in a "prepared" state and the last log record for each unfinished transaction.

3. A method as claimed in claim 1 wherein the restart information includes a file identifier in which the recovery information is located.

4. A method as claimed in claim 3 wherein restart information is stored for a plurality of client processes, the restart information including a unique identifier for each of said client processes.

5. A method as claimed in claim 3 wherein the restart information for a process includes an indication of whether restart should be attempted for that process.

6. A method as claimed in claim 3 wherein the restart information includes an indication of how many times restart should be attempted.

7. A method as claimed in claim 3 wherein the restart information includes the name of a program to restart as a surrogate to the client process.

8. A method as claimed in claim 3 wherein the restart information includes a file identifier for the log file for the client process.

9. A method as claimed in claim 1 wherein said monitoring is by means of a periodic check of the status of each of the client processes having entries in the Restart Repository.

10. A distributed OMG-compliant transaction system comprising:

a client process having a unique identifier;

means for executing a transaction, including;

means for invocation of requests on processes running in a system remote from the client process;

means for committing said transaction, causing said transaction to go into a "prepared" state;

a Recovery Service, associated with said client process, for logging of recovery information in a log file;

characterised in that the system further comprises;

a restart repository for the storage of restart information associated with the transaction;

wherein said means for executing a transaction further includes means for storing in said restart repository, restart information associated with the transaction, said restart information being stored after said transaction goes into a "prepared" state;

a restart process including;

means for monitoring said client process and providing an indication if said client fails;

means, responsive to said monitoring means, for recreating the process context associated with said client process;

means, responsive to said monitoring means, for recreating said Recovery Service associated with said client process;

means for determining the outcome of any in-doubt transactions using data from said log file; and

means for executing commit or rollback operations on the participants in each of said in-doubt transactions having their outcome determined, corresponding to the outcome of the transactions.

11. A system as claimed in claim 10 wherein the recovery information is a list of all transactions which are in a "prepared" state and the last log record for each unfinished transaction.

12. A system as claimed in claim 10 wherein the restart information includes a file identifier in which the recovery information is located.

13. A system as claimed in claim 10 wherein said monitoring is by means of a periodic check of the status of each of the processes having entries in the Restart Repository.