Scalable Database Server, HiRDB Version 8 Description

[Contents][Glossary][Index][Back][Next]

8.2.1 Overview of recovery-unnecessary front-end servers

When an error in a unit that contains a front-end server causes the front-end server to terminate abnormally, transactions that were being executed by that front-end server may remain uncommitted. Transactions in uncommitted status maintain an exclusive hold on the database, restricting access to and updating of that locked portion of the database. Normally, the front-end server error must be cleared and the server restarted to commit the uncommitted transactions. However, if a front-end server that is terminated abnormally is a recovery-unnecessary front-end server, HiRDB automatically commits its uncommitted transactions. You can then you use another front-end server or back-end server to resume processing on the database. A unit that contains a recovery-unnecessary front-end server is called a recovery-unnecessary front-end server unit. Figure 8-12 shows the operation with and without using a recovery-unnecessary front-end server.

Figure 8-12 Operation with and without using a recovery-unnecessary front-end server

[Figure]

Note that HiRDB Non Recover FES must be installed in order to use recovery-unnecessary front-end servers.

Application criteria
This feature enables the front-end servers that remain after an error to resume online operations without the erroneous front-end server having to be restarted. It is recommended that this feature be used with systems that require continuous, 24-hour per day operation.

Specification method
To use a recovery-unnecessary front-end server, specify stls in the -k option of the pdstart operand.