HP 3000 Manuals HP 3000 Manuals
Dynamic Roll-Back Recovery
[REV BEG]
Dynamic roll-back allows a more timely recovery of databases than is
possible with DBRECOV. Dynamic roll-back eliminates the overhead incurred
when a database is enabled for user logging and permits database access
to continue, even while other users are accessing a database.[REV END]
Using XM, uncommitted logical transactions can be rolled back dynamically
(online) while other database activity is occurring. This is
accomplished through the use of three intrinsics: DBXBEGIN, DBXEND, and
DBXUNDO.
DBXBEGIN and DBXEND mark the beginning and end of the dynamic
transaction. The dynamic transaction can be rolled back in the following
ways:
* Programmatically with a call to DBXUNDO.
* Automatically when the application aborts or a system failure
occurs within the transaction.
[REV BEG]
In any case, those transactions begun after the call to DBXBEGIN that do
not have a corresponding call to DBXEND will be rolled back. When you
use DBXUNDO, your program logic must ensure that it does not call DBXEND
subsequently; otherwise, you will get an error.
Use the following sequence of operations when modifying a database with
dynamic transactions:
1. Call DBLOCK to lock all data that must not be changed by other
processes during the transaction. This includes data to be read
and data to be modified.
2. If you wish, read data using DBFIND and DBGET to determine the
necessary modifications.
3. Call DBXBEGIN to declare the beginning of modifications.
4. Make modifications using DBPUT, DBDELETE, or DBUPDATE.
For every DBPUT, DBDELETE, or DBUPDATE, the status must be checked
before proceeding further. If an error is returned indicating the
failure of the intrinsic, the choices are:
a. Call DBXEND. The successful modifications completed within
this dynamic transaction will not be rolled back.
b. Call DBXUNDO to roll back the entire transaction. Even
successful modifications completed within this dynamic
transaction will be rolled back.
c. Continue with the remainder of the dynamic transaction even
though this intrinsic failed. As the application designer,
you should be very cautious when taking this option as the
final result can be unpredictable.
[REV END]
5. Call DBXEND to declare the end of the modifications. If DBXUNDO
was used to roll back a transaction, your program logic should
ensure that the subsequent call to DBXEND is not processed.
6. Call DBUNLOCK to release all of the locks.
[REV BEG]
Dynamic roll-back requires strong locking as discussed previously under
"Locking and Dynamic Transactions." Calling DBUNLOCK after a call to
DBPUT, DBDELETE, or DBUPDATE within a dynamic transaction will return an
error because the call to DBUNLOCK must occur after the call to DBXEND.
If necessary locks are not acquired before calling DBXBEGIN, covering
locks must be used on the intrinsic calls within the dynamic transaction,
otherwise an error will be returned.
It is essential that you check the status after each intrinsic. If a
database intrinsic fails, you may end the transaction by calling DBXEND
or roll back the entire transaction by calling DBXUNDO. You may be able
to continue with the transaction despite the intrinsic failure, however,
you must account for the intrinsic failure. The outcome varies based on
your application design.
Do not use DBCLOSE mode 1 (close the database) inside an active dynamic
transaction. This use of DBCLOSE will cause your dynamic transaction to
be rolled back, the locks will be released, the database will be closed,
and subsequent use of DBXEND or DBXUNDO will return an error.
If your dynamic transaction is very long causing XM to reach its limit of
the log buffer space allowed per process, it will become a stalled
transaction, and you cannot continue any further. This stalled
transaction will be rolled back and the process is terminated.[REV END]
If the system aborts or TurboIMAGE/XL encounters an internal error, the
active memo records are saved in a file. All of the unrecovered memo
records for a particular database are held in the dbname00 file. It
resides in the same group and account as the database, and each database
has only one dbname00 file. The first DBOPEN of an unrecovered database
initiates the recovery using the dbname00 file.
User logging (discussed later in this chapter) is not required for
dynamic roll-back recovery, but it is recommended to guard against a
media failure.