Availability Guide for Application Design

Increasing the Availability of Tuxedo Applications
Availability Guide for Application Design—525637-004
5-11
Availability of NonStop Tuxedo Applications
If the workstation client uses dynamically bound /WS libraries, then, depending on the
client platform, the WSH process might not detect the error; in this case, it does not
abort transactions.
Recovery From a Machine Failure
If a machine failure occurs, any currently active transactions that involve the failed
machine are aborted. Other machines, of course, are not able to access any service
performed exclusively on the failed machine.
Other recovery issues depend on whether the failed machine is the master machine, a
nonmaster machine, or a client workstation, as follows:
•
Master machine failure
If a master machine fails, nonmaster machines can continue without change
except that they cannot perform functions that require access to the DBBL
process, such as starting a server process.
Reintegration of the master machine requires restarting the application. Before
bringing the master machine up again, nonmaster machines must be manually
shut down. The master machine must then be brought up first.
•
Nonmaster machine
If a nonmaster machine fails, other machines can continue unimpaired, except for
the loss of function normally provided by the failed machine. When the nonmaster
machine is available again, it can be manually rebooted and reintegrated into the
Tuxedo system.
•
Client workstation
Failure of a client workstation is detected by the relevant WSH process because
the data communications connection is lost. The error may not be detected until an
operation that uses the network is attempted. The WSH process aborts any
outstanding TMF transactions started on behalf of the client process.
Recovery From a Network Failure Between Master Machine
and Nonmaster Machine
If a communications failure occurs between the master machine and a nonmaster
machine, then the master machine can continue unimpaired, except, of course, for
access to application services on the inaccessible machine. The nonmaster machine
can continue to do work although it cannot perform functions that require access to the
DBBL process, such as starting a server.
When the network recovers, the application is automatically reintegrated.