Commitment definition for two-phase commit: Indicate OK to leave out

Normally, the transaction manager at every location in the transaction program network participates in every commit or rollback operation. To improve performance, you can set up some or all locations in a transaction to allow the transaction manager to indicate OK to leave out.

Note: The Indicate OK to leave out option does not apply if you are using a DRDA® distributed unit of work over TCP/IP connection.

If no communications flows are sent to the location during a transaction, the location is left out when a commit or rollback operation is performed. This improves overall performance because the communications flows that normally occur during the commit or rollback are eliminated during transactions in which no data is sent to one or more remote locations.

After you start commitment control, you can use the Change Commitment Options (QTNCHGCO) API to change the OK to leave out option to Y (Yes). You might want to do this if one or more remote systems often are not involved in a transaction.

If your commitment definition is set up to indicate OK to leave out, the application waits for the next message flow from another location.

The OK to leave out option is intended for applications that are client/server in nature. If the only purpose of program A is to satisfy requests from program I and not to do any independent work, then it is appropriate to allow the OK to leave out option for program A.

Flow of commit processing without last agent optimization when agent votes OK to leave out

The following figure shows the flow of messages among the application programs and the transaction managers when an application program issues a commit instruction without last agent optimization when the agent indicates OK to leave out. Both the initiator application program and the agent application programs are unaware of the two-phase commit processing. The numbers in parentheses () in the figure correspond to the numbered items in the description that follows.


Flow of commit processing without last agent optimization when agent votes OK to leave out

Here is a description of the events for normal processing without last agent optimization when the agent votes OK to leave out. This describes a basic flow. The sequence of events can become much more complex when the transaction program network has multiple levels or when errors occur.

  1. Application program A does a receive request to indicate that it is ready to receive a request from program I.
  2. The initiator application (I) issues a commit instruction.
  3. The transaction manager for the initiator (TM-I) takes the role of initiator for this transaction. It starts the prepare wave by sending a prepare message to all the other locations that are participating in the transaction.
  4. The transaction managers for every other location take the role of agent (TM-A). The application program A is notified by TM-A that a request to commit has been received. For ICF files, the notification is in the form of the Receive Take Commit (RCVTKCMT) ICF indicator being set on.
  5. The application program A responds by issuing a commit instruction (or a rollback instruction). This is the application program's vote.
  6. If application program A has used the Change Commitment Options API (QTNCHGCO) to set the OK to leave out commitment option to Y, an indicator is sent when the agent (TM-A) responds to the initiator (TM-I) with a request commit message.
    Note: Any change to the OK to leave out commitment option does not take effect until the next successful commit operation.
  7. When the initiator (TM-I) receives all the votes, the TM-I sends a commit message. This starts the committed wave.
  8. Each agent (TM-A) commits and responds with a reset message.
  9. A return is sent to the application program (I) to indicate that the transaction is complete at the initiator.
  10. Any number of transactions might occur on TM-I, none of which requires changes to TM-A or data from TM-A. TM-A is not included in these transactions.
  11. The next time the initiator (TM-I) issues a message to the agent (A), a new transaction ID is sent with the message. If the initiator performs any commit or rollback operations before sending a message to the agent, no messages are sent to the agent during those operations (the agent is 'left out' of those commits or rollbacks). Because one or more transactions might have been committed or rolled back at the initiator while the agent was left out, the initiator must communicate its current transaction ID when the next message is sent to the agent.
  12. A return is sent to the application program (A) to indicate that the original commit is complete and that it is participating in the current transaction.
Related concepts
Optimize performance for commitment control