Availability Guide for Application Design

Availability in the Pathway Transaction-Processing
Environment
Availability Guide for Application Design—525637-004
6-11
Design Implications for Server Processes
•
If a processor fails, the server processes running in that processor are no longer
available to service transaction requests, so the length of the request queue
increases. That increase causes the LCS process to start new server processes on
other processors within the logical Pathway/XM node object. That action
automatically redistributes the transaction workload to minimize processing delays.
•
When a processor is reloaded, the LCS process begins to rebalance the workload
among processors. First, the LCS process deletes the links to existing server
processes as those processes finish transactions and become available. That
action causes the length of the request queue to increase, and the increase
causes the LCS process to start new server processes on the reloaded processor.
Design Implications for Server Processes
Application servers designed for Pathway and the NonStop TS/MP environment do not
need to be modified to benefit from the basic automation and management facilities of
Pathway/XM. However, application servers that use the Subsystem Programmatic
Interface (SPI) of PATHMON must be modified to run in the Pathway/XM environment;
changes are needed because of the difference in the way PATHMON coordinates
activities within the Pathway/XM environment. (Such applications typically use the
PATHMON SPI to provide custom load-balancing or configuration management.)
The application design considerations described in Development Concerns on
page 6-7 apply to servers in direct and replicated server classes. The same
considerations apply to servers in distributed server classes, although the operational
concerns are reduced because of the ability to reconfigure the environment while it is
running.
Direct server classes are usually used for single-server applications. However, if the
Pathway/XM environment is configured so that only one PATHMON process is used,
then single-server processes can be run as distributed server class processes.
An application server coded without TMF, or an application server that makes any
assumptions about how Pathway/iTS link management is performed, can only run in a
direct or replicated server class.
For distributed server classes, requests from Pathsend processes are handled the
same way as other transaction requests, with one difference. Pathsend requests are
always directed to the single named PATHMON process within the Pathway/XM
environment and are serviced by the server processes controlled by that PATHMON
process. This routing can restrict throughput, so Pathsend requester processes are not
good candidates for use with distributed server classes.
Availability Through RSC/MP
Remote Server Call/MP (RSC/MP) software lets you use personal computers (PCs)
and workstations to communicate with Pathway servers and other NonStop processes
on a NonStop system. The NonStop system can act as the host to one or many client
workstations.