Compaq Reliable Transaction Router Bedienungsanleitung

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

Zur Seite of

Richtige Gebrauchsanleitung

Die Vorschriften verpflichten den Verkäufer zur Übertragung der Gebrauchsanleitung Compaq Reliable Transaction Router an den Erwerber, zusammen mit der Ware. Eine fehlende Anleitung oder falsche Informationen, die dem Verbraucher übertragen werden, bilden eine Grundlage für eine Reklamation aufgrund Unstimmigkeit des Geräts mit dem Vertrag. Rechtsmäßig lässt man das Anfügen einer Gebrauchsanleitung in anderer Form als Papierform zu, was letztens sehr oft genutzt wird, indem man eine grafische oder elektronische Anleitung von Compaq Reliable Transaction Router, sowie Anleitungsvideos für Nutzer beifügt. Die Bedingung ist, dass ihre Form leserlich und verständlich ist.

Was ist eine Gebrauchsanleitung?

Das Wort kommt vom lateinischen „instructio”, d.h. ordnen. Demnach kann man in der Anleitung Compaq Reliable Transaction Router die Beschreibung der Etappen der Vorgehensweisen finden. Das Ziel der Anleitung ist die Belehrung, Vereinfachung des Starts, der Nutzung des Geräts oder auch der Ausführung bestimmter Tätigkeiten. Die Anleitung ist eine Sammlung von Informationen über ein Gegenstand/eine Dienstleistung, ein Hinweis.

Leider widmen nicht viele Nutzer ihre Zeit der Gebrauchsanleitung Compaq Reliable Transaction Router. Eine gute Gebrauchsanleitung erlaubt nicht nur eine Reihe zusätzlicher Funktionen des gekauften Geräts kennenzulernen, sondern hilft dabei viele Fehler zu vermeiden.

Was sollte also eine ideale Gebrauchsanleitung beinhalten?

Die Gebrauchsanleitung Compaq Reliable Transaction Router sollte vor allem folgendes enthalten:
- Informationen über technische Daten des Geräts Compaq Reliable Transaction Router
- Den Namen des Produzenten und das Produktionsjahr des Geräts Compaq Reliable Transaction Router
- Grundsätze der Bedienung, Regulierung und Wartung des Geräts Compaq Reliable Transaction Router
- Sicherheitszeichen und Zertifikate, die die Übereinstimmung mit entsprechenden Normen bestätigen

Warum lesen wir keine Gebrauchsanleitungen?

Der Grund dafür ist die fehlende Zeit und die Sicherheit, was die bestimmten Funktionen der gekauften Geräte angeht. Leider ist das Anschließen und Starten von Compaq Reliable Transaction Router zu wenig. Eine Anleitung beinhaltet eine Reihe von Hinweisen bezüglich bestimmter Funktionen, Sicherheitsgrundsätze, Wartungsarten (sogar das, welche Mittel man benutzen sollte), eventueller Fehler von Compaq Reliable Transaction Router und Lösungsarten für Probleme, die während der Nutzung auftreten könnten. Immerhin kann man in der Gebrauchsanleitung die Kontaktnummer zum Service Compaq finden, wenn die vorgeschlagenen Lösungen nicht wirksam sind. Aktuell erfreuen sich Anleitungen in Form von interessanten Animationen oder Videoanleitungen an Popularität, die den Nutzer besser ansprechen als eine Broschüre. Diese Art von Anleitung gibt garantiert, dass der Nutzer sich das ganze Video anschaut, ohne die spezifizierten und komplizierten technischen Beschreibungen von Compaq Reliable Transaction Router zu überspringen, wie es bei der Papierform passiert.

Warum sollte man Gebrauchsanleitungen lesen?

In der Gebrauchsanleitung finden wir vor allem die Antwort über den Bau sowie die Möglichkeiten des Geräts Compaq Reliable Transaction Router, über die Nutzung bestimmter Accessoires und eine Reihe von Informationen, die erlauben, jegliche Funktionen und Bequemlichkeiten zu nutzen.

Nach dem gelungenen Kauf des Geräts, sollte man einige Zeit für das Kennenlernen jedes Teils der Anleitung von Compaq Reliable Transaction Router widmen. Aktuell sind sie genau vorbereitet oder übersetzt, damit sie nicht nur verständlich für die Nutzer sind, aber auch ihre grundliegende Hilfs-Informations-Funktion erfüllen.

