Standards Update, IEEE 1003.11: Transaction Processing

[Jeffrey S. Haemer]

From: Jeffrey S. Haemer <jsh at usenix.org>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.11: Transaction Processing Update

Bob Snead <bobs at ico.isc.com> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

Context

Our charter is to develop an application profile for POSIX Transaction
Processing (TP).  We're wrestling with both the content of our profile
and the idea of a profile, since the profiles are new to POSIX.
[Editor: Jim Isaak reviews application profiles in the February IEEE
Computer.]

The content is influenced by two other TP efforts: OSI's DTP and
X/OPEN's XTP.  We must handle OSI DTP, just to gain ISO acceptance--a
goal of all the 1003 efforts.  In theory, XTP is just another
proprietary concern.  In fact, XTP's ongoing deliberations are
currently confidential.  Moreover, X/OPEN isn't an official standards
body so we can't officially reference XTP in our profile.
Nevertheless, XTP will carry considerable weight, since it will be a
multi-vendor consensus on how to do UNIX TP.

Models

As at previous meetings, we spent much time discussing TP models.  For
the most part these discussions were based on a snapshot of XTP's
model released to non-X/OPEN members some time ago.  Each model we
discussed consisted of three or four of the following elements:
Application Programs (APs), Resource Managers (RMs, like database
managers), Communications Managers (CMs, like TCP/IP), and Transaction
Managers (TMs, which enforce the transaction protocol among APs, CMs
and RMs).  Here, in chronological order, were the major topics of
discussion.

We discussed whether a CM might just be an instance of an RM (viewing
an instance of a communications protocol or link as a resource), but
concluded that attributes of CMs make them fundamentally different
beasts (though, to be honest, it's still not clear to me why).
__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


                                - 2 -

We considered several models based on XTP, but differing from one
another in the roles of the CM and the interfaces between the AP and
CM.  We concluded that each communications protocol would have to have
its own CM, and that our model must support multiple concurrently
active CMs.  A CM, though, is more than just its protocol support.  It
has to include support for additional functionality required for DTP.
We never concluded whether or not an AP should talk directly to a CM,
or to a CM via the TM.

Requirements

In the course of the model discussions, it became clear that many of
us had different requirements in mind, so we shifted our focus to
requirements to try to reach some consensus.  Ultimately, we decided
that POSIX TP must:

   - be mappable onto OSI DTP,

   - support global (distributed) transactions,

   - support chained and unchained transactions,

   - support a conversational mode,

   - provide data conversion (e.g., ASN.1),

   - ensure that POSIX RPC supports DTP semantics,

   - ensure that DTP can be accomplished through RPC,

   - provide for location independence via directory services, and

   - provide for security of data.

Exercises

We decided to break the modeling deadlock by focusing on the AP/TM
interface and ignoring communication.  We worked several examples,
following ISO DTP services but using an RPC paradigm, and concluded
that an API based in RPCs would need at least four services:

   - one for a caller to start a transaction,

   - one for a callee to find out if it is participating in a
     transaction,

   - one for a callee to abort a transaction,

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


                                - 3 -

   - one for a caller to commit or abort a transaction.

We also identified the following assumptions for TP via RPC:

   - A thread of control (TOC) can be in at most one transaction at
     any given time.

   - If one TOC communicates with another, the latter joins the
     former's transaction by default.

   - No nested transactions are permitted.

   - A GTRID (Global TRansaction ID) can be associated with multiple
     TOCs and multiple RMs.

   - A transaction has only one initiator and only the initiator can
     issue commit.  Any TOC may abort.

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


Volume-Number: Volume 19, Number 9