Controlling transaction requests between applications and servers

Abstract

A concept for controlling transaction requests delivered between applications and servers over a distributed architecture, in which delivery of transaction requests is controlled taking into account information about groups of transaction requests that may cause transaction collisions if processed in parallel, and such groupings of transaction requests may be defined, modified, and updated at runtime based on previous or current observed transaction collisions.

Description

[[Technical Field]]

[0001] The present invention generally relates to the field of communication between an application and a server, and more particularly to a middleware system for controlling transaction requests between an application and a server.

[0002] The invention also relates to a computer-implemented method for controlling transaction requests between an application and a server.

[0003] The invention also relates to a computer program product comprising computer-readable program code that enables a processor of a system, or several processors of a network, to implement such a method.

[0004] Enterprise architectures are typically built around integration middleware configured to route data between various sources and targets, for example database management systems, messaging systems, and distributed ledger technologies.

[0005] Such an architectural implementation may utilize multi-version concurrency control (MVCC), which allows concurrent reading and writing of data with the requirement that a request to write one piece of data must be accompanied by a hash or version code representing the current value of the data being overwritten. If the hash or version code does not match the current value, the request to overwrite data is rejected, resulting in an MVCC failure. This is because it indicates that another connected client is updating the value at the same time. If a client's write request is rejected, the client must retry (for example, repeat the request), which typically requires reading the current value and sending a write request again. Under heavy load, the rate of MVCC failures can increase rapidly, resulting in insufficient system performance. [[Summary of the Invention]]

[0006] This invention seeks to provide a middleware system for controlling transaction requests between an application and a server.

[0007] The present invention also seeks to provide a method for controlling transaction requests between an application and a server. Such a method can be implemented on a computer.

[0008] The present invention further seeks to provide a computer program product comprising computer program code for implementing the proposed method when executed by a processing device. The present invention also seeks to provide a processing system adapted to execute this computer program code.

[0009] According to one aspect of the present invention, a middleware system is provided for controlling transaction requests between an application and a server. The middleware system comprises a broker component, which is configured to define one or more collision groups of transaction requests based on previously or currently observed transaction collisions at runtime, and to control the delivery of parallel transaction requests based on one or more collision groups.

[0010] A concept is proposed for controlling transaction requests to reduce the risk of MVCC collisions. In such a concept, a middleware system may be used between the application and the server (e.g., between a client application and a blockchain network (or other MVCC-constrained backend system)), and the middleware system may control the flow of transaction requests (e.g., throttling or queuing) so that only certain requests are allowed to be submitted in parallel. For example, the middleware system may, at runtime, group transaction requests that the middleware system observes would produce a transaction collision when delivered in parallel. Based on such groups, the middleware system may determine whether transactions should be delivered in parallel.

[0011] The embodiment proposes that potentially competing transaction requests may be organized into groups, which can be done dynamically at runtime based on observed collisions. Transaction requests within each group may then be temporarily queued in sequence until previous requests are successfully processed, or in the case of a blockchain, until committed to the ledger. Thus, some embodiments may offer proposals for integrated flow nodes that can dynamically control request throttling behavior to maximize the throughput of successful transaction submissions.

[0012] The proposed embodiment may utilize the concept of dynamically creating collision groups based on the runtime history of transactional collisions (e.g., MVCC collisions). Furthermore, such dynamic grouping information may be issued to other components, nodes, or organizations, thereby enabling those components, nodes, or organizations to update their group configurations.

[0013] According to the proposed concept, middleware components or systems may be provided as an integration flow, positioned between client applications and servers. Such an integration flow may form a new “submitter” or “broker” node, configured to control the submission of transaction requests in a manner that minimizes, or potentially eliminates, transaction collisions (e.g., failures).

[0014] For example, a node may maintain a set of groups (hereinafter referred to as "collision groups"), where each transaction request within a group is more likely to cause a collision failure if submitted simultaneously with any other transaction requests within that group. If multiple transaction requests within a group arrive at any given time, the node may throttle the requests by queuing them in first-in, first-out (FIFO) order until the requests can be submitted. Each group may operate independently of the others, thereby enabling parallel processing of transaction requests from different groups.

