Transaction processing method, system, and program

Abstract

To provide a transaction processing method response to a constrained resource event, a system, and a program.SOLUTION: A resource manager (RM) instance is associated with each transaction processing system (TPS) member, of a TPS group. Each RM instance monitors performance of the associated TPS member. If a TPS member becomes unavailable for any reason (a failing TPS), the associated RM instance broadcasts status of the failing TPS to RMs associated "surviving" members of the group. RM instances associated with surviving members initiate a series of actions that reduce the resources used by the surviving TPS members. Once the failing TPS is brought back online and made available again (or a replacement TPS is brought online), RM instances associated with the surviving members perform actions to undo the resource usage reduction tasks, and the TPS group returns to a nominal configuration.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to the field of transaction processing, and more particularly to transaction processing systems that respond to constrained resource events. [Background technology]

[0002] A transaction processing system (TPS) receives transaction requests and processes them in near real time. Transactions may involve banking transactions, credit / debit card, database, or ticket sales transactions, or any combination of these, to name a few. A TPS may include many individual systems working together to process a large volume of incoming transaction requests within response time specifications. Characteristics of a TPS include uninterrupted availability, data integrity, even if some TPS components fail, and the ability to scale as workloads change. Summary of the Invention [Problem to be solved by the invention]

[0003] A transaction processing method, system, and program that responds to constrained resource events is provided. [Means for solving the problem]

[0004] According to one aspect of the present invention, there is provided a method, computer program product, or system, or combination thereof, that performs (not necessarily in this order): (i) determining that a first status of a first Transaction Processing System (TPS) member of a group of TPS members is "unavailable"; (ii) in response to determining the first status of the first TPS member, broadcasting a first message to a second TPS member of the group of TPS members, the first message including information regarding the first status of the first TPS member; and (iii) in response to receiving the first message, implementing a resource usage reduction action by the second TPS member. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram illustrating a system in accordance with at least one embodiment of the present invention. [Figure 2] 1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. [Figure 3] FIG. 1 is a block diagram illustrating the machine logic (e.g., software) portion of a system in accordance with at least one embodiment of the present invention. [Figure 4] 1 is a block diagram illustrating a transaction processing system in accordance with at least one embodiment of the present invention. [Figure 5A] 1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. [Figure 5B] 1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. [Figure 5C] 1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. [Figure 5D] 1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. [Figure 5E]1 is a flowchart illustrating a method performed, at least in part, in accordance with at least one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0006] Some embodiments of the present invention add a resource manager (RM) component to a transaction processing system (TPS). More specifically, an instance of the RM is hosted by each TPS member of a TPS group. Each RM instance monitors the performance of its host TPS. If a TPS member goes down or becomes unavailable to process incoming transactions, the RM instance hosted by the failed TPS broadcasts the status of the failed TPS to other (surviving) members of the TPS group. The RM instances hosted by the surviving members of the TPS group initiate a series of actions to reduce the resources used by their corresponding surviving members so that the surviving members can better handle the additional workload imposed on them due to the unavailability of the failed TPS. Thus, the surviving TPS members can better handle the additional workload imposed on them due to the unavailability of the failed TPS. When the failed TPS (or an alternative TPS) is brought back into service and made available again, the RM instance hosted by the surviving members of the TPS group performs actions to release the resource usage reduction task, and the TPS group returns to its normal configuration.

[0007] This "Detailed Description" section is divided into the following subsections: (i) Hardware and Software Environment, (ii) Exemplary Embodiments, (iii) Other Notes and / or Embodiments, and (iv) Definitions.

[0008] I. Hardware and Software Environment The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may also include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to implement aspects of the present invention.

[0009] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media may include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge structure in a groove in which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted over electrical wires.

[0010] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0011] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or conventional procedural programming languages, such as object-oriented programming languages ​​like Smalltalk, C++, and the "C" programming language, or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by personalizing the electronic circuitry using state information of the computer-readable program instructions.

[0012] Aspects of the present invention will be described with reference to flowchart illustrations and / or block diagrams that illustrate methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0013] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, form a machine that implements the functions / acts specified in the blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the blocks of the flowcharts and / or block diagrams.

[0014] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to realize a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0015] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed as a single step, in parallel, substantially in parallel, or with partial or full overlap, depending on the functionality involved, or the blocks may even be executed in the reverse order. It will also be understood that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or may embody a combination of dedicated hardware and computer instructions.

[0016] One embodiment of a possible hardware and software environment for the software and / or methods according to the present invention is described in detail below with reference to the drawings: Figure 1 is a functional block diagram illustrating various portions of a networked computer system 100, including a storage subsystem 102, a client computer 104, a transaction processing system (TPS) 106, a communication network 114, a resource manager (RM) server computer 200, a communication unit 202, a processor set 204, an input / output (I / O) interface set 206, memory 208, persistent storage 210, a display 212, an external device 214, a random access memory (RAM) 230, a cache 232, and a resource manager (RM) 300.

[0017] Storage subsystem 102 is in many ways representative of various computer subsystems in the present invention, and therefore the following paragraphs will describe several portions of storage subsystem 102.

[0018] Storage subsystem 102 can be a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, personal digital assistant (PDA), smartphone, or any programmable electronic device capable of communicating with a client subsystem over communications network 114. RM 300 is a collection of machine-readable instructions and / or data used to create, manage, and control certain software functions detailed in the "Illustrative Embodiments" subsection of the "Detailed Description of the Invention" section below.

[0019] The storage subsystem 102 can communicate with other computer subsystems via a communications network 114. The communications network 114 can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and can include wired, wireless, or fiber optic connections. In general, the communications network 114 can be any combination of connections and protocols that support communication between server and client subsystems.

