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

Chapter 4 121
Using the Database
Using the Locking Facility
entries. At system design time, a compromise must be made between the benefits of
low-level locking and the extra programming effort required.
Data entry locking should give the best concurrency; however, there are situations in
which the extra programming effort for data entry locking is not worthwhile. Concurrency
is least optimum at the higher level of the lock. Concurrency and programming effort
should be considered; some other considerations that could affect your choice of locking
level are discussed below.
Locking at the Same Level
All programs concurrently accessing a database should lock at the same level most of the
time. For example, one process locking a data set will hold up all other processes that are
attempting to lock entries in that set. Therefore, the attempt by the process locking at the
data entry level to allow other processes to share the database is nullified by the process
locking at the data set level and the effect is as if all processes were locking at the data set
level. The rule of locking at the same level can be violated for infrequent operations such
as exception handling or rare transactions.
Length of Transactions
Generally, the longer the lock is to be held, the lower the level it should be. In other words,
if you are performing lengthy transactions, you should probably lock at the entry level. For
shorter transactions, you can use locks at either the database or data set level with
satisfactory results.
An extreme case of a long transaction is one in which user dialog takes place while a lock is
held. For example, a program can read some data entries, interact with a terminal
operator, and modify some or all of the entries. A lock to cover this transaction can last
several minutes which is an unacceptable amount of time to stop all database or data set
activity. In this situation, data entry level locking should be used.
Because the length of different transactions varies, the longest transaction (that is also
frequently used) should guide the choice of locking level.
Locking During User Dialog
In the situation described above, where a lock is held during interactive dialog with a
terminal operator, the terminal time-out feature of MPE/iX can be used to avoid having the
locked entity inaccessible when the terminal operator is interrupted in the middle of the
dialog. The time-out feature can be used to cause the terminal read to terminate
automatically if no response is received within a certain time period. Refer to the
discussion of "FCONTROL" in the MPE/iX Intrinsics Manual.
Strong Locking and Dynamic Transactions
Dynamic transactions, which are described later in this chapter, are only allowed with a
database access mode that enforces locking, because strong locking is required for this type
of transaction. TurboIMAGE/XL requires that dynamic transactions be independent of all
other types of transactions. This is guaranteed when the database access mode is 3 or 4,
because the mode guarantees exclusive modify access.
When a database is opened in access mode 1, the programmer must ensure that strong
locks are in place. In other words, any call to DBUNLOCK must occur after the call to DBXEND,