rfc2372.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Evans, et. al.               Informational                      [Page 6]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   4) The book_flight application does its work (which may involve
      access to a recoverable resource manager (e.g. an RDBMS), in which
      case the local TM will associate the RM with the local transaction
      (via the XA interface or whatever)).

   5) The book_flight application returns to the travel agency
      application indicating success.

   6) Steps 2-5 are then repeated with the hotel server "book_room"
      application. At the conclusion of this, the superior TM has
      registered two subordinate TMs as participants in the transaction,
      there are TIP connections between the agency TM and the airline
      and hotel TMs, and there are inflight transactions at the airline
      and hotel servers. [Note that steps 2-5 and 6 could be performed
      in parallel.]

   7) The travel agency application issues a "commit transaction"
      request (using the API of the local TM). The local TM sends a
      PREPARE command on the TIP connections to the airline and hotel
      TMs (as these are registered as subordinate transaction
      participants).

   8) The TMs at the airline and hotel servers perform the
      necessary steps to prepare their local recoverable resources (e.g.
      by issuing xa_prepare() requests). If successful, the subordinate
      TMs change their TIP transaction state to Prepared, and log
      recovery information (e.g. local and superior transaction branch
      identifiers, and the IP address of the superior TM). The
      subordinate TMs then send PREPARED commands to the superior TM.

   9) If both subordinates respond PREPARED, the superior TM logs that
      the transaction is Committed, with recovery information (e.g.
      local and subordinate transaction identifiers, and subordinate TM
      IP addresses). The superior TM then sends COMMIT commands on the
      two subordinate TIP connections.

   10) The TMs at the airline and hotel servers perform the
       necessary steps to commit their local recoverable resources (e.g.
       by issuing xa_commit() requests). The subordinate TMs forget the
       transaction. The subordinate TMs then send COMITTED commands to
       the superior TM.

   11) The superior TM forgets the transaction. The TIP connections
       between the superior and subordinate TMs return to Idle state
       (not associated with any transaction). The superior TM returns
       success to the travel agency application "commit transaction"
       request.




Evans, et. al.               Informational                      [Page 7]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   12) The travel agency application returns "reservation made" to the
       client.

   This example illustrates the use of PULL. If PUSH were to be used
   instead, events 2) and 3) above would change as follows:

   2) The travel agency application:

      a.  passes the TIP URL obtained in 1. above, together with the
          listening endpoint address of the TM at the airline server, to
          its local TM via a "tip_push()" API request. The tip_push()
          function causes the following to occur:

          i. if a TIP connection does not already exist to the
             subordinate (airline server) TM (as identified via the IP
             address passed on the tip_push), one is created and an
             IDENTIFY exchange occurs (if multiplexing is to be used on
             the connection, this is followed by a MULTIPLEX exchange),

          ii. a PUSH command is sent to the subordinate TM,

          iii. in response to the PUSH, the subordinate TM creates a
               local transaction, associates this transaction with the
               connection, and sends a PUSHED response to the superior
               TM,

          iv. in response to the PUSHED response, the superior TM
              associates the subordinate TM with the transaction,

          v. the superior TM returns control to the travel agency
             application.

      b.  the travel agency application sends a request to the airline
         server (via some protocol (e.g. HTTP)), requesting the
         "book_flight" service, passing the flights selected by the
         client, and the TIP URL (obtained in 1 above).

   3) The request is received by the airline server which invokes the
      book_flight application. This application retrieves the TIP URL
      from the input data, and passes this on a "tip_pull()" API request
      to its local TM. Since the local TM has already "seen" this URL
      (it was already pushed), it simply returns to the book_flight
      application, which is now executing in the context of the
      previously created local transaction.







Evans, et. al.               Informational                      [Page 8]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   [Note that although in this example the transaction coordinator role
   is performed by a node which is also a participant in the transaction
   (the Travel Agency), other configurations are possible (e.g. where
   the transaction coordinator role is performed by a non-participant
   3rd-party node).]

8. TIP Transaction Recovery

   Until the transaction reaches the Prepared state, any failure results
   in the transaction being aborted. If an error occurs once the
   transaction has reached the Prepared state, then transaction recovery
   must be performed. Recovery behaviour is different for superior and
   subordinate; the details depend upon the outcome of the transaction
   (committed or aborted), and the precise point at which failure
   occurs.

   In the travel agency application for example, if the connection to
   the hotel server fails before the COMMIT command has been received by
   the hotel TM, then (once the connection is restored):

   1)  The superior (travel agency) TM sends a RECONNECT command
      (passing the subordinate transaction identifier (recovered from
      the transaction log if necessary)).

   2) The subordinate (hotel) TM responds RECONNECTED (since it never
      received the COMMIT command, and still has the transaction in
      Prepared state (if the failure had occurred after the subordinate
      had responded COMMITTED, then the subordinate would have forgotten
      the transaction, and responded NOTRECONNECTED to the RECONNECT
      command)).

   3) The superior TM sends a COMMIT command. The subordinate TM
      commits the transaction and responds COMMITTED. The transaction is
      now resolved.

   4) If the subordinate TM restores the connection to the superior TM
      before receiving a RECONNECT command, then it may send a QUERY
      command. In this case, the superior TM will respond QUERIEDEXISTS,
      and the subordinate TM should wait for the superior to send a
      RECONNECT command. If the transaction had been aborted, then the
      superior may respond QUERIEDNOTFOUND, in which case the
      subordinate should abort the transaction (note that the superior
      is not obliged to send a RECONNECT command for an aborted
      transaction (i.e. it could just forget the transaction after
      sending ABORT and before receiving an ABORTED response)).






