|
|
|
|
|
|
Transaction Timeouts
As described in Transaction Errors, two types of timeouts can occur in a BEA Tuxedo application: blocking and transaction. The following sections describe how various programming features are affected by transaction timeouts. Refer to Transaction Errors for more information on timeouts.
TPCOMMIT Call
What is the state of a transaction if a timeout occurs after a call to TPCOMMIT? If the transaction timed out and the system knows that it was aborted, the system reports these events by setting TP-STATUS to TPEABORT. If the status of the transaction is unknown, the system sets the error code to TPETIME.
When the state of a transaction is in doubt, you must query the resource manager. First, verify whether or not any of the changes that were part of the transaction were applied. Then you can determine whether the transaction was committed or aborted.
TPNOTRAN
When a process is in transaction mode and makes a communication call with TPNOTRAN, it prohibits the called service from becoming a participant in the current transaction. Whether the service request succeeds or fails has no impact on the outcome of the transaction. The transaction can still timeout while waiting for a reply that is due from a service, whether it is part of the transaction or not.
For additional information on using TPNOTRAN, refer to TPRETURN and TPFORWAR Calls.
TPRETURN and TPFORWAR Calls
If you call a process while running in transaction mode, TPRETURN and TPFORWAR place the service portion of the transaction in a state that allows it to be either committed or aborted when the transaction completes. You can call a service several times on behalf of the same transaction. The system does not fully commit or abort the transaction until the initiator of the transaction calls TPCOMMIT or TPABORT.
Neither TPRETURN nor TPFORWAR should be called until all outstanding handles for the communication calls made within the service have been retrieved. If you call TPRETURN with outstanding handles for which TP-RETURN-VAL is set to TPSUCCESS, the system encounters a protocol error and returns TPESVCERR to the process waiting on TPGETRPLY. If the process is in transaction mode, the system marks the caller as "abort-only." Even if the initiator of the transaction calls TPCOMMIT, the system implicitly aborts the transaction. If you call TPRETURN with outstanding handles for which TP-RETURN-VAL is set to TPFAIL, the system returns TPESVCFAIL to the process waiting on TPGETRPLY. The effect on the transaction is the same.
When you call TPRETURN while running in transaction mode, this function can affect the result of the transaction by the processing errors that it encounters or that are retrieved from the value placed in TP-RETURN-VAL by the application.
You can use TPFORWAR to indicate that success has been achieved up to a particular point in the processing of a request. If no application errors have been detected, the system invokes TPFORWAR; otherwise, the system invokes TPRETURN with TPFAIL. If you call TPFORWAR improperly, the system considers the call a processing error and returns a failed message to the requester.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|