Filter
Top Products
RTR Terminology
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.
Nontransactional
messaging
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.
Transaction ID
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.)
Transaction
Controller
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–8 Introduction