Transaction Internet Protocol - Requirements and Supplemental Information
RFC 2372
Network Working Group K. Evans
Request for Comments: 2372 J. Klein
Category: Informational Tandem Computers
J. Lyon
Microsoft
July 1998
Transaction Internet Protocol - Requirements and
Supplemental Information
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes the purpose (usage scenarios), and
requirements for the Transaction Internet Protocol [1]. It is
intended to help qualify the necessary features and functions of the
protocol. It also provides supplemental information to aid
understanding and facilitate implementation of the TIP protocol.
Table of Contents
1. Introduction 2
2. The Transaction Internet Protocol 3
3. Scope 4
4. Anticipated Usage of TIP 4
5. TIP Compliant Systems 4
6. Relationship to the X/Open DTP Model 5
7. Example TIP Usage Scenario 5
8. TIP Transaction Recovery 9
9. TIP Transaction and Application Message Serialisation 10
10. TIP Protocol and Local Actions 10
11. Security Considerations 11
12. TIP Requirements 11
References 14
Authors' Addresses 15
Comments 15
A. An Example TIP Transaction Manager API 16
Full Copyright Statement 24
Evans, et. al. Informational [Page 1]
RFC 2372 TIP Requirements and Supplemental Information July 1998
1. Introduction
Transactions are a very useful programming paradigm, greatly
simplifying the writing of distributed applications. When
transactions are employed, no matter how many distributed application
components participate in a particular unit-of-work, the number of
possible outcomes is reduced to only two; that is, either all of the
work completed successfully, or none of it did (this characteristic
is known as atomicity). Applications programming is therefore much
less complex since the programmer does not have to deal with a
multitude of possible failure scenarios. Typically, transaction
semantics are provided by some underlying system infrastructure
(usually in the form of products such as Transaction Processing
Monitors, and/or Databases). This infrastructure deals with failures,
and performs the necessary recovery actions to guarantee the property
of atomicity. The use of transactions enables the development of
reliable distributed applications which would otherwise be difficult,
if not impossible.
A key technology required to support distributed transactions is the
two-phase commit protocol (2-pc). 2-pc protocols have been used in
commercial Transaction Processing (TP) systems for many years, and
are well understood (e.g. the LU6.2 2-pc (syncpoint) protocol was
first implemented more than 12 years ago). Today a number of
different 2-pc protocols are supported by a variety of TP monitor and
database products. 2-pc is used between the components participating
in a distributed unit-of-work (transaction) to ensure agreement by
all parties regarding the outcome of that work (regardless of any
failure).
Today both standard and proprietary 2-pc protocols exist. These
protocols typically employ a "one-pipe" model. That is, the
transaction and application protocols are tightly-integrated,
executing over the same communications channel. An application may
use only the particular communications mechanism associated with the
transaction protocol. The standard protocols (OSI TP, LU6.2) are
complex, with a large footprint and extensive configuration and
administration requirements. For these reasons they are not very
widely deployed. The net of all this is restricted application
flexibility and interoperability if transactions are to be used.
Applications may wish to use a number of communications protocols for
which there are no transactional variants (e.g. HTTP), and be
Show full document text