HP Reliable Transaction Router Getting Started page 95

transaction
An operation performed on a database, typically causing an
update to the database. Analogous in many cases to a business
transaction such as executing a stock trade or purchasing an
item in a store. A business transaction may consist of one or
more than one RTR transaction. A transaction is classified as
original, replay, or recovery, depending on how it arrives at the
backend:
Original—Transaction arrived on the first attempt from the
client.
Replay—Transaction arrived after some failure as the
result of a re-send from the client (that is, from the client
transaction-replay buffers in the RTRACP).
Recovery—Transaction arrived as the result of a backend-
to-backend recovery operation (recovery from the
journal).
transaction controller
A transaction controller processes transactions. A transaction
controller may have 0 or 1 transactions active at any moment in
time. It is through the transaction controller that messages and
events are sent and received.
transaction ID
Transaction identification created for each transaction by RTR.
transaction state
As a transaction proceeds from initiation to completion, it passes
through several defined states such as SENDING, VOTING,
RECEIVING, and COMMIT. These states are shown, for
example, with the SHOW TRANSACTION command.
transaction voting
A transaction cannot be committed to the database until all
participating servers agree that it is to be committed. This is
part of the two-phase commit process. Once voting is complete
and all servers are in agreement, the transaction proceeds to the
COMMIT state. See voting.
transactional message
A message containing transactional data.
Glossary–11