[0015] Accordingly, according to the proposed embodiment, an integrated middleware may be provided that is configured to dynamically group and throttle transaction requests in a manner that reduces the risk of transaction collisions. By dynamically grouping transaction requests based on previously or currently observed transaction collisions, information may be provided that can be utilized to control the parallel submission of transaction requests.

[0016] Specifically, the proposed concept may seek to mitigate the risk of MVCC collisions by providing middleware (e.g., integration flow or broker component) between the client application and the MVCC-constrained backend system. The middleware throttles transaction requests so that only requests that do not cause an MVCC crash are allowed to be submitted in parallel. Embodiments may leverage the idea of ​​grouping potentially conflicting transactions (e.g., based on the runtime history of MVCC collisions) and then use such groups to determine whether incoming transactions can be submitted in parallel. For example, if multiple transaction requests in a group arrive at any given time, the transaction requests may be queued until they can be safely submitted.

[0017] In some embodiments, the broker component may include a publisher component configured to communicate information about one or more collision groups to one or more remote components. In this way, the embodiment may be configured to share information with other components, nodes, or organizations, such as other broker components, thereby enabling the other components, nodes, or organizations to update their configuration.

[0018] A broker component may include a receiver component configured to receive information about observed transaction collisions and at least one of other collision groups of transaction requests from remote components. The broker component may then be configured to define one or more collision groups of transaction requests at runtime based on the received information. Thus, embodiments may leverage information from other components, nodes, or organizations, such as other broker components, to update and improve collision groups. In this way, embodiments can dynamically adapt and reconfigure to reflect changing conditions or parameters, or both, within the network or system.

[0019] In some embodiments, a broker component may be configured to queue multiple transaction requests in response to identifying multiple transaction requests that are members of the same collision group among one or more collision groups, in order to prevent the parallel delivery of the multiple transaction requests. For example, a broker component may be configured to queue multiple transaction requests in a first-in, first-out order. This may allow control over the delivery of the transaction requests, for example, through deferral or delay, until a later time when the transaction collision will be avoided / prevented.

[0020] The broker component may be configured to redefine one or more collision groups of a transaction request based on the identified transaction collision in response to the identification of a transaction collision resulting from the delivery of the transaction request, and to control the redelivery of the transaction request based on the redefined collision groups. Thus, embodiments may be adapted to dynamically reconfigure the delivery of transaction requests. For example, a transaction request may be automatically redelivered / resent after the collision groups are redefined, thus avoiding the simple termination of delivery in response to the transaction request causing a collision.

[0021] The middleware system can be configured to intercept and control the delivery of transaction requests between client applications and multi-version concurrency control (MVCC) constrained servers. Therefore, the embodiment may be particularly valuable for architectural implementations that utilize MVCC.

[0022] According to another aspect of the present invention, a computer implementation method for controlling transaction requests between an application and a server is provided. The method includes defining one or more collision groups of transaction requests based on previously or currently observed transaction collisions at runtime, and controlling the delivery of parallel transaction requests based on one or more collision groups.

[0023] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a computer-readable storage medium on which program instructions are executed, the program instructions being executable by the processing unit to cause the processing unit to execute the method according to the proposed embodiment.

[0024] According to another aspect of the present invention, there is provided a computer system comprising at least one processor and a computer program product according to one embodiment. The at least one processor is adapted to execute computer program code of the computer program product.

[0025] These and other objects, features, and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the invention, which should be read in conjunction with the accompanying drawings. The figures are provided for clarity to facilitate understanding of the present invention for those skilled in the art along with the detailed description, and thus various features in the drawings are not drawn to scale. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] [Figure 1] FIG. 1 is a diagram illustrating a pictorial representation of an exemplary distributed system in which aspects of the exemplary embodiments may be implemented. [Figure 2] FIG. 2 is a block diagram of an exemplary system in which aspects of the exemplary embodiments may be implemented. [Figure 3] FIG. 3 is a schematic diagram of a proposed distributed communication system, according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a system according to another embodiment. DESCRIPTION OF EMBODIMENTS