[0020] The storage subsystem 102 is shown as a block diagram using a number of double-headed arrows. These double-headed arrows (without separate reference numbers) represent a communications fabric that provides communication between the various components of the storage subsystem 102. This communications fabric may be implemented using any architecture designed to pass data and / or control information between processors (such as microprocessors, communications and network processors), system memory, peripheral devices, and any other hardware components in the system. For example, the communications fabric may be implemented, at least in part, by one or more buses.

[0021] Memory 208 and persistent storage 210 are computer-readable storage media. In general, memory 208 may include any suitable volatile or non-volatile computer-readable storage medium. Furthermore, it should be noted that, currently or in the foreseeable future, (i) external devices 214 may be able to provide some or all of the memory for storage subsystem 102, and / or (ii) devices external to storage subsystem 102 may be able to provide memory for storage subsystem 102.

[0022] RM 300 is typically stored in persistent storage 210 for access and / or execution by one or more of the respective computer processor sets 204 via one or more of the memories 208. Persistent storage 210 (i) is at least more persistent than signals in transmission, (ii) stores the program (including its soft logic and / or data) on a tangible medium (such as the magnetic or optical domain), and (iii) is substantially less persistent than permanent storage. Alternatively, data storage may be more persistent and / or permanent than the type of storage provided by persistent storage 210.

[0023] RM 300 may include both machine-readable and executable instructions and / or tangible data (i.e., the kind of data stored in a database). In this particular embodiment, persistent storage 210 includes a magnetic hard disk drive. To name a few possible types, persistent storage 210 may include a solid-state hard drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0024] The media used by persistent storage 210 may be removable. For example, a removable hard drive may be used for persistent storage 210. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer to another computer-readable storage medium that is also part of persistent storage 210.

[0025] Communications unit 202, in these examples, provides for communication with other data processing systems or devices external to storage subsystem 102. In these examples, communications unit 202 includes one or more network interface cards. Communications unit 202 may provide communication using either or both physical and wireless communications links. Any software modules described herein may be downloaded to a persistent storage device (e.g., persistent storage 210) via a communications unit (e.g., communications unit 202).

[0026] The I / O interface set 206 enables input and output of data to and from other devices locally connectable in data communication with the server computer 200. For example, the I / O interface set 206 provides a connection to external devices 214. The external devices 214 may include devices such as a keyboard, keypad, touch screen, or any other suitable input device or combination thereof. The external devices 214 may also include portable computer-readable storage media, such as thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to implement embodiments of the present invention, such as the RM 300, may be stored on such portable computer-readable storage media. In these embodiments, all or part of the applicable software may (or may not) be loaded into persistent storage 210 via the I / O interface set 206. The I / O interface set 206 also connects in data communication with a display device 212.

[0027] Display device 212 provides a mechanism for displaying data to a user and may be, for example, a computer monitor or a smartphone display screen.

[0028] The programs described herein are identified based on the applications for which they are implemented in particular embodiments of the invention. However, it should be understood that any specific program designations herein are used for convenience only, and that the present invention should not be limited to use with only any particular application identified and / or implied by such designations.

[0029] The description of various embodiments of the present invention is presented for illustrative purposes only and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over commercially available technologies, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0030] II. Illustrative Embodiments Figure 2 shows a flowchart 250 illustrating a method in accordance with the present invention. Figure 3 shows a resource manager (RM) 300 for performing at least some of the method operations of flowchart 250. The method and associated software will now be described in the following paragraphs with detailed reference to Figure 2 (for method operation blocks) and Figure 3 (for software blocks).

[0031] Processing begins at operation S255, in which daemon module 302 of resource manager (RM 300) determines the status of a first transaction processing system (first TPS) member associated with RM 300 as "unavailable." The first TPS is a member of a group of TPS members that work together to process incoming transaction requests. In some embodiments, RM 300 is hosted by the first TPS, and each TPS member of the group hosts a separate instance of RM 300. Alternatively, in some embodiments, one or more instances of RM 300 are external to the associated TPS member (e.g., on separate computer hardware) so that RM 300 can continue to operate in the event of a TPS member failure and is unaffected by the TPS failure.

[0032] RM300 monitors the first TPS member for conditions affecting the first TPS member's ability to process transaction requests, including incoming requests and requests already in progress. RM300 monitors the first TPS member by observing one or more characteristics related to the first TPS member's performance and / or availability. Examples of characteristics include the rate of incoming transactions, where a sudden and / or unexpected decrease in rate may indicate a network failure, an abnormally long time to process a transaction may indicate central processing unit (CPU) throttling due to a thermal issue, transaction processing time, CPU clock frequency, frequency, number or rate of errors, or a combination thereof, CPU utilization, memory read and / or write latency, or any other measure related to memory access, storage read and / or write latency, or any other measure related to storage access, or network communication conditions, to name a few.

[0033] Examples of conditions that may affect the availability of TPS members include, but are not limited to, network failures or disruptions, hardware failures (such as processors, storage or memory devices, or power interruptions), software failures (such as operating system, virtual machine or application crashes), or excessive workload resulting in TPS failure due to the exhaustion of computational, memory or storage resources, or any combination thereof.

[0034] The daemon module 302 further monitors for notification messages received by the first TPS or RM 300, which indicate the status (available, unavailable, etc.) of other TPS members of the group.

[0035] Processing continues to operation S260, where, in response to determining that the first TPS has become unavailable, the broadcast module 304 of the RM 300 sends a notification to all other members of the TPS group, including the second TPS member, the notification including information about the failure of the first TPS member.

[0036] Alternatively, in some embodiments, a manual or automatically generated command instructs the broadcast module 304 to send a notification to members of a TPS group, thereby instructing them to enter a "suppression" mode. While not in response to a TPS member failure, such a command may be issued to help a TPS group handle particularly heavy workloads, such as those that may occur periodically during certain "busy" times. Such resource consumption reduction actions may allow the TPS system to accommodate busy times without having to draw on more TPS processing resources.

