1. Manuals
  2. Brands
  3. Compaq Manuals
  4. Network Router
  5. Reliable Transaction Router
  6. Getting started

Compaq Reliable Transaction Router Getting Started

Reliable transaction router
Hide thumbs Also See for Reliable Transaction Router:
Table of Contents

Advertisement

Quick Links

Download this manual
Reliable Transaction Router

Getting Started

Order Number: AA-RLE1A-TE
January 2001
This document introduces Reliable Transaction Router and describes its
concepts for the system manager, system administrator, and applications
programmer.
Revision/Update Information:
Software Version:
Compaq Computer Corporation
Houston, Texas
This is a new manual.
Reliable Transaction Router Version 4.0

Advertisement

Table of Contents
loading

Related Manuals for Compaq Reliable Transaction Router

Summary of Contents for Compaq Reliable Transaction Router

  • Page 1: Getting Started

    Reliable Transaction Router Getting Started Order Number: AA-RLE1A-TE January 2001 This document introduces Reliable Transaction Router and describes its concepts for the system manager, system administrator, and applications programmer. Revision/Update Information: Software Version: Compaq Computer Corporation Houston, Texas This is a new manual.
  • Page 2 Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this publication is subject to change without notice and is provided ‘‘AS IS’’...

  • Page 3: Table Of Contents

    1 Introduction Reliable Transaction Router ......RTR Continuous Computing Concepts .....
  • Page 4 3 Reliability Features Servers ..........Failover and Recovery .
  • Page 5 Figures RTR Reading Path ....... . . 1–1 Client Symbol ........1–2 Server Symbol .

  • Page 7: Preface

    Purpose of this Document The goal of this document is to assist an experienced system manager, system administrator, or application programmer to understand the Reliable Transaction Router (RTR) product. Document Structure This document contains the following chapters: • Chapter 1, Introduction to RTR, provides information on RTR technology, basic RTR concepts, and RTR terminology.

  • Page 8: Related Documentation

    Reliable Transaction Router C Application Programmer’s Reference Manual You can find additional information on RTR and existing implementations on the RTR web site at http://www.compaq.com/rtr/. viii Content Describes new features, changes, and known restrictions for RTR. Lists all RTR commands, their qualifiers and defaults.
  • Page 9 Reader’s Comments Compaq welcomes your comments on this guide. Please send your comments and suggestions by email to rtrdoc@compaq.com. Please include the document title, date from title page, order number, section and page numbers in your message. For product information, send email to rtr@compaq.com.
  • Page 10 Figure 1 RTR Reading Path System Manager Installation Guide System Manager's Manual Commands Cover letter Getting Started Application Programmer Application Design Guide If V2 to V3 C Application Migration Programmer's Guide Reference Manual Release Notes If C++ Foundation Classes = Tutorial ZKO-GS015-99AI...

  • Page 11: Introduction

    Oracle, Microsoft Access, Microsoft SQL Server, Sybase, and Informix. For specifics on operating systems, operating system versions, and supported hardware, see the Reliable Transaction Router Software Product Description for each supported operating system.

  • Page 12: Rtr Continuous Computing Concepts

    RTR Continuous Computing Concepts RTR Continuous Computing Concepts RTR provides a continuous computing environment that is particularly valuable in financial transactions, for example in banking, stock trading, or passenger reservations systems. RTR satisfies many requirements of a continuous computing environment: •...

  • Page 13: Rtr Terminology

    RTR Terminology The following terms are either unique to RTR or redefined when used in the RTR context. If you have learned any of these terms in other contexts, take the time to assimilate their meaning in the RTR environment. The terms are described in the following order: •...
  • Page 14 RTR Terminology An RTR application is user-written software that executes RTR Application within the confines of several distributed processes. The RTR application may perform user interface, business, and server logic tasks and is written in response to some business need. An RTR application can be written in any language, commonly C or C++, and includes calls to RTR.
  • Page 15 Figure 1–2 Server Symbol RTR expects client and server applications to identify themselves Channel before they request RTR services. During the identification process, RTR provides a tag or handle that is used for subsequent interactions. This tag or handle is called an RTR channel. A channel is used by client and server applications to exchange units of work with the help of RTR.
  • Page 16 RTR Terminology Figure 1–3 Roles Symbols The mapping between nodes and roles is done using a facility. Facility An RTR facility is the user-defined name for a particular configuration whose definition provides the role-to-node map for a given application. Nodes can share several facilities. The role of a node is defined within the scope of a particular facility.
  • Page 17 Figure 1–5 Components in the RTR Environment User Accounts Facility Client application disconnected before all parts of the transaction are done, then the transaction remains incomplete. A transaction is a piece of work or group of operations that Transaction must be executed together to perform a consistent transformation of data.
  • Page 18 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.
  • Page 19 RTR Terminology Figure 1–6 Two-Tier Client/Server Environment Database Server Application Presentation and Business Logic (ODBC Model) LKG-11204-98WI Figure 1–7 Three-Tier Client/Server Environment Server Database Application Presentation/ Application Server/ Database Server User Interface Business Logic LKG-11205-98WI RTR provides a multicomponent software model where clients running on frontends, routers, and servers running on backends cooperate to provide reliable service and transactional integrity.
  • Page 20 RTR Terminology All components can reside on a single node but are typically deployed on different nodes to achieve modularity, scalability, and redundancy for availability. With different systems, if one physical node goes down or off line, another router and backend node takes over.
  • Page 21 single node configuration can be useful during development, but would not normally be used when your application is deployed. Figure 1–9 RTR with Browser, Single Node, and Database Browser When creating the configuration used by an application and defining the nodes where a facility has its frontends, routers, and backends, the setup must also define which nodes will have journal files.
  • Page 22 RTR Terminology In this example, the frontend with the client and the router reside on one node, and the server resides on the backend. Frequently, routers are placed on backends rather than on frontends. A further separation of workload onto three nodes is shown in Figure 1–11.
  • Page 23 Figure 1–12 Standby Server Configuration To increase transaction availability, transactions can be Transactional shadowing shadowed with a shadow server. This is called transactional shadowing and is accomplished by having a second location, often at a different site, where transactions are also recorded. This is illustrated in Figure 1–13.
  • Page 24 RTR Terminology Figure 1–13 Transactional Shadowing Configuration With transactional shadowing, there is no requirement that hardware, the data store, or the operating system at different sites be the same. You could, for example, have one site running OpenVMS and another running Windows NT; the RTR transactional commit process would be the same at each site.

  • Page 25: Rtr Server Types

    Figure 1–14 Two Sites: Transactional and Disk Shadowing with Standby Servers Standby Server or Router RTR Server Types In the RTR environment, in addition to the placement of frontends, routers, and servers, the application designer must determine what server capabilities to use. RTR provides four types of software servers for application use: •...
  • Page 26 RTR Server Types • Concurrent servers • Callout servers These are described in the next few paragraphs. You specify server types to your application in RTR API calls. RTR server types help to provide continuous availability and a secure transactional environment. The standby server remains idle while the RTR primary Standby server backend server performs its work, accepting transactions and...
  • Page 27 one node can contain the primary servers for one key range and standby servers for another key range to balance the load across systems. This allows the nodes in a cluster environment to act as standby for other nodes without having idle hardware. When setting up a standby server, both servers must have access to the same journal.
  • Page 28 RTR Server Types Figure 1–16 shows a simple shadow configuration. The main (BE) Server at Site 1 and the shadow server (Shadow) at Site 2 both receive every transaction for the data partition they are servicing. Should Site 1 fail, Site 2 continues to operate without interruption.
  • Page 29 RTR Server Types channels within a single process or as one channel in separate processes. Figure 1–17 Concurrent Servers Server1 Server2 Server3 Server4 LKG-11275-98WI The callout server provides message authentication on Callout server transaction requests made in a given facility, and could be used, for example, to provide audit trail logging.
  • Page 30 RTR Server Types Figure 1–18 A Callout Server Transaction RTR callout servers provide partition-independent processing for Authentication authentication. For example, a callout server can enable checks to be carried out on all requests in a given facility. Callout servers run on backend or router nodes. They receive a copy of every transaction either delivered to or passing through the node.
  • Page 31 When working with database systems, partitioning the database Partition can be essential to ensuring smooth and untrammeled performance with a minimum of bottlenecks. When you partition your database, you locate different parts of your database on different disk drives to spread both the physical storage of your database onto different physical media and to balance access traffic across different disk controllers and drives.
  • Page 32 RTR Server Types but strictly speaking, the key range defines the partition. A partition has both a name, its partition name, and an identifier generated by RTR — the partition ID. The properties of a partition (callout, standby, shadow, concurrent, key segment range) can be defined by the system manager with a CREATE PARTITION command.

  • Page 33: Rtr Networking Capabilities

    Figure 1–20 Standby with Partitioning Application 1-19999 Router 1-19999 Application 20000-39999 RTR Networking Capabilities Depending on operating system, RTR uses TCP/IP or DECnet as underlying transports for the virtual network (RTR facilities) and can be deployed in both local area and wide area networks. PATHWORKS 32 is required for DECnet configurations on Windows NT.

  • Page 35: Architectural Concepts

    This chapter introduces concepts on basic transaction processing and RTR architecture. The Three-Layer Model RTR is based on a three-layer architecture consisting of frontend (FE) roles, backend (BE) roles and router (TR) roles. The roles are shown in Figure 2–1. In this and subsequent diagrams, rectangles represent physical nodes, ovals represent application software, and DB represents the disks storing the database (and usually the database software that runs on the server).
  • Page 36 The Three-Layer Model Figure 2–1 The Three Layer Model Terminals • Allows performance or geographic expansion while protecting the investments made in existing hardware and application software. The router layer contains no application software unless running callout servers. This layer reduces the number of logical network links required on frontend and backend nodes.

  • Page 37: Rtr Facilities Bridge The Gap

    RTR Facilities Bridge the Gap Many applications can use RTR at the same time without interfering with one another. This is achieved by defining a separate facility for each application. When an application calls the declare a channel as a client or server, it specifies the name of the facility it will use.

  • Page 38: Transaction Integrity

    To ensure that your application deals with transactions correctly, its transactions must be: • Atomic • Consistent • Isolated • Durable These are the ACID properties of transactions. For more detail on these properties, see the Reliable Transaction Router Application Design Guide. 2–4 Architectural Concepts...

  • Page 39: The Partitioned Data Model

    RTR routes messages to the correct partition on the basis of an application-defined key. For a more complete description of partitioning as provided with RTR, see the Reliable Transaction Router Application Design Guide. Object-Oriented Programming The C++ foundation classes map traditional RTR functional programming concepts into an object-oriented programming model.
  • Page 40 Object-Oriented Programming Figure 2–2 Partitioned Data Model Terminals 2–6 Architectural Concepts Backends (BE) Database (DB) Frontends (FE) Routers (TR) Client Client Client Client Server Server Server ZKO-GS012-99AI...

  • Page 41: Objects

    Table 2–1 Functional and Object-Oriented Programming Functional Programming A program consists of data structures and algorithms. The basic programming unit is the function, that when run, implements an algorithm. Functions operate on elemental data types or data structures. An application’s architecture consists of a hierarchy of functions and sub-functions.

  • Page 42: Messages

    Object-Oriented Programming Example 2–1 Objects-Defined Sample Dog.h: class Dog { ... main.cpp: #include "Dog.h" main() Dog King; Dog Fifi; Messages Objects communicate by sending messages. This is done by calling an object’s methods. Some principal categories of messages are: • Constructors: Create objects •...

  • Page 43: Polymorphism

    Polymorphism Polymorphism is the ability of objects, inherited from a common base or parent class, to respond differently to the same message. This is done by defining different implementations of the same method name within the individual child class definitions. For example: A DogArray object, "DogArray OurDogs[2];"...

  • Page 44: Xa Support

    XA Support XA Support The XA interface is part of the X/Open DTP (Distributed Transaction Processing) standard. It defines the interface that transaction managers (TM) and resource managers (RM) use to perform the two-phase commit protocol. (Resource managers are underlying database systems such as ORACLE RDBMS, Microsoft SQL Server, and others.) This interface is not used by the application programs;...

  • Page 45: Reliability Features

    Reliability in RTR is enhanced by the use of: • Concurrent servers • Standby servers • Shadow servers • Callout servers • Router failover Servers Note that, conceptually, servers can be contrasted as follows: • Concurrent servers handle similar transactions which access the same data partition and run on the same node.

  • Page 46: Failover And Recovery

    Failover and Recovery Failover and Recovery RTR provides several capabilities to ensure failover and recovery under several circumstances. Router Failover Frontend nodes automatically connect to another router if the one being used fails. This reconnection is transparent to the application. Routers are responsible for coordinating the two-phase commit for transactions.

  • Page 47: Backend Recovery

    Backend If standby or shadow servers are available on another backend Recovery node, operation of the rest of the system will continue without interruption, using the standby or shadow server. If a backend processor is lost, any transactions in progress are remembered by RTR and later recovered, either when the backend restarts, or by a standby if one is present.

  • Page 49: Rtr Interfaces

    You can use the command line interface to the API to write simple RTR applications for testing and experimentation. The CLI is described in the Reliable Transaction Router System Manager’s Manual. Its use is illustrated in this chapter. RTR Interfaces...

  • Page 50: Rtr Management Station

    RTR. The object-oriented API is fully described in the manual Reliable Transaction Router C++ Foundation Classes. The C- programming API is fully described in the Reliable Transaction Router C Application Programmer’s Reference Manual. Both APIs are used in designs in the RTR Application Design Guide.
  • Page 51 The user is called user, the facility being defined is called DESIGN, a client and a server are established, and a test message containing the words "Kathy’s text today" is sent from the client to the server. After the server receives this text, the user on the server enters the words "And this is my response."...
  • Page 52 [The user issues the following commands on the server application where RTR is running on the backend.] $ RTR Copyright Compaq Computer Corporation 1994. RTR> set mode/group %RTR-I-STACOMSRV, starting command server on node NODEA %RTR-I-GRPMODCHG, group changed from " " to "username"...
  • Page 53 RTR> RTR_RECEIVE_MESSAGE/CHAN=S %RTR-S-OK, normal successful completion channel name: S msgsb msgtype: rtr_mt_msg1 msglen: usrhdl: Tid: 63b01d10,0,0,0,0,2e59,43ea2002 message offset bytes 000000 4B 61 74 68 79 27 73 20 74 65 78 74 20 74 6F 64 Kathy’s text tod 000010 61 79 00 reason: Ox00000000 RTR>...
  • Page 54 RTR Management Station RTR> RTR_RECEIVE_MESSAGE/CHANNEL=C/tim [to get mt_opened or mt_closed] %RTR-S-OK, normal successful completion channel name: C msgsb msgtype: rtr_mt_opened msglen: message status: normal successful completion reason: Ox00000000 RTR> RTR_START_TX/CHAN=C %RTR-S-OK, normal successful completion RTR> RTR_SEND_TO_SERVER/CHAN=C "Kathy’s text today." [text sent to the server] %RTR-S-OK, normal successful completion RTR>...

  • Page 55: Browser Interface

    RTR> RTR_RECEIVE_MESSAGE %RTR-S-OK, normal successful completion channel name: S msgtype: rtr_mt_accepted RTR> STOP RTR Browser With the RTR browser interface, your management station has Interface a network-browser-like display from which you can view RTR status and issue RTR certain commands with a point-and-click operation, rather than by entering commands.
  • Page 56 Application Programming Interfaces Figure 4–1 RTR Browser Interface Example of object creation in an RTR client program. Sample C++ client code // Create a Transaction Controller to receive incoming messages // and events from a client. RTRClientTransactionController *pTransaction = new RTRClientTransactionController(); // Create an RTRData object to hold an ASCII message for the server.

  • Page 57: Rtr C Programming Interface

    Example of object creation in an RTR server program. Sample C++ server code void CombinationOrderProcessor::StartProcessingOrdersAtoL() // Create an RTRKeySegment for all ASCII values between "A" and "L." m_pkeyRange = new RTRKeySegment (rtr_keyseg_string, //To process strings. StartProcessingOrders(PARTITION_NAMEAToL,m_pKeyRange); // Create an RTRData Oobject to hold each incoming message or event. This // object will be reused.
  • Page 58 Application Programming Interfaces Example of an open channel call in an RTR client program: Sample C client code status = rtr_open_channel(&Channel, if (Status != RTR_STS_OK) Example of a receive message call in an RTR server program: Sample C server code status = rtr_receive_message(&Channel, if (status != RTR_STS_OK) A client can have one or multiple channels, and a server can...

  • Page 59: The Rtr Environment

    The RTR environment has two parts: • The system management environment • The runtime environment The RTR System Management Environment You manage your RTR environment from a management station, which can be on a node running RTR or on some other node. You can manage your RTR environment either from your management station running a network browser, or from the command line using the RTR CLI.
  • Page 60 The RTR System Management Environment • Handles all transactions and recovery RTRACP handles interprocess communication traffic, network traffic, and is the main repository of runtime information. ACP processes operate across all RTR roles and execute certain commands both locally and at remote nodes. These commands include: •...
  • Page 61 The Command Server Process executes commands both locally and across nodes. Commands that can be executed at the RTR COMSERV include: • START RTR • CREATE/MODIFY JOURNAL • SHOW LINK/FACILITY/SERVER/CLIENT (ACP must be running) • Application programmer commands (for testing and demonstration) The RTR system management environment is illustrated in Figure 5–1.

  • Page 62: Monitoring Rtr

    The RTR System Management Environment Monitoring RTR RTR Monitor pictures or the RTR Monitor let you view the status and activities of RTR and your applications. A monitor picture is dynamic, its data periodically updated. RTR SHOW commands that also let you view status are snapshots, giving you a view at one moment in time.

  • Page 63: Partition Management

    Partition Partitions are subdivisions of a routing key range of values used Management with a partitioned data model and RTR data-content routing. Partitions exist for each range of values in the routing key for which a server is available to process transactions. Redundant instances of partitions can be started in a distributed network, to which RTR automatically manages the state and flow of transactions.
  • Page 64 The RTR Runtime Environment • Server application • RTR shareable image, LIBRTR • RTR control process, RTRACP • RTR daemon, RTRD Figure 5–2 shows these components and their placement on frontend, router, and backend nodes. The frontend, router, and backend can be on the same or different nodes. If these are all on the same node, there is only one RTRACP process.

  • Page 65: What's Next

    What’s Next? This concludes the material on RTR concepts and capabilities that all users and implementors should know. For more information, proceed as follows: If you are: a system manager, system administrator, or software installer an applications or system management developer, programmer, or software engineer What’s Next?

  • Page 67: Glossary

    Glossary A few additional terms are defined in the Glossary to the Reliable Transaction Router Application Design Guide. ACID Transaction properties supported by RTR: atomicity, consistency, isolation, durability. The RTR Application Control Process. Application Programming Interface. applet A small application designed for running on a browser.
  • Page 68 branch A subdivision of a bank; perhaps in another town. broadcast A nontransactional message. callout server A server process used for transactional authentication. 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.
  • Page 69 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. Central processing unit. data marshalling The capability of using systems of different architectures (big endian, little endian) within one application.
  • Page 70 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.
  • Page 71 frontend FE, the physical node in an RTR facility where the client application runs. 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.
  • Page 72 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.
  • Page 73 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.
  • Page 74 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 pre-transaction state. router The RTR role that manages traffic between RTR clients and servers.
  • Page 75 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. Symmetric MultiProcessing. standby The state of the partition that can take over if the process for which it is on standby is unavailable.
  • Page 76 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.

  • Page 77: Index

    ACID, 2–4 Anonymous client, 1–22 API, 4–1 Application distributed, 2–4 software, 2–2 Authentication, 1–20 Backend, 2–1 loss, 3–3 BE, 2–1 Broadcast, 2–3 Callout server, 1–20, 3–1 Client anonymous, 1–22 processes, 2–1 Concurrent server, 3–1 Database, 2–1, 2–2 locks, 2–5 shared, 2–5 Data model partitioned, 2–5 Index...
  • Page 78 Network wide area, 1–18 Nodes, 2–2 Object-oriented, 2–5 Oracle RDBMS, 2–10 Parallel execution, 2–4 Partitioned data model, 2–5 Processes client, 2–1 server, 2–1 RDBMS, 2–10 Recovery, 3–2 Reliability features, 3–1 Resource manager, 2–10 RM, 2–10 Router, 2–1 failover, 3–2 layer, 2–2 loss, 3–3 API, 4–1 broadcasts, 2–3...

This manual is also suitable for:

Rtr

Table of Contents