Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using C

The following sections provide some considerations for the following transaction scenarios:

• Called Service in Same Transaction as Caller

• Called Service in Different Transaction with AUTOTRAN Set

• Called Service that Starts a New Explicit Transaction

Called Service in Same Transaction as Caller

When a caller in transaction mode calls another service to participate in the current transaction, the following facts apply:

• tpreturn() and tpforward(), when called by the participating service, place that service's portion of the transaction in a state from which it can be either aborted or committed by the initiator.

• The success or failure of the called process affects the current transaction. If any fatal transaction errors are encountered by the participant, the current transaction is marked "abort-only."

• Whether or not the tasks performed by a successful participant are applied depends on the fate of the transaction. In other words, if the transaction is aborted, the work of all participants is reversed.

• The TPNOREPLY flag cannot be used when calling another service to participate in the current transaction.

Called Service in Different Transaction with AUTOTRAN Set

If you issue a communication call with the TPNOTRAN flag set and the called service is configured such that a transaction automatically starts when the service is called, the system places both the calling and called processes in transaction mode, but the two constitute different transactions. In this situation, the following facts apply:

• tpreturn() plays the initiator's transaction role: it terminates the transaction in the service in which the transaction was automatically started. Alternatively, if the transaction is automatically started in a service that terminates with tpforward(), the tpreturn() call issued in the last service in the forward chain plays the initiator's transaction role: it terminates the transaction. (For an example, refer to the figure called Transaction Roles of tpforward( ) and tpreturn() with AUTOTRAN.)

• Because it is in transaction mode, tpreturn() is vulnerable to the failure of any participant in the transaction, as well as to transaction time-outs. In this scenario, the system is more likely to return a failed message.

• The state of the caller's transaction is not affected by any failed messages or application failures returned to the caller.

• The caller's own transaction may timeout as the caller waits for a reply.

• If no reply is expected, the caller's transaction cannot be affected in any way by the communication call.

  Transaction Roles of tpforward( ) and tpreturn() with AUTOTRAN

  

Called Service that Starts a New Explicit Transaction

If a communication call is made with TPNOTRAN, and the called service is not automatically placed in transaction mode by a configuration option, the service can define multiple transactions using explicit calls to tpbegin(), tpcommit(), and tpabort(). As a result, the transaction can be completed before a call is issued to tpreturn().

In this situation, the following facts apply:

• tpreturn() plays no transaction role; that is, the role of tpreturn() is always the same, regardless of whether transactions are explicitly defined in the service routine.

• tpreturn() can return any value in rval, regardless of the outcome of the transaction.

• Typically, the system returns processing errors, buffer type errors, or application failure, and follows the normal rules for TPESVCFAIL, TPEITYPE/TPEOTYPE, and TPESVCERR.

• The state of the caller's transaction is not affected by any failed messages or application failures returned to the caller.

• The caller is vulnerable to the possibility that its own transaction may time out as it waits for its reply.

• If no reply is expected, the caller's transaction cannot be affected in any way by the communication call.

Copyright © 2000 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.