ACID: Transaction properties supported by RTR: atomicity, consistency, isolation, durability.

ACP: The RTR Application Control Process.

API: Application programming interface.

applet: A small application designed for running on a browser.

application: User-written software that employs RTR. An application can be written in C++ or C; RTR is also XA compliant.

application classes: The C++ API classes used for implementing client and server applications.

ASP: Active Server Page

backend: BE, the physical node in an RTR facility where the server application runs.

bank: An establishment for the custody of money, which it pays out on a customer's request.

branch: A subdivision of a bank; perhaps in another town.

broadcast: A nontransactional message.

callout server: A server process used for transactional authentication.

CGI: Common Gateway Interface

channel: A logical port opened by an application with an identifier to exchange messages with RTR.

client: A client is always a client application, one that initiates and demarcates a piece of work. In the context of RTR, a client must run on a node defined to have the frontend role. Clients typically deal with presentation services, handling forms input, screens, and so on. A browser, perhaps running an applet, could connect to a web application that acts as an RTR client, sending data to a server through RTR.

In other contexts, a client can be a physical system, but in the context of RTR and in this document, such a system is always called a frontend or a node.

client classes: C++ foundation classes used for implementing client applications.

commit process: The transactional process by which a transaction is prepared, accepted, committed, and hardened in the database.

commit sequence number (CSN): A sequence number assigned to an RTR commit group, established by the vote window, the time interval during which transaction response is returned from the backend to the router. All transactions in the commit group have the same CSN and lock the database.

common classes: C++ foundation classes that can be used in both client and server applications.

concurrent server: A server process identical to other server processes running on the same node.

connectionpool: A buffer or cache of reusable open connections to a database. Use of the connectiopool cache can reduce the overhead of making and releasing database connections. Connections are used with the JNDI API and are registered with a JNDI service.

credit: A value used by RTR for flow control between sender and receiver.

CPU: Central processing unit.

data marshalling: The capability of using systems of different architectures (big endian, little endian) within one application.

data object: See RTRData object.

datasource: A source of data such as a database system. Datasources are used with the JNDI API. In RTR, a datasource is represented by a datasource object. A datasource is registered with a JNDI service.

deadlock: Deadly embrace, a situation that occurs when two transactions or parts of transactions conflict with each other, which could violate the consistency ACID property when committing them to the database.

disk shadowing: A process by which identical data are written to multiple disks to increase data availability in the event of a disk failure. Used in a cluster environment to replicate entire disks or disk volumes. See also transactional shadowing.

dispatch: A method in the C++ API RTRData class which, when called, interprets the contents on the RTRData object and calls an appropriate handler to process the data. The handler chosen to process the data is the handler registered with the transaction controller. This method is used with the event-driven receive model.

DTC: Microsoft Distributed Transaction Coordinator.

endian: The byte-ordering of multibyte values. Big endian: high-order byte at starting address; little endian: low-order byte at starting address.

event: RTR or application-generated information about an application or RTR.

event driven: A processing model in which the application receives messages and events by registering handlers with the transaction controller. These handlers are derived from the C++ foundation class message and event-handler classes.

event handler: A C++ API-derived object used in event-driven processing that processes events.

facility: The mapping between nodes and roles used by RTR and established when the facility is created.

facility manager: A C++ API management class that creates and deletes facilities.

facility member: A defined entity within a facility. A facility member is a role and node combined. Can be a client, router or server.

failover: The ability to continue operation on a second system when the first has failed or become disconnected.

failure tolerant: Software that enables an application to continue when failures such as node or site outages occur. Failover is automatic.

fault tolerant: Hardware built with redundant components to ensure that processing survives component failure.

frontend: FE, the physical node in an RTR facility where the client application runs.

FTP: File transfer protocol.

inquorate: Nodes/roles that cannot participate in a facility's transactions are inquorate.

journal: A file containing transactional messages used for recovery.

key range: An attribute of a key segment, for example a range A to E or F to K.

key segment: An attribute of a partition that defines the type and range of values that the partition handles.

LAN: Local area network.

link: A communications path between two nodes in a network.

local node: The node on which a C++ API client or server application runs. The local node is the computer on which this instance of the RTR application is executing.

management classes: C++ API classes used by new or existing applications to manage RTR.

member: See facility member.

message: A logical grouping of information transmitted between software components, typically over network links.

message handler: A C++ API-derived object used in event-driven processing that processes messages.