[0037] Processing continues to operation 265, where, in response to receiving the notification, the throttling module 306 of the RM 300 associated with the second TPS member takes action (and / or causes the second TPS member to take action) to reduce resource usage by the second TPS member. In other words, the throttling module 306 causes the second TPS member to be reconfigured into a "throttling mode," thereby consuming fewer resources.

[0038] Once in "throttling mode", the second TPS member will reduce resource consumption by taking at least the following actions: making the Transaction Instance Block (TIB) lighter to use less memory, implementing a delay factor to make transaction flow more controllable, disabling diagnostic tracing, disabling TPS dumps (at least for infinity issues), and canceling idle transactions more frequently.

[0039] Processing continues to operation 270 where the daemon module 302 of the RM 300 determines that the status of the first TPS has returned to "available."

[0040] Alternatively, in some embodiments, the daemon module 302 of the RM 300 determines that a new TPS member has been added to the TPS group and that the status of the new TPS member is "available" and therefore replaces the first TPS member.

[0041] Processing continues to operation S272, where, in response to determining that the status of the first TPS has returned to an "available" status (or a new TPS member has become available in the TPS group), the broadcast module 304 of the RM 300 sends a notification to all other members of the TPS group, including the second TPS member, where the notification includes information regarding the first TPS member's return to availability (or replacement).

[0042] Processing continues to operation 280, where, in response to receiving the notification, the suppression module 306 of the RM 300 associated with the second TPS member overrides (releases) the action taken in operation S265 above, thereby returning the second TPS member to its normal processing configuration.

[0043] III. Other Notes and / or Embodiments A transaction processing system (TPS) contains multiple physical systems operating as a group to process incoming transaction workloads in real time. To facilitate the sharing of transaction workloads among TPS group members, individual transactions can be queued in one or more transaction queues. Each transaction can be processed by any one of the physical systems to meet the required response time criteria.

[0044] Each transaction processed by a TPS consumes system resources within the group member processing that transaction. The infrastructure for commonly processed transactions is duplicated among TPS members. However, for efficiency or other reasons, a subset of transactions (priority transactions) may be directed to a specific TPS member for processing. The physical system resources used by a TPS include the resources required to process commonly processed transactions (which may be processed by any TPS member) and the additional resources required to process priority transactions.

[0045] When a TPS group member experiences a catastrophic failure (i.e., the member is unable to process transactions), the general transaction workload must be distributed among the surviving TPS group members, thereby placing additional strain on the physical system resources associated with the surviving members. Additionally, each TPS group member creates infrastructure to process transactions that were previously prioritized only on the failed TPS group member. The resulting infrastructure for additional prioritized processing transactions requires an even greater level of physical system resources to be available among the remaining TPS group members.

[0046] If a TPS group member fails, the TPS group enters a "critical period" that begins when the TPS member fails and ends when the failed TPS member recovers and restarts or is replaced by a new member added to the group. During this critical period, the sudden increase in physical resource demands on surviving TPS group members may cause them to face sudden failures of their own, in a cascading effect due to reaching the resource limits of their respective physical systems.

[0047] Some embodiments of the present invention include methods and systems for creating a Resource Manager (RM) that enables members of a TPS to collaborate to handle large web-related banking workloads and to overcome catastrophic failures of one or more members of the TPS group.

[0048] The Resource Manager is a new component in each member of a TPS group. In the event of a catastrophic failure, the RM streamlines system resource usage on the remaining TPS group members to prevent system resource exhaustion and subsequent catastrophic failure of the remaining members.

[0049] The RM component is designed with four modes: (i) Ready mode, (ii) Broadcast mode, (iii) Suppress mode, and (iv) Return-to-Ready mode. These modes are described below.

[0050] Ready Mode - The RM is initialized and waits for notification of (i) catastrophic failures from the TPS system on which it is installed, and (ii) unavailability status messages sent by TPS group members in broadcast mode. In some embodiments, an RM instance hosted on a TPS system includes a daemon that takes one or more response actions when triggered by a notification message from the host TPS system or from another instance of the RM.

[0051] Broadcast mode - The RM enters broadcast mode to send TPS member "unavailable" and "available" status messages to surviving TPS group members.

[0052] In response to a TPS member experiencing a failure, the failed TPS member invokes the RM instance hosted by the failed TPS member and instructs the RM to enter "broadcast mode" to send an "unavailability" message to surviving TPS group members. In some embodiments, the RM instance enters "broadcast mode" in response to detecting a system termination process or other indicator of a failure regarding the TPS in which the RM instance is installed.

[0053] In response to the completion of the system restart process for the failed TPS member, the RM broadcast mode sends an "availability" message to the surviving TPS group members informing them that the previously failed TPS member is now available to resume processing transaction workloads within the TPS group.

[0054] Once the RM has finished sending its "availability" messages, it re-enters "ready mode".

[0055] Suppression mode - In response to receiving an "unavailability status" message corresponding to a failed TPS group member, the surviving TPS group member enters suppression mode. In suppression mode, the RM controls and reduces the system resources used by the surviving TPS group member. Suppression mode allows the surviving TPS system to take on the increased transaction workload sent to it that would normally have been sent to and processed by the failed TPS group member.

[0056] TPS group members remain in suppression mode for a critical period, which begins when the failed TPS group member fails and ends when the previously failed TPS group member recovers and restarts. More precisely, the critical period (for each surviving TPS group member) begins when the surviving TPS group member receives an "unavailability" message and ends when the surviving TPS group member receives an "availability" message. In some embodiments, the surviving TPS group members receive an "availability" message from a new TPS member added to the group that is (potentially) designed to replace the failed member.

