A Transaction Processing Monitor
Transaction Processing Monitor

The backbone of this system is process known as the Transaction Processing Monitor (TPM). All event and transaction control is centralized in the TPM --- any operations requested by an application involves exchanging messages with the TPM. The TPM provides several features.
  • Interprocess Communication:

    The only inter-application IPC method supported by the system is the event mechanism. Thus, in this architecture, all IPC must go through the TPM. If one process wants to send a message to another, it actually does so by sending it to the TPM which forwards it to the other process.

    Communication is done using standard UNIX pipes. All IPC done by the TPM passes through these pipes. There is one input pipe for each application that is used to carry messages from the TPM to that applications. There is one TPM input pipe that is used by all applications to send messages to the TPM.

  • Event and Process Management:

    There is a disk database that the TPM reads at startup time that describes the system. This database contains:

    • The definitions of all known events. That is, a mapping between event code and the list of transactions that are included in it.
    • A table of that describes the server programs that implement the transactions.
    • A list of applications that are to be run at startup time.
    When an event is requested, the requestor sends a message to the TPM containing the event's event code plus message buffer containing the input parameters for the event. The TPM then inspects its internal tables and broadcasts the message it received from the requestor to all of the servers that implement transactions that are part of the event.

    At any point in time, the TPM is aware of which applications are running in the system, which are ready to perform a transaction for a requestor and which are currently executing transactions. If there are no running servers that can provide a requested transaction, the TPM uses the information in its database to start one. It is possible that some servers needed for a requested event are busy woking on some other event. If this is the case, the request is queued until the server is free.

  • Error recovery:

    The TPM has a built in logging mechanism that keeps track of the status of non-completed event requests. Before sending the {\small {\em CALL}} response to the requestor, the TPM creates a record for the new event in its log file. This file contains information on all events and transactions that are run in the system. State information on the events run by the system and their related transactions is updated at significant points in their lifetimes (i.e. end of a phase in the two-phase commit protocol, etc.) The log file allows the TPM to recover events if there is a system crash.