multichannel: An application that uses more than one channel. A server is usually multichannel.

multithreaded: An application that uses more than one thread of execution in a single process.

MS DTC: Microsoft DTC; see DTC.

network partition: A network partition, usually inadvertently, separates a network into disconnected parts. For example, due to link failures, a 20-node network could become two unconnected 10-node networks. This would constitute a network partition.

node: A physical system.

nontransactional message: A message containing data that does not contain any part of a transaction such as a broadcast or diagnostic message. See transactional message.

partition: RTR transactions can be sent to a specified key range of a database or a partition. This is data-content routing and is handled by RTR when so programmed in the application and specified by the system administrator. For example, a database with keys from A to Z can be partitioned into key ranges from A to I, J to R, and S to Z. A partition can be in one of three states: primary, standby, and shadow. See also network partition.

partition properties: Information about the attributes of a partition.

polling: A processing method where the application polls for incoming messages.

polymorphism: The ability of objects inherited from a common parent class to respond differently to the same message. The object responds depending on where it is in the inheritance hierarchy.

primary: The state of the partition servicing the original data store or database. A primary has a secondary or shadow counterpart.

process: The basic software entity, including address space, scheduled by system software, that provides the context in which an image executes.

properties: Application, transaction and system information.

property classes: Classes used for obtaining information about facilities, partitions, and transactions.

quorate: Nodes/roles in a facility that has quorum are quorate.

quorum: The minimum number of routers and backends in a facility, usually a majority, who must be active and connected for the valid completion of processing.

quorum node: A node, specified in a facility as a router, whose purpose is not to process transactions but to ensure that quorum negotiations are possible.

quorum threshold: The minimum number of routers and backends in a facility required to achieve quorum.

roles: Roles are defined for each node in an RTR configuration based on the requirements of a specific facility. Roles are frontend, router, or backend.

rollback: When a transaction has been committed on the primary database but cannot be committed on its shadow, the committed transaction must be removed or rolled back to restore the database to its pretransaction state.

router: The RTR role that manages traffic between RTR clients and servers.

RTRACP: The RTR application control process.

RTR configuration: The set of nodes, disk drives, and connections between them used by RTR.

RTR environment: The RTR run-time and system management areas.

RTRData object: An instance of the C++ API RTRData class. This object contains either a message or an event. It is used for both sending and receiving data between client and server applications.

secondary: See shadow.

server: A server is always a server application or process, one that reacts to a client application's units of work and carries them through to completion. This may involve updating persistent storage such as a database file, toggling the switch on a device, or performing another predefined task. In the context of RTR, a server must run on a node defined to have the backend role.

In other contexts, a server may be a physical node, but in RTR and in this document, physical servers are called backends or nodes.

server classes: C++ foundation classes used for implementing server applications.

serviceprovider: A context or initial context implementation used by a JNDI client for dynamic connection to the JNDI architecture. Serviceproviders are used with the JNDI API.

shadow: The state of the server process that services a copy of the data store or primary database. In the context of RTR, the shadow method is transactional shadowing, not disk shadowing. Its counterpart is primary. See transactional shadowing and disk shadowing.

SMP: Symmetric MultiProcessing.

standby: The state of the partition that can take over if the process for which it is on standby is unavailable. It is held in reserve, ready for use.

striped: The recording of records across more than one disk.

tier: Hardware separation of system components such as a client application and a server application. Also called a layer or system component.

TPS: Transactions per second.

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.

transactional shadowing: A process by which identical transactional data are written to separate disks often at separate sites to increase data availability in the event of site failure. See also disk shadowing.

two-phase commit: A database commit/rollback concept that works in two steps: 1. The coordinator asks each local recovery manager if it is able to commit the transaction. 2. If and only if all local recovery managers agree that they can commit the transaction, the coordinator commits the transaction. If one or more recovery managers cannot commit the transaction, then all are told to roll back the transaction.

Two-phase commit is an all-or-nothing process: either all of a transaction is committed, or none of it is.

voting: Used in the two-phase commit process to ensure that all servers agree that a transaction is to be committed to the database. If all agree, RTR commits the transaction to the database. If any server votes "no", the transaction is not committed and all servers roll back the transaction.

WAN: Wide area network.

XA: An X/Open interface used in distributed transaction processing. An application that is XA-compliant uses the XA interface between the transaction manager and the resource manager. RTR is XA-compliant.