[0057] In some embodiments of the present invention, the suppression mode includes the following tasks to reduce the use of system resources by surviving TPS group members during a "critical period" (during which the TPS group member is unavailable):

[0058] 1. Lighten the transaction instance block.

[0059] 2. Activate flood monitoring using weighting factors.

[0060] 3. Activate transaction flow control using delay time coefficients.

[0061] 4. Disable TPS diagnostic tracing.

[0062] 5. Disable TPS dumps for infinite problems.

[0063] 6. Start canceling idle transactions more frequently.

[0064] In some embodiments, the RM provides the option (via a command interface or through automation) to dynamically activate and deactivate a "throttling mode" for any selected period of time to reduce system resource usage during that period. RM users may also choose to activate a "throttling mode" on a permanent, full-time basis to reduce day-to-day system resource usage.

[0065] The tasks outlined above with respect to the suppressed mode are described in more detail below with reference to the flowcharts of FIGS.

[0066] Return to Ready Mode - Once all "Availability" messages have been received by the surviving TPS group members, the RM enters "Return to Ready Mode" to release any tasks performed during "Inhibit Mode." Once the RM completes the "Return to Ready Mode" process, the RM (and therefore its associated TPM) enters "Ready" mode again.

[0067] 4 is a block diagram illustrating a high availability system 400 in accordance with at least one embodiment of the present invention. High availability system 400 includes any number of mobile and / or fixed user devices 405, a system complex (sysplex) distributor 410, any number of Transmission Control Protocol / Internet Protocol (TCP / IP) gateways, including a first gateway 411, a second gateway 412, and an Mth gateway 413, a transaction processing system (TPS) group 425, including any number of TPS members, including a first TPS 421, a second TPS 422, and an Nth TPS 423, and a transaction queue 415. Note: Depending on the embodiment, the number of TCP / IP gateways (M) may or may not be the same as the number of TPS members (N).

[0068] Users initiate transactions through user devices 405 (mobile or fixed, such as smartphones, tablets, laptop and desktop computers, smart watches, televisions, etc.) There can be any number of such systems running in parallel, especially in large enterprise-wide systems such as online payment systems or media streaming services.

[0069] In some embodiments, a transaction arrives at sysplex distributor 410. Sysplex distributor 410 routes the transaction to any available TCP / IP gateway. The TCP / IP gateway then routes the transaction to any available transaction processing system (TPS) member of TPS group 425. (Note: The term "sysplex" may be subject to trademark rights in various jurisdictions worldwide and is used herein only to refer to products or services properly designated by the trademark to the extent such trademark rights may exist.)

[0070] To maintain high availability, members of a TPS group 425 cooperate to avoid having a single point of failure. Each TPS member may have a preferred set of incoming transaction types for which it is optimized to process efficiently. The TCP / IP gateway routes incoming transactions of a given type to the TPS member optimized for that transaction type.

[0071] Any TPS member can make a transaction available on the transaction queue 415 for processing by any TPS member of the group. Any TPS member can create a transaction instance block (TIB) to represent an incoming transaction or to process a transaction from another TPS member of the group. Each TIB consumes system resources.

[0072] Consider now the situation in which the first TPS 421 becomes unavailable due to a system failure, network failure, or any other cause that prevents the first TPS 421 from processing its assigned transactions. Such a failure may be referred to herein as an "emergency event." In response to the failure, the system redirects the transaction workload that would have been directed to the first TPS 421 to one or more surviving TPS members, such as the second TPS 422 and the Nth TPS 423 (see bold line 424 in Figure 4). The first TPS 421 can also reallocate its workload to other TPS members in the TPS group 425 by placing the workload in transaction queue 415.

[0073] Redirected transactions impose increased workload on surviving TPS members that receive the redirected transactions. Some surviving TPS members that receive the increased workload may run out of system resources and crash (due, at least in part, to the increased workload). Each surviving TPS member (that receives the redirected workload) allocates a TIB associated with the directed workload associated with the transactions queued in transaction queue 415 from first TPS 421. In an embodiment that processes a large volume of transactions, the corresponding large number of new TIBs (perhaps thousands or more) associated with the redirected workload may overload the surviving TPS members.

[0074] In some embodiments, such as large transaction processing systems, it may take 5 to 10 minutes to restart an unavailable or failed TPS member. During this critical time window, surviving TPS members may be affected enough to cause individual TPS system failure or even cascading failure of the entire TPS group 425.

[0075] Surviving TPS members that are starved of system resources can cause the creation of a large number of new TIBs to accommodate the workload redirected to the surviving members. Furthermore, if one TPS member goes down, the workload can accumulate on the surviving TPS members, potentially initiating a cascading failure sequence that causes more and more members to fail, thereby redirecting increasingly heavy workloads to fewer and fewer surviving members. In this type of situation, the entire TPS system can rapidly fail in a domino-like fashion, all initially triggered by the failure of one TPS member.

[0076] Some embodiments of the present invention install an instance of a "resource manager" (RM 601) for each member of a TPS group 425. RM 601 facilitates the survival of a TPS group 425 in the event that one or more TPS members become unavailable.

[0077] In some embodiments, RM601 includes software components that are installed on each corresponding TPS group member to streamline the use of system resources required to process transactions during an emergency and to avoid cascading outages such as those described above.

[0078] The RM 601 has four operating modes: (i) Broadcast, (ii) Suppress, (III) Return to Ready, and (iv) Ready. The functionality of these four modes is described below.

