Commitment definition for two-phase commit: Not wait for outcome

Commitment definition for two-phase commit: Not wait for outcome

When a communication or system failure occurs during a commit operation so that resynchronization is required, the default is to wait until the resynchronization is finished before the commit operation completes.
The Not wait for outcome option does not apply if you are using a Distributed Relational Database Architecture™ (DRDA^®) distributed unit of work over TCP/IP connection. DRDA distributed unit of work over TCP/IP connections never waits for outcome.
Consider changing this behavior if the following conditions are true:

The applications that participate are independent of each other.

Your program logic does not need the results of previous transactions to ensure that your database files remain synchronized.

After you start commitment control, you can use the Change Commitment Options (QTNCHGCO) API to specify that the commitment definition does not wait for the outcome of resynchronization. If you specify N (No) for the Wait for outcome option, the system uses a database server job (QDBSRVnn) to handle resynchronization asynchronously.
These database server jobs are started during the initial program load (IPL) process. If you change the options for commitment control, this has no effect on the number of jobs that the system starts.
This topic only refers to two values for the resolved Wait for outcome option, Y (Yes) and N (No). There are actually two more values that you can specify, L (Yes or Inherit from Initiator) and U (No or Inherit from Initiator). When you use these values, the actual value used during each commit operation is resolved to Yes or No by the system. The QTNCHGCO (Change Commitment Options) API topic has more details about these values.
The initiator's value can only be inherited by an agent if both the initiator and the agent support presumed abort.
The wait for outcome (WFO) option does not affect normal, error-free commit processing. If an error occurs, the WFO option determines whether the application waits for resynchronization or not, with the following conditions:

If the resolved WFO option is Y (Yes), the application waits for the result of the resynchronization.

If the resolved WFO option is N (No) and a communication failure occurs during the prepare wave or rollback of a location that supports presumed abort protocols, no resynchronization is performed and the commitment definition is rolled back.

If the commitment definition is in doubt (transaction state is prepared or Last Agent Pending), the application will wait for the result of the resynchronization regardless of the resolved WFO value.

If the resolved WFO option is N and neither one of conditions two or three is true, the system attempts to resynchronize once. If it is not successful, the system signals STATUS message CPF83E6 to the application to indicate that resynchronization is in progress.
Because CPF83E6 is a STATUS message, it only has an effect if the application is monitoring for it. Normally, your application can treat this message as an informational message. The systems that are participating in the transaction attempt to resynchronize the transaction until the failure is repaired. These subsequent resynchronization attempts are performed in the database server jobs. If a subsequent resynchronization attempt that is performed in a database server job fails, the message CPI83D0 is sent to QSYSOPR.

Wait for outcome value: Yes

In the following figure, the commitment definition for the initiator (I) uses the default value of Y (Yes) for the Wait for outcome option. When communications between TM-I and TM-A is lost, both application A and application I wait until the transaction is resynchronized.

Wait for outcome value: No

In the following figure, the commitment definition for the initiator has the resolved WFO set to N (No). TM-A meets condition 3 in the preceding list, while TM-I meets condition 4. Control is returned to application I after one attempt to resynchronize with TM-A. A database server job attempts to resynchronize. Application I never receives the return indicator when the commit request has completed successfully. Control is not returned to the agent application (A) until after communications is reestablished. This depends on the timing of the failure. In this case, the communications failure occurs before the commit message is received from the initiator, leaving TM-A in doubt as to whether to commit or rollback. When the transaction manager is in doubt, it retains control until the resynchronization is completed, regardless of the resolved WFO value at that system.
If you want the applications at all systems to continue before resynchronization completes, either change the resolved WFO option to N (No) on all systems, or set the initiator to N and the rest of the systems to U (No or Inherit from Initiator). But remember that the resolved WFO option is ignored when the transaction manager is in doubt as to whether to commit or rollback, and always waits until resynchronization completes before returning control.

When a connection is made to a remote relational database, and no protected conversations have already been started, the system implicitly changes the Wait for outcome value to N. The reason for this is that the performance of commit operations is improved when the Wait for outcome value is N and the remote system supports presumed abort. This implicit change of the Wait for outcome value is only performed for DRDA and DDM applications. APPC applications use the default Wait for outcome value of Y unless they call the QTNCHGCO API to change it.

Parent topic:
Commitment definitions for two-phase commitment control

Related concepts

States of the transaction for two-phase commitment control
Commitment control errors

Related reference

Change Commitment Options (QTNCHGCO) API