Browse Prior Art Database

Asynchronous Progressive Transaction Recovery Protocol for Distributed DB/DC Systems

IP.com Disclosure Number: IPCOM000039277D
Original Publication Date: 1987-May-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 5 page(s) / 63K

Publishing Venue

IBM

Related People

Iyer, BR: AUTHOR [+3]

Abstract

This invention describes an asynchronous transaction recovery protocol that coordinates communications between different subsystems with execution in distributed DB/DC systems. To meet the increasing requirements for high availability, online transaction processing systems are being designed with mechanisms that allow rapid recovery from failure. System recovery includes not only preservation of database integrity through database recovery, but also transaction recovery, that is, the operations performed after failure to restore and continue processing of all affected messages. In a distributed DB/DC environment, several DB (database management) and DC (data communication management) subsystems are connected together.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 5

Asynchronous Progressive Transaction Recovery Protocol for Distributed DB/DC Systems

This invention describes an asynchronous transaction recovery protocol that coordinates communications between different subsystems with execution in distributed DB/DC systems. To meet the increasing requirements for high availability, online transaction processing systems are being designed with mechanisms that allow rapid recovery from failure. System recovery includes not only preservation of database integrity through database recovery, but also transaction recovery, that is, the operations performed after failure to restore and continue processing of all affected messages. In a distributed DB/DC environment, several DB (database management) and DC (data communication management) subsystems are connected together. A transaction request is entered into the system through a DC that provides data communication and message formatting services. This message then gets routed to one of the DB processors to invoke the transaction application program and access the database. After all database activities of the transaction are completed, output messages are sent back to the terminal via a DC subsystem. This distributed DB/DC configuration provides (a) flexible growth in processing capability, and (b) the potential for isolating failures and performing recovery actions independently on different subsystems.

(Image Omitted)

The coordination of transaction processing with the tracking and securing activities is an important issue in transaction recovery. There is an increased overhead during normal processing to perform tracking, securing and coordination. Securing and tracking can be coordinated with the transaction processing by a two-phase commit protocol, such that upon a failure the affected transactions can be identified. These transactions are then re-executed using the secured transaction progress information. This is referred to as the pessimistic approach, and its normal processing overhead can be substantial. The present invention describes a new protocol called the "Asynchronous Progressive Transaction Recovery Protocol." This new protocol reduces the normal processing overhead and leads to performance improvements over the pessimistic approach. The asynchronous progressive recovery protocol is illustrated in Fig. 1. After execution of a transaction on subsystem 1, the processed transaction message is simultaneously communicated to the next subsystem and secured on subsystem

(Image Omitted)

1. Upon completion of securing, a "end of securing" message is sent to trigger the scheduling of transaction execution at the succeeding subsystem. This protocol allows more parallel operations during the securing of transaction messages at the cost of extra messages as compared to a previously disclosed synchronous transaction recovery protocol. The end of securing message depicted in Fig. 1 is needed since, in asynchronous progressive recovery (see Fig. 1...