TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-22
Design Considerations
•
Update or read-only server: A single server exclusively handles either update
transactions or inquiry transactions.
One approach to packaging server functions is to first group server functions based on
management considerations (for example, all servers within a server class must freeze
and stop as a unit) and security considerations (for example, the server class must
execute under one user ID). Then, partition server functions based on the database files
that are most frequently accessed.
To ensure acceptable response times for users and allow you to tune your application for
performance, it is very important to partition server functions based on service times. If
the same set of servers handles short and long transactions, some requests for short
transactions will be queued behind long transactions, resulting in poor response times
for the short requests. If the short and long transactions perform different functions, put
those functions in separate server programs. If the short and long transactions perform
essentially the same work—for example, a simple database lookup—but some requests
could be for multiple lookups, you can configure two or more server classes for requests
of different lengths, all using the same program code.
Nested Servers
A server written in C, C++, COBOL85, Pascal, TAL, or pTAL can use the Pathsend
procedures to send a request message to a server in another server class and receive a
reply. In such a case, the server is acting as a requester. Servers communicating with
each other in this manner are called nested servers.
For example, consider a situation where a requester on one node requires the services of
two server classes on another node. Instead of sending to server class A, waiting for a
reply, and then sending to server class B, the requester could send to server class A, and
server class A could send to server class B, get the response, and then reply to the
requester. This use of nested servers reduces the number of messages sent across data
communications lines and enables application logic to be distributed near the resources
it manages.
Consider the following when considering the use of nested server programs:
•
Single-threaded servers that send to other server classes can cause process
deadlocks. A process deadlock is a situation in which two processes cannot proceed
because each is waiting for a reply from the other.
For example, if a process in server class A sends a request to server class B and the
process in server class B then sends a request to server class A, a deadlock might
occur. Even if there is more than one process in server class A, there is no guarantee
that the second request would not be sent to the same process that sent the original
request.
To avoid this problem, the server program for server class A should keep a read
operation posted on $RECEIVE and wait for completion of either the send operation
or the read operation. Although this multithreading increases the complexity of the
program, it is necessary in order to prevent deadlock.