RTR Terminology
With transactional 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 identi
fi
ed on initiation with a transaction
identi
fi
er or
transaction ID
(TID), with which it can be logged
and tracked. RTR guarantees that TIDs are unique.
To reinforce the use of these terms in the RTR context, this
section brie
fl
y reviews other uses of con
fi
guration terminology.
Tiers
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 con
fi
guration is
illustrated in Figure 1–6. (In all diagrams, all lines are actually
bidirectional, even when represented otherwise for clarity. For
a given transaction, the initial action is typically from left to
right.) In Figure 1–6, Application Presentation and Business
Logic are the
fi
rst tier, and the Database Server is the second
tier.
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, where Presentation
and User Interface are the
fi
rst tier, the Application Server and
Business Logic are the second tier, and the Database Server is
the third tier.
1–10 Introduction
