OpenTP1 Version 7 Programming Guide

[Contents][Index][Back][Next]

2.1.11 Relationship between remote procedure calls and processes for executing services

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

[Figure]

  1. If a service is requested from client UAP1 to server UAP1, server UAP1 is executed in process A.
  2. If a service is requested from client UAP1 to server UAP2, server UAP2 is executed in process B.
  3. If a service is requested from new client UAP2 to server UAP1, server UAP1 is executed in process C unlike when a service is requested in 1.
Organization of this subsection
(1) Chained RPCs

(1) Chained RPCs

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.

(a) Starting chained RPCs

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.

(b) Terminating chained RPCs

Use one of the following methods to terminate chained RPCs:

(c) Time monitoring for 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.

(d) Chained RPCs to servers that receive requests from socket

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

[Figure]

  1. When client UAP1 requests server UAP1 for service using a chained RPC (DCRPC_CHAINED specified for flags), server UAP1 is run by process A.
  2. When client UAP1 requests server UAP2 for service using a chained RPC, server UAP2 is run by process B.
  3. When client UAP1 requests server UAP1 for service using a chained RPC again, server UAP1 is run by the same process A as in 1.
  4. When client UAP1 requests server UAP1 for service using a synchronous-response-type RPC (DCNOFLAGS specified for flags), server UAP1 is run by process A. The chained RPCs for linkage between client UAP1 and server UAP1 are terminated.
  5. When client UAP1 requests server UAP2 for service using a chained RPC, server UAP2 is run by process B.
  6. When the synchronization point is acquired, the chained RPCs for linkage between client UAP1 and server UAP2 are terminated.