Availability Guide for Application Design

Increasing the Availability of Tuxedo Applications
Availability Guide for Application Design—525637-004
5-7
Availability of NonStop Tuxedo Applications
by the application in the client. The WSL and DBBL processes run with immediate
persistence, while other processes—such as the WSL process—are restarted as
needed.
As shown in Figure 5-2 on page 5-5, several processes are involved in executing a
NonStop Tuxedo application. Each of these processes is important in providing a fully
functional application; some processes are critical to keeping the application online.
To ensure availability, the NonStop Tuxedo product, the application, or the operations
function must provide recovery if:
•
A processor fails or some other reason causes a critical process to stop. Critical
processes include: server processes, the WSH process, the WSL process, a
NonStop TCP/IP process, the BBL process, the DBBL process, the supervisor
process, and client processes.
•
An entire machine fails.
•
Communication between machines fails: between a master machine and a
nonmaster machine, or between a WSH process and a workstation client.
After discussing the role of transaction protection, the remainder of this subsection
discusses how the NonStop Tuxedo product, the application code, and appropriate
operation combine to protect the application from these potential failures.
Transaction Protection
The ability to protect the database with transactions is critical to providing availability in
NonStop Tuxedo applications. Transaction begin, commit, and abort operations
requested by the client process using ATMI or TX function calls are converted to TMF
calls on the server by the WSH process. A known point of consistency is established at
the beginning of the transaction, providing a safe point at which to resume operation if
a critical component were to fail, such as loss of the connection to the server, loss of
the WSH, or loss of the server process.
When the WSH process invokes a service while in transaction mode, the actions taken
by the server process also become a part of the transaction. These actions are
committed or aborted when the transaction ends.
Note that TMF transactions begin and end in the WSH. It is up to the application
developer to trace the integrity of the transaction from the client process. Refer to
Design Implications for NonStop Tuxedo Applications on page 5-12.
For more details on the role of TMF software in keeping applications available, refer to
Section 4, Data Protection and Recovery.
Recovery From Server Process Failure
NonStop Tuxedo server processes run as members of NonStop TS/MP server classes;
in other words, replicated copies of the same server run in different processors. Any
currently active TMF transactions started by a failing server process are aborted. In