[0079] (i) Broadcast Mode - In response to a failed TPS member of a TPS group entering the initial dump formatting phase related to the downed TPS member, the corresponding instance of RM601 is invoked. RM601 broadcasts a notification message to some or all of the TPS members of the group. The broadcast notification indicates an "unavailable" status for the failed TPS member. Additionally, when a TPS member completes restart and becomes available again, RM601 broadcasts a notification message to the group indicating an "available" status for the previously failed TPS that has now recovered.

[0080] In some embodiments, RM601 broadcasts an "unavailable" notification to TPS members that have the same priority as the failed TPS. That is, if the failed TPS has priority (is optimized) for processing credit card payment transactions, RM601 broadcasts an "unavailable" notification to surviving TPS members that also have priority for processing credit card payment transactions. At the same time, the relay gateway that receives and distributes transactions to members of the TPS group redirects the credit card payment transaction to a TPS member that has the same priority as the failed TPS member. This minimizes the adverse impact on processing credit card payment transactions in the absence of the failed TPS member. In some embodiments, if a surviving TPS member is at risk of or is overloaded by the additional workload (e.g., if the average time to process incoming transactions increases beyond a predetermined threshold), some of that additional workload may be redirected to other TPS members regardless of priority, in which case RM601 broadcasts an "unavailable" notification to those other TPS members.

[0081] (ii) Suppression Mode - In response to receiving a broadcast notification about a failed TPS member, the surviving TPS member enters suppression mode. When operating in suppression mode, the TPS member controls system resources to manage the increased workload and prevent system failure during a critical time window (while the failed TPS member is unavailable).

[0082] (iii) Return to Ready Mode - When the (former) failed TPS member becomes available again (or an alternative TPS member is introduced into the group), the surviving TPS members enter "return to ready mode" to release the special tasks performed in suppressed mode.

[0083] (iv) Ready Mode - In "Ready Mode," RM601 does not need to take any action other than waiting to respond to a failure or impending failure of a TPS member of the group. RM601 detects an impending failure of a TPS group member based in part on actual resource utilization compared to the maximum resource utilization available to the TPS group member. RM601 determines that a failure is imminent when actual resource utilization is trending upward and remains above the "action" threshold for a predetermined period of time.

[0084] In some embodiments of the present invention, when RM 601 is in throttling mode (see item (ii) above), it performs "special" tasks, including (a) weighting transaction instance blocks, (b) initiating flood monitoring using weighting factors, and (c) initiating transaction flow control using delay time factors.

[0085] (a) Lighten transaction instance blocks

[0086] Each TIB contains a base portion, which is always required for transaction processing, and an on-demand portion, which is for specialized operations such as receiving transaction inputs and delivering transaction outputs.

[0087] In quiet mode, the TPS creates a TIB with only a basic portion to consume fewer system resources. Other portions of the TIB are constructed or created on demand (i.e., when their operation is required). In addition, the RM scans existing TIBs that were created before the TPS entered quiet mode. If the TPS does not use any on-demand portions of an existing TIB, it releases the storage associated with that existing TIB.

[0088] The RM also marks the TIB created for its new workload (the new TIB originally destined for the failed / unavailable TPS) so that when the RM leaves throttle mode, i.e. when the RM enters "return ready" or "ready" mode, the processing TPS will free the new TIB first (before any other TIBs).

[0089] (b) Start the flood monitor using the weighting factor.

[0090] Since light TIBs are used when TPS is in throttle mode, the RM takes smaller TIB sizes into account when calculating whether the overflow limit has been reached for all allocated TIBs.

[0091] For example, consider a lightweight TIB that is 20% smaller than a normal TIB, with no on-demand parts (e.g., input and output parts). The resulting 20% ​​storage reduction factor, called the "weighting factor," is used to calculate the adjusted TIB overflow limit X for overflow control.

[0092] In some embodiments, the adjusted TIB overflow limit X is determined using the following formula:

[0093] X = A(0.2 × B) + (0.5 × C) + (0.7 × D)

[0094] In the above equation,

[0095] A is the number of full-sized TIBs,

[0096] B is the number of TIBs with only the base part (light TIBs),

[0097] C is the number of TIBs with a base part and on-demand fields for input,

[0098] D is the number of TIBs with base parts and on-demand fields for output,

[0099] 0.2, 0.5, and 0.7 (corresponding to 20%, 50%, and 70%, respectively) are example weighting factors applied to values ​​B, C, and D, respectively. These example weighting factors may vary depending on the embodiment.

[0100] (c) Activate transaction flow control using delay time coefficients

[0101] The RM activates a delay factor function for input transactions by adding a delay to the input transactions in response to the TPS reaching a predetermined flood threshold high utilization. The delay factor helps reduce the impact on resource constraints that result from receiving increased input transactions, for example, from mobile devices. This allows the TPS to delay the creation of some TIBs, thereby consuming fewer system resources.

[0102] For example, if the TPS reaches 60% of a given flood threshold, the TPS assigns a 5-millisecond delay to the incoming transaction before the TPS accepts the new transaction. If the TPS reaches 70% of the flood threshold, the TPS assigns a 10-millisecond delay. In other words, the TPS dynamically increases or decreases the delay as the flood situation worsens or improves, respectively. Note: The values ​​shown here (60%, 70%, 5 milliseconds, and 10 milliseconds) are merely exemplary. Some embodiments define a set of different flood threshold percentages and corresponding delay times. Some embodiments define a linear or nonlinear functional relationship between the fraction of the flood threshold (TPS load) reached and the respective delay times. Some embodiments also incorporate a certain amount of hysteresis into the load / delay time relationship so that different delay times are activated at different load breakpoints when the load changes in an increasing rather than decreasing direction.

[0103] In addition to the "special" tasks (a), (b), and (c) described above, the RM, in quiet mode, also performs the following tasks: (iv) disable TPS diagnostic tracing to save storage; (v) disable TPS dumps for infinite problems; and (vi) cancel idle transactions more frequently to save storage.

