TurboIMAGE/XL Database Management System Reference Manual (30391-90012)

316 Chapter7
Logging and Recovery
Logical Transactions
If logging is specified and DBBEGIN/DBEND (static transactions) or DBXBEGIN/DBXEND
(dynamic transactions) are not used, TurboIMAGE/XL considers each DBPUT, DBDELETE,
and DBUPDATE to be a single logical transaction. While a transaction is executing, the
database is considered to be in an inconsistent state. Thus, each transaction takes the
database from one consistent state to another.
For example, consider the manual master data set CUSTOMER in the ORDERS database,
with the addition of a new field, YTDSALES, indicating the total value of the year-to-date
sales for each customer. A one-step transaction might involve updating a particular
customer's address. Adding a new sales item is a two-step transaction: adding an entry to
the SALES detail data set and updating the YTDSALES item in the CUSTOMER master
set. The database is consistent before the transaction begins because the YTDSALES
value corresponds exactly with the sum of the TOTAL values in the SALES detail set that
are chained to that particular customer's account number. However, after the first
modification, which might be adding the new SALES entry, this correspondence no longer
holds, so the database is said to be inconsistent. After the second step, modifying the
YTDSALES item in the CUSTOMER data set, the database is returned to a consistent
state.
If the system fails while the database is being modified, database integrity could be
affected. Logical inconsistency could result if the failure occurs between modifications of a
multiple- step transaction, as illustrated by the example in the preceding paragraph.
Secondly, if AUTODEFER is enabled, structural damage (such as, broken chains) can result if
the failure occurs during the execution of a TurboIMAGE/XL intrinsic.
Because the recovery system is designed to restore the database to a consistent state, those
modifications belonging to transactions that failed to complete due to a system failure are
suppressed by the recovery system. Consequently, although one or more database
modifications may be lost upon recovery, the resulting database will be consistent. To this
end, each user application should indicate the beginning and end of each transaction by
using a DBBEGIN and DBEND pair or a DBXBEGIN and DBXEND pair. (Refer to chapter 4 for
more information on transactions.)
Unlike a dynamic transaction for one database, DMDBX requires that a DBCONTROL
mode 7 be done once for every database you want to include in a DMDBX, after
DBOPEN of that database and before using it in the DBXBEGIN intrinsic. DBCONTROL
mode 7 enables the database for deadlock detection, which when encountered,
returns an error 26 instead of triggering a process hang.
If the calling process is logging, DBXBEGIN, DBXEND, and DBXUNDO cause a log
record to be written to the log file to identify the beginning, end, and roll-back,
respectively, of a dynamic transaction. For DMDBX, logging should be either
disabled or enabled for all databases involved in the DMDBX. In addition, if logging
is enabled, the same logid needs to be used for all databases in the DMDBX as well.
In case of DMDBX when logging is enabled, multiple log records, one for each
database, will be written to the log file.
Table 7-1. Types of Logical Transactions
Transaction Definition