Routing transactions in the presence of failing servers

#This invention disclosed in this application is related in subject matter to that disclosed in copending application entitled "Workload Manager for Achieving Transaction Class Response Time Goals in a Multiprocessing System," Ser. No. 07/876,670 filed on Apr. 30, 1992, by D. Ferguson, L. Georgiadis and C. Nikolaou and assigned to a common assignee. The subject matter of application Ser. No. 07/876,670 is incorporated herein by reference.

#1. Field of the Invention

#The present invention generally relates to transaction processing systems and, more particularly, to a mechanism for routing transactions to servers in a transaction processing system in which the servers may cause transaction failures.

#The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

#FIG. 1 is a schematic diagram illustrating a generalized transaction processing system employing a single transaction router;

#FIG. 2 is a schematic diagram illustrating in more detail a transaction processing system in a network environment using multiple transaction routers;

#Referring again to the drawings, and more particularly to FIG. 2, there is shown in more detail a typical transaction processing system such as, for example, IBM's ACP on which the subject invention may be implemented. This is a multiprocessing system comprising a plurality of computer systems 20.sub.1, 20.sub.2, . . . , 20.sub.n connected by a network 21. The computer systems, or servers, may be micro, mini or mainframe computer systems, and the network may be a local area network (LAN), wide area network (WAN), such as a T1/T3 telecommunications network, or a combination of LANs and WAN. Each of these computer systems access and store data in memory and on direct access storage devices (DASDs) attached to the computer systems. The DASDs provide storage for one or more databases which are accessed for reads and updates during a transaction. These DASDs may be, for example, disk drives 20.sub.11 and 20.sub.12 shown attached to computer system 20.sub.1, disk drives 20.sub.21 and 20.sub.22 shown attached to computer system 20.sub.2, and so forth. Each of the computer systems also have attached a plurality of terminals by which users input various transactions. Thus, for example, terminals 20.sub.13, 20.sub.14 and 20.sub.15 are shown attached to computer system 20.sub.1. These terminals may be smart terminals capable of local processing, such as personal computers similar to IBM's PS/2 personal computers, or so-called dumb terminals, such as IBM 3278 terminals. Each transaction generally processes user input data, performs reads and updates against one or more databases, executes application code and returns results to the user. There may be multiple interactions between a user and an executing program. The basic function and operation of transaction processing systems of the type illustrated in FIG. 2 is well understood in the art, and further information may be had by reference to one of the standard text books, such as C. J. Date, An Introduction to Database Systems, vol. 2, Addison-Wesley Co. (1983).

#FIG. 3 shows in simplified block diagram form the relationships between the several routers and computer systems of the transaction processing system shown in FIG. 2. Observe that each computer system may be a server to every other computer system, including itself. Thus, router 1 at computer system 1 receives transactions and routes the transactions according to some algorithm to one of the several available computer systems 1 to N. Similarly, router 2 at computer system 2 receives transactions and routes these transactions according to an algorithm to one of the computer systems 1 to N.

#The invention is a mechanism for routing transactions in the presence of faulty systems such that: