Browse Prior Art Database

Progressive Transaction Recovery Scheme for Distributed DB/DC Systems

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

Publishing Venue

IBM

Related People

Iyer, BR: AUTHOR [+3]

Abstract

This article describes a transaction recovery scheme in a distributed DB/DC system which contains multiple DB and DC subsystems residing on different processors that causes minimal interference to transactions on a non-failed DB or DC system. A transaction needs the services of a DC to do input and output message formatting and screen analysis and a DB to interface with the database. The objective is to use transaction level structural information to reduce costly lower level handshaking protocols, eliminate the need for any centralized recovery management mechanism by making recovery actions local to interacting components, and eliminate propagation of recovery actions to more than one antecedent component. Logging devices (e.g., disks) are assumed to be the mechanism available to store redundant information.

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 25% of the total text.

Page 1 of 5

Progressive Transaction Recovery Scheme for Distributed DB/DC Systems

This article describes a transaction recovery scheme in a distributed DB/DC system which contains multiple DB and DC subsystems residing on different processors that causes minimal interference to transactions on a non-failed DB or DC system. A transaction needs the services of a DC to do input and output message formatting and screen analysis and a DB to interface with the database. The objective is to use transaction level structural information to reduce costly lower level handshaking protocols, eliminate the need for any centralized recovery management mechanism by making recovery actions local to interacting components, and eliminate propagation of recovery actions to more than one antecedent component. Logging devices (e.g., disks) are assumed to be the mechanism available to store redundant information. Transaction processing involves different execution stages (DC, DB, followed by the DC), perhaps on different processors. Some stages make data base changes, and others are purely transformations of data. The latter permit re-executions without side effects. The former require special handling during re-execution. Formally, the transaction processing system is comprised of several subsystems (in this case, DB's and DC's). Each subsystem is comprised of software components (e.g., message formatter, application program, screen formatter). Failure may cease the operations of one or more components. For instance, when a processor on which a DC executes fails, all its components, e.g., network interface manager, message formatter, etc., are affected and have to be restarted. If only an application program terminates abnormally, it alone may be restarted with a fresh copy after all updates to the database have been backed out. In addition, regarding the processing interrupted by a failure, database recovery and transaction recovery may need to be performed. It is desirable that all recovery operations be localized to the failed components, as much as possible. Transaction Recovery in Distributed DB/DC Systems with Logging Devices Like traditional database logging, we assume that each subsystem owns log data sets for saving messages on a logging device, e.g., disk. The log data sets of subsystem, SS, are denoted as LDS(SSin) and LDS (SSout) for input and output transaction messages, respectively. For each transaction requested, a unique transaction identification number, denoted by Tx, is generated and used during the transaction's lifetime. When a subsystem receives an input transaction message, Tx.MS, a log record which is composed of Tx, the message and the name of the precedent subsystem is written into LDS(SSin) before processing of the transaction. After the input message is processed by the subsystem and before the processed transaction message is sent to the subsequent subsystem, a log record containing the transaction's identification number, the message...