A Transaction Processing Monitor
Reducing IPC Overhead

The number of messages in the protocol caused a high overhead. To reduce this, the following additions were made to the system.
  • A mechanism that allows a server participating in an event to tell the TPM that is does not need to participate in the second phase of the commit protocol. Since many of the transactions in a typical event don't have any work to in the second phase of the commit process, this saves quite a few messages.
  • The protocol was modified to combine some frequently-associated operations to reduce the number of messages. For example, a requestor very frequently sends a WAIT for the result of an event immediately after it is called so a call_and_wait option was added to the CALL operation to allow this to be done by passing only one message to the TPM. It is also typical for a server process to GET a transaction, process it, END, and then repeat. So an end_and_get option was added to the END operation. Using this option tells the system that the server can process a new transaction once the current one completes. Since the majority of applications are of the form described above, these ``combined'' operations significantly increase efficiency.
  • A special subroutine interface, the Transaction Front End (TFE) was developed. The TFE allows server code to be compiled directly into the TPM without any modification. This is accomplished by offering two separate libraries : the external TFE and the internal TFE. The external version of the TFE is used by servers that are implemented as separate processes and need to communicate with the TPM. The internal TFE is linked in with the TPM code and provides the same functional interface to applications as the external, but all message passing is done with function calls and local buffers instead if IPC since the server code is actually present within the TPM process.