![[Contents]](FIGURE/CONTENT.GIF)
OpenTP1 Version 7 TP1/Client User's Guide TP1/Client/W, TP1/Client/P
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
A multi-server environment can concurrently activate multiple instances of the same SPP for multiple processes. In this environment, an SPP execution process is started every time a service is requested. When a CUP calls the same service group more than once, the SPPs of the service group are not always executed with the same process. However, if you use synchronous-response RPCs to request more than one service of the same service group, the services can be executed with the same process. This execution method is called a chained RPC.
A chained RPC can be used only when a transaction is started from a CUP or a permanent connection has been established.
Using a chained RPC reduces the number of user processes required for processing one transaction, leading to a lower load on the transaction processing. If used as a transaction, the chained RPC works on one global transaction.
The chained RPC is assured on a CUP process basis. However, note that, if a different client UAP is used even within the same global transaction, it is not assured that the service called several times is started in the same process.
To request a service that will work in chained-RPC mode, specify 'DCRPC_CHAINED' in the flags of the dc_rpc_call_s function. Requesting the service with this value specified lets the SPP recognize the chained RPC and reserves a process. Specify 'DCRPC_CHAINED' in the flags for the second or subsequent service requests.
A chained RPC can be terminated by either
The UAP requested to provide a service in chained-RPC mode watches the time between returning a response to the CUP and requesting the next service or the synchronous-point process of a transaction. If the next service or synchronous-point processing request does not arrive within the watching time, the system assumes a CUP error and terminates the SPP abnormally. The watching time must be specified in 'watch_next_chain_time' of the user service definition.
All Rights Reserved. Copyright (C) 2006, 2009, Hitachi, Ltd.