Filter
Top Products
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 identified on initiation with a transaction
identifier 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 briefly reviews other uses of configuration 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 configuration 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 first 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 first tier, the Application Server and
Business Logic are the second tier, and the Database Server is
the third tier.
1–10 Introduction