Enscribe Programmer's Guide

By performing heavy activity against an audited database, an application process can generate
a large number of locks and thereby inadvertently create deadlock situations with other application
processes. Therefore, when designing your application, you should consider the coordinated use
of file locks and/or generic record locks among those processes that need access to the same
database.
A TMF transaction is begun by a call to BEGINTRANSACTION and terminated by a call to
ENDTRANSACTION.
Figure 21 illustrates how processes can acquire locks and update audited files and when the disk
process will release the locks.
If the complete set of currently active transactions requires too many locks, the attempt is rejected
with an error 33, 35, or 37.
File locks and record locks are owned by the current transid of the process that issued the lock
request. For example, a single transaction can send requests to several servers or multiple requests
to the same server class. In this situation, where several processes share a common transid and
the locks are held by the same transid, the locks do not cause conflict among the processes
participating in the transaction.
Figure 21 Record Locking for TMF
Transaction A
LOCK record 1
Change record 1
UNLOCK record 1
Locks for records 1
and 2 will be held until
transaction A commits or is
aborted and backed out.
Transaction B
LOCKFILE
Change record 1
The file lock will be held until
transaction B commits or is
aborted and backed out.
Transaction C
LOCK record 1
Change record 1
Lock for record 1 will be held
until transaction C commits
or
is aborted and backed out.
Lock for record 2 is released
immediately by
UNLOCKFILE.
Audited
File
LOCK record 2
Delete record
2
•
•
Change record 2
UNLOCKFILE
•
•
LOCK record 2
No change to record 2
UNLOCKFILE
•
•
•
•
Audited
File
Audited
File
156 File and Record Locking