Enscribe Programmer's Guide

Figure 22 (page 157) illustrates these principles:
• The terminal control process (TCP) interprets BEGINTRANSACTION and obtains the transid
before requesting database activity from the servers.
• The transid is transmitted to the servers as part of the request message, and any disk activity
performed by the servers is associated with the particular transid.
• The particular transid owns the lock(s); all servers that are performing work for the same transid
can read, lock, add, delete, and change records in the audited files. For example, server A
can read and lock a record and server B can read or change the same record if both servers
are operating on behalf of the same transid.
Figure 22 Record Locking by Transid
TCP
Server A
Server B
Transid
Transid
Transid
Transid
Audited
File
BEGIN-TRANSACTION
•
•
"transaction mode"
•
•
END-TRANSACTION
All locks and changes to
audited files are associated
with a transaction identifier
(transid).
Errors in Opening Audited Files
With TMF, locks can persist longer than the opener process because the locks are owned by the
transid instead of by the opener of a file. This means that even if a file has been closed by all its
openers, the disk process will effectively keep it open until all transactions owning locks in the file
have been either committed or aborted and backed out.
For files with pending transaction locks, these types of errors are possible:
• Any attempt to open an audited file with exclusive access will fail with error 12 (file in use)
regardless of whether openers of the file exist.
• FUP operations that require exclusive access, such as PURGE and PURGEDATA, will fail.
PURGE operations will fail with error 12 (file in use) while PURGEDATA operations will fail
with error 80 (invalid operation on audited file).
Error 80 will also be returned if the OPEN call specifies unstructured access to a structured audited
file.
TMF Locking Considerations 157