[0027] It should be understood that the figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the figures to indicate the same or similar parts.

[0028] In the context of the present application, it should be understood that where an embodiment of the present invention constitutes a method, such a method may be a process for execution by a computer, i.e., may be a computer-implemented method. Accordingly, various steps of the method may reflect various portions of a computer program, for example, various portions of one or more algorithms.

[0029] Furthermore, in the context of this application, a system may be a single device or a collection of distributed devices adapted to perform one or more embodiments of the methods of the present invention. For example, a system may be a personal computer (PC), a server, or a collection of PCs or servers or a combination thereof connected via a network such as a local area network or the Internet to collaboratively perform at least one embodiment of the methods of the present invention. Furthermore, the components may be an integrated flow performed by one or more processing units.

[0030] A concept is proposed for controlling transaction requests delivered between applications and servers via a distributed architecture (i.e., an interconnected distributed network). In such a concept, the delivery of transaction requests is controlled by considering information about groups of transaction requests that, when processed in parallel, could cause transaction collisions. Such groupings of transaction requests can be defined, modified, and updated at runtime based on previously or currently observed transaction collisions.

[0031] For example, it is proposed that potentially competing transaction requests may be placed within a group, and this may be done dynamically at runtime based on observed transaction collisions. Thus, predefined groups may be used to determine whether multiple received (or intercepted) transaction requests should be prevented from being processed in parallel. For example, multiple transaction requests within the same group may be temporarily queued in order until the previous request is successfully processed. In this way, embodiments may dynamically throttle transaction request behavior to reduce or avoid collisions (thus seeking to maximize the throughput of successful transaction submissions).

[0032] Specifically, the embodiments can be implemented in conjunction with existing distributed communication architectures that utilize integrated middleware (e.g., database management systems, messaging systems, and distributed ledger technologies).

[0033] Figure 1 shows a pictorial representation of an exemplary distributed system in which an aspect of the exemplary embodiment may be implemented. The distributed system 100 may include a network of computers in which an aspect of the exemplary embodiment may be implemented. The distributed system 100 includes at least one network 102 which is a medium used to provide communication links between various devices and computers connected to each other within the distributed data processing system 100. The network 102 may include connections such as wires, wireless communication links, and fiber optic cables.

[0034] In the illustrated example, a first server 104 and a second server 106 are connected to a network 102 along with a storage unit 108. Furthermore, clients 110, 112, and 114 are also connected to the network 102. Clients 110, 112, and 114 may be edge devices, such as personal computers, network computers, or IoT devices. In the illustrated example, the first server 104 provides clients 110, 112, and 114 with data such as boot files, operating system images, and applications. Clients 110, 112, and 114 are clients to the first server 104 in the illustrated example. The distributed processing system 100 may include additional servers, clients, and other devices not shown.

[0035] In the illustrated example, the distributed system 100 is the Internet, and network 102 represents a global collection of networks and gateways that use the Transmission Control Protocol / Internet Protocol (TCP / IP) protocol suite to communicate with one another. At the heart of the Internet is the backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, governmental, educational, and other computer systems that route data and messages. Of course, the distributed system 100 can also be implemented to include several different types of networks, such as intranets, local area networks (LANs), and wide area networks (WANs). As stated above, Figure 1 is intended as an example rather than an architectural limitation on various embodiments of the present invention, and therefore the specific elements shown in Figure 1 should not be considered a limitation on the environments in which exemplary embodiments of the present invention may be implemented.

[0036] Figure 2 is a block diagram of an exemplary system 200 in which an embodiment of the exemplary embodiment may be implemented. System 200 is an example of a computer, such as client 110 in Figure 1, in which computer-readable code or instructions that implement the processes of the exemplary embodiment of the present invention may be located. For example, the proposed embodiment may be partially implemented within the processing unit 206 of system 200.

