TMF Application Programmer's Guide (G06.26+)

TMF Programming Environment
HP NonStop TMF Application Programmer’s Guide—522419-005
1-9
Excluding a Server from a TMF Transaction
Enhancing Performance in a Network Environment
When a work request associated with a transaction identifier is transmitted from a
requester process on one node of a network to a server process on another node, TMF
generates additional messages and internal overhead (when the transaction is being
either committed or aborted) beyond that required for messages not associated with a
transaction identifier.
If the remote server is one of several processes locking or updating records in a
protected database as part of a single business function, then you will want the work of
all the processes to be interrelated within the bounds of a single TMF transaction. In
that scenario, the additional network overhead is not only unavoidable but is actually a
positive factor because of the transaction-oriented database protection it helps provide.
If, however, the remote server manipulates the database independently of other
processes, you should let the server initiate and terminate its own transaction for the
work request. In that scenario, because the work request has no transaction identifier,
you avoid unnecessary network overhead.
Eliminating Unnecessary Dependencies
The more processes that are explicitly involved in the processing of a transaction, the
more opportunity there is for the transaction to be aborted. Consequently, you should
minimize the number of server processes doing work under the same transaction
identifier.
If work being delegated to a server process is logically external to the requester’s
current transaction in that it does not involve protected portions of a database, you
should exclude that work from the particular transaction identifier.
For example, suppose a requester needs to send a message to the spooler. Requests
to the spooler occasionally time out. If that were to occur within the bounds of a
transaction, the entire transaction would be aborted and all of the work associated with
it would be backed out.
Because the spooler does not use audited database files, there is nothing to be gained
by including its activities within a TMF transaction.
By setting the current transaction to the nil state before issuing a WRITEREAD system
procedure call to the spooler, the requester’s transaction will not abort if a timeout
occurs for the WRITEREAD system procedure.