Transaction Internet Protocol - Requirements and Supplemental Information (RFC2372)
Original Publication Date: 1998-Jul-01
Included in the Prior Art Database: 2019-Feb-15
Internet Society Requests For Comment (RFCs)
K. Evans: AUTHOR [+2]
This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
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 (C) The Internet Society (1998). All Rights Reserved.
This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol . 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
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 th...