Vote reliable is an optimization that improves performance by returning earlier to the initiator application after a commit operation and eliminating one message during a commit operation.
There is no explicit vote reliable optimization for DRDA® distributed unit of work over TCP/IP. However, i5/OS™ never requests a reset (forget) confirmation for TCP/IP connections. Therefore, a reset (forget) is always implied for TCP/IP connections.
After you start commitment control, you can use the Change Commitment Options (QTNCHGCO) API to change the Accept vote reliable option to Y.
Vote reliable can be thought of as a promise by an agent to its initiator that no heuristic decisions will be made at the agent if communications failure occurs while the agent is in doubt. An agent that is using the vote reliable optimization sends an indicator to the initiator during the prepare wave of the commit. If the initiator is also using the vote reliable optimization, it then sends an indicator to the agent that no reset is required in response to the commit message. This eliminates the reset message, and allows the transaction manager to return to the application at the initiator as soon as the commit message is sent.
Consider using the vote reliable optimization if the following conditions are true:
- It is unlikely that a heuristic decision will be made at an in doubt agent in the event of a systems or communications failure unless the failure cannot be repaired.
- Your program logic does not need the results of previous transactions to ensure that your database files remain synchronized.
The vote reliable optimization is used by i5/OS only if all the following conditions are true:
- The initiator and agent locations support the presumed abort level of commitment control.
- The initiator location accepts the vote reliable
indication from the agent. On i5/OS initiators, this depends on the value
of two commitment options:
- The value of the Wait for outcome commitment option must be No (Yes is the default).
- The value of the Accept vote reliable commitment option must be Yes (Yes is the default).
- The agent location votes reliable during the prepare wave. i5/OS agents always vote reliable. This is because heuristic decisions can be made only through a manual procedure that warns of the possible negative side-effects of making a heuristic decision.
Flow of commit processing with vote reliable optimization
The following figure shows the flow of messages among the application programs and the transaction managers when the vote reliable optimization is used. 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.
The following list describes the events for normal processing without last agent optimization when the agent votes reliable. 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.
- The agent (TM-A) responds to the initiator (TM-I) with a request commit message. i5/OS systems send a vote reliable indicator with the request commit.
- When the initiator (TM-I) receives all the votes, the TM-I sends a commit message. If the Wait for outcome commitment option is N (No) and the Accept vote reliable commitment option is Y (Yes), a no reset indicator is sent with the commit message. This tells the agent that no reset message is required in response to the commit.
- The transaction is complete. A return is sent to the application programs (I and A). This return indicates that the commit operation was successful. If a heuristic damage occurs at system A due to a heuristic decision being made before the committed message is received, application I is not informed. Instead, a message is sent to the QSYSOPR message queue. However, application A receives the heuristic damage indication.
- The next time the agent (TM-A) sends any message to the initiator (TM-I), either a data flow or a commitment instruction, an implied reset indicator is sent with the message to inform TM-I that TM-A completed the commit successfully. The reason for this is that TM-I must retain information about the completed transaction until it has confirmed that TM-A successfully received the commit message in step 7