Inhaltsverzeichnis der Gebrauchsanleitungen

  • Seite 1

    Reliable T ransaction Router Getting Started Order Number: AA-RLE1A-TE January 2001 This document introduces Reliable T ransaction Router and describes its concepts for the system manager , system administrator , and applications programmer . Revision/Update Information: This is a new manual. Software V ersion: Reliable T ransaction Router V ersion[...]

  • Seite 2

    © 2001 Compaq Computer Corporation Compaq, the Compaq logo, AlphaServer , T ruCluster , V AX, and VMS Registered in U. S. Patent and T rademark Office. DECnet, OpenVMS, and P ATHWORKS are trademarks of Compaq Information T echnologies Group, L.P . Microsoft and W indows NT are trademarks of Microsoft Corporation. Intel is a trademark of Intel Cor[...]

  • Seite 3

    Contents Preface ..................................................... vii 1 Introduction Reliable T ransaction Router . . ........................... 1–1 RTR Continuous Computing Concepts . . ................... 1–2 RTR T erminology . . ................................... 1–3 RTR Server T ypes . ................................... 1–15 RTR[...]

  • Seite 4

    3 Reliability Features Servers . . ........................................... 3–1 Failover and Recovery ................................. 3–2 Router Failover ................................... 3–2 Recovery Scenarios . ................................... 3–2 Backend Recovery ................................. 3–3 Router Recovery .........[...]

  • Seite 5

    Figures 1 RTR Reading Path ................................. x 1–1 Client Symbol . ................................... 1–4 1–2 Server Symbol . ................................... 1–5 1–3 Roles Symbols . ................................... 1–6 1–4 Facility Symbol ................................... 1–6 1–5 Components in the RTR Env[...]

  • Seite 6

    [...]

  • Seite 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 T ransaction Router (RTR) product. Document Structure This document contains the following chapters: • Chapter 1, Introduction to RTR, provides information on RTR techn[...]

  • Seite 8

    Related Documentation Additional resources in the RTR documentation kit include: Document Content For all users: Reliable T ransaction Router Release Notes Describes new features, changes, and known restrictions for RTR. RTR Commands Lists all RTR commands, their qualifiers and defaults. For the system manager: Reliable T ransaction Router Install[...]

  • Seite 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 . Conventions This manual adopts the foll[...]

  • Seite 10

    Figure 1 RTR Reading Path Cov er letter ZK O-GS015-99AI SPD Release Notes Getting Star ted System Manager Application Programmer Installation Guide Migration Guide System Manager's Manual Commands If V2 to V3 = T utorial Application Design Guide C++ F oundation Classes C Application Programmer's Reference Manual If C++ x[...]

  • Seite 11

    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 T ransaction Router (RTR). Reliable T ransaction Router Reliable T ransaction Router (RTR) is failure-tolerant transactional messa[...]

  • Seite 12

    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: • Reliability • Failure to[...]

  • Seite 13

    RTR T erminology RTR T erminology 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: • Application • Client, client application • Serv[...]

  • Seite 14

    RTR T erminology 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 any language, commonly C or C++, an[...]

  • Seite 15

    RTR T erminology Figure 1–2 Server Symbol Channel RTR expects client and server applications to identify themselves 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 applica[...]

  • Seite 16

    RTR T erminology Figure 1–3 Roles Symbols FE BE TR Facility The mapping between nodes and roles is done using a 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 [...]

  • Seite 17

    RTR T erminology Figure 1–5 Components in the RTR Environment LKG-11203-98WI User Accounts F acility FE TR BE General Ledger F acility Client application Server application disconnected before all parts of the transaction are done, then the transaction remains incomplete. T ransaction A transaction is a piece of work or group of operations that m[...]

  • Seite 18

    RTR T erminology 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 me[...]

  • Seite 19

    RTR T erminology Figure 1–6 T wo-Tier Client/Server Environment LKG-11204-98WI Database Ser v er DM Application Presentation and Business Logic (ODBC Model) Figure 1–7 Three-Tier Client/Server Environment LKG-11205-98WI Presentation/ User Interf ace Application Ser v er/ Business Logic Database Ser v er DB Server Database Application RTR provid[...]

  • Seite 20

    RTR T erminology All components can reside on a single node but are typically deployed on different nodes to achieve modularity , scalability , and redundancy for availability . W ith different systems, if one physical node goes down or off line, another router and backend node takes over . In a slightly different configuration, you could have an [...]

  • Seite 21

    RTR T erminology 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 LKG-11207-98WI Browser TR BE FE DB When creating the configuration used by an application and defining the nodes where a facility has its frontend[...]

  • Seite 22

    RTR T erminology 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–1 1. Figure 1–1 1 RTR Deployed on Three Nodes LKG-11209-98WI Browser[...]

  • Seite 23

    RTR T erminology Figure 1–12 Standby Server Configuration LKG-11210-98WI TR BE DB BE Ser v er Ser v er Primary Server Standby Server T ransactional shadowing T o increase transaction availability , transactions can be shadowed with a shadow server . This is called transactional shadowing and is accomplished by having a second location, often at [...]

  • Seite 24

    RTR T erminology Figure 1–13 T ransactional Shadowing Configuration LKG-11211-98WI TR BE BE Ser v er Ser v er Primary Server Shadow Server FE W ith transactional shadowing, there is no requirement that hardware, the data store, or the operating system at different sites be the same. Y ou could, for example, have one site running OpenVMS and anot[...]

  • Seite 25

    RTR Server T ypes Figure 1–14 T wo Sites: T ransactional and Disk Shadowing with Standby Servers LKG-11212-98WI Disk Shadowing FE TR BE BE BE BE TR T ransactional Shadowing Standby Server or Router RTR Server T ypes In the RTR environment, in addition to the placement of frontends, routers, and servers, the application designer must determine wha[...]

  • Seite 26

    RTR Server T ypes • Concurrent servers • Callout servers These are described in the next few paragraphs. Y ou specify server types to your application in RTR API calls. RTR server types help to provide continuous availability and a secure transactional environment. Standby server The standby server remains idle while the RTR primary backend ser[...]

  • Seite 27

    RTR Server T ypes 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[...]

  • Seite 28

    RTR Server T ypes 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. Sites can be geographically remote, for example, available at se[...]

  • Seite 29

    RTR Server T ypes channels within a single process or as one channel in separate processes. Figure 1–17 Concurrent Servers BE Ser v er1 A-N Ser v er2 Ser v er3 Ser v er4 LKG-11275-98WI Callout server The callout server provides message authentication on transaction requests made in a given facility , and could be used, for example, to provide aud[...]

  • Seite 30

    RTR Server T ypes Figure 1–18 A Callout Server T ransaction To P ar tition A TR Callout Server Application Server BE User Accounts F acility LKG-11276-98WI Authentication RTR callout servers provide partition-independent processing for authentication. For example, a callout server can enable checks to be carried out on all requests in a given fac[...]

  • Seite 31

    RTR Server T ypes Partition When working with database systems, partitioning the database 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 diff[...]

  • Seite 32

    RTR Server T ypes 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 CREA TE P ARTITION command. F[...]

  • Seite 33

    RTR Networking Capabilities Figure 1–20 Standby with Partitioning LKG-11214-98WI Router 1-19999 1-19999 1-19999 1-19999 Accounts: 1-19999 20000-39999 20000-39999 20000-39999 Application Ser v erA Application Ser v erB RTR Networking Capabilities Depending on operating system, RTR uses TCP/IP or DECnet as underlying transports for the virtual netw[...]

  • Seite 34

    [...]

  • Seite 35

    2 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 physi[...]

  • Seite 36

    The Three-Layer Model Figure 2–1 The Three Layer Model DB BE Ser v er BE Ser v er TR FE Client FE Client FE Client DB T er minals F rontends (FE) Routers (TR) Back ends (BE) Database (DB) DB FE Client TR BE Ser v er ZK O-GS011-99AI • Allows performance or geographic expansion while protecting the investments made in existing hardware and applic[...]

  • Seite 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 rtr_open_channel( ) routine to declare a channel as a client or server , it specifies the name of the[...]

  • Seite 38

    Flexibility and Growth • User access patterns • The volume of data Since an RTR-based system can be built using multiple systems at each functional layer , it easily lends itself to step-by-step growth, avoiding unused capacity at each stage. W ith your system still up and running, it is possible to: • Create and delete concurrent server proc[...]

  • Seite 39

    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. Users compete for a shared database in three ways: •[...]

  • Seite 40

    Object-Oriented Programming Figure 2–2 Partitioned Data Model DB BE Ser v er BE Ser v er TR FE Client FE Client FE Client DB T er minals F rontends (FE) Routers (TR) Back ends (BE) Database (DB) DB FE Client TR BE Ser v er ZK O-GS012-99AI 2–6 Architectural Concepts[...]

  • Seite 41

    Object-Oriented Programming T able 2–1 Functional and Object-Oriented Programming Compared 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 progr[...]

  • Seite 42

    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 • Destructors:[...]

  • Seite 43

    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[[...]

  • Seite 44

    XA Support XA Support The XA interface is part of the X/Open DTP (Distributed T ransaction 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.[...]

  • Seite 45

    3 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[...]

  • Seite 46

    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 com[...]

  • Seite 47

    Recovery Scenarios Backend Recovery If standby or shadow servers are available on another backend 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,[...]

  • Seite 48

    [...]

  • Seite 49

    4 RTR Interfaces RTR provides interfaces for management and application programming. Y ou manage RTR with a management interface from the RTR management station. The management interfaces are: • The command line interface or CLI • The browser interface The application programming interfaces (APIs) are: • The object-oriented API for C++ progra[...]

  • Seite 50

    The RTR application programming interfaces are identical on all hardware and operating system platforms that support RTR. The object-oriented API is fully described in the manual Reliable T ransaction Router C++ Foundation Classes . The C- programming API is fully described in the Reliable T ransaction Router C Application Programmer ’ s Referenc[...]

  • Seite 51

    RTR Management Station 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 res[...]

  • Seite 52

    RTR Management Station [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" %RTR-I-SRVDISCON, s[...]

  • Seite 53

    RTR Management Station 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. reason: Ox00000000 RTR> RTR_R[...]

  • Seite 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: 8 message status: normal successful completion reason: Ox00000000 RTR> RTR_START_TX/CHAN=C %RTR-S-OK, normal successful completion RTR> RTR_SEND_TO_SERVER[...]

  • Seite 55

    RTR Management Station RTR> RTR_RECEIVE_MESSAGE %RTR-S-OK, normal successful completion channel name: S . . . msgtype: rtr_mt_accepted . . . RTR> STOP RTR Browser Interface W ith the RTR browser interface, your management station has a network-browser-like display from which you can view RTR status and issue RTR certain commands with a point-[...]

  • Seite 56

    Application Programming Interfaces Figure 4–1 RTR Browser Interface Sample C++ client code Example of object creation in an RTR client program. // // Create a Transaction Controller to receive incoming messages // and events from a client. // RTRClientTransactionController *pTransaction = new RTRClientTransactionController(); // // Create an RTRD[...]

  • Seite 57

    Application Programming Interfaces Sample C++ server code Example of object creation in an RTR server program. 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, //Len[...]

  • Seite 58

    Application Programming Interfaces Sample C client code Example of an open channel call in an RTR client program: status = rtr_open_channel(&Channel, Flags, Facility, Recipient, RTR_NO_PEVTNUM, Access, RTR_NO_NUMSEG, RTR_NO_PKEYSEG); if (Status != RTR_STS_OK) Sample C server code Example of a receive message call in an RTR server program: statu[...]

  • Seite 59

    5 The RTR Environment The RTR environment has two parts: • The system management environment • The runtime environment The RTR System Management Environment Y ou manage your RTR environment from a management station, which can be on a node running RTR or on some other node. Y ou can manage your RTR environment either from your management statio[...]

  • Seite 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: • F ACILITY • S[...]

  • Seite 61

    The RTR System Management Environment The Command Server Process executes commands both locally and across nodes. Commands that can be executed at the RTR COMSER V include: • ST ART RTR • CREA TE/MODIFY JOURNAL • SHOW LINK/F ACILITY/SER VER/CLIENT (ACP must be running) • Application programmer commands (for testing and demonstration) The RT[...]

  • Seite 62

    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. A full list of RTR Moni[...]

  • Seite 63

    The RTR System Management Environment Partition Management Partitions are subdivisions of a routing key range of values used 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 starte[...]

  • Seite 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[...]

  • Seite 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: Read these documents: a system manager , system administrator , or software installer 1. RTR Release Notes 2. RTR Installation Guide 3. RTR Migration Guide (i[...]

  • Seite 66

    [...]

  • Seite 67

    Glossary A few additional terms are defined in the Glossary to the Reliable T ransaction Router Application Design Guide . ACID T ransaction 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 o[...]

  • Seite 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 [...]

  • Seite 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. CPU Central processing unit. data marshalling The capability of using systems of different architectures (big endian, little endian) within one application. d[...]

  • Seite 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 transacti[...]

  • Seite 71

    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 t[...]

  • Seite 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 [...]

  • Seite 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. properties Application, transaction and system information. property class[...]

  • Seite 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. RTR configuration The set of nodes, disk drives, and[...]

  • Seite 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 . SMP Symmetric MultiProcessing. standby The state of the partition that can take over if the process for which it is on standby is una[...]

  • Seite 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:[...]

  • Seite 77

    Index A ACID, 2–4 Anonymous client, 1–22 API, 4–1 Application distributed, 2–4 software, 2–2 Authentication, 1–20 B Backend, 2–1 loss, 3–3 BE, 2–1 Broadcast, 2–3 C Callout server, 1–20, 3–1 Client anonymous, 1–22 processes, 2–1 Concurrent server, 3–1 D Database, 2–1, 2–2 locks, 2–5 shared, 2–5 Data model partit[...]

  • Seite 78

    N Network wide area, 1–18 Nodes, 2–2 O Object-oriented, 2–5 Oracle RDBMS, 2–10 P Parallel execution, 2–4 Partitioned data model, 2–5 Processes client, 2–1 server, 2–1 R 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 RTR API, 4–1 b[...]