[0104] Flowcharts 500A, 500B, 500C, 500D, and 500E in Figures 5A, 5B, 5C, 5D, and 5E, respectively, collectively illustrate a method according to an embodiment of the present invention for determining (i) the origin of a transaction processing system (TPS) fault-related notification message and (ii) the action to be taken in a suppressed mode by a resource manager (RM 601, see Figure 4) in response to the TPS fault-related notification. A TPS embodiment corresponding to the methods illustrated in the flowcharts includes a TPS group 425 that includes at least first and second TPS members (first TPS 421 and second TPS 422, respectively, see Figure 4).

[0105] Processing begins at operation 501, where an instance of an RM (hereafter referred to as RM 601) corresponding to a first TPS 421 receives a notification related to an emergency situation (a TPS failure-related notification) involving a member of the TPS group 425. The notification may have originated from the first TPS 421 or from any other TPS member of the TPS group 425. For ease of explanation, the failed TPS will be referred to as the second TPS 422 (see FIG. 4).

[0106] Processing continues to decision 503, where RM 601 determines the source of the notification and the status associated with the notification. If RM 601 determines that the notification is from a second TPS 422 and that the status of the second TPS 422 has changed from available to unavailable (decision 503, "left" branch), processing continues to entry point A of flowchart 500B (FIG. 5B).

[0107] If RM 601 determines that the notification is from the second TPS 422 and that the status of the second TPS 422 has changed from unavailable to available (decision 503, "right" branch), processing proceeds to entry point B of flowchart 500C (FIG. 5C).

[0108] If the RM 601 determines that the source of the notification is the first TPS 421 (decision 503, “center” branch), processing continues to selection operation 505.

[0109] If the RM 601 determines that the status of the first TPS 421 changes from "available" to "unavailable" (selection operation 505, "1" branch), processing proceeds to entry point C of flowchart 500D of FIG. 5D.

[0110] If the RM 601 determines that the state of the first TPS 421 changes from "unavailable" to "available" (selection operation 505, branch "2"), processing proceeds to entry point D of flowchart 500E of FIG. 5E.

[0111] If the RM 601 determines that the first TPS 421 will experience a critical system resource shortage but remains "available" (selection operation 505, branch "3"), processing proceeds to entry point A of flowchart 500B of FIG. 5B.

[0112] If the RM 601 determines that the first TPS 421 has left the critical system resource shortage state (the shortage has been resolved) (selection operation 505, branch "4"), processing proceeds to entry point B of flowchart 500C of FIG. 5C.

[0113] Referring now to flowchart 500B of FIG. 5B (Entry Point A, continuing from flowchart 500A of FIG. 5A), processing continues to decision 520 where the RM 601 determines whether the first TPS 421 is in throttle mode.

[0114] If RM 601 determines that the first TPS 421 is in suppression mode (decision 520, "Yes" branch), processing proceeds to decision 521, where RM 601 determines whether the notification was sent from the second TPS 422. If RM 601 determines that the notification was sent from the second TPS 422 (decision 521, "Yes" branch), RM 601 ignores the notification.

[0115] If no notification has been sent from the second TPS 422 (decision 521, "No" branch), the RM 601 starts the maximum delay time factor between the incoming (new) transaction and the existing transaction (already received by the first TPS 421 and queued for processing).

[0116] If the RM 601 determines that the first TPS 421 is not in the throttle mode (decision 520, "No" branch), processing continues to operation 523, where the RM 601 enters the throttle mode.

[0117] Processing continues at operation 524, where RM 601 performs the following tasks, not necessarily in this order: (i) lighten the existing transaction instance block (TIB); (ii) create a new TIB with only the basic parts; (iii) activate flood monitoring using a TIB weighting factor; (iv) activate transaction flow control using a delay time factor; (v) disable TPS diagnostic tracing and TPS dumps; and (vi) initiate more frequent termination of idle transactions.

[0118] Referring now to flowchart 500C of FIG. 5C (Entry Point B, continuing from flowchart 500A of FIG. 5A), processing continues to decision 530 where the RM 601 determines whether the first TPS 421 is in "return to ready" mode.

[0119] If the RM 601 determines that the first TPS 421 is not in the "return ready" mode (decision 530, "No" branch), processing proceeds to decision 531, where the RM 601 determines whether the first TPS 421 is in the "suppress" mode.

[0120] If the RM 601 determines that the first TPS 421 is in "suppression" mode (decision 531, "Yes" branch), processing proceeds to decision 532, where the RM 601 determines whether a notification has been sent from the second TPS 422.

[0121] If RM601 determines that the notification was sent from the second TPS422 (decision 532, "Yes" branch), processing proceeds to decision 533, where RM601 determines whether the second TPS422 is the only unavailable TPS in the TPS group 425.

[0122] If RM601 determines that the second TPS422 is not the only TPS in the TPS group 425 that remains unavailable (decision 533, "No" branch), in other words, if at least one other member of the TPS group 425 is unavailable, processing ends.

[0123] Returning to decision 530, if the RM 601 determines that the first TPS 421 is in "return ready" mode (decision 530, "Yes" branch), the RM 601 ignores the notification.

[0124] Returning to decision 531, if RM 601 determines that the first TPS 421 is not in "suppression" mode (decision 531, "No" branch), RM 601 ignores the notification.

[0125] Returning to decision 532, if the RM 601 determines that the notification was not sent from the second TPS 422 (decision 532, “No” branch), processing continues to operation 535.

[0126] Returning to decision 533, if RM601 determines that the second TPS422 is the only TPS in the TPS group 425 that remains unavailable (decision 533, "Yes" branch), in other words, if there are no other members in the TPS group 425 that are unavailable, processing proceeds to operation 535.