Evans, et. al.               Informational                      [Page 9]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   There are failure circumstances in which the client application (the
   one calling "commit") may not receive a response indicating the final
   outcome of the transaction (even though the transaction itself is
   successfully completed). This is a common problem, and one not unique
   to TIP. In such circumstances, it is up to the application to
   ascertain the final outcome of the transaction (a TIP TM may
   facilitate this by providing some implementation specific mechanism.
   e.g. writing the outcome to a user-log).

9. TIP Transaction and Application Message Serialisation

   A relationship exists between TIP commands and application messages:
   a TIP transaction must not be committed until it is certain that all
   participants have properly registered, and have finished work on the
   transaction. Because of the two-pipe nature of TIP, this behaviour
   cannot necessarily be enforced by the TIP system itself (although it
   may be possible in some implementations). It is therefore incumbent
   upon the application to behave properly.  Generally, an application
   must not:

   1)  call it's local TMs "commit" function when it has any requests
       associated with the transaction still outstanding.

   2)  positively respond to a transactional request from a partner
       application prior to having registered it's local TM with the
       transaction.

10. TIP Protocol and Local Actions

   In order to ensure that transaction atomicity is properly guaranteed,
   a system implementing TIP must perform other local actions at certain
   points in the protocol exchange. These actions pertain to the
   creation and deletion of transaction "log-records" (the necessary
   information which survives failures and ensures that transaction
   recovery is correctly executed). The following information regarding
   the relationship between the TIP protocol and logging events is
   advisory, and is not intended to be definitive (see [2] for more
   discussion on this subject):

   1) before sending a PREPARED response, the system should create
      a prepared-recovery-record for the transaction.

   2) having created a prepared-recovery-record, this record should not
      be deleted until after:
      a.  an ABORT message is received; or
      b.  a COMMIT message is received; or
      c.  a QUERIEDNOTFOUND response is received.




Evans, et. al.               Informational                     [Page 10]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   3) the system should not send a COMMITTED or NOTRECONNECTED message
      if a prepared-recovery-record exists.

   4) before creating a commit-recovery-record for the transaction, the
      system should have received a PREPARED response.

   5) before sending a COMMIT message in Prepared state, the system
      should have created a commit-recovery-record for the transaction.

   6) having created a commit-recovery-record, this record should not be
      deleted until after:
      a.  a COMMITTED message is received; or
      b.  a NOTRECONNECTED message is received.

11. Security Considerations

   The means by which applications communicate and perform distributed
   work are outside the scope of the TIP protocol. The mechanisms used
   for authentication and authorisation of clients to access programs
   and information on a particular system are part of the application
   communications protocol and the application execution infrastructure.
   Use of the TIP protocol does not affect these considerations.

   Security relates to the TIP protocol itself inasmuch that systems
   require to protect themselves from the receipt of unauthorised TIP
   commands, or the impersonation of a trusted partner TIP TM.  Probably
   the worst consequence of this is the possibility of undetected data
   inconsistency resulting from violations of the TIP commitment
   protocol (e.g. a COMMIT command is injected on a TIP connection in
   place of an ABORT command). TIP uses the Transport Layer Security
   protocol [6] to restrict access to only trusted partners (i.e. to
   control from which remote endpoints TIP transactions will be
   accepted, and to verify that an end-point is genuine), and to encrypt
   TIP commands. Usage of TLS (or not) is negotiated between partner TIP
   TMs. See [1] for details of how TLS is used with TIP.

   TIP TM implementations will also likely provide local means to time-
   out and abort transactions which have not completed within some time
   period (thereby preventing unavailability of resources due to
   malicious intent). Transaction time-out also serves as a means of
   deadlock resolution.

12. TIP Requirements

   Most of these requirements stem from the primary objective of making
   transactions a ubiquitous system service, available to all
   application classes (much as TCP may be assumed to be available
   everywhere). In general this requires imposing as few restrictions



Evans, et. al.               Informational                     [Page 11]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   regarding the use of TIP as possible (applications should not be
   required to execute in some "special" environment in order to use
   transactions), and keeping the protocol simple and efficient. This
   enables the widespread implementation of TIP (it's cheap to do), on a
   wide range of systems (it's cheap to run).

   1) Application Communications Protocol Independence

      The TIP protocol must be defined independently of the
      communications protocol used for transferring application data, to
      allow TIP usage in conjunction with any application protocol.  It
      must be possible for applications using arbitrary communications
      protocols to begin, end, and propagate TIP transactions.

      This implies that the TIP protocol employ a 2-pipe model of
      operation. This model requires the separation of application
      communications and transaction coordination, into two discrete
      communication channels (pipes). This separation enables the use of
      the transaction coordination protocol (TIP), with any application
      communications protocol (e.g. HTTP, ODBC, plain TCP/UDP, etc).

   2) Support for Transaction Semantics

      The TIP protocol must provide the functionality of the de-facto
      standard presumed-abort 2-pc protocol, to guarantee transactional
      atomicity even in the event of failure. It should provide a means
      to construct the transaction tree, as well as provide commitment
      and recovery functions.

   3) Application Transaction Propagation and Interoperability

      In order to facilitate protocol independence, application
      interoperability, and provide a means for TIP transaction context
      propagation, a standard representation of the TIP transaction
      context information is required (in the form of a URL). This
      information must include the listening endpoint address of the
      partner TIP TM, and transaction identifier information.

   4) Ease of Implementation

      The TIP protocol must be simple to implement. It should support
      only those features necessary to provide a useful, performant 2-pc
      protocol service. The protocol should not add complexity in the
      form of extraneous optimisations.







Evans, et. al.               Informational                     [Page 12]