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

118 Chapter4
Using the Database
Using the Locking Facility
With the exception of compound items, any data item can be used in a lock descriptor; that
is, the lock item need not be a search item.
TurboIMAGE/XL does not require that you have read or write access to a data set or data
item in order to specify it in a lock request.
A process can specify any number of lock descriptors with a single DBLOCK call. For
example, the following lock descriptors can be specified in one DBLOCK call:
CUSTOMER: ACCOUNT = 89393899
SALES: ACCOUNT = 89393899
SUP-MASTER: STATE = AZ
INVENTORY: ONHANDQTY <= 100
INVENTORY: ONHANDQTY >= 1500
NOTE Multiple calls to DBLOCK without intervening calls to DBUNLOCK are not
allowed unless the program has Multiple RIN (MR) capability. Refer to
"Issuing Multiple Calls to DBLOCK" later in this chapter.
How Locking Works
The internal implementation of locking does not involve reading or writing to the database
element to be locked. TurboIMAGE/XL keeps a table of everything that is locked by all
processes that have the database opened. One table is associated with each database. This
table serves as a global list of lock descriptors. In locking mode 5 or 6, a database lock is
specified with the descriptor @:@ and a data set lock with dset:@. If you call DBLOCK in
locking mode 1, 2, 3, or 4, TurboIMAGE/XL sets up the appropriate lock descriptor and
puts it in the lock descriptor table. Figure 4-3. illustrates the contents of this list in a
situation where one process has locked all SALES data entries with ACCOUNT equal to
12121212 or equal to 33334444. Another process has locked all INVENTORY data entries
with STOCK# equal to 6650D22S. A third process has locked the whole SUP-MASTER
data set. The figure illustrates what the table represents, not the actual internal format.
When a lock request is made, TurboIMAGE/XL compares the newly specified lock
descriptors with those that are currently in the list. If a conflict exists, TurboIMAGE/XL
notifies the calling process that the entity cannot be locked or, if the process has requested
unconditional locking, it is placed in a waiting state until the entity can be locked. If there
are no conflicts, TurboIMAGE/XL adds the new lock descriptors to the list.
Users whose programs have MR capability and issue multiple DBLOCK calls, without a
DBUNLOCK call between the DBLOCK calls, may cause a deadlock if DBLOCK calls are not done
carefully. Recovery from a deadlock requires a restart of the operating system. If it is
desired to activate the database for automatic deadlock detection, DBCONTROL mode 7 must
be done prior to the first DBLOCK call for the database. In this case, when a possibility of a
potential deadlock is detected by the DBLOCK procedure, a status code of 26 is returned to
the calling process. The calling process must call DBUNLOCK to release all locks acquired by
DBLOCK(s) for the same access path.