OpenTP1 Version 7 Programming Guide
A server UAP to which a service request was issued is executed in a process different from the process of the client UAP. OpenTP1 can implement a multiserver that starts multiple processes for executing a server UAP. When the multiserver is used to nest RPCs, the same number of processes as services to be nested might be executed.
Even when the same server UAP is used, the server UAP is not always executed in the same process if a different client UAP is used. Also, when a service which belongs to the same service group as for the client UAP is requested, a new process is necessary for executing the service group. When using a multiserver, specify a sufficient number of processes.
The figure below shows the relationship between RPCs and processes.
Figure 2-10 Relationship between RPCs and processes
If a synchronous-response-type RPC requests the services belonging to the same service group more than once, the service offered in response to each request can be run by the same process. This RPC is called a chained RPC. If chained RPCs are used to request for services, the services are run by the same process as with the preceding RPC, even in a multiserver environment. The number of processes needed for transaction processing can thus be minimized. Since a UAP process is assigned for each service group, chained RPCs can be used to request for different types of service if these services belong to the same service group.
Processing for chained RPCs may or may not be performed as a transaction. If chained RPCs are run as a transaction, the transaction will be a global transaction.
Operation of a chained RPC is guaranteed within each process of the client UAP. Suppose that a service is called multiple times within the same global transaction, but that the client UAPs involved are different. It is not guaranteed that the service offered in response to each request is run by the same process.
When requesting a service which will be the first of chained RPCs, specify DCRPC_CHAINED for flags in the function dc_rpc_call() that requests the service. The server UAP acquires a process with the recognition that the RPC is a chained RPC. Specify DCRPC_CHAINED also for flags in the second and subsequent service requests.
The second and subsequent service requests cannot detect the shutdown status of a user server or service. If an error occurs during execution of the second or a subsequent service request, the user server shuts down. In this situation, you cannot shut down individual services.
Use one of the following methods to terminate chained RPCs:
If an SPP fails to accept a service request because of a communication error or other condition when a chained RPC is being processed, the process could remain assigned to the SPP. To avoid this, the OpenTP1 time-monitors SPPs which are activated by chained RPCs. Actually, checking is made to see whether the following value is exceeded by the period (maximum interval) from the time a response is issued to the time the next service request or a chained RPC termination request comes:
If the next service request or chained RPC termination request does not come within the above interval, the OpenTP1 considers that a failure has occurred in the client UAP and aborts the SPP process.
Servers that receive requests from socket (SPPs which receive service requests without using a schedule queue) do not work as multiserver. They do not work as nonresident processes, either. They work as one server with resident process.
When a service request carried by a chained RPC is executed to a server that receives requests from socket, the server UAP can receive service requests only from the pertinent client UAP. As far as possible, avoid requesting services to servers that receive requests from socket through chained RPCs.
The figure below shows the relationship between chained RPCs and processes.
Figure 2-11 Relationship between chained RPCs and processes
All Rights Reserved. Copyright (C) 2006, 2010, Hitachi, Ltd.