TurboIMAGE/XL Database Management System Reference Manual MPE/iX V6.5 (30391-90011)
120 Chapter4
Using the Database
Using the Locking Facility
Automatic Masters
When adding or deleting entries from a detail data set, you need not have locks covering
the implicit additions or deletions that occur in any associated automatic masters.
Locking Levels
Locking can be viewed as operating on three levels: the whole database, whole data sets, or
data entries. TurboIMAGE/XL allows mixed levels of locking. For example, one user could
be locking data entries and another locking the data set. In this situation, a request to lock
the data set cannot succeed until all the currently locked data entries have been released.
Subsequent requests to lock data entries, those that are made while the data set lock is
pending, are placed in a queue behind the data set lock.
This principle is followed for database locks also. If data set or data entry locks are in effect
at the time a database lock is requested, the database lock must wait until they are
released and all subsequent locking requests must wait behind the pending database lock.
In either case, if the request is for a conditional lock, an exceptional condition is generated.
(Refer to the "Locking Mode Options" table in chapter 5.)
Deciding on a Locking Strategy
It is important, especially for on-line interactive applications, to establish a locking
strategy at application design time. In general, locking is related to the transaction, the
basic unit of work performed against a database. TurboIMAGE/XL transactions are either
single or logical, and logical transactions can be static, multiple database, or dynamic.
Refer to "User Logging and Logical Transactions" later in this chapter for more details and
to chapter 5 for additional information.
Typically a transaction consists of several calls to TurboIMAGE/XL intrinsics to locate and
modify data. For example, a transaction to add a new order with three line items could
require several reads to locate customer information and several DBPUT calls to add the
order detail records.
One characteristic of a transaction is that the data in the database is consistent both
before and after the transaction, but not while it is in progress. For example, a user
reading the detail data set being modiļ¬ed by the above order transaction may only see
some of the line items and may get no indication that the transaction is incomplete. This
type of problem is referred to as logical inconsistency of data and can be prevented by
using the locking facilities.
The general principle that should be applied for any transaction in a shared-access
environment is: At the start of any transaction, establish locks that cover all data entries
that you intend to modify (with
DBPUT, DBDELETE
, or
DBUPDATE
) and/or all data entries
which must not be changed by other processes during the transaction.
Choosing a Locking Level
Because TurboIMAGE/XL needs more information to lock data entries than to lock the
whole database, program complexity tends to increase as locks are employed at lower and
lower levels. Locking the whole database or a single data set is the simplest operation,
followed in increasing order of complexity by locking multiple data sets and locking data