Browse Prior Art Database

Log and Loggable Object Abstractions for Recovery Management

IP.com Disclosure Number: IPCOM000116576D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 59K

Publishing Venue

IBM

Related People

Normington, G: AUTHOR

Abstract

Recoverability in transaction processes systems such as CICS/ESA* is usually implemented using a system log, i.e., a sequence of log records the tail of which is made non-volatile at appropriate points so that units of work may be reconstructed after a system failure.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Log and Loggable Object Abstractions for Recovery Management

      Recoverability in transaction processes systems such as
CICS/ESA* is usually implemented using a system log, i.e., a sequence
of log records the tail of which is made non-volatile at appropriate
points so that units of work may be reconstructed after a system
failure.

      Updates for a particular Unit of Work (UOW), information
relating to the remote systems which are also participating in this
Unit of Work, and other UOW-specific data is logged under the UOW.
Other information such as activity keypoint log records and
non-UOW-related updates is not logged under a UOW.

      The problem in prior implementations was that the mechanisms
for logging UOW-specific data and non-UOW-related data were simply
writing different kinds of log records using the same log write
interface.

      This lack of uniformity makes it difficult to fit both kinds of
logging into a single unifying framework.  The implementations become
somewhat arbitrary and difficult to understand and there is very
little re-use of design.

      This problem is solved in the Recovery Manager (RM) described
below, by introducing two abstract classes: Log and Loggable Object.

      A Loggable Object makes itself sufficiently non-volatile by
writing log records to a Log.  The log records are 'forced' to stable
storage as necessary.

      A Log is also responsible for delivering log records back to
the Loggable Objects which logged them when a UOW is backed out or a
system restart occurs and RM's state must be reconstructed.

      Logging is implemented at two levels: the system level and the
UOW level.

      At the system level, System Log inherits from Log and logs
records from Unit of Work and Resource Owner (which inherit from
Loggable Object).

      At the UOW level, Unit of Work i...