[0037] In the illustrated example, system 200 utilizes a hub architecture including a northbridge and memory controller hub (NB / MCH) 202 and a southbridge and input / output (I / O) controller hub (SB / ICH) 204. Thus, another proposed embodiment may be implemented in the memory controller hub 202 of system 200. The processing unit 206, main memory 208, and graphics processor 210 are connected to the NB / MCH 202. The graphics processor 210 may be connected to the NB / MCH 202 via an accelerated graphics port (AGP).

[0038] In the illustrated example, a local area network (LAN) adapter 212 is connected to the SB / ICH204. An audio adapter 216, a keyboard and mouse adapter 220, a modem 222, read-only memory (ROM) 224, a hard disk drive (HDD) 226, a CD-ROM drive 230, a Universal Serial Bus (USB) port and other communication ports 232, and PCI / PCIe devices 234 are connected to the SB / ICH204 via a first bus 238 and a second bus 240. PCI / PCIe devices may include, for example, an Ethernet(R) adapter, an add-in card, and a PC card for a notebook computer. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash basic input / output system (BIOS).

[0039] The HDD226 and CD-ROM drive 230 are connected to the SB / ICH204 via a second bus 240. The HDD226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A SuperI / O (SIO) device 236 may also be connected to the SB / ICH204.

[0040] The operating system runs on the processing unit 206. The operating system coordinates and implements control over the various components within the system 200 in Figure 2. As a client, the operating system can be a commercially available operating system. An object-oriented programming system, such as the Java(R)(TM) programming system, may run alongside the operating system, enabling calls to the operating system from Java(R)(TM) programs or applications running on the system 200.

[0041] As a server, system 200 could be, for example, an IBM® eServer™ System p® computer system running the Advanced Interactive Executive (AIX®) operating system or the Linux® operating system. System 200 could be a symmetric multiprocessor (SMP) system containing multiple processors within the processing unit 206. Alternatively, a single-processor system may be used.

[0042] An operating system, a programming system, and instructions for an application or program may be placed on a storage device such as an HDD 226 and loaded into main memory 208 for execution by the processing unit 206. Similarly, one or more programs according to an embodiment may be adapted to be stored in a storage device, main memory 208, or both.

[0043] Processes for exemplary embodiments of the present invention may be carried out by a processing unit 206 using computer-usable program code, which may be located in memory such as main memory 208, ROM 224, or in one or more peripheral devices 226 and 230.

[0044] A bus system, such as the first bus 238 and the second bus 240 shown in Figure 2, may comprise one or more buses. Of course, the bus system can be implemented using any type of communication fabric or architecture that enables the transfer of data between different components or devices connected to the fabric or architecture. Communication units, such as the modem 222 and network adapter 212 in Figure 2, may include one or more devices used to transmit and receive data. Memory may be, for example, main memory 208, ROM 224, or a cache, such as those found in NB / MCH202 in Figure 2.

[0045] Those skilled in the art will understand that the hardware in Figures 1 and 2 can vary depending on the implementation. Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, and optical disc drives may be used in addition to or instead of the hardware shown in Figures 1 and 2. Furthermore, the processes of the exemplary embodiments may be applied to multiprocessor data processing systems other than those described above without departing from the scope of the invention.

[0046] Furthermore, System 200 can take the form of any of several different data processing systems, including client computing devices, server computing devices, tablet computers, laptop computers, telephones or other communication devices, and personal digital assistants (PDAs). In some exemplary examples, System 200 may be a portable computing device configured with flash memory to provide non-volatile memory for storing, for example, operating system files or user-generated data, or both. Thus, System 200 can be any known or later developed data processing system, without any architectural limitations.

[0047] As detailed above, the proposed embodiment provides a method and system for controlling transaction requests delivered between an application and a server via a distributed architecture. In a separate explanation, the proposed embodiment will now be described in relation to a distributed communication system including an application 310 and a server 320.

