Compaq Reliable Transaction Router manual Introduction

RTR Terminology

Nontransactional messaging

Transaction ID

Transaction

Controller

messaging, RTR ensures that a transaction is ``all or nothing''— either fully completed or discarded; either both the checking account debit and the savings account credit are done, or the checking account debit is backed out and not recorded in the database. RTR transactions have the ACID properties.

An application will also contain nontransactional tasks such as writing diagnostic trace messages or sending a broadcast message about a change in a stock price after a transaction has been completed.

Every transaction is identified on initiation with a transaction identifier or transaction ID, with which it can be logged and tracked.

To reinforce the use of these terms in the RTR context, this section briefly reviews other uses of configuration terminology.

A traditional two-tier client/server environment is based on hardware that separates application presentation and business logic (the clients) from database server activities. The client hardware runs presentation and business logic software, and server hardware runs database or data manager (DM) software, also called resource managers (RM). This type of configuration is illustrated in Figure 1–6. (In all diagrams, all lines are bidirectional.)

With the C++ API, the Transaction Controller manages transactions (one at a time), channels, messages, and events.

Further separation into three tiers is achieved by separating presentation software from business logic on two systems, and retaining a third physical system for interaction with the database. This is illustrated in Figure 1–7.

RTR extends the three-tier model based on hardware to a multitier, multilayer, or multicomponent software model.

1–8Introduction