Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Designing Recoverability in a Server

IP.com Disclosure Number: IPCOM000104552D
Original Publication Date: 1993-May-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 90K

Publishing Venue

IBM

Related People

Dennison, CM: AUTHOR [+7]

Abstract

Disclosed is a method for storing request status information that can be used to track progress and implement server recoverability. This status information, which may be spread among multiple nodes, contains details about the request at many levels and about the database operations that are in-progress.

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

Method for Designing Recoverability in a Server

      Disclosed is a method for storing request status information
that can be used to track progress and implement server
recoverability.  This status information, which may be spread among
multiple nodes, contains details about the request at many levels and
about the database operations that are in-progress.

      The operation of this method begins when a user requests an
operation which requires independent database updates be performed on
one or more nodes in a network.  This request is then distributed to
the appropriate nodes which need to process portions of the overall
request.

      The main features of this method are:

o   A status-table on each node which is taking part in doing
    database updates.
o   A primary-request, represented by an entry in a status table,
    that represents the status of the overall request.

o   A secondary-request, represented by an entry in a status table,
    that represents the portion of the primary request that is being
    processed on this node.
o   A results-file, represented by an entry in a status table, that
    contains the status information for a group of related database
    operations.

      The figure illustrates this method.  The left half of the
figure illustrates a primary request initiated on a node, resulting
in two secondary requests being sent to two other nodes.  On one node
all the database updates are logically grouped together, while on the
other node there are two distinct logical groups of updates (a
"logical group" in this context is a set of updates that is processed
sequentially and can take place independently from any other logical
groups on the node; each logical group is possibly processed by a
separate thread or process).

      The right half of the figure shows the features of this method
that correspond to the work flow shown on the left.  The following
numbers correspond to the numbers in the diagram:

      1.  On the originating node there is a primary request entry
created in the status table to track the overall request.  As
secondary requests are sent off to other nodes, they are tracked
using secondary request entries in the origi...