Normally, a transaction manager participates in both phases of commit processing. To improve the performance of commit processing, you can set up some or all locations in a transaction to allow the transaction manager to vote read-only.
If the location has no committable changes during a transaction, the transaction manager votes read-only during the prepare wave. The location does not participate in the committed wave. This improves overall performance because the communication flows that normally occur during the committed wave are eliminated during transactions in which no updates are made at one or more remote locations.
After you start commitment control, you can use the Change Commitment Options (QTNCHGCO) API to change the Vote read-only permitted option to Y. You might want to do this if the following conditions are true:
- One or more remote systems often do not have any committable changes for a transaction.
- A transaction does not depend on where the file cursor (next record) was set by the previous transaction. When a location votes read-only, the application is never notified if the transaction is rolled back. The location has committed any read operations to the database files and, thus, moved the cursor position. The position of the file cursor is typically important only if you do sequential processing.
If your commitment definition is set up to allow vote read-only, the application waits for the next message flow from another location.
The Vote read-only permitted option is intended for applications that are client/server in nature. If the purpose of program A is only to satisfy requests from program I, not to do any independent work, it is appropriate to allow the Vote read-only option for program A.
Flow of commit processing without last agent optimization when agent votes read-only
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 votes read-only. Neither the initiator application program nor the agent application programs is aware of the two-phase commit processing. The numbers in parentheses () in the figure correspond to the numbered items in the description that follows.
The following list is a description of the events for normal processing without last agent optimization when the agent votes read only. 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.
- Application program A does a receive request to indicate that it is ready to receive a request from program I.
- The initiator application (I) issues a commit instruction.
- 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.
- 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.
- The application program A responds by issuing a commit instruction (or a rollback instruction). This is the application program's vote.
- If application program A has used the Change Commitment Options API (QTNCHGCO) to set the Vote read-only permitted commitment option to Y and no changes have been made at the agent during the transaction, the agent (TM-A) responds to the initiator (TM-I) with a reset message. There is no committed wave for the agent.
- A return is sent to the application program (A) to indicate that the transaction is complete at agent TM-A.
- The next time the initiator (TM-I) issues any message to the agent (TM-A), either a data flow or a commitment instruction, TM-I causes its current transaction ID to be sent with the message. The reason for this is that a new transaction ID might have been generated at TM-I if a communications failure had occurred between TM-I and another system during the commit operation.
- A return is sent to the application program (A) to indicate that the transaction is complete at agent TM-A. The return is delayed until after the next message is received because a new transaction ID must be received from TM-I before the next transaction can be started by application A.