OpenTP1 performs control transaction via X/Open XA interface. On XA interface, the synchronization point of transactions is acquired by prepare processing and commit processing separately. This synchronization point processing is called two-phase commit. Therefore, the client UAP communicates with the server UAP four times in total: sending two requests for synchronization point processing and receiving two responses. During two-phase commit processing, the process of transaction processing cannot receive other service requests until the synchronization point is acquired.

The figure below shows the outline of ordinary transaction processing (two-phase commit).

Figure 2-37 Outline of ordinary transaction processing (two-phase commit)

When the conditions for commit optimization are satisfied, the synchronization point processing for phase 2 (commit/rollback processing) to be performed in the transaction branch on the server is performed in the transaction branch on the client. This eliminates two of the inter-process communications and improves the performance of transaction processing.

Commit optimization is performed when all the following conditions are satisfied:

1. Both transaction branches on the client and the server are within the same OpenTP1 system.
2. The XA interface object file for the resource manager accessed in the transaction branch on the server has been linked to the transaction branch on the client.

During commit optimization, the transaction branch on the server can receive other service requests when the synchronization point processing for phase 1 terminates, without waiting for completion of processing for phase 2.

The figure below shows the outline of commit optimization.

Figure 2-38 Outline of commit optimization

When the conditions for prepare optimization are satisfied, the synchronization point processing for phase 1 (prepare processing) to be performed in the transaction branch on the server is performed in the transaction branch on the client. This eliminates two of the inter-process communications and improves the performance of transaction processing.

Prepare optimization is performed when all the following conditions are satisfied:

1. Both transaction branches on the client and the server are within the same OpenTP1 system.
2. The XA interface object file for the resource manager accessed in the transaction branch on the server has been linked to the transaction branch on the client.
3. The transaction branch on the client uses synchronous-response RPCs. (DCNOFLAGS is specified for flags of the function dc_rpc_call().)

Since commit optimization is also performed during prepare optimization, it results in eliminating four of inter-process communications. The transaction branch on the server can receive other service requests without waiting for completion of synchronization point processing.

The figure below shows the outline of prepare optimization.

Figure 2-39 Outline of prepare optimization

When the conditions for asynchronous prepare optimization are satisfied, the transaction branch on the server performs prepare processing at the time the service processing terminates before control returns to the transaction branch on the client. This eliminates two of the inter-process communications and improves the performance of transaction processing.

Asynchronous prepare optimization is performed when all the following conditions are satisfied:

1. The UAP on the client specifies asyncprepare in the trn_optimum_item operand of the user service definition.
2. Prepare optimization is disallowed. (If allowed, prepare optimization has precedence over asynchronous prepare optimization.)
3. The transaction branch on the client uses synchronous-response RPCs. (DCNOFLAGS is specified for flags of the function dc_rpc_call().)

Asynchronous prepare optimization has a much longer RPC response time than ordinary transaction processing. If OpenTP1 containing the transaction branch on the client terminates abnormally during transaction processing, OpenTP1 containing the transaction branch on the server may also terminate abnormally due to journal acquisition.

The figure below shows the outline of asynchronous prepare optimization.

Figure 2-40 Outline of asynchronous prepare optimization

When the conditions for one-phase optimization are satisfied, only the transaction branch on the server performs the synchronization point processing while the transaction branch on the client does not access the resource manager. This eliminates two of the inter-process communications and improves the performance of transaction processing.

One-phase optimization is performed when all the following conditions are satisfied:

1. Only the resource manager supporting dynamic registration has been linked to the transaction branch on the client.
2. The transaction branch on the client neither accesses the resource manager nor outputs the user journal.
3. The transaction branch on the client has only one child transaction branch.

The figure below shows the outline of one-phase optimization.

Figure 2-41 Outline of one-phase optimization

When the conditions for read-only optimization are satisfied, the synchronization point processing for phase 2 is not performed if the transaction branch on the server does not perform update processing. This eliminates two of the inter-process communications and improves the performance of transaction processing.

Read-only optimization is performed when all the following conditions are satisfied:

1. The transaction branch on the server neither updates resources (excluding reference) nor outputs the user journal.
2. The transaction branch on the client has only one child transaction branch.

During read-only optimization, the transaction branch on the server can receive the next service request when the synchronization point processing for phase 1 terminates, without waiting for completion of processing for phase 2.

The figure below shows the outline of read-only optimization.

Figure 2-42 Outline of read-only optimization

When the conditions for no-access optimization are satisfied, the synchronization point processing is not performed if the transaction branch on the server does not access the resource manager. This eliminates four of the inter-process communications and improves the performance of transaction processing.

No-access optimization is performed when all the following conditions are satisfied:

1. The transaction branch on the client uses synchronous-response RPCs. (DCNOFLAGS is specified for flags of the function dc_rpc_call().)
2. Only the resource manager supporting dynamic registration has been linked to the transaction branch on the server.
3. The transaction branch on the server neither accesses the resource manager nor outputs the user journal.
4. The transaction branch on the server has no child transaction branch. Alternatively, it has child transaction branch(es) for which read-only optimization is available.

During no-access optimization, the transaction branch on the server can receive other service requests without waiting for completion of the synchronization point processing.

The figure below shows the outline of no-access optimization.

Figure 2-43 Outline of no-access optimization

When the conditions for rollback optimization are satisfied, the transaction branch on the server rolls back out of synchronization with other transaction branches if it uses a rollback function. Other transaction branches do not execute the synchronization point processing for phase 1. This eliminates two of the inter-process communications and improves the performance of transaction processing.

Rollback optimization is performed when all the following conditions are satisfied:

1. The transaction branch on the client uses synchronous-response RPCs. (DCNOFLAGS is specified for flags of the function dc_rpc_call().)
2. The transaction branch on the server uses a rollback function.

During rollback optimization, the transaction branch on the server can receive other service requests without waiting for completion of the synchronization point processing.

The figure below shows the outline of rollback optimization.

Figure 2-44 Outline of rollback optimization

In general, when a service is requested from a transaction branch to a UAP for which the transaction attribute is specified, the process of the transaction branch on the server is handled as another transaction branch. However, when a chained RPC is used for the same service group (various services can exist), that is, when DCRPC_CHAINED is specified for flags of the function dc_rpc_call(), the process is handled as the same transaction branch until the chained RPC is completed. When the conditions for optimization using chained RPCs are satisfied, the performance of transaction processing is improved since the number of transaction branches in a global transaction is reduced.

The figure below shows the outline of optimization using chained RPCs.

Figure 2-45 Outline of optimization using chained RPCs