Skip navigation.

WebLogic Tuxedo Connector Programmer's Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Application Error Management

The following sections provide mechanisms to manage and interpret error conditions in your applications:


Testing for Application Errors

Note: To view an example that demonstrates how to test for error conditions, see Example Transaction Code.

Your application logic should test for error conditions after the calls that have return values and take suitable steps based on those conditions. In the event that a function returned a value, you may invoke a functions that tests for specific values and performs the appropriate application logic for each condition.

Exception Classes

The WebLogic Tuxedo Connector throws the following exception classes:

Fatal Transaction Errors

In managing transactions, it is important to understand which errors prove fatal to transactions. When these errors are encountered, transactions should be explicitly aborted on the application level by having the initiator of the transaction call commit(). Transactions fail for the following reasons:


WebLogic Tuxedo Connector Time-Out Conditions

There are two types of time-out which can occur when using the WebLogic Tuxedo Connector:

Blocking vs. Transaction Time-out

Blocking time-out is exceeding the amount of time a call can wait for a blocking condition to clear up. Transaction time-out occurs when a transaction takes longer than the amount of timed defined for it in setTransactionTimeout(). By default, if a process is not in transaction mode, blocking time-outs are performed. When the flags parameter of a a communication call is set to TPNOTIME, it applies to blocking time-outs only. If a process is in transaction mode, blocking time-out and the TPNOTIME flag are not relevant. The process is sensitive to transaction time-out only as it has been defined for it when the transaction was started. The implications of the two different types of time-out follow:

Effect on commit()

The state of a transaction if time-out occurs after the call to commit() is undetermined. If the transaction timed out and the system knows that it was aborted, setRollbackOnly() or rollback() returns with an error.

If the state of the transaction is in doubt, you must query the resource to determine if any of the changes that were part of that transaction have been applied to it in order to discover whether the transaction committed or aborted.

Effect of TPNOTRAN

Note: A transaction can time-out while waiting for a reply that is due from a service that is not part of that transaction.

When a process is in transaction and makes a communications call with flags set to TPNOTRAN, it prohibits the called service from becoming a participant of that transaction. The success or failure of the service does not influence the outcome of that transaction.


Guidelines for Tracking Application Events

You can track the execution of your applications by using System.out.println() to write messages to the WebLogic Server trace log. Create a log() method that takes a variable of type String and use the variable name as the argument to the call, or include the message as a literal within quotation marks as the argument to the call. In the following example, a series of messages are used to track the progress of a tpcall().

Listing 10-1 Example Event Logging

log("About to call tpcall"); 
try {
myRtn = myTux.tpcall("TOUPPER", myData, 0);
catch (TPReplyException tre) {
log("tpcall threw TPReplyExcption " + tre);
throw tre;
catch (TPException te) {
log("tpcall threw TPException " + te);
throw te;
catch (Exception ee) {
log("tpcall threw exception: " + ee);
throw new TPException(TPException.TPESYSTEM, "Exception: " + ee);
log("tpcall successfull!");
private static void
log(String s)
{	System.out.println(s);}


Back to Top Previous Next