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

Reducing the Latency of Distributed Resource Registration

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

Publishing Venue

IBM

Related People

Cobb, EE: AUTHOR [+4]

Abstract

This is a technique for reducing the amount time it takes for a "Resource" to be registered (by a registrant) for involvement in a distributed transaction that is managed by an implementation of the Object Transaction Service (OTS). The behavior of the OTS is specified by the Object Management Group (OMG) as an Object Service component of the Common Object Request Broker Architecture (CORBA).

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

Reducing the Latency of Distributed Resource Registration

      This is a technique for reducing the amount time it takes for a
"Resource"  to be registered (by a registrant) for involvement in a
distributed transaction that is managed by an implementation of the
Object Transaction Service (OTS).  The behavior of the OTS is
specified by the Object Management Group (OMG) as an Object Service
component of the Common Object Request Broker Architecture (CORBA).

      The reduction in time is only apparent in cases where the
transaction is distributed and is observed by the registrant when its
local "Coordinator"  is a subordinate.  The technique can improve
throughput and reduce the occurrence of time-outs: the advantage of
its effect will increase as the distance in the path between the
registrant's "Coordinator"  and the root "Coordinator"  object
increases in the "commit digraph."

      According to the OTS specification (OMG TC document 94-8-4), a
"Resource"  is not involved in a transaction until it is registered
with its local "Coordinator"  object.  In turn, a "Coordinator"  is
not involved in any of its superiors' transactions until a local
"Resource"  is registered for involvement in one of those
transactions.  A set of transactional operations can be invoked on
"TransactionalObject"s in a single transaction; objects in this set
are related in a "request digraph."  Any path in this graph can span
the domains of several "Coordinator"s.  Until the first "Resource"
is registered for involvement in the transaction there is no
corresponding commit digraph.

      The problem is most easily recognized when a "Resource"  at the
end of a long "request path"  is first registered and a corresponding
"commit path"  must be constructed.  The commit path is constructed
as a side effect of the "Resource"'s "Coordinator"  registering
itself with its superior and each superior "Coordinator"  recursively
registering itself with its own superior.

      If the commit path is constructed by "Coordinator"s registering
themselves by invoking normal synchronous
"Coordinator::register_resource"  operations on their superiors, then
the time between the first "Resource"  invoking "register_resource"
and receiving the corresponding reply could easily exceed a local
timeout interval, especially if a long series of inter-machine and
inter-process communications ne...