[0127] In operation 535, RM601 performs the following tasks, not necessarily in this order: (i) stop the light TIB function and cancel existing TIB lightening tasks (to consume less system resources); (ii) cancel overflow monitoring using TIB weighting factors; (iii) disable transaction overflow control using delay time factors; (iv) enable TPS diagnostic tracing and TPS dumps; and (v) resume terminating idle transactions at their normal frequency.

[0128] Referring now to flowchart 500D of FIG. 5D (entry point C, continuing from flowchart 500A of FIG. 5A), processing continues to decision 540, where RM 601 determines whether the first TPS 421 (the transaction processing system that sent the failure notification) is a member of a TPS group (e.g., TPS group 425, see FIG. 4).

[0129] If RM601 determines that the first TPS421 is part of a TPS group (decision 540, "Yes" branch), RM601 sends an "unavailable" notification regarding the first TPS421 to the surviving TPS members of the TPS group425.

[0130] Next, in flowchart 500E of FIG. 5E (entry point D, continuing from flowchart 500A of FIG. 5A), processing continues to decision 550, where RM 601 determines whether the first TPS 421 (the transaction processing system from which the failure notification originated) is a member of a TPS group (e.g., TPS group 425, see FIG. 4).

[0131] If RM601 determines that the first TPS421 is part of a TPS group (decision 550, "Yes" branch), RM601 sends an "available" notification about the first TPS421 to the surviving TPS members of the TPS group425.

[0132] The following paragraphs present various use cases: (i) a sudden system failure of one or more members of a TPS group, (ii) a single TPS system inundated with transactions, (iii) a TPS group experiencing heavier than normal system resource utilization, and (iv) a large transaction processing system with a single TPS or TPS group that wants to reduce operational costs by reducing system resource utilization.

[0133] (i) Sudden system failure of one or more members of the TPS group

[0134] For a large banking customer with multiple transaction processing systems (TPSs), one or more TPSs may go down for reasons including transaction flooding, transaction routing problems, long I / O wait times, or internal latch issues. Before the failed TPS completes its system restart, the surviving TPSs in the group may rapidly exhaust their system resources due to the transaction workload redirected from the failed TPS. If a TPS Resource Manager (RM) is installed, the RM detects the sudden system failure and takes internal action to start and stop various RM processing modes, including "suppression mode," on the surviving TPS group members to conserve system resources and avoid further sudden outages for the remaining TPS group members. Therefore, TPS groups with RMs installed can avoid a series of sudden outages.

[0135] (ii) A single TPS system flooded with transactions

[0136] A small banking customer with a single TPS may have millions of transactions submitted to it from mobile devices in a short period of time. The TPS may then experience a severe flood condition and crash as the TPS's system resources are depleted. In some embodiments of the present invention, system automation dynamically activates an RM "throttling mode" in response to reaching a predefined flood threshold to reduce system resources. The RM acts proactively to prevent catastrophic failure of any member of the TPS group. In some embodiments, system automation dynamically deactivates the RM "throttling mode" once the transaction flood subsides. In some embodiments, the RM provides a means for human intervention to activate / deactivate the RM or specific components thereof.

[0137] (iii) TPS group with heavier than normal system resource utilization

[0138] In some embodiments of the present invention, for example, at a large banking customer with multiple TPSs operating as a TPS group, one preferred TPS group member receives the primary transaction workload from various gateways. When system resources on that preferred TPS group member become low (e.g., resource usage levels exceed an action threshold level), system automation dynamically activates RM "throttling mode" for some or all TPS group members to reduce system resource usage. When system resource usage levels fall below the action threshold (e.g., return to normal levels), the RM automatically deactivates "throttling mode." This feature allows the RM to prevent members of the TPS group from unexpectedly going down due to a sudden system failure.

[0139] (iv) A large-scale transaction processing system with a single TPS or group of TPSs that wants to reduce operational costs by reducing system resource utilization.

[0140] A large-scale industrial TPS (e.g., a TPS focused primarily on customer analytics) may use an RM to run in "throttled mode" on a full-time basis to reduce overall system resource overhead. Running the RM in this manner may result in lower operational costs associated with the TPS. In some embodiments, the RM is started automatically upon system initialization or restart. In some embodiments, a means is provided for manually starting the RM.

[0141] The corresponding structure, material, acts, and equivalents of all means or step-plus-function elements in the following claims are intended to include any structure, material, or acts for performing the function in combination with other claim elements that are specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the disclosure to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the present disclosure. The embodiments have been chosen and described to best explain the principles and practical applications of the disclosure and to enable those skilled in the art to understand the disclosure in various embodiments with various modifications as suited to the particular uses contemplated.

[0142] IV. Definition The present invention: "The present invention" should not be taken as an absolute indication that the subject matter described by the term "the present invention" is covered by the claims as filed or as may ultimately be issued after patent prosecution. The term "the present invention" is used to help the reader get a general sense that the disclosures herein may be novel, but this understanding implied by use of the term "the present invention" is tentative and provisional and may change during the course of patent prosecution as relevant information becomes known and as the claims are, if necessary, amended.

[0143] Embodiment: See definition of "present invention" above. A similar note applies to the term "embodiment."

[0144] ...or...or both (combinations): A non-exclusive disjunction, or for example, "A or B or C or combinations thereof" means that at least one of A or B or C is true and applicable.

[0145] Including / Include / Includes: Unless otherwise specified, means "including but not necessarily limited to."

[0146] User / Subscriber: Includes, but is not necessarily limited to, (i) a single individual, (ii) an artificial intelligence entity with sufficient intelligence to act as a user or subscriber, or (iii) a group of related users or subscribers, or any combination thereof.

