TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Writing Pathway Servers
NonStop TS/MP Pathsend and Server Programming Manual–132500
4-5
Considerations for Servers That Use the TMF
Subsystem
Considerations for Servers That Use the TMF
Subsystem
If you are writing a Pathway server that uses the TMF subsystem for transaction
management, a number of additional programming considerations apply, related to the
following topics:
•
Recommended application structure
•
Writing a server to use the TMF subsystem if your application does not follow the
recommended structure
•
Using audited and nonaudited files
•
Record locking
•
Grouping transaction operations
Recommended Structure for Applications
The recommended structure for applications that use the TMF subsystem is described in
this subsection. If your current or planned application has these characteristics,
programming the application to use the TMF subsystem is relatively straightforward;
otherwise, refer to Writing a Server to Use the TMF Subsystem, later in this section, for
a checklist of changes to make.
One process (usually the requester) coordinates all of the work required to do a single
TMF transaction; this process identifies the beginning and ending points of each
transaction. Additionally, if the server replies to a request message by indicating that it
failed to complete all of the changes, this process can either abort and abandon the
transaction or abort and retry the transaction.
The communication between requesters and servers is by standard interprocess I/O. The
requester does the send operation, and the server does the READUPDATE call for
$RECEIVE and the REPLY call. Each request message and the server’s reply to the
message is for a single transaction.
Any disk I/O request is for a single transaction. The TMF subsystem appends the
process’s current transaction identifier to each disk-request message so that the audit
trails can include the identity of the transaction responsible for each database change.
How concurrency control is performed depends on which relational database
management system (RDBMS) is being used. If the NonStop SQL/MP relational
database management system is used, concurrency control is done by means of
NonStop SQL/MP access options. Use of the access options causes NonStop SQL/MP
software to generate the appropriate TMF transactions as required; therefore, servers that
use NonStop SQL/MP databases are not required to include TMF procedure calls or
statements. For information about use of the NonStop SQL/MP access options, refer to
the NonStop SQL/MP Reference Manual. For servers that use the Enscribe database
record manager, concurrency control is done by using the Enscribe locking facilities,
and you must program the transactions by using TMF procedure calls or statements. For