25.19 Transaction queuing facility

You can use the transaction queuing facility while using the rapid system switchover facility or the standby-less system switchover facility on a HiRDB/Parallel Server.

Organization of this section
(1) About the transaction queuing facility
(2) Setting up the environment
(3) Transactions that are subject to queuing
(4) Notes

(1) About the transaction queuing facility

When system switchover occurs in a unit for a back-end server or dictionary server, the back-end server or dictionary server cannot accept any transactions until system switchover is completed. This means that any transaction to be processed by the back-end server or dictionary server while the system switchover is in progress results in an error.

The function called the transactions queuing facility queues transactions on the front-end server until system switchover is complete without causing errors for these transactions. This makes it possible to reduce the number of transaction errors occurring during system switchover. Figure 25-78 provides an overview of the transaction queuing facility.

Figure 25-78 Overview of the transaction queuing facility

[Figure]

* In the case of standby-less system switchover:

Explanation
An error has occurred in the unit for a back-end server and system switchover has occurred. Transactions are queued until the unit in the standby system has been activated, then transaction processing resumes.
Remarks
  • Transactions for execution by a unit that was not switched (did not cause an error) are not queued. These transactions are executed as usual.
  • Using multiple front-end servers makes it possible to reduce transaction errors when system switchover occurs for units for front-end servers. In such a case, only the transaction in progress when an error occurs results in an error.

(2) Setting up the environment

Use of the rapid system switchover facility on a HiRDB/Parallel Server is assumed. The operands explained in Table 25-54 are specified to use the transaction queuing facility.

Table 25-54 Operands specified to use the transaction queuing facility

OperandDescription
pd_ha_transactionSpecifies that the transaction queuing facility is to be used.
When NO is specified in the PDHATRNQUEUING operand in the client environment definition, the UAP executed by the HiRDB client is not subject to the transaction queuing facility. For details about the PDHATRNQUEUING operand, see the manual HiRDB Version 8 UAP Development Guide.
pd_ha_trn_queuing_wait_timeSpecifies the queuing wait time for transactions. If the unit in the standby system is not activated before the wait time specified in this operand expires, transactions currently being queued result in an error. Any subsequent transactions result in an error and are not queued.
pd_ha_trn_restart_retry_timeIf system switchover occurs while the transaction queuing facility is being used, transactions are queued on the front-end server. However, the front-end server cannot detect system switchover until the unit in the standby system restarts. During the time from when system switchover occurs until the time the unit in the standby system restarts, the front-end server continues to request that the unit in the running system start transactions. However, such transaction startup requests result in errors because the unit in the running system has already terminated abnormally. The front-end server retries the transaction startup requests continuously.
A maximum retry time value is specified in this operand. If the unit in the standby system has not restarted by the time the value specified in this operand is reached, transactions currently being retried result in an error. All subsequent transactions result in an error also and are not retried. Figure 25-79 shows the relationship between the pd_ha_trn_queuing_wait_time operand and the pd_ha_trn_restart_retry_time operand.

Figure 25-79 Relationship between the pd_ha_trn_queuing_wait_time operand and the pd_ha_trn_restart_retry_time operand

[Figure]

* For standby-less system switchover:

Explanation
Intervals A and D:
Transactions can be started (normal status).
Interval B:
The back-end server unit is performing system switchover but the front-end server cannot detect that system switchover is in progress. A transaction startup request is retried until the amount of time specified in the pd_ha_trn_restart_retry_time operand is reached. When the front-end server detects system switchover, the transaction is queued. If system switchover is not detected before the specified amount of time is reached, the transaction results in an error.
Interval C:
The back-end server unit is performing system switchover but the front-end server cannot detect that system switchover is in progress. The transaction is queued until the amount of time specified in the pd_ha_trn_queuing_wait_time operand is reached. If the transaction cannot be started before this amount of time is reached, the transaction results in an error.

(3) Transactions that are subject to queuing

Transactions generated by an SQL extension are subject to queuing. However, transactions generated by definition SQL and transactions using the holdable cursor facility are not subject to queuing. The following transactions not subject to queuing:

However, depending on the timing, some of these transactions may be queued.

(4) Notes

(a) Interval monitoring operands

The transaction queuing time is the maximum value that is equal to the sum of the value of the pd_ha_trn_queuing_wait_time operand (default: 180 seconds) and the value of the pd_ha_trn_restart_retry_time operand (default: 60 seconds). Therefore, be sure to take careful note of the values for the following operands.

The time required for system switchover is determined by calculating the difference between the time the cluster software outputs the system switchover startup message to syslogfile and the time it outputs the system switchover completion message to syslogfile. One of the messages listed below is output when system switchover starts:

The KAMN311-I message is output when system switchover is completed.

(b) Notes on using lists

Caution is urged if system switchover occurs while a search using a list is underway. A list created by a unit before system switchover occurred is deleted when system switchover occurs on a back-end server or a dictionary server. Therefore, a search that uses a list (queued transactions) will result in an error after system switchover occurs. In such a case, either delete or re-create the list.

(c) Maximum number of concurrent connections (value of the pd_max_users operand)

Because a larger number of users than usual is waiting to perform processing while transactions are being queued, the maximum number of concurrent connections (value of the pd_max_users operand) may be exceeded. If this occurs, no additional users will be able to connect to the front-end server, and processes for connecting to the front-end server will be retried. These processes will be retried only for the amount of time equal to the sum of the values specified in the pd_ha_trn_queuing_wait_time and pd_ha_trn_restart_retry_time operands.

(d) UAPs that cannot connect to HiRDB during system switchover

UAPs cannot connect to HiRDB during system switchover in the situations listed below:

In these cases, the UAP uses the automatic reconnect facility to retry connecting to HiRDB. If system switchover is completed during the retry interval, the UAP will connect successfully to HiRDB. For details about the automatic reconnect facility, see the manual HiRDB Version 8 UAP Development Guide.

(e) When the BES connection holding facility is used

For notes on using the BES connection holding facility, see E.1(3)(c) Setting the maximum client wait time.