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 C

Transaction Errors

The following sections describe transaction-related errors.

Non-fatal Transaction Errors

When transaction errors occur, the system returns TPETRAN in tperrno(5). The precise meaning of such an error, however, depends on the function that is returning it. The following table lists the functions that return transaction errors and describes possible causes of them.

Transaction Errors

Function
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()

The function was called for a transaction reply after a request was made without the TPNOTRAN flag.

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(), tppost(), 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 TPNOTRAN flag or by accessing the service for which an error was returned outside of the transaction.

Function	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()	The function was called for a transaction reply after a request was made without the TPNOTRAN flag.
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(), tppost(), 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 TPNOTRAN flag 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; 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.

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 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 should 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 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 the flags parameter to TPNOREPLY, TPNOBLOCK, or TPNOTRAN.

Heuristic Decision Errors

The tpcommit() function 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.