HP 3000 Manuals HP 3000 Manuals
Logical Transactions
A Definition
TurboIMAGE/XL logging and recovery (via DBRECOV) provide the ability to
restore the database to a consistent state after a system failure. To
understand how this is done, it is important to understand the concept of
a logical transaction. A logical transaction is a sequence of one or
more procedure calls that are considered one logical unit of work. Table
7-1 describes the types of logical transactions: static, multiple
database, and dynamic.
Table 7-1. Types of Logical Transactions
--------------------------------------------------------------------------------------------
| | |
| Transaction | Definition |
| | |
--------------------------------------------------------------------------------------------
| | |
| Static | A logical transaction that begins with a DBBEGIN call and ends |
| | with a DBEND call. A static transaction spans only one database |
| | and uses DBBEGIN mode 1 and DBEND mode 1 or 2. |
| | |
--------------------------------------------------------------------------------------------
| | |
| Multiple database | A logical transaction that begins with a DBBEGIN mode 3 or 4 |
| | call and ends with a DBEND mode 3 or 4 call. A multiple |
| | database transaction spans more than one database and can be |
| | recovered with roll-back or roll-forward recovery. |
| | |
| | Programmers may be tempted to call DBBEGIN twice (once for each |
| | database), update both databases, and then call DBEND twice in |
| | an attempt to implement this capability. However, a system |
| | failure during the "window" between the two final calls to DBEND |
| | will result in the recovery of the transaction for the first |
| | database and its suppression on the second. To perform a |
| | transaction accessing multiple databases, use a multiple |
| | database transaction. |
| | |
--------------------------------------------------------------------------------------------
| | |
| Dynamic | A logical transaction that begins with a DBXBEGIN call and ends |
| | with a DBXEND call. A dynamic transaction spans only one |
| | database. A call to DBXUNDO or a program abort will cause a |
| | dynamic transaction to be rolled back dynamically. If a system |
| | failure occurs, the dynamic transaction will be rolled back at |
| | the first call to DBOPEN for the database after the system is |
| | restarted. However, in the event of a media failure, DBRECOV |
| | roll-forward recovery can be used on dynamic transactions as |
| | long as user logging has first been enabled. |
| | |
--------------------------------------------------------------------------------------------
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.)
Figure 7-1 illustrates the concept of a logical transaction using a
static and a dynamic transaction. Note that a transaction block is also
illustrated. A transaction block consists of all transactions between a
call to DBOPEN and a call to DBCLOSE. For further information about
transaction blocks, refer to "FILE Command" later in this chapter.
![[]](../../pic3k/M012332/FFN333c50.gif)
Figure 7-1. Transactions and Transaction Blocks
Locking Requirements for Logical Transactions
DBRECOV requires that all multiple-intrinsic database transactions
execute independently of all other transactions. Transaction
independence within the database can be ensured in a user program by
locking data before a transaction and then releasing locks after a DBEND
or DBXEND is called, thus eliminating the possibility of another user
modifying the same data at the same time. The following example may
clarify the need for locking data to be modified.
Suppose transaction A consists of adding two records to the database that
are later modified by transaction B. Transaction B is dependent upon
transaction A, because the records must exist before they can be
modified. Recall that a transaction is defined as a sequence of one or
more modifications that transfer the database from one consistent state
to another. A database may be in an inconsistent state during a
transaction. Therefore, if transactions A and B are executing
concurrently without locking, transaction B may be viewing the database
in an inconsistent state and consequently could be generating invalid
results. However, if transaction A locks the data and completes
properly, this problem is avoided because transaction B cannot access the
data until transaction A has released its locks.
A second problem due to inadequate locking affects suppression of
transactions by the recovery system (see Figure 7-2 ). Suppose
transaction A intends to add six records to the database, and after
adding three records, transaction B is executed by another process.
Transaction B concurrently modifies one of the records added by
transaction A and then completes. Suppose that at this time, the system
fails and recovery is executed. Because transaction A failed to
complete, all of its record additions are suppressed. Because
transaction B is dependent upon the suppressed transaction A, it cannot
be recovered. DBRECOV is forced to suppress transaction B, even though
it successfully completed during real-time processing. This potential
problem could be avoided if transactions modifying the database employ
locking correctly. Transactions attempting to access the same data
concurrently are serialized by the locking mechanism.
Locking and Transaction Interdependence.
To maximize the extent of recovery, locking should be used with logging
to eliminate interdependence of concurrent static and multiple database
transactions. Locking by logical transaction (that is, DBBEGIN and DBEND
or DBXBEGIN and DBXEND) guarantees the logical consistency of the
database. For roll-back recovery, locking by logical transaction ensures
that all incomplete transactions are backed out of the database. For
roll-forward recovery, transaction locking is recommended.
![[]](../../pic3k/M012332/FFN343c50.gif)
Figure 7-2. Suppression of Transactions Due to Inadequate Locking
Locking Examples.
Examples of the two recommended locking schemes follow:
Single Lock Strategy
DBLOCK for account 2,18,34 Lock should precede DBBEGIN call.
DBBEGIN
DBGET data for account 2
DBPUT data for account 34
DBGET data for account 18
DBDELETE data for account 18
DBEND
DBUNLOCK for all accounts DBUNLOCK must be last call.
Multiple Lock Strategy
DBLOCK account 2,34
DBBEGIN
DBGET data for account 2
DBUPDATE data for account 2
DBPUT data for account 34
DBLOCK for account 18
DBGET data account 18
DBDELETE data account 18
DBEND
DBUNLOCK for all accounts DBUNLOCK must be last call.
CAUTION Use caution when employing a multiple lock strategy requiring
Multiple RIN (Resource Identification Number) capability, also
known as MR capability; refer to appendix D for information.
Hewlett-Packard does not accept responsibility for possible
deadlocks or system lockouts that could result from improper use
of the MR capability.
In the first example above, calling DBLOCK before DBBEGIN makes the
transaction shorter in duration. The recommendation is to call DBLOCK
first, because there is no way of knowing how long DBLOCK will have to
wait to acquire the lock after the transaction has begun. For additional
locking information, refer to "Using the Locking Facility" in chapter 4.
Locking and Dynamic Transactions.
Because dynamic transactions can be rolled back by calling DBXUNDO and
are automatically rolled back in case of a system failure or program
abort, TurboIMAGE/XL requires that a dynamic transaction be independent
of all other transactions. When the database is opened in access mode 3
or 4, transaction independence is guaranteed because the program is the
only modifier of the database.
[REV BEG]
When the database is opened in access mode 1, dynamic transactions
require the programmer to use strong locking. A call to DBUNLOCK must
occur after the call to DBXEND. Failure to follow this sequence after a
call to DBPUT, DBDELETE, or DBUPDATE will cause an error. Intrinsic
calls within the dynamic transaction must have covering locks. If an
error is returned indicating the failure of the intrinsic, the status
condition must be checked before proceeding further or rolling back the
entire transaction.[REV END]
As with nondynamic transactions, the placement of DBLOCK calls either
before or after DBXBEGIN is up to the programmer. A program with
Multiple RIN (MR) capability can apply multiple locks with a dynamic
transaction. MR capability is described in appendix D.
Dynamic transactions are not allowed when a database is opened in mode 2,
because mode 2 does not enforce locking or guarantee transaction
independence.
An example of strong locking follows:
DBLOCK for account 2,18,34 Lock should precede DBXBEGIN call.
DBXBEGIN
DBGET data for account 2
DBPUT data for account 34
DBGET data for account 18
DBDELETE data for account 18
DBXEND
DBUNLOCK for all accounts DBUNLOCK must follow DBXEND call.