Availability Guide for Application Design

Increasing the Availability of Tuxedo Applications
Availability Guide for Application Design—525637-004
5-8
Availability of NonStop Tuxedo Applications
addition, active TMF transactions started elsewhere but encompassing the failing
server process are also aborted.
To recover the application to the point of failure, it is up to the client process to restart
the aborted transaction. When the restarted transaction requests a service, the link
manager process provides the linkage between the WSH process and any member
process of the appropriate server class.
Restart of the failed server process depends on whether it was a static process or a
dynamic process. Static server processes are started when the server class is started.
Dynamic server processes are started only when the workload of the application needs
extra processing capability; dynamic processes stop again when they are no longer
required.
In the case of a failed processor, static server processes are immediately restarted in
the next configured processor. If only one processor is configured, then no servers will
be started until that processor is available.
Dynamic server processes are not restarted. However, the PATHMON process will
start new dynamic servers as required to handle the workload.
After the failed processor is reloaded, it will not be immediately repopulated with
servers. It will be used only when the supervisor process needs to start new server
processes because of workload or failure of another processor.
If a static server process unexpectedly stops for some other reason—for example, it
terminates itself—then the process is restarted in the same processor.
Recovery From a WSH Process Failure
If a WSH process fails, all currently active TMF transactions initiated by the WSH
process on behalf of workstation clients are aborted; the WSH process is multithreaded
and is potentially the initiator of many concurrent transactions. All Transmission Control
Protocol/Internet Protocol (TCP/IP) connections are lost.
Workstation clients will detect lost connection errors and must reconnect and reissue
the transaction. The WSH process will not be automatically restarted. WSH processes
are started by WSL processes when already executing WSH processes cannot handle
additional incoming connection requests.
If the failure was due to a processor failure, then recovery depends on how the
corresponding WSL process is configured. If the WSL process was configured to run
WSH processes in only the failed processor, then no workstation-client connection
attempts will succeed until the failed processor is reloaded. If more than one processor
is configured for the WSH process, then the WSL process starts a new WSH process
immediately and connection attempts will succeed.
Recovery From a WSL Process Failure
A WSL process runs as a member of a NonStop TS/MP server class and is, therefore,
restarted by the supervisor process if it fails. If the WSL process fails because of a