[0147] Data Communications: Any type of data communication method now known or hereafter developed, including wireless communication, wired communication, and communication paths having wireless and wired portions. Data communications is not necessarily limited to (i) direct data communication, (ii) indirect data communication, or (iii) data communication in which the format, packetization state, medium, encryption state, or protocol, or any combination thereof, remains constant throughout the entire course of the data communication.

[0148] Receive / Provide / Send / Input / Output / Report: Unless otherwise specified, these terms should not be construed as implying (i) any particular degree of directness regarding the relationship between the object and the subject, or (ii) the absence of any intermediate components, actions, or things, or combinations thereof, intervening between the object and the subject.

[0149] Without Substantial Human Intervention: A process that is carried out automatically, with little or no human input (often through the operation of machine logic such as software). Some examples of "without substantial human intervention" include (i) a computer is performing a complex process and a power grid outage causes a human to switch the computer to an alternate power source so that the process can continue uninterrupted; (ii) a computer is about to perform a resource-intensive process and a human determines that the resource-intensive process should actually begin (in this case, the determination process, when considered in isolation, involves substantial human intervention, but the resource-intensive process does not involve any substantial human intervention, despite the simple yes / no determination that must be made by a human); and (iii) a computer uses machine logic to make an important decision (e.g., to ground all aircraft in anticipation of bad weather), but before it can carry out the important decision, the computer must obtain a simple yes / no determination from a human source.

[0150] Automatically: Without any human intervention.

[0151] Module / Sub-Module: Any set of hardware, firmware, or software, or a combination thereof, operable to perform a certain function, whether the module is (i) in a single local neighborhood, (ii) distributed over a wide area, (iii) in a single neighborhood within a larger software code, (iv) located within a single software code, (v) in a single storage device, memory, or medium, (vi) mechanically connected, (vii) electrically connected, or (viii) connected in data communication, or any combination thereof.

[0152] Computer: Any device capable of significant data processing and / or machine-readable instruction reading, including, but not limited to, a desktop computer, mainframe computer, laptop computer, field programmable gate array (FPGA)-based device, smartphone, personal digital assistant (PDA), body-worn or insertable computer, embedded device computer, or application-specific integrated circuit (ASIC)-based device, or any combination thereof. [Explanation of symbols]

[0153] 100 Networked Computer Systems 102 Storage Subsystem 104 client computers 106 Transaction Processing System 114 Communication Network 200 Resource Manager Server Computers 202 Communication Unit 204 processor set 206 I / O Interface Set 208 memory 210 Persistent Storage 212 Displays, display devices 214 External Devices 232 Cache 300 Resource Manager 302 Daemon Module 304 Broadcast Module 306 Suppression Module 405 User Devices 410 Siplex Distributor 411 First Gateway 412 Second Gateway 413 Gateway of the Mth 415 Transaction Queue 421 First TPS 422 Second TPS 423 Nth TPS 425 TPS Group 601 Resource Manager

Claims

1. A transaction processing method using information processing in a computer having a processor, the method comprising: receiving a transaction request sent from a user device by a transaction processing system (TPS), the TPS forming a TPS group including a plurality of TPS members, each TPS member including a resource manager (RM) that determines the member's status; For a first TPS member of the TPS members, an RM of the first TPS member determines a condition in which the first TPS member is unavailable; In response to determining the unavailable status, the RM of the first TPS member broadcasts a message to other TPS members including information regarding the status of the first TPS member; In response to receiving the message, the other TPS member performs a resource consumption reduction action, which is a process of dynamically suppressing resource consumption, by monitoring performance characteristics including the number of transaction instance blocks (TIBs) in each TPS member, and for a TPS member determined to be in an overloaded state, dynamically performs a resource consumption reduction action that suppresses execution of a portion of the TIBs, and cancels the resource consumption reduction action when it is determined that the first TPS member is available. and

2. Determining, for the first TPS member, a status that an RM of the first TPS member is available includes: In response to determining the status of the first TPS member, the RM broadcasts a message to other TPS members that includes information regarding the first TPS member's previous status; 2. The method of claim 1, further comprising: in response to receiving the message, by the other TPS member, canceling the resource consumption reduction action.

3. The resource consumption reduction measures include: creating a first transaction instance block (TIB) excluding an on-demand portion for load evaluation based on the TIB using actual resources; basing the flood monitor on the number of TIBs excluding their corresponding on-demand portions; delaying the creation of the second TIB based on a delay time factor; Disabling creation of a first diagnostic trace; Disabling the first system dump; 2. The method of claim 1, wherein the first plurality of idle transactions are selected from the group consisting of: canceling the first plurality of idle transactions more frequently.

4. Canceling the resource consumption reduction measure includes: creating a third TIB including the on-demand portion; creating a fourth TIB based on the transaction request sent from the user device; enabling creation of said first diagnostic trace; enabling the first system dump; and reducing the frequency of cancellation of said first plurality of idle transactions.

5. 2. The method of claim 1, further comprising installing a plurality of instances of a resource manager, including a first instance and a second instance, on each TPS member, each instance of the resource manager being associated with a corresponding TPS member of the TPS group.

6. Determining the first status of the first TPS member includes: The method of claim 1 , further comprising monitoring a performance characteristic of the first TPS member.

7. The performance characteristics are the rate of incoming transactions, and The time to process the transaction, the clock frequency of the central processing unit (CPU); The frequency of errors and The number of errors that occurred, Error rate and CPU usage measurements; memory access measurements; storage access measurements; 7. The method of claim 6, wherein the network communication parameters are selected from the group consisting of:

8. A computer program causing a computer to execute the method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing the computer program according to claim 8.

10. A computer system that executes the method according to any one of claims 1 to 7 by means of dedicated hardware.

Images