HP Reliable Transaction Router Getting Started Order Number: AA-RLE1C-TE June 2005 This document introduces HP Reliable Transaction Router and describes its concepts for the system manager, system administrator, and applications programmer. Revision/Update Information: This manual supersedes Reliable Transaction Router Getting Started, Version 4.2. Software Version: HP Reliable Transaction Router Version 5.
© Copyright 2003, 2005 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1 Introduction Reliable Transaction Router . . . . . . . . RTR Continuous Computing Concepts RTR Terminology . . . . . . . . . . . . . . . . RTR Server Types . . . . . . . . . . . . . . . RTR Networking Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Reliability Features RTR Server Types . . . Failover and Recovery Router Failover . . Recovery Scenarios . . . Backend Recovery Router Recovery . Frontend Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4–3 4–4 4–5 4–6 4–7 4–8 Commands and system response at client. . . . . . . . . . . . . . The following lines arrive at the client from RTR after the user enters commands at the server. . . . . . . . . . . . . . . . . . Creating a Facility with the C++ API . . . . . . . . . . . . . . . . Starting RTR with the C++ API . . . . . . . . . . . . . . . . . . . . . Creating a Facility with the C++ API . . . . . . . . . . . . . . . . Creating a Partition with the C++ API . . . . . . . . . . . . . . . .. 4–14 .
4–6 5–1 5–2 RTR Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTR System Management Environment . . . . . . . . . . . . . . . . RTR Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 4–17 5–4 5–7 RTR Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional and Object-Oriented Programming Compared . . . RTR Development Interfaces and their Use . . . . . . . . . . . . . .
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, provides information on RTR technology, basic RTR concepts, and RTR terminology.
Related Documentation Table 1 describes RTR documents and groups them by audience. Table 1 RTR Documents Document Content For all users: HP Reliable Transaction Router Release Notes1 Describes new features, corrections, restrictions, and known problems for RTR. HP Reliable Transaction Router Getting Started Provides an overview of RTR technology and solutions, and includes the glossary that defines all RTR terms. HP Reliable Transaction Router Software Product Description Describes product features.
Table 1 (Cont.) RTR Documents Document Content HP Reliable Transaction Router JRTR Getting Started 2 Provides an overview of the object-oriented JRTR Toolkit including installation, configuration and Java programming concepts, with links to additional online documentation. HP Reliable Transaction Router C++ Foundation Classes Describes the objectoriented C++ interface that can be used to implement RTR object-oriented applications.
Conventions This manual adopts the following conventions: Convention Description New term New terms are shown in bold when introduced and defined. All RTR terms are defined in the glossary at the end of this document. User input User input and programming examples are shown in a monospaced font. Boldface monospaced font indicates user input. Terms and titles Terms defined only in the glossary are shown in italics when presented for the first time.
Release Notes SPD Figure 1 RTR Reading Path Getting Started = Glossary System Manager Application Programmer If Java Application Design Guide Installation Guide JRTR Getting Started (Online Only) If C If C++ C Application Programmer’s Reference Manual System Manager’s Manual C++ Foundation Classes RTR Help (Online Only) = Tutorial VM-0818A-AI xi
1 Introduction This document introduces RTR and describes RTR concepts. It is intended for the system manager or administrator and for the application programmer who is developing an application that works with Reliable Transaction Router (RTR). Reliable Transaction Router Reliable Transaction Router (RTR) is failure-tolerant transactional messaging middleware used to implement large, distributed applications with client/server technologies.
Reliable Transaction Router Interoperability You use the architecture of RTR to ensure high availability and transaction completion. RTR supports applications that run on different hardware and different operating systems. RTR applications can be designed to work with several database products including Oracle, Microsoft Access, Microsoft SQL Server, Sybase, and Informix.
Reliable Transaction Router processing system using RTR requires analysis, planning, and considered execution. 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 Continuous Computing Concepts • Durable For more details on transactional ACID properties, see the brief discussion later in this document in the section Transaction Integrity and refer to the HP Reliable Transaction Router Application Design Guide. RTR Terminology In addition to the terms previously defined, the following terms are either unique to RTR or redefined when used in the RTR context.
RTR Terminology • Standby server • Transactional shadowing • RTR journal • Partition • Key range • XA RTR Application An RTR application is user-written software that executes 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 one of the supported languages, C, C++, or Java and includes calls to RTR.
RTR Terminology Server A server is always a server application, one that reacts to a client’s units of work and carries them through to completion. This may involve updating persistent storage such as a database file, toggling a 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 can be a physical system, but in RTR and in this document, physical servers are called backends or nodes.
RTR Terminology Roles A node that runs client applications is called a frontend (FE), or is said to have the frontend role. A node that runs server applications is called a backend (BE). Additionally, the transaction router (TR) contains no application software but acts as a traffic cop between frontends and backends, routing transactions to the appropriate destinations. The router controls the distributed RTR nodes, and takes care of two-phase commit, failover and failback.
RTR Terminology Figure 1–4 Facility Symbol VM-0822A-AI A facility name is mapped to specific physical nodes and their roles using the CREATE FACILITY command. Figure 1–5 shows the logical relationship between client application, server application, frontends (FEs), routers (TRs), and backends (BEs) in the RTR environment at a specific location. The database is represented by the cylinder.
RTR Terminology Clients send messages to servers to ask that a piece of work be done. Such requests may be bundled together into transactions. An RTR transaction consists of one or more messages that have been grouped together by a client application, so that the work done as a result of each message can be undone completely, if some part of that work cannot be done. If the system fails or is disconnected before all parts of the transaction are done, then the transaction remains incomplete.
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.
RTR Terminology Figure 1–6 Two-Tier Client/Server Environment Data Manager software Application Presentation and Business Logic (ODBC Model) Database Server VM-0824A-AI Figure 1–7 Three-Tier Client/Server Environment Database Server Database Application Presentation/User Interface Application Server/ Business Logic Database Server VM-0825A-AI RTR extends the three-tier model, which is based on hardware, to a multilayer, or multicomponent software model.
RTR Terminology connection to the current router is maintained until the current router fails or connections to it are lost. All RTR software components can reside on a single node but are typically deployed on different nodes to achieve modularity, scalability, and redundancy for availability. During initial application development, it can be convenient to use a single physical node for all RTR roles and application software.
RTR Terminology For example, you could use an underutilized system as a standby server in certain configurations. As you modularize your application and distribute its components on frontends and backends, you can identify usage bottlenecks, add new nodes, and provide redundancy to increase availability. Adding backend nodes can help divide the transactional load and distribute it more evenly.
RTR Terminology In this example, the frontend with the client application resides on one node, and the router with the server application reside a node that has both the router and backend roles. This is a typical configuration where routers are placed on backends rather than on frontends. A further separation of workload onto three nodes is shown in Figure 1–11.
RTR Terminology The standby server is usually placed on a node other than the node where the primary server runs, and should be, to avoid being a single point of failure. Network capability, clustering or disk-sharing technology, and appropriate software must be available on both primary and standby backend systems when running RTR.
RTR Terminology Figure 1–13 Transactional Shadowing Configuration Primary Server FE TR BE Server application Database BE Server application Database Shadow Server VM-0831A-AI RTR Journal In the RTR environment, one data store (database or data file) is elected the primary, and a second data store is made the shadow. The shadow data store is a copy of the data store kept on the primary.
RTR Terminology Note Transactional shadowing shadows only transactions controlled by RTR. For full redundancy to assure maximum availability, a configuration could employ disk shadowing in clusters at separate sites coupled with transactional shadowing across sites. Disk shadowing used in specific cluster environments copies data to another disk to ensure data availability. Transactional shadowing copies only transactional data.
RTR Server Types Standby server The standby server remains idle while the RTR primary backend server performs its work, accepting transactions and updating the database. When the primary server fails, the standby server takes over, recovers any in-progress transactions, updates the database, and communicates with clients until the primary server returns. There can be many instances of a standby server. Activation of the standby server is transparent to the user.
RTR Server Types Note that 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.
RTR Server Types Transactional shadowing is done by partition. A transactional shadow configuration can have only two members of the shadow set. Shadow servers are servers on separate backends that handle the same transactions in parallel on identical copies of the database. Figure 1–15 shows a simple shadow configuration. The main backend server application at Site 1 and the shadow server (Shadow application) at Site 2 both receive every transaction for the data partition they are servicing.
RTR Server Types Concurrent server The concurrent server is an additional instance of a server application running on the same node. RTR delivers transactions to a free server from the pool of concurrent servers. If one server fails, the transaction in process is replayed to another server in the concurrent pool. Concurrent servers are designed primarily to increase throughput and can exploit Symmetric Multiprocessing (SMP) systems.
RTR Server Types Callout server The callout server enables message authentication on transaction requests made in a given facility, and could be used, for example, to provide audit trail logging. A callout server can run on either backend or router nodes. A callout server receives a copy of all messages in a facility. Because the callout server votes on the outcome of each transaction it receives, it can veto any transaction that does not pass its checks.
RTR Server Types Authentication RTR callout servers provide facility-based processing for authentication. For example, a callout server can enable verification 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 facility. Callout servers offer the following advantages: • The checking code is completely separated from other application code.
RTR Server Types Figure 1–18 Bank Partitioning Example TR BE BE BE BE BE Server application Server application Server application Server application Server application Accounts 1-19,999 Accounts 20,00039,999 Accounts 40,00069,999 Accounts 70,00089,999 Accounts 90,00099,999 VM-0837A-AI You can assign a partition name in your application program or have it set by the system manager.
RTR Server Types easily. The system manager can change the key range with a command, for example, in an overnight operation, or you can plan to do this during scheduled maintenance. A partition can also have multiple standby servers. Standby Server Configurations A node can be configured as a primary server for one key range and as a standby server for another key range. This helps to distribute the work of the standby servers. Figure 1–19 illustrates this use of standbys with distributed partitioning.
RTR Networking Capabilities 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.
2 Architectural Concepts This chapter introduces concepts on basic transaction processing and RTR architecture. The Three-Tier Architecture RTR is based on a three-tier physical 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 cylinders represent the disks storing the database.
The Three-Tier Architecture Figure 2–1 The Multitier Model FE BE Client application FE Server application TR Client application BE FE Server application Client application FE TR Client application Terminals Frontends BE Server application Routers Backends Database VM-0839A-AI Client application processes run on nodes defined to have the frontend role. This tier allows computing power to be provided locally at the end-user site for transaction acquisition and presentation.
The Three-Tier Architecture • Allows performance or geographic expansion while protecting the investments made in existing hardware and application software The router tier contains no application software unless running callout servers. This tier reduces the number of logical network links required on frontend and backend nodes and helps ensure good performance even in an unstable network.
Broadcasts Broadcasts Sometimes an application has a requirement to send unsolicited messages to multiple recipients. An example of such an application is a commodity trading system, where the clients submit orders and also need to be informed of the latest price changes. The RTR broadcast capability meets this requirement. Recipients subscribe to a class of broadcasts; a sender broadcasts a message in this class, and all interested recipients receive the message.
Flexibility and Growth RTR also allows parallel execution. This means that different parts of a single transaction can be processed in parallel by multiple servers. RTR provides a comprehensive set of monitoring tools to help you evaluate the volume of traffic passing through the system. These tools can help you respond to unexpected load changes, making you aware of system degradation that you can sometimes alleviate by altering the system configuration dynamically.
The Partitioned Data Model The Partitioned Data Model One goal in designing for high transaction throughput is reducing the time that users must wait for shared resources. While many elements of a transaction processing system can be duplicated, one resource that must be shared is the database.
Object-Oriented Programming Figure 2–2 Partitioned Data Model FE BE Client application FE Server application TR Client application Partition 1 BE FE Server application Client application FE TR Client application Terminals Frontends Partition 2 Partition 3 BE Server application Routers Backends Database VM-0840A-AI Architectural Concepts 2–7
Object-Oriented Programming Table 2–1 Functional and Object-Oriented Programming Compared Objects Functional Programming Object-Oriented Programming A program consists of data structures and algorithms. A program consists of a team of cooperating objects. The basic programming unit is the function, that when run, implements an algorithm. The basic programming unit is the class, that when instantiated, implements an object. Functions operate on elemental data types or data structures.
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: Class Relationships • Constructors: Create objects • Destructors: Delete objects • Selectors: Return part or all of an object’s state. For example, a Get method • Modifiers: Change part or all of an object’s state.
Object-Oriented Programming 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];" refers to two element objects of class Dog, the base class: • King, of class Doberman, is a derived or child class of Dog.
Java Support Java Support RTR clients and servers can be Java applications that obtain the benefits of high availability, fault tolerance and scalability provided by RTR. RTR clients and servers employing Java technology use standard Java and J2EE interfaces for transaction management, data input/output, and database access. For additional information, see the JRTR Getting Started manual and associated online documentation.
3 Reliability Features This chapter addresses: • RTR server types • Failover and recovery • Recovery scenarios RTR Server Types Reliability in RTR is enhanced by the use of: • Concurrent servers • Standby servers • Shadow servers • Callout servers • Router failover 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.
RTR Server Types When there is concern that your database is a single point of failure, add a shadow server, if possible at a different physical location. • Standby servers provide a node that can take over processing on a data partition when the primary server or node fails. When there is concern that your server application or the node where it is running is a single point of failure in your configuration, configure a standby server to be ready to take over.
Failover and Recovery Backend Restart Recovery Transactions in the process of being committed at the time of a failure are recovered from RTR’s disk journal. Recovery could be with a concurrent server, a standby server, or a restarted server created when the failed backend restarts. Correct ordering of the execution of transactions against the database is maintained. Transaction Message Replay Transaction messages that are lost in transit are resent when possible.
Recovery Scenarios Frontend Recovery 3–4 Reliability Features If a frontend is lost: • All transactions committed but not completed on the frontend node at the time of failure will be completed. • All transactions started but not committed on the frontend node at the time of failure will be aborted.
4 RTR Interfaces RTR provides interfaces for system management (the management interfaces) and for development of transaction processing and management applications (the programming or application development interfaces). Management Interfaces The management interfaces are: • • The RTR Administrator, a browser interface.
RTR Interfaces Figure 4–1 RTR Administrator vm-1152A-AI The RTR CLI contains all RTR system manager commands and calls to all RTR C API routines such as rtr_open_channel or rtr_create_facility. You can use either the RTR Manager or the RTR CLI to manage your RTR configuration. You can also use the command line interface to write short RTR C applications for testing and experimentation. The CLI is described in the HP Reliable Transaction Router System Manager’s Manual.
RTR Interfaces Figure 4–2 RTR Command Line Interface VM-1103a-AI Programming Interfaces RTR provides several programming or application development interfaces for design and implementation of transaction processing programs. They include the following: • The object-oriented RTR Java interface You can use this API for new development, and, where appropriate, for new development with existing applications. This API can be used to implement applications with RTR using Java and J2EE technologies.
RTR Interfaces • An interface that enables use of an X/Open Distributed Transaction Processing-conformant resource manager This interface, invoked through the RTR management interfaces, enables RTR applications to be used with X/Open-compliant resource managers such as Oracle8. • The OpenVMS API containing OpenVMS calls This API, supported on OpenVMS only, is obsolete for new development.
RTR Interfaces Many books are available to assist the developer with both design and development, including: • J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, San Mateo, CA, 1992 • Philip A.
RTR Management RTR Management You can manage RTR from several locations: RTR Administrator • from a node on which RTR is running • from a remote node from which you send RTR commands to a node running RTR • from a web browser that can be on or access a node running RTR With the RTR Administrator, you have a network-browserlike display from which you can view RTR status and issue certain RTR commands with a point-and-click operation.
RTR Management Figure 4–3 RTR Manager http://nodename nodename nodename VM-1158A-AI RTR Explorer Figure 4–4 shows a sample screen of the RTR Explorer with several defined facilities. The RTR Explorer lets the system manager or administrator view the entire RTR configuration by facility and by node, and assess the state of the RTR network and the state of any individual node or facility in the network.
RTR Management Figure 4–4 RTR Explorer: View of All Facilities vm-1155A-AI Information available for each facility includes the facility name, the alerts associated with nodes participating in the facility, and the state of the facility. Information for each node includes its name, role, cluster name, partition names, partition states, node state, and alerts.
RTR Management Figure 4–5 RTR Explorer: View of One Facility http://nodename nodename Mode: Navigation Design Facility nodename nodename Generated by nodename with 8 seconds old information VM-1151A-AI Nodes can monitor themselves for alerts. Each alert can be set at progressive levels of severity – first Warning, second Error, and third Fatal. The severity of an alert indicates the urgency of the alert. Warning means RTR may or may not be operating normally, but something needs to be looked at.
RTR Management or group of nodes. If there are no flags, the node or group is operating normally. RTR Command Line Interface The command line interface (CLI) to the RTR API enables the programmer to write short RTR applications from the RTR command line. This can be useful for testing short program segments and exploring how RTR works. Figure 4–2 shows the RTR CLI interface. For example, the commands shown in Examples 4-1 to 4-4 start RTR and exchange a message between a client and a server.
RTR Management System responses begin with the characters %RTR-. Notes on the procedure are enclosed in square brackets [ ]. For clarity, commands you enter are shown in bold. You can view the status of a transaction with the SHOW TRANSACTION command. The exchange of messages you observe in executing these commands illustrates RTR activity. You need to retain a similar sequence in your own designs for starting up RTR and initiating your own application.
RTR Management Examples Example 4–1 The user issues the following commands on the server application where RTR is running on the backend. $ RTR Copyright 1994, 2003 Hewlett-Packard Development Company, L.P.
RTR Management Example 4–2 When the next command is issued, RTR waits for the message from the client, which does not appear until after the client sends it (Example 4-3). RTR> RTR_RECEIVE_MESSAGE/CHAN=S %RTR-S-OK, normal successful completion channel name: S msgsb msgtype: rtr_mt_msg1 msglen: 19 usrhdl: 0 Tid: 63b01d10,0,0,0,0,2e59,43ea2002 message offset bytes text 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 ay.
RTR Management Example 4–3 Commands and system response at client.
RTR Management Example 4–4 The following lines arrive at the client from RTR after the user enters commands at the server. %RTR-S-OK, normal successful completion channel name: C msgsb msgtype: rtr_mt_reply msglen: 25 usrhdl: 0 tid: 63b01d10,0,0,0,0,2e59,43ea2002 message offset bytes text 000000 41 6E 64 20 74 68 69 73 20 69 73 20 6D 79 20 72 And this is my r 000010 65 73 70 6F 6E 73 65 2E 00 esponse..
Application Programming Interfaces Application Programming Interfaces You write application programs and management applications with the RTR application programming interfaces. RTR Java Object-Oriented Interface You can use Java and J2EE technology to write applications that use RTR. For additional information on these technologies, see the documentation that is part of the JRTR downloadable kit.
Application Programming Interfaces Figure 4–6 RTR Service Provider JNDI Service Provider DataSource JRTR Server Application Connection Pool JDBC Driver VM-1181A-AI A database resource is represented by a datasource object. For the application to locate the datasource representing the database resource, a naming service that implements the Java Naming and Directory Interface (JNDI) must be present.
Application Programming Interfaces RTR C++ Object-Oriented Programming Interface You can use the object-oriented programming interface to write C++ applications that use RTR. For more information on the C++ object-oriented programming interface, refer to the HP Reliable Transaction Router C++ Foundation Classes manual and the HP Reliable Transaction Router Application Design Guide.
Application Programming Interfaces void CombinationOrderProcessor::StartProcessingOrdersAtoL() { // // Create an RTRKeySegment for all ASCII values between "A" and "L." // m_pkeyRange = new RTRKeySegment (rtr_keyseg_string, //To process strings. 1, //Length of the key. OffsetIntoApplicationProtocol, //Offset value. "A", //Lowest ASCII value for partition. "L"); //Highest ASCII value for partition.
Application Programming Interfaces Example 4–5 Creating a Facility with the C++ API // Use the C++ interface to create an RTR facility RTRFacilityManager::CreateFacilityWithAllRoles_3() { bool bOverallResult = true; //Create facility manager, abort if creation fails RTRFacilityManager * pFacilityManager; pFacilityManager = new RTRFacilityManager; if ( IsFailure(pFacilityManager != NULL) ) { return false; } // Create the facility rtr_status_t stsCreateFacility; stsCreateFacility = pFacilityManager->CreateFa
Application Programming Interfaces Example 4–6 Starting RTR with the C++ API //Start RTR. RTR rtr; rtr.Start(); Example 4–7 Creating a Facility with the C++ API //Create facility named "myFacility". RTRFacilityManager FacMgr; rtr_status_t sts = FacMgr.CreateFacility("myFacility", "router", "frontend", "backend", false, false) ; Example 4–8 Creating a Partition with the C++ API //Create a partition named "myPartition" in facility "myFacility.
Application Programming Interfaces Sample C client code Example of an open channel call in an RTR client program: Sample C server code Example of a receive message call in an RTR server program: status = rtr_open_channel(&Channel, Flags, Facility, Recipient, RTR_NO_PEVTNUM, Access, RTR_NO_NUMSEG, RTR_NO_PKEYSEG); if (Status != RTR_STS_OK) status = rtr_receive_message(&Channel, RTR_NO_FLAGS, RTR_ANYCHAN, MsgBuffer, DataLen, RTR_NO_TIMOUTMS, &MsgStatusBlock); if (status != RTR_STS_OK) A client can have
5 The RTR Environment The RTR environment has two parts: • System management environment • 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 using the RTR Administrator, Manager and Explorer or from the command line using the RTR CLI.
The RTR System Management Environment • Sends messages between nodes • 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.
The RTR System Management Environment 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) Figure 5–1 illustrates the RTR system management environment.
The RTR System Management Environment Figure 5–1 RTR System Management Environment FE TR RTRACP RTRACP BE RTRACP RTRD RTRD RTRD RTR COMSERV RTR COMSERV RTR COMSERV RTR CLI RTR CLI Management Station Running Browser Software VM-0841A-AI Transaction Management The RTR transaction is the heart of an RTR application, and transaction state characterizes the current condition of a transaction. As a transaction passes from one state to another, it undergoes a state transition.
The RTR System Management Environment Transaction journal state describes how a transaction progresses from the point of view of the RTR journal. The transaction journal state, not seen by frontends and routers, managed by the backend, is used by RTR for recovery replay of a transaction after a failure. Transaction server state, also managed by the backend, describes how a transaction progresses from the point of view of the server.
The RTR System Management Environment • Overriding the automatic recovery procedures of RTR with manual recovery procedures, for added flexibility • Specifying retry limits for problem transactions The operator can selectively inspect transactions, modify states, or remove transactions from the journal or the running RTR system. This allows for greater operational control and enhanced management of a system where RTR is running.
What’s Next? Figure 5–2 RTR Runtime Environment FE TR BE LIBRTR/RTRDLL LIBRTR/RTRDLL LIBRTR/RTRDLL Client application Server application RTRACP RTRACP RTRACP RTRD RTRD RTRD RTR COMSERV RTR COMSERV RTR COMSERV RTR CLI RTR CLI Optional External Applet Not Running RTR VM-0842A-AI What’s Next? This concludes the material on RTR concepts and capabilities that all users and application designers and implementors should know.
What’s Next? If you are: Read these documents in this order: a system manager, system administrator, or software installer 1. RTR Release Notes 2. RTR Installation Guide 3. RTR System Manager’s Manual If you are: Read these documents: an applications or system management designer, developer, programmer, or software engineer 1.
Glossary ACID Transaction properties supported by RTR: atomicity, consistency, isolation, durability. For additional information, see the section on Transaction Integrity in Chapter 2. 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++, C, or Java; RTR is also XA compliant.
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.
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.
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.
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.
JNDI Java Naming and Directory Interface, an API providing such functions to applications written in the Java programming language. Connection pools and datasources are registered with a JNDI service. 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.
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.
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.
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.
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 JNDI. Service providers are used with the JNDI API. shadow The state of the server process that services a copy of the data store or primary database.
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.
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.
Index A ACID properties, 2–5 Anonymous client, 1–25 API, 4–1 Applet, 1–12 Application distributed, 2–5 RTR, 1–5 software, 2–3 Application logging, 3–2 Authentication, 1–23, 3–2 B Backend, 2–1 loss, 3–3 recovery, 3–3 BE, 2–1 Broadcast, 2–4 C Callout server, 1–22, 1–23, 3–2 Callout server, 1–22 Channel, 1–6 Check authentication, 1–23 Client, 1–5 anonymous, 1–25 processes, 2–2 Cluster standby, 1–18 Commit two-phase, Glossary–12 Concurrent server, 1–21, 3–1 Configuration RTR, 1–6 Connectionpool, Glossary–3 C
I O ID transaction, 1–10 J J2EE, 2–11 Java, 2–11 Journal RTR, 1–16 Object-oriented, 2–6 Oracle RDBMS, 2–11 P Key range, 1–18, 1–23 Parallel execution, 2–5 Partition, 1–23, Glossary–7 Partitioned data model, 2–6 Polymorphism, 2–10 Processes client, 2–2 server, 2–2 L R LAN, 1–26 Link failure recovery, 3–3 Load balance, 1–19 Lock database, 2–6 Logging application, 3–2 Range key, 1–23 RDBMS, 2–11 Recovery, 3–3 Reliability features, 3–1 Resource manager, 2–11 RM, 2–11 Roles, 1–7 Router, 2–1 failover,
Runtime environment, 5–6 S Security check, 1–23 Server, 1–6 callout, 1–22, 1–23, 3–2 concurrent, 1–21, 3–1 shadow, 1–15, 3–2 spare, 1–18 standby, 1–14, 1–18, 3–2 standby configuration, 1–25 transactional shadow, 1–19 types, 3–1 Serviceprovider, Glossary–10 Shadow server, 1–15, 1–20, 3–2 Shadowing disk, 1–17 transactional, 1–15, 1–17 Shadow server transactional, 1–19 Shared database, 2–6 Spare server, 1–18 SQL server, 2–11 Standby cluster, 1–18 server, 1–14, 1–18, 3–2 Standby server configuration, 1–25 Subs
