In the case of transaction processing of a synchronous-response-type RPC is executed, the transaction terminates when the processing results are returned to the root transaction branch and synchronization point processing is completed.

If the requirements for optimizing transaction are satisfied, a process of the server UAP can accept the next service request when processing terminates.

The figure below shows the relationship between the synchronous-response-type RPC and the synchronization point.

Figure 2-32 Relationship between synchronous-response-type RPC and synchronization point

In the case of transaction processing of an asynchronous-response-type RPC, RPC processing will terminate when the client UAP finishes synchronization point processing. If a response comes from the server UAP after synchronization point processing, the UAP which called the function dc_rpc_call() cannot receive the response.

The figure below shows the relationship between the asynchronous-response-type RPC and the synchronization point.

Figure 2-33 Relationship between asynchronous-response-type RPC and synchronization point

In the case of transaction processing of a nonresponse-type RPC, the client UAP waits until the server UAP finishes processing, and then executes synchronization point acquisition processing.

The figure below shows the relationship between the nonresponse-type RPC and the synchronization point.

Figure 2-34 Relationship between nonresponse-type RPC and synchronization point

Chained RPCs are executed by one server UAP process. Therefore, there is one transaction branch regardless of the number of chained RPCs used.

In the case of transaction processing of chained RPCs, the transaction will terminate when synchronization point processing is terminated. The server UAP process is then freed.

If non-transactional chained RPCs are used during the transaction, the server UAP process in charge of the processing will, in general, be freed when the synchronous point processing ends. If you want to free the server UAP process in charge of the processing by means of a synchronous-response-type RPC (with DCNOFLAGS assigned to flags) rather than the termination of the synchronous point processing, assign 00000002 to the user service definition rpc_extend_function operand.

When the chained RPCs are terminated by a synchronous-response-type RPC, the server UAP process can accept the next service request when processing is terminated, provided that the requirements for optimizing transaction are satisfied.

The figures below show the relationship between chained RPCs and the synchronization point.

Figure 2-35 Relationship between chained RPCs and synchronization point (transactional chained RPCs)

Figure 2-36 Relationship between chained RPCs and synchronization points (if a specification is given so that the server processing will not end with the non-transactional chained RPCs)

Even when the function dc_rpc_call() or the function dc_rpc_poll_any_replies() returns with an error, the transaction synchronization point might becomes commitment.

A transaction might have to be rolled back depending on the return value. In this case, use a rollback function (dc_trn_chained_rollback() or dc_trn_unchained_rollback()) to roll back the transaction.

The following return values cause a transaction to be rolled back:

• Return value of the function dc_rpc_call()
• Return value of the function dc_rpc_poll_any_replies()

For details on the function dc_rpc_call() or dc_rpc_poll_any_replies() that must be rolled back, see the applicable OpenTP1 Programming Reference manual.