KR0173056B1 - Transaction processing method in dispersive real time system - Google Patents

Abstract

The present invention relates to a transaction processing method in a distributed real-time system, wherein a collaborator transaction requires remote processing to ensure mutual consistency and atomicity between distributed transactions including time constraints for real-time processing. Stage 1; A second step of storing a message to be transmitted in a communication area for a remote processing request after performing the first step; A third step of generating a participant transaction for real-time processing by receiving a distributed remote processing message after performing the second step; A fourth step of asynchronously storing an execution result in an area to be received by a collaborator transaction after the participant transaction completes execution after performing the third step; And a fifth step of taking a message received asynchronously from the remote participant transaction requested by the cooperator transaction without a receiving command after performing the fourth step.

Description

Transaction Processing Method in Distributed Real-Time System

1 is a schematic structural diagram of a distributed real-time system to which the present invention is applied.

2 is a structural diagram showing an actual message transmission flow of communication commands according to the present invention.

3 is a flow diagram of an embodiment of a distributed real-time transaction processing method according to the present invention.

The present invention relates to a transaction processing method in a distributed real time system.

In general, various application programs operating in various real-time distributed systems, including a communication system, are distributed and operated at various sites (a type of processor) for reasons such as high reliability and high performance of the system.

In order to manage dynamically generated transactions in a real-time distributed system, an asynchronous message processing method is required for various reasons as follows.

First, if a single transaction requires distributed processing, he or she wants to perform local negotiations while waiting for the outcome of the transaction created at the remote site. For example, if a transaction requires a change to a remote database, then the transaction that requested the remote processing at the same time as the remote transaction that performs the change function does not need to continue to perform other work that is not related to the request. Because there is. As another example, considering a case where a query is performed on data distributed to multiple sites, a collaborator transaction requesting query processing sends a query request message to distributed sites. In this case, a new transaction is generated in each site that receives the request message, performs the requested query, and delivers the result to the collaborator transaction. At this time, the result messages of the remote transactions are asynchronously arrived at the collaborator transaction. Therefore, collaborator transaction needs asynchronous message processing method to receive and use the result message from multiple sites when parallel processing is required.

In order to manage such asynchronously generated and executed transactions, it is necessary to maintain the results of asynchronously received participant transactions until the collaborator transaction intends to use them in transactions that perform the collaborator role.

In fact, the atomic completion protocol protocol is driven to ensure mutual correspondence and atomicity among distributed transactions, and these protocols exchange many messages. There is a need for a communication method and a transaction management method suitable for a real-time system such as a method of transmitting and receiving asynchronously and generating a transaction while reducing the number of message exchanges.

Therefore, there is a need for a communication method that transacts events that occur dynamically within a distributed real-time system and allows message transmission while ensuring the above properties between these transactions.

The present invention devised in response to the above requirements provides a method for transactionalizing various events occurring in a distributed real-time system and a transaction processing method in a distributed real-time system that is an asynchronous message transmission method generated between these transactions. Its purpose is to.

In order to achieve the above object, the present invention provides a dynamic transaction processing method in a distributed real-time system, wherein when a collaborator transaction generates a remote processing request message when a remote processing request is made to another site, the present invention is distributed with a participant transaction generation request time constraint. A first step of constructing messages to be transmitted so as to ensure mutual correspondence and atomicity between transactions and storing them in a communication area within a site where a remote processing request will be performed; A second step of determining whether a message arrives in the site receiving the remote processing request message and generating a new participant transaction when the message arrives between new request messages; A third step of asynchronously transmitting the result to the collaborator transaction upon completion of the participant transaction, and storing the result message in the communication area of the collaborator transaction; A fourth step of investigating whether the execution results requested at the time when the result of the participant transaction is required while the cooperative transaction performs its own function separately from the participant transaction after performing the first step; And a fifth step of terminating the remote processing request of the collaborator transaction using all of the result messages of the required participant transaction when they arrive.

In the present invention, three types and commands for communication are defined to support a real-time distributed transaction processing function. Two commands, request_rpc and reply_rpc, are defined for transmission and one command, receive_rpc, is defined for reception.

Participant transactions that have performed remote processing requests immediately deliver their results to collaborator transactions after their execution is complete. These result messages are delivered asynchronously to the collaborator's site, so they must be maintained until a transaction uses these result messages. To this end, the following three commands were invented to support the meaning of 'send-and-no-wait'. The first is a request_rpc command for generating a remote processing request, the second is a receive_case_rpc command for receiving a request message, and the third is a reply_rpc command for sending a result message. When the dynamic transaction processing function is implemented based on the three types of communication methods presented, it is possible to reduce the number of transmissions of messages, and thus it can be preferably applied to distributed real-time systems requiring time constraints such as real-time systems. Indeed, the proposed method is applied to implement the Atomic Commitment Protocol, which is a protocol for guaranteeing the reliability of transactions in a distributed database system, in a real-time system.

Hereinafter, with reference to the accompanying drawings will be described in detail the present invention.

1 is a structural diagram of a series of distributed real-time systems such as an exchanger to which the present invention is applied.

