Enscribe Programmer's Guide

..
LOCKREC: record 1LOCKREC: record 2
Here, process A has record 1 locked and is requesting a lock for record 2, while process B has
record 2 locked and is requesting a lock for record 1.
One possible way to avoid deadlock is to always lock the records in the same order. Thus, this
illustrated situation could never happen if each process requested the lock to record 1 before it
requested the lock to record 2.
Because it is sometimes impossible for an application program to know in which order the records
it must lock are going to be encountered, this approach is worth considering. For updates to single
records of the file, no special processing needs to be done. For an update involving two or more
records, however, the solution is to first lock some designated common record, and then lock the
necessary data records. This prevents deadlock among those processes requiring multiple records,
because they must first gain access to the common record, but still allows maximum concurrency
and minimum overhead for accessors of single records.
File Locking and Record Locking With Unstructured Files
You lock and unlock unstructured files in essentially the same way that you do structured files. You
lock records in unstructured files by positioning the file to the relative byte address of the record
to be locked and then calling the FILE_LOCKREC64_, LOCKREC, FILE_READLOCK64_,
FILE_READUPDATELOCK64_, READLOCK, or READUPDATELOCK procedure. Any other user
attempting to access the file at a point beginning at exactly that address sees the address as being
locked; the action taken is governed by the current locking mode.
NOTE: Only the starting point specified by the relative byte address is locked. Another application
could access part of the record if it specified a relative byte address somewhere else within the
record.
TMF Locking Considerations
When your application is running under the control of TMF, every transaction must lock all of the
records that it updates or deletes. To do so, the transactions can use either file locks or record
locks.
When a process changes an audited database, the disk process imposes these constraints to
prevent other transactions from either reading uncommitted changes or performing conflicting
operations:
• Whenever a transaction inserts a new record into an audited file, the disk process automatically
obtains a lock based on the inserted record's primary-key value. This lock prevents any other
transaction from inserting a record with the same primary-key value as the newly inserted
record, and from reading, locking, updating, or deleting the newly inserted record.
• Before a transaction can update or delete an existing record in an audited file, the transaction
must previously have locked either the record or its file. If the transaction does not do so, the
attempt to update or delete the record is rejected immediately with an error 79.
• The disk process retains all locks on inserted, updated, or deleted records in audited files until
the associated transactions are either committed or aborted and backed out. Note, however,
that for an FILE_UNLOCKREC64_/UNLOCKREC call following a
FILE_READLOCK64_/READLOCK call, the lock is released immediately.
• Transactions should lock all of the records that they read and use in producing output regardless
of whether the transaction modifies the data. Doing so guarantees that the data on which
each transaction depends does not change before the transaction is either committed or
aborted and backed out.
File Locking and Record Locking With Unstructured Files 155