[0048] Referring to Figure 3, a schematic diagram of the proposed distributed communication system according to one embodiment is shown. The communication system includes a middleware system 300 for controlling transaction requests between an application 310 and a server 320, according to one embodiment. More specifically, in the example illustrated in Figure 3, the middleware system 300 is configured to intercept and control the delivery of transaction requests between the client application 310 and the MVCC-constrained server 320 over a communication network 330 (e.g., the Internet).

[0049] The middleware system 300 includes a broker component 340. The broker component 340 is configured to define one or more collision groups of transaction requests at runtime based on previously or currently observed transaction collisions within the distributed communication system. In other words, the broker component defines collision groups based on the runtime history of transaction collisions.

[0050] Here, the broker component 340 defines groups such that each collision group defines multiple transaction requests that would result in a transaction collision if delivered in parallel.

[0051] In this example, the broker component 340 includes a receiver component 350 configured to receive information about observed transaction collisions within the communication system, or other collision groups of transaction requests from a remote component (such as another broker component 360), or both. The broker component 340 may also use this received information to define collision groups. Thus, in the illustrated example of Figure 3, the broker component is configured to define collision groups of transaction requests at runtime based on the received information.

[0052] The broker component 340 also includes a publisher component 355 configured to communicate information about defined collision groups (over the network 330) to one or more remote components (another broker 360 or a remotely located database 370 or both). In this way, the broker component 340 is configured to share information about collision groups, thus potentially enabling multiple broker components to cooperate (for example, by combining or pooling information) to update or improve or both collision group definitions.

[0053] Based on collision groups, the broker component 340 is configured to control the delivery of intercepted transaction requests. More specifically, in response to identifying that multiple intercepted transaction requests are members of the same collision group, the broker component 340 queues the multiple transaction requests to prevent parallel delivery of the multiple transaction requests. For example, the broker component 340 may queue multiple transaction requests in a first-in, first-out order. In this way, if the first and second transaction requests are members of the same collision group, the broker component 340 may delay the first transaction request to prevent it from being submitted in parallel with the second transaction request.

[0054] Furthermore, in this example, in response to identifying a transaction collision resulting from the delivery of a transaction request, the broker component 340 is configured to redefine the collision group based on the identified transaction collision. Moreover, instead of terminating the transaction request, the broker component 340 controls the re-delivery of the transaction request based on the newly redefined collision group.

[0055] With further explanation and illustration of the proposed concept, we will now consider how the proposed embodiment may modify conventional transaction request delivery mechanisms. Conventional mechanisms for submitting transaction requests to a blockchain network typically require initiating the following multi-step process: (i) Create a transaction request - this is a data structure that contains the function to be invoked on the blockchain network and the parameters / arguments to be supplied to that function. (ii) Send a transaction request to each node in the blockchain network seeking "approval" - each node's smart contract simulates processing its function and generates a read / write set (RWset). This RWset contains the current and proposed future states of the relevant portion of the ledger data store for each node in the blockchain network. The RWset is not actually applied at this stage and is returned to the requesting client. (iii) The client groups the RWsets received from each node and sends them to the blockchain's “ordering service.” This service performs the following steps: a) Check that all RWsets (or a sufficient number to satisfy the authorization policy) have the same RWset. At this stage, if the RWsets are different, the transaction request may be rejected. This is because one node may have a different read state to another node, and that particular state may be in a process of changing within the network (MVCC failure). b) If step a) is passed, the ordering service creates a “block” containing one or more batches of transactions. This block is cryptographically signed and sent to each peer in the network. c) Each peer attempts to apply each transaction to its ledger upon receiving a block. For each transaction in the block, each peer checks that the "read" portion of the RWset matches the current read state in the peer's ledger. If they do not match, the transaction is rejected as an MVCC failure. Note that the ordering service's actions ensure that all nodes in the network accept or reject transactions similarly. d) Assuming that no MVCC failure has occurred, the transaction is committed to the blockchain network at this time.

[0056] Step (iii) described above is asynchronous. If the client wants to be notified when the transaction is finally committed to the ledger, the client registers a listener with the peer to receive notifications of the event.

