Browse Prior Art Database

Method for Minimizing the Information Difference Between Active and Log-Based Recovery in Transaction Systems Using Incremental Instead of Periodic Checkpointing

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

Publishing Venue

IBM

Related People

Burkes, DL: AUTHOR [+2]

Abstract

This invention relates to a method for accumulating checkpoint information incrementally instead of periodically in the front-end/back- end checkpoint processing portion of a transaction-oriented system. The processors utilize a circular (ring) buffer memory to effectuate transfer and overlapped processing of said information. This processing reduces the information lag and recovery time between the log-based recovery system and the active system in the event the active system is to be reconstituted from the log-based system. Transaction processing systems usually use a log or journal to record changes to state information which must remain persistent between periods of execution (whether the period is planned or due to failure).

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

Page 1 of 5

Method for Minimizing the Information Difference Between Active and Log- Based Recovery in Transaction Systems Using Incremental Instead of Periodic Checkpointing

This invention relates to a method for accumulating checkpoint information incrementally instead of periodically in the front-end/back- end checkpoint processing portion of a transaction-oriented system. The processors utilize a circular (ring) buffer memory to effectuate transfer and overlapped processing of said information. This processing reduces the information lag and recovery time between the log-based recovery system and the active system in the event the active system is to be reconstituted from the log-based system. Transaction processing systems usually use a log or journal to record changes to state information which must remain persistent between periods of execution (whether the period is planned or due to failure). One example of such state information might be the relative priority of a specific transaction type.

Another example might be the state and last message number of a communications session. The base information is usually available from information stored on stable storage as the result of some definition process, but the defined state

(Image Omitted)

will change due to system actions which take place during normal processing or by the direction of some external agency. The classical method of operation, which allows the changes to be persistent, follows. . During normal processing: 1. As the changes occur, record each change on a log

or journal.

2. Periodically record (at least) the modifiable

state of all the resources on the journal (a

checkpoint). This ensures that, in the event of a

failure in the future, there is a point on the

journal (other than the "beginning of time") at

which a recovery process may start reading. . Should a failure occur, the recovery process must: 1. Reload the initial states of the resources from

their repositories.

2. Read the journal from the beginning of the last

completed checkpoint, applying the recorded

information to the main storage copy of the

information.

(Image Omitted)

3. Either in parallel with the processing of the

checkpoint (if the checkpoint is "fuzzy") or

immediately following the final checkpoint record

(if the checkpoint is not "fuzzy"), read each

1

Page 2 of 5

status change record and further update the main

storage copy of the information.

4. This update process continues to the end of the

journal when the main storage copy has been

restored to its latest state. The inventive method requires that the journal process have a definition for the following: 1. The type of record being processed (e.g.,

recoverable status).

2. The identity of the resource class to which the

record belongs (e.g., session information).

3. The resource manager writing the record (e.g.,

communications manager).

4. The identity of the specific resource (e.g.,

session ID) whose new status is being recorded.

(Image Omitted)

I...