Transaction Internet Protocol - Requirements and Supplemental Information
RFC 2372

Document Type RFC - Informational (July 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2372 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         K. Evans
Request for Comments: 2372                                    J. Klein
Category: Informational                               Tandem Computers
                                                               J. Lyon
                                                             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.


   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

   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