Browse Prior Art Database

Recovery Management in Transaction Processing Systems

IP.com Disclosure Number: IPCOM000117576D
Original Publication Date: 1996-Apr-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 100K

Publishing Venue

IBM

Related People

Normington, G: AUTHOR

Abstract

Recovery management in transaction process systems using the two-phase commit syncpoint protocol is prone to complexity and lack of uniformity because of the differences in protocols used for local and for remote updates.

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

Recovery Management in Transaction Processing Systems

      Recovery management in transaction process systems using the
two-phase commit syncpoint protocol is prone to complexity and lack
of uniformity because of the differences in protocols used for local
and for remote updates.

      Local updates are prepared and then either committed or backed
out, whereas remote updates also include the protocols associated
with one of the systems acting as coordinator, the existence of the
indoubt window, and the possibility of a communications failure
necessitating resynchronization.

      The lack of uniformity makes it difficult to fit both protocols
into a single, unifying framework.  The implementations become
complex and confused and there is very little re-use of design.

      The solution described below uses a collection of protocols
known as Two-Phase Commit (2PC) to ensure that updates for a unit of
work are all committed or all backed out.  These protocols are
abstractly implemented by two classes of component, referred to
herein as Voter and Poller classes.

      The principle of 2PC is that the components responsible for
the updates are first asked to vote to indicate whether or not they
are capable of committing the updates.  If all the components vote
that they are capable, then the decision is taken to commit the unit
of work.  Subsequently, the components are told what the decision
was.

      If any of the components votes that it is not capable of
committing its updates, then the decision is taken to back out the
unit of work and the components are then informed of that decision.

      So, abstractly, 2PC is the polling of a 'panel' of voters.

      Most of the complications arise because, after a voter has
voted, it is in doubt until it is told what the decision was.  If the
voter resides on a different system to that where the decision is
taken, then there is the possibility of a long wait for the decision.

      In this case, the voter is said to be waiting indoubt.  If the
connection to the deciding (or 'coordinator') system is lost, then
the indoubt wait may be indefinitely long.  To reduce the amount of
system resources consumed by an indoubt voter, the system will
'shunt' the voter  until the decision becomes available.  Shunting
simply frees some system  resources which are not required for the
moment.

      Concretely, polling, voting, and shunting are implemented by
the Unit of Work, Link Set, Link, Resource Owner, and Transaction
classes.  These classes inherit the abstract behavior of Voter or
Poller.  Link Set inherits from both, as it is both a voter as well
as a poller of its links, as shown in the Figure:

DEFINITIONS:
  Unit of Work           This class is responsible for managing
                          units of work and for coordinating all the
                          local and remote recove...