[0057] When considering how the aforementioned conventional methods are modified according to the proposed embodiment, it should be noted that a middleware component (e.g., an integration flow) is placed between the client application and the blockchain network. This is configured to act as a new broker component (which can be thought of as a “submitter” node) that controls the submission of transaction requests to the blockchain in a manner that minimizes or potentially eliminates MVCC failures.

[0058] Broker components maintain information about separate sets of collision groups, and each transaction request within a group is likely to cause an MVCC failure if submitted simultaneously with any other transaction request within the same group. Based on these collision groups, if multiple transaction requests from the same group arrive at the same time (e.g., simultaneously or within a given time window), the broker components delay those transaction requests (e.g., by queuing them) until they can be submitted without causing an MVCC collision. Collision groups can operate independently of each other, thus enabling parallel processing of transaction requests from different groups.

[0059] As another example, a broker component according to one embodiment may be configured to operate as follows: - The "Collision Group Definition" property is configured with an expression that determines at runtime which group each transaction request should belong to. This expression may be one that uses the contents of the transaction request to derive a string value that matches the collision group name. - If, at runtime, the broker component determines that proposals from different groups are causing an MVCC failure, a flag may be set to allow the broker component to dynamically combine the groups.

[0060] At runtime, the broker components may implement the following processes: - For each transaction request arriving at the broker component, the collision group definition expression is evaluated to determine which collision group the transaction request should be placed in. If a collision group with that name does not exist, a collision group with that name is created. - The transaction request is placed in a FIFO queue associated with its collision group. Next, each collision group may implement the following process (in parallel and independently of each other's collision groups): -If the queue is not empty, the transaction request is removed from the head of the queue. - Steps 1 and 2 of the conventional blockchain submission process are carried out as detailed above. - Commit listeners are registered as blockchain peers. -Step 3 of the blockchain submission process will be implemented. - Wait for the commit event. -When a successful commit event is received, this process can start from the beginning (processing the next proposal on the group's queue). - If a commit event signals an MVCC failure, determine the cause of the failure, and if the cause is an MVCC failure, determine which other transaction requests caused the crash and which group those other transaction requests belong to. This information can be extracted from block metadata. -If they are different groups, merge the two groups into one and move this transaction request to the newly merged group for processing. Additionally, issue a message containing information about this group merge so that other broker component instances can choose to act on this information. - Otherwise, this process is repeated until the failed transaction request is successfully processed (because MVCC failures can still occur if there are other client applications that submit transactions directly, rather than through this integration flow).

[0061] The embodiment may include a computer system 70, which may form part of the networked system 7 shown in Figure 4. For example, a broker component configured to control transaction requests between an application and a server, according to one embodiment, may be implemented within the computer system 70 (for example, as a processing unit 71). The components of the computer system / server 70 may include, but are not limited to, one or more processing configurations comprising, for example, a processor or processing unit 71, system memory 74, and a bus 90 that connects various system components, including the system memory 74, to the processing unit 71.

[0062] The system memory 74 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 75 or cache memory 76 or both. The computer system / server 70 may further include other removable / non-removable volatile / non-volatile computer system storage media. In such cases, each may be connected to the bus 90 by one or more data medium interfaces. The memory 74 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of the proposed embodiment. For example, the memory 74 may include a computer program product having a program executable by the processing unit 71 to cause the input / output (I / O) interface 72 to perform a method for controlling transaction requests between an application and a server, according to the proposed embodiment. A program / utility 78 having a set of program modules 79 (at least one) may be stored in the memory 74. The program modules 79 generally perform the functions or methods, or both, of the proposed embodiment for partial write operations to memory.

[0063] The computer system / server 70 may also communicate with one or more external devices 80, such as a keyboard, pointing device, or display 85; one or more devices that enable a user to interact with the computer system / server 70; or any device (e.g., a network card, modem, etc.) that enables the computer system / server 70 to communicate with one or more other computing devices; or a combination thereof. Such communication may occur via an input / output (I / O) interface 72. Furthermore, the computer system / server 70 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 73 (for example, to communicate the desired optimal DFWF value to an edge device of a distributed network).

