Browse Prior Art Database

Optimizing Use of Local Coordinators in Distributed Applications

IP.com Disclosure Number: IPCOM000118485D
Original Publication Date: 1997-Feb-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 6 page(s) / 235K

Publishing Venue

IBM

Related People

Hutchison, GD: AUTHOR

Abstract

The use of subordinate coordinators local to resource managers has traditionally improved performance in distributed transactions, but this is not always so.

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

Optimizing Use of Local Coordinators in Distributed Applications

      The use of subordinate coordinators local to resource managers
has traditionally improved performance in distributed transactions,
but this is not always so.

      The described approach provides a method of dynamically
deciding when to use subordinate coordinators as intermediaries
between a root coordinator and resource managers in a distributed
transaction.  The method used is useful in a system where all nodes
in a distributed transaction can communicate with each other.  The
initial optimization is based on simple algorithms regarding numbers
and types of branches at any one point in the commit tree but this
can be refined to use timestamps on message traffic to analyze
message node to node duration when deciding on the suitability of the
use and location of root and subordinate coordinators.

      This is done during the first stage of the two phase commit
process if deemed advantageous.  The commit tree is collapsed to give
an optimum commit tree with a reduced number of subordinate
coordinators for the subsequent commit/rollback phase.

      In a simple two phase commit scenario, a transaction
coordinator controls a number of resource managers to ensure they
commit or reject updates in unison.  The coordinator communicates
directly with  each individual resource manager.

      During phase one, the coordinator polls each resource manager
asking it to prepare updates and return a vote on whether it can
commit to making all changes permanent should the overall vote be a
unanimous 'commit'.  If, for any reason, the resource manager cannot
commit to making updates for the transaction permanent, it will vote
'rollback'.

      In the second and subsequent phase, the coordinator will ask
each resource manager to finally 'commit' all changes if they all
voted they would be able to do so.  If any resource manager voted
'rollback' during the initial prepare phase, then during the second
phase the coordinator will instruct all resource managers to
'rollback'; i.e., reject any changes made during the transaction.

Optimization of Distributed Transactions using Local Coordinators

      In this case, the sub-environments that make up the distributed
transaction each have a local coordinator that distributes and
resolves the two phase commit messages for that sub-environment.

      Instead of all resource managers being coordinated directly by
the root coordinator in a 'star' topology, a root coordinator
coordinates directly with other 'subordinate coordinators' in a
tree-like structure  often called the 'commit tree'.  Typically, each
site will have its own  transaction coordinator that deals directly
with the resource managers  at that site and relays messages to other
coordinators.  The distributed  commit algorithm, thus, becomes a
recursive operation with each coordinator polling the resource
managers and subordinates direc...