Transaction Errors


	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 COBOL

Transaction Errors

The following sections describe transaction-related errors.

Non-fatal Transaction Errors

When transaction errors occur, the system returns TPETRAN in TP-STATUS. The precise meaning of such an error, however, depends on the call that is returning it. The following table lists the calls that return transaction errors and describes possible causes of them.

Transaction Errors

Call
Cause

TPBEGIN

Usually caused by a transient system error that occur during an attempt to start the transaction. The problem may clear up with a repeated call.

TPCANCEL

Returns TPETRAN when called from a transaction.

TPRESUME

The BEA Tuxedo system is unable to resume a global transaction because the caller is currently participating in work outside the global transaction with one or more resource managers. All such work must be completed before the global transaction can be resumed. The caller's state with respect to the local transaction is unchanged.

TPCONNECT, TPCALL, and TPACALL

A call was made in transaction mode to a service that does not support transactions. Some services belong to server groups that access a database management system (DBMS) that, in turn, support transactions. Other services, however, do not belong to such groups. In addition, some services that support transactions may require interoperation with software that does not. For example, a service that prints a form may work with a printer that does not support transactions. Services that do not support transactions may not function as participants in a transaction.

The grouping of services into servers and server groups is an administrative task. In order to determine which services support transactions, check with your application administrator.

You can correct transaction-level errors at the application level by enabling the setting TPSVCDEF-REF or by accessing the service for which an error was returned outside of the transaction.

Call	Cause
TPBEGIN	Usually caused by a transient system error that occur during an attempt to start the transaction. The problem may clear up with a repeated call.
TPCANCEL	Returns TPETRAN when called from a transaction.
TPRESUME	The BEA Tuxedo system is unable to resume a global transaction because the caller is currently participating in work outside the global transaction with one or more resource managers. All such work must be completed before the global transaction can be resumed. The caller's state with respect to the local transaction is unchanged.
TPCONNECT, TPCALL, and TPACALL	A call was made in transaction mode to a service that does not support transactions. Some services belong to server groups that access a database management system (DBMS) that, in turn, support transactions. Other services, however, do not belong to such groups. In addition, some services that support transactions may require interoperation with software that does not. For example, a service that prints a form may work with a printer that does not support transactions. Services that do not support transactions may not function as participants in a transaction. The grouping of services into servers and server groups is an administrative task. In order to determine which services support transactions, check with your application administrator. You can correct transaction-level errors at the application level by enabling the setting TPSVCDEF-REF or by accessing the service for which an error was returned outside of the transaction.

Fatal Transaction Errors

When a fatal transaction error occurs, the application should 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; TP-STATUS is set to TPESVCERR.
The TP-RETURN-VAL to TPRETURN was set to TPFAIL; TP-STATUS is set to TPESVCFAIL.
The type of the reply record is not known or not allowed by the caller and, as a result, success or failure cannot be determined; TP-STATUS is set to TPEOTYPE.
The transaction times out; TP-STATUS is set to TPETIME.
TPCOMMIT is called by a participant rather than by the originator of a transaction; TP-STATUS 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 time-out, the result is an implicit abort error. Then, because the commit failed, the transaction should be aborted.

If the system returns TPESVCERR, TPESVCFAIL, TPEOTYPE, or TPETIME for any communication call, the transaction should be aborted explicitly with a call to TPABORT. You need not wait for outstanding communication handles before explicitly aborting the transaction. However, because these communication handles 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 should call any communication functions with 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 time-out occurs, communication can continue, but communication requests cannot:

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

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

Heuristic Decision Errors

The TPCOMMIT call may return TPEHAZARD or TPEHEURISTIC, depending on how TP-COMMIT-CONTROL is set.

If you set TP-COMMIT-CONTROL to TP-CMT-LOGGED, the application obtains control before the second phase of a two-phase commit is performed. In this case, the application may not be aware of a heuristic decision that occurs during the second phase.

TPEHAZARD or TPEHEURISTIC can be returned in a one-phase commit, however, if a single resource manager is involved in the transaction and it returns a heuristic decision or a hazard indication during a one-phase commit.

If you set TP_COMMIT_CONTROL to TP_CMT_COMPLETE, then the system returns TPEHEURISTIC if any resource manager reports a heuristic decision, and TPEHAZARD if any resource manager reports a hazard. TPEHAZARD specifies that a participant failed during the second phase of commit (or during a one-phase commit) and that it is not known whether a transaction completed successfully.