Using the ATMI to Handle System and Application Errors


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Administering a BEA Tuxedo Application at Run Time \| Local Topics \| Previous Topic \| Next Topic \| Contents

Using the ATMI, a programmer controls some of the more global aspects of communications. The ATMI provides functions for handling both application and system-related errors. When a service routine encounters an application error, such as an invalid account number, the client knows the service performed its task but could not fulfill its request because of an application error.

With a system failure, such as a server crashing while performing a request, the client knows the service routine did not perform its task because of an underlying system error. The BEA Tuxedo system notifies programs of system errors that occur as it monitors the application's behavior and its own behavior.

Using Configurable Timeout Mechanisms

At times, a service may get stuck in an infinite loop while processing a request. The client waits, but no reply is forthcoming. To protect a client from endless waiting, the BEA Tuxedo system has two types of configurable timeout mechanisms: blocking timeouts and transaction timeouts.

A blocking timeout is a mechanism that ensures a blocked program waits no longer than the specified timeout value for something to occur. Once a timeout is detected, the waiting program is alerted with a system error informing it that a blocking timeout has occurred. The blocking timeout defines the duration of service requests, or how long the application is willing to wait for a reply to a service request. The timeout value is a global value defined in the BLOCKTIME field of the RESOURCES section of the TUXCONFIG file.

A transaction timeout is another type of timeout that can occur because active transactions tend to be resource-intensive. A transaction timeout defines the duration of a transaction, which may involve several service requests. The timeout value is defined when the transaction is started (with tpbegin(3c)). Transaction timeouts are useful when maximizing resources. For example, if database locks are held while a transaction progresses, an application programmer may want to limit the amount of time that the application's transaction resources are held up. A transaction timeout always overrides a blocking timeout.

Configuring Redundant Servers to Handle Failures

You can handle some failure situations by configuring an application with redundant servers and the automatic restart capability. Redundant servers provide high availability, and can be used to handle large amounts of work, server failures, or machine failures. The BEA Tuxedo system continually checks the status of active servers, and when it detects the failure of a restartable server, the system automatically creates a new instance of that server.

By configuring servers with the automatic restart property, you can handle individual server failures.You can also specify the number of restarts that the system will provide. This capability can prevent a recurring application error by limiting the number of times a server is restarted.

The BEA Tuxedo system frequently checks the availability of each active machine. A machine is marked as partitioned when it cannot be reached by the system. If this occurs, a system event is generated. A partition can occur due to a network failure, machine failure, or severe performance degradation.