2.2.7 Operands related to transaction decision processing
- 27) pd_trn_rerun_branch_auto_decide = Y | N
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies whether an undecided transaction that has branched from a transaction is to be decided automatically if a unit terminates abnormally before the first prepare processing for transaction commitment control is completed.
- Y:
- Decide undecided transactions automatically.
- N:
- Do not decide undecided transactions automatically. In this case, the HiRDB administrator must make the decision for an undecided transaction. For details about how to decide an undecided transaction, see the HiRDB Version 9 System Operation Guide.
- Notes
- Note the following when Y is specified or when specification of this operand is omitted:
- If the reduced activation facility is used, transactions on a unit that is not running at the time of reduced activation are not subject to automatic decision. Therefore, when you restart a unit that was not running during reduced activation, such as after error recovery, check for any undecided transactions. Any undecided transactions that exist must be decided. For details about how to check for undecided transactions and how to decide them, see the HiRDB Version 9 System Operation Guide.
- The volume of system log information at the server where the branching-source transaction resides will increase.
- While an undecided transaction is being decided, write-protection is applied to the system log at the server where the branching-source transaction resides.
- 28) pd_trn_send_decision_intval_sec = transmission-retry-interval-in-seconds-for-automatic-transaction-decision
- ~<unsigned integer>((0-65535)) <<15>> (seconds)
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies the interval (in seconds) for sending an automatic decision instruction to a branched transaction when the previous send operation has failed, for example, due to a communication error.
- Condition
- Y must be specified in the pd_trn_rerun_branch_auto_decide operand, or the pd_trn_rerun_branch_auto_decide operand must be omitted.
- Notes
- Specifying 0 increases the communication workload, because the decision instruction is resent continuously.
- Relationships to other operands
- This operand has the following relationships with the pd_trn_send_decision_interval operand:
- To specify the time before re-transmission in seconds, use the pd_trn_send_decision_intval_sec operand; to specify it in minutes, use the pd_trn_send_decision_interval operand.
- If the pd_trn_send_decision_intval_sec and the pd_trn_send_decision_interval operands are both specified, the pd_trn_send_decision_intval_sec operand takes precedence.
- 29) pd_trn_send_decision_interval = transmission-retry-interval-in-minutes-for-automatic-transaction-decision
- ~<unsigned integer>((0-65535)) (minutes)
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies the interval (in minutes) for sending an automatic decision instruction to a branched transaction when the previous send operation has failed, for example, due to a communication error. Normally, you will specify the pd_trn_send_decision_intval_sec operand and omit this operand.
- Condition
- Y must be specified in the pd_trn_rerun_branch_auto_decide operand, or the pd_trn_rerun_branch_auto_decide operand must be omitted.
- Notes
- Specifying 0 increases the communication workload, because the decision instruction is resent continuously.
- Relationships to other operands
- This operand has the following relationships with the pd_trn_send_decision_intval_sec operand:
- To specify the time before re-transmission in seconds, use the pd_trn_send_decision_intval_sec operand; to specify it in minutes, use the pd_trn_send_decision_interval operand.
- If the pd_trn_send_decision_intval_sec and the pd_trn_send_decision_interval operands are both specified, the pd_trn_send_decision_intval_sec operand takes precedence.
- If the pd_trn_send_decision_intval_sec and the pd_trn_send_decision_interval operands are both omitted, the default value of the pd_trn_send_decision_intval_sec operand is assumed.
- 30) pd_trn_send_decision_retry_time = maximum-wait-time-for-transaction-auto-decision
- ~<unsigned integer>((0-65535)) <<360>> (minutes)
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies the maximum amount of time to wait for a decision completion response to be returned after an automatic decision instruction has been sent to a branched transaction. If no decision completion response is returned within the amount of time specified here, it is assumed that an unrecoverable error (such as a communication error) has occurred, the decision instruction to the branched transaction is canceled, and the branching-source transaction is decided.
- When 0 is specified for this operand, time monitoring is not performed.
- Notes
- Y must be specified in the pd_trn_rerun_branch_auto_decide operand, or the pd_trn_rerun_branch_auto_decide operand must be omitted.
- 31) pd_trn_watch_time = maximum-communication-wait-time-during-transaction-synchronization-point-processing
- ~<unsigned integer>((0, 300-65535)) <<3600>> (seconds)
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies the maximum amount of time to wait for receiving communication (prepare, commit request, or completion communication) between transaction branches during transaction synchronization point processing executed in the HiRDB server process. If no request or completion communication is received within the specified time, the applicable transaction is rolled back if it has not completed the first phase of a two-phase commit. If the first phase has already been completed, the requested processing is performed and the transaction is completed. For details about communications between transactions, see Commit and rollback in the manual HiRDB Version 9 Description.
- Advantage
- Even when a HiRDB client halts the transaction determination instruction (by forcibly terminating a client process, for example), the transaction execution continues unless it is stopped by the HiRDB server. Consequently, locked resources in a database, for example, might be monopolized for a long time. Specifying this operand can shorten the time during which locked resources are monopolized.
- Specification guidelines
- Normally, you need not specify this operand. Specify it in the following cases:
- The KFPA11989-E or KFPA11722-E message is output during commit.
- Processing of a COMMIT statement takes a long time, even though the number of database updates in the transaction is small.
- Operand rules
- If 0 is specified, HiRDB waits indefinitely for a prepare and commit request or completion communication.
- If a value between 1 and 299 is specified, it is rounded up to 300.
- Note
- For the commit request or completion communication in the second phase of a two-phase commit, the value specified for this operand takes effect only if pd_dbsync_point=commit is specified.
- 32)pd_trn_rcvmsg_store_buflen = transaction-recovery-message-queue-size
- ~<unsigned integer> ((4096-25600000))<<8192>> (bytes)
- 0904 compatibility mode: ((4096-25600000))<<4096>>
- When HiRDB performs transaction recovery processing, it registers the transaction to be recovered in the transaction recovery message queue. This operand specifies the transaction recovery message queue size.
- Specification guidelines
- Normally, there is no need to specify this operand.
- If the KFPS00854-W message (server=_trnrcv) is issued during HiRDB operation, consider specifying this operand. The formula for estimating the value to specify is shown below. If the estimated value is less than or equal to the default value, specify the default value.
For a HiRDB single server configuration
72
A
1,024![[Figure]](figure/zueng010.gif)
1,024 (bytes)
For a HiRDB parallel server configuration
72
(B + C + D + E)
1,024![[Figure]](figure/zueng010.gif)
1,024 (bytes)
A: (pd_max_users operand value + pd_max_reflect_process_count operand value)
2 + 7
B:
If the unit contains FES: b
2 + 7
b:
For multi-FES: pd_max_users operand value + pd_max_reflect_process_count operand value + 1
For non-multi-FES: pd_max_users operand value + pd_max_reflect_process_count operand value
If the unit contains no FES: 0
C:
If the unit contains a BES (if there are multiple BESs, add the values for individual BESs):
(MAX(pd_max_bes_process operand value, pd_max_users operand value) + pd_max_reflect_process_count operand value)
2 + 7
If the unit contains no BES: 0
D:
If the unit contains a DS:
(MAX(pd_max_dic_process operand value, pd_max_users operand value) + pd_max_reflect_process_count operand value)
2 + 7
If the unit contains no DS: 0
E:
If the standby-less system switchover (effects distributed) facility is used:
((MAX(largest pd_max_bes_process operand value in all guest BESs, pd_max_users operand value) + pd_max_reflect_process_count operand value)
2 + 7)
pd_ha_max_act_guest_servers operand value
If the standby-less system switchover (effects distributed) facility is not used: 0
- Notes
- If a value greater than the default value is specified in this operand, the shared memory size for unit controllers increases. For details, see Formulas for shared memory used by a unit controller in the HiRDB Version 9 Installation and Design Guide.
- If a value greater than the default value is specified in this operand, the maximum number of transaction recovery processes (pdtrnrvd) increases. The following formula shows how to determine the maximum number of pdtrnrvds.
For a HiRDB single server configuration
MIN(transaction recovery message queue size
72, (pd_max_users operand value + pd_max_reflect_process_count operand value)
2 + 7)
For a HiRDB parallel server configuration
MIN(transaction recovery message queue size)
72, A + B + C + D)
A:
If the unit contains a FES: a
2 + 7
a:
For multi-FES: pd_max_users operand value + pd_max_reflect_process_count operand value + 1
For non-multi-FES: pd_max_users operand value + pd_max_reflect_process_count operand value
If the unit contains no FES: 0
B:
If the unit contains a BES: (MAX(pd_max_bes_process operand value, pd_max_users operand value) +pd_max_reflect_process_count operand value)
2 + 7
If the unit contains no BES: 0
C:
If the unit contains a DS: (MAX(pd_max_dic_process operand value, pd_max_users operand value) + pd_max_reflect_process_count operand value)
2 + 7
If the unit contains no DS: 0
D:
If the standby-less system switchover (effects distributed) facility is used:
((MAX(largest pd_max_bes_process operand value in all guest BESs, pd_max_users operand value) + pd_max_reflect_process_count operand value)
2 + 7)
pd_ha_max_act_guest_servers operand value
If the standby-less system switchover (effects distributed) facility is not used: 0
- Relationship to other operands
- This operand is related to the pd_max_server_process operand.
- 33) pd_trn_commit_optimize = ONEPHASE | NOUSE
- This operand is applicable only to a HiRDB parallel server configuration.
- Specifies whether to use one-phase commit in a HiRDB parallel server configuration's commitment control. For details about one-phase commitment, see the manual HiRDB Version 9 Description.
- ONEPHASE:
- Uses one-phase commit for commitment control when the number of branches to be updated within a transaction is one (the number of servers to be updated by one transaction is one). Note that using one-phase commit in commitment control is called one-phase optimization.
- NOUSE:
- Uses two-phase commit for commitment control. One-phase commit is not used.
- Specification guideline
- Normally specify ONEPHASE or omit this operand.
- Notes
- Specification of this operand is invalid if an OLTP system has specified two-phase commit.
- If a recovery-unnecessary front-end server is used, the restrictions on this front-end server takes precedence over the specification for this operand. These restrictions are described below.
The log to be output to a front-end server is suppressed.
In a recovery-unnecessary front-end server, a UAP that uses the X/Open XA interface to make connection cannot be executed.
- 34) pd_trn_rollback_watch_time = maximum-wait-time-for-rollback-completion-response[,rollback-instruction-resending-limit-time]
- This operand is applicable only to a HiRDB parallel server configuration.
- This operand only takes effect if Y is specified in the pd_trn_rerun_branch_auto_decide operand or the operand is omitted.
- The monitoring target is the UAP for which 0 or nothing is specified for PDCWAITTIME in the client environment definition.
- maximum-wait-time-for-rollback-completion-response: ~<unsigned integer>((0-65535))<<3600>> (seconds)
- Specifies the maximum amount of time for the front-end server to wait for receiving a rollback completion response from a back-end server or a dictionary server. If no response is received within the specified time, the rollback instruction is resent to the corresponding back-end server or dictionary server.
- Specification guidelines
- Normally, there is no need to specify the maximum time to wait for rollback completion response. If your system requires that transactions be decided within 3,600 seconds, specify the maximum time (in seconds) to wait before a transaction is decided, taking into account a situation where transactions cannot be decided.
- Notes
- If 0 or nothing is specified for the maximum time to wait for rollback completion response, no rollback instruction is resent.
- If a value from 1 to 9 is specified for the maximum time to wait for rollback completion response, the value is automatically rounded up to 10 seconds.
- rollback-instruction-resending-limit-time: ~<unsigned integer> ((0-65535))<<600>> (seconds)
- Specifies the interval at which the resending of rollback instruction is to repeated if the resending of rollback instruction fails.
- If a rollback completion response is not received from the back-end server or the dictionary server within the maximum time to wait for rollback completion response, the front-end server resends the rollback instruction to the corresponding server. If the resending fails, the front-end server keeps resending the rollback instruction until the rollback instruction resending limit time is reached.
- If the resending is still not successful when the rollback instruction resending limit time is reached, the KFPS00936-E message is issued, the front-end server process terminates abnormally, and then the transaction is canceled.
- Specification guidelines
- Normally, there is no need to specify the rollback instruction resending limit time. If your system requires that transactions be decided within 600 seconds, specify the maximum time (in seconds) to wait before a transaction is decided, taking into account a situation where the resending of rollback instruction keeps failing.
- To send a response to a UAP in the event of a communication failure, maximum time to wait for rollback completion response + rollback instruction resending limit time is required. Take this into account when specifying the value.
- Notes
- If a value from 1 to 239 is specified for the rollback instruction resending limit time, the value is automatically rounded up to 240 seconds.
- The following figure shows the scope of this operand.
![[Figure]](figure/zu020245.gif)