Within each site in a real-time distributed system, a real-time system (hereinafter referred to as RTE) exists to support dynamic transaction processing. RTE, which supports dynamic transaction processing, supports the following three functions. It consists of a transaction manager that supports the creation and destruction of transactions, a communication manager that supports message exchange between transactions, and a scheduler that manages the execution order between transactions. In the distributed transaction processing structure, the daemon process that receives and processes events received from outside is always running in the distributed transaction processing structure. It has a communication area using shared memory to support message exchange between distributed transactions. This communication area provides message exchange between transactions in different sites. Accordingly, a communication area for message transmission between sites is defined in advance. When a transaction sends a message to another transaction at a remote site, the transaction to be received is sent through a predefined communication area. In other words, when a coordinating transaction wants to deliver a message to its own remote site, it is necessary to define a communication area for the remote site. Messages are delivered to remote transactions. In addition, remote transactions also deliver the resulting message to collaborator transactions through a pre-defined area after their execution is complete.

2 is a diagram illustrating a procedure of asynchronous remote processing for explaining the mutual flow for implementing a client-server structure to be implemented in a distributed real-time system.

Assuming that there are any two sites as shown in the figure, one site is Si, which is a cooperating site, and the other is Sj, which is a participant site. Further, it is assumed that the cooperating site Sj has a shared memory SMj, which is a communication area for communicating with the participant site Si, and an event flag EFj indicating which message has arrived in this communication area, SMj.

First, when the collaborator transaction Tc at the participant site Si requests remote processing, when a coworker transaction Tc wants to deliver a remote processing request message Mj to the cooperative site Sj using a command request_rpc for generating a predefined remote processing request, Is stored in shared memory SMj and transmitted to the site. The shared memory SMj stores information such as an ID for the collaborator transaction Tc, a transaction name for remote processing, a message INVOKE for a remote processing request, a message size, and an address for a message content. At the same time, the value in the event flag EFj is changed to 'set' to inform the cooperative site Sj that a request message has been generated from the cooperative transaction Tc. For reference, the event flag has two values here. One is 'SET', indicating that a message exists in the communication area, and the other has 'CLEAR' indicating that the message does not exist. These event flags play an important role in indicating communication status between transactions.

Every site has a daemon process that detects messages arriving asynchronously from the outside world. Therefore, the daemon process in the cooperative site Sj periodically checks the event flag EFj for the SMj communication area. If the content of the event flag EFj is set, the daemon process receives a request message from the shared memory SMj. The message Mj is taken using the receive_rpc command to receive. The daemon process analyzes the type of transaction in message Mj and creates a transaction Tp that will perform the remote processing request. At the same time, the contents of the event flag EFj are changed to 'clear'. Then, the remote processing request execution transaction Tp performs its own function with the support of the transaction manager. After the remote processing request execution transaction Tp completes the execution, the result is transmitted to the collaborator transaction Tc using the command reply_rpc to transmit the execution result message. In this case, the remote processing request performing transaction Tp uses the reply_rpc command, and the transaction manager stores the result message directly in a return-arrary to be received which is predefined in the cooperative transaction Tc. Thus, the cooperative transaction Tc can immediately receive the result messages arriving asynchronously without using a receive command arbitrarily.

3 is a flow diagram of an embodiment of a method for processing dynamic transactions occurring within a distributed real-time system in accordance with the present invention.

Generate a remote processing request message if the collaborator transaction requires a remote processing request to another site (1). In this case, messages to be transmitted are constructed and stored in a communication area within a site where a remote processing request is to be performed (2). Then, within the site that received the remote processing request message, it is determined whether the message has arrived (7), and when a new request message arrives, it creates a new participant transaction to process it and waits / cancels if it does not arrive. 8). Participant and collaborator transactions then perform their given function (9). When the participant transaction is finished, the execution result is asynchronously transmitted to the collaborator transaction. At this time, the result message is stored in the communication area of the collaborator transaction to complete the transmission (10, 11).

The collaborator transaction also performs its own function (4) and checks whether the execution results requested at the time when the result of the participant transaction are required have arrived (5). When all the necessary result messages have arrived, they are used to terminate the series of remote processing requests of the collaborator transaction (5). This process provides distributed real-time transaction processing that occurs asynchronously (6).

The present invention as described above, when the proposed communication command is applied to a real-time distributed system has the following advantages.

First, you can transform asynchronously generated remote processing requests into transactions and manage them as transactions, so the inherent properties of a transaction can ensure consistency and atomicity.

Second, even if the transactions requesting the remote processing do not require the result message, the remote transaction stores the result of its execution asynchronously in the receiving area of the request, thereby reducing the number of message transmissions.

Third, time constraints can be delivered in the remote processing request message, thereby satisfying the temporal accuracy required in the real-time system.

Claims (1)

In a dynamic transaction processing method in a distributed real-time system, when a collaborator transaction generates a remote processing request message when a remote processing request is made to another site, mutual consistency and atomicity between distributed transactions are guaranteed under a participant transaction creation time constraint. A first step of constructing messages to be transmitted and storing them in a communication area within a site that will perform a remote processing request; A second step of determining whether a message arrives in the site receiving the remote processing request message and generating a new participant transaction when a new request message arrives; A third step of asynchronously transmitting the result to the collaborator transaction upon completion of the participant transaction, and storing the result message in the communication area of the collaborator transaction; A fourth step of investigating whether the execution results requested at the time when the result of the participant transaction is required while the cooperative transaction performs its own function separately from the participant transaction after performing the first step; And a fifth step of terminating the remote processing request of the collaborator transaction using them when all the result messages of the necessary participant transaction have arrived.