[0064] In the context of this application, when embodiments of the present invention constitute a method, it should be understood that such a method is a process for execution by a computer, i.e., a method that can be implemented on a computer. Therefore, the steps of the method reflect various parts of a computer program, for example, parts of one or more algorithms.

[0065] While this disclosure includes a detailed description of cloud computing, it should be understood that the implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented with any other type of computing environment that is currently known or to be developed in the future.

[0066] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0067] The features are as follows: On-demand self-service: Cloud consumers can unilaterally provision computing functions such as server time and network storage automatically as needed, without requiring human interaction with a service provider. Extensive network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: Using a multi-tenant model, a provider's computing resources are pooled to serve multiple consumers, with different physical and virtual resources dynamically allocated and reallocated as needed. Consumers generally do not have control or knowledge of the exact location of the resources provided, but they can specify the location at a higher level of abstraction (e.g., country, state, or data center), thus exhibiting a degree of location independence. Rapid elasticity: To scale out quickly, release quickly, and scale in quickly, features can be provisioned quickly and elastically, sometimes automatically. To consumers, the features available for provisioning often appear unlimited, and they can purchase any amount at any time. Measurement Services: Cloud systems automatically control and optimize resource usage by leveraging metric capabilities at some appropriate level of abstraction for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both service providers and consumers of the services being used.

[0068] The service model is as follows: Software as a Service (SaaS): The functionality provided to consumers is the use of the provider's applications running on cloud infrastructure. These applications are accessible from various client devices through thin-client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application functionalities, with the possible exception being limited user-specific application configuration settings. Platform as a Service (PaaS): The functionality offered to consumers is the deployment of applications they have created or acquired, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the applications they deploy and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capabilities offered to consumers are provisioning of processing, storage, networking, and other basic computing resources, allowing consumers to deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have limited control over the operating system, storage, deployed applications, and, in some cases, selected networking components (e.g., host firewalls).

[0069] The deployment model is as follows: Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by the organization or a third party, and may reside on-premises or off-premises. Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., missions, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by an organization or a third party and may reside on-premises or off-premises. Public cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services. Hybrid Cloud: A hybrid cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain separate entities but are linked together by standardization technologies that enable data and application portability or technologies that allow for the assertion of ownership (e.g., cloud bursting for load balancing between clouds).

[0070] Cloud computing environments are services that aim to focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0071] The present invention may be a system, method, or computer program product, or a combination thereof, with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0072] Computer-readable storage media can be tangible devices that hold and store instructions for use by instruction-executing devices. Computer-readable storage media can be, for example, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved structures on which instructions are recorded, and any suitable combination thereof. In this specification, computer-readable storage media should not be interpreted as inherently transient signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0073] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via 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, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers them for storage in a computer-readable storage medium within each computing / processing device.

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

[0075] Aspects of the present invention will be described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block in a flowchart or block diagram, or both, and any combination of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0076] Such computer-readable program instructions may be given to a computer or other programmable data processing device processor, through instructions executed via the processor of the computer or other programmable data processing device, to generate means for implementing functions / operations specified in one or more blocks of a flowchart or block diagram, or both, thereby creating a machine. Such computer-readable program instructions may also be stored in a computer-readable storage medium that can be instructed to function in a particular manner to a computer, a programmable data processing device, or other device, or a combination thereof, so as to contain a product containing instructions that implements the modes of functions / operations specified in one or more blocks of a flowchart or block diagram, or both.

[0077] Computer-readable program instructions can also be loaded onto a computer, other programmable device, or other device so that the instructions executed on the computer, other programmable device, or other device implement a function / operation specified in one or more blocks of a flowchart or block diagram, or both, thereby generating a computer implementation process by causing the computer, other programmable device, or other device to perform a series of operational steps.

