11.24.2 Fatal Transaction Errors

When a fatal transaction error occurs, the application must explicitly abort the transaction by having the initiator call tpabort(). Therefore, it is important to understand the errors that are fatal to transactions. Three conditions cause a transaction to fail:

• The initiator or a participant in the transaction causes it to be marked “abort-only” for one of the following reasons:
• tpreturn() encounters an error while processing its arguments; tperrno(5) is set to TPESVCERR.
  • The rval argument to tpreturn() was set to TPFAIL; tperrno(5) is set to TPESVCFAIL.
  • The type or subtype of the reply buffer is not known or not allowed by the caller and, as a result, success or failure cannot be determined; tperrno(5) is set to TPEOTYPE.
• The transaction times out; tperrno(5) is set to TPETIME.
• tpcommit() is called by a participant rather than by the originator of a transaction; tperrno(5) is set to TPEPROTO.
• tpcommit() is called by a participant rather than by the originator of a transaction; tperrno(5) is set to TPEPROTO.

The only protocol error that is fatal to transactions is calling tpcommit() from the wrong participant in a transaction. This error can be corrected in the application during the development phase.

If tpcommit() is called after an initiator/participant failure or transaction timeout, the result is an implicit abort error. Then, because the commit failed, the transaction must be aborted.

If the system returns TPESVCERR, TPESVCFAIL, TPEOTYPE, or TPETIME for any communication call, the transaction must be aborted explicitly with a call to tpabort(). You need not wait for outstanding call descriptors before explicitly aborting the transaction. However, because these descriptors are considered stale after the call is aborted, any attempt to access them after the transaction is terminated returns TPEBADDESC.

In the case of TPESVCERR, TPESVCFAIL, and TPEOTYPE, communication calls continue to be allowed as long as the transaction has not timed out. When these errors are returned, the transaction is marked abort-only. To preserve the results of any further work, you must call any communication functions with the flags parameter set to TPNOTRAN. By setting this flag, you ensure that the work performed for the transaction marked “abort-only” will not be rolled back when the transaction is aborted.

When a transaction timeout occurs, communication can continue, but communication requests cannot:

• Requires replies
• Block
• Be performed on behalf of the caller's transaction

Therefore, to make asynchronous calls, you must set the flags parameter to TPNOREPLY, TPNOBLOCK, or TPNOTRAN.