[0078] 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 containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described within a block may be performed in an order other than that shown in the figures. For example, two blocks shown consecutively may actually be performed as a single step, simultaneously or nearly simultaneously, in a manner that partially or entirely overlaps in time, or the blocks may sometimes be performed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, or both, and any combination of blocks in a block diagram or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0079] While various embodiments of the present invention have been presented for illustrative purposes, the description is not exhaustive and is not limited to the embodiments disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the embodiments described. The terms used herein have been chosen to best describe the principles, practical applications, or technological improvements over technologies available on the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A middleware computer system for controlling transaction requests between an application and a server, The middleware computer system includes a broker component, and the broker component, at runtime, Based on previously observed transaction collisions, one or more collision groups of transaction requests are defined, where transaction requests that have previously or currently experienced transaction collisions are considered to belong to the same collision group, and transaction requests that have not previously or currently experienced transaction collisions are considered to belong to different collision groups. Based on the aforementioned one or more collision groups, the delivery of parallel transaction requests is controlled, where transaction requests from the same collision group are delivered sequentially, and transaction requests from different collision groups are delivered in parallel. It is configured in such a way, The broker component is The system includes a receiver component configured to receive information about another collision group of a transaction request from a remote component, and the broker component is configured to update the one or more collision groups of the transaction request at runtime based on the received information. Middleware computer systems.

2. The middleware computer system according to claim 1, wherein each of the one or more collision groups defines a plurality of transaction requests that result in transaction collisions in response to being delivered in parallel.

3. The middleware computer system according to claim 1, wherein the broker component comprises a publisher component configured to communicate information about the one or more collision groups to one or more remote components.

4. The middleware computer system according to claim 1, wherein the broker component is configured to queue the multiple transaction requests in order to prevent parallel delivery of the multiple transaction requests in response to the broker component identifying multiple transaction requests that are members of the same collision group among the one or more collision groups.

5. The middleware computer system according to claim 4, wherein the broker component is configured to queue the plurality of transaction requests in a first-in, first-out order.

6. The middleware computer system according to claim 1, wherein the broker component is configured to, in response to identifying a transaction collision resulting from the delivery of a transaction request, redefine one or more collision groups of the transaction request based on the identified transaction collision, and control the redelivery of the transaction request based on the one or more redefined collision groups.

7. The middleware computer system according to claim 1, wherein the middleware system is configured to intercept and control the delivery of transaction requests between a client application and a multi-version concurrency control (MVCC) constrained server.

8. A processor implementation method for controlling transaction requests between an application and a server, The processor implementation method is, At runtime, one or more collision groups of transaction requests are defined based on previously observed transaction collisions, where transaction requests that have previously or currently observed transaction collisions are considered to belong to the same collision group, and transaction requests that have not previously or currently observed transaction collisions are considered to belong to different collision groups. Based on the one or more collision groups, the delivery of parallel transaction requests is controlled, wherein transaction requests from the same collision group are delivered sequentially, and transaction requests from different collision groups are delivered in parallel. Includes, The processor implementation method is, Receiving information about another collision group of transaction requests from remote components. It further includes, Here, updating one or more collision groups of a transaction request is based on the information received. method.

9. The method according to claim 8, wherein each of the one or more collision groups defines a plurality of transaction requests that result in transaction collisions in response to being delivered in parallel.

10. To communicate information about the one or more collision groups to one or more remote components. The method according to claim 8, further comprising:

11. In response to identifying multiple transaction requests that are members of the same collision group among the one or more collision groups, the plurality of transaction requests are queued to prevent parallel delivery of the plurality of transaction requests. The method according to claim 8, further comprising:

12. The method according to claim 8, wherein queuing the plurality of transaction requests includes queuing the plurality of transaction requests in a first-in, first-out order.

13. In response to identifying a transaction collision resulting from the delivery of a transaction request, the one or more collision groups of the transaction request are redefined based on the identified transaction collision. To control the resending of the transaction request based on one or more redefined collision groups. The method according to claim 8, further comprising:

14. The method according to claim 8, configured to intercept and control the delivery of transaction requests between a client application and a server with multi-version concurrency control (MVCC) constraints.

15. A computer program that runs on a middleware computer on a computer network and causes the middleware computer to perform the method according to any one of claims 8 to 14 for controlling transaction requests between an application and a server.

Images