KR100198809B1 - Processing method of distributed commit protocol concering the nested transaction - Google Patents

Processing method of distributed commit protocol concering the nested transaction Download PDF

Info

Publication number
KR100198809B1
KR100198809B1 KR1019960064144A KR19960064144A KR100198809B1 KR 100198809 B1 KR100198809 B1 KR 100198809B1 KR 1019960064144 A KR1019960064144 A KR 1019960064144A KR 19960064144 A KR19960064144 A KR 19960064144A KR 100198809 B1 KR100198809 B1 KR 100198809B1
Authority
KR
South Korea
Prior art keywords
transaction
coordinator
withdrawal
message
result
Prior art date
Application number
KR1019960064144A
Other languages
Korean (ko)
Other versions
KR19980045899A (en
Inventor
장덕호
김문자
류영철
손덕주
Original Assignee
정선종
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 정선종, 한국전자통신연구원 filed Critical 정선종
Priority to KR1019960064144A priority Critical patent/KR100198809B1/en
Publication of KR19980045899A publication Critical patent/KR19980045899A/en
Application granted granted Critical
Publication of KR100198809B1 publication Critical patent/KR100198809B1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/17—Interprocessor communication using an input/output type connection, e.g. channel, I/O port

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

본 발명은 분산 트랜잭션 처리 방법에 관한 것으로, 무결성있는 데이터 처리가 목적인 트랜잭션 처리에서 분산 트랜잭션 전체가 승인되던지, 혹은 전체가 철회되던지 둘중의 하나를 선택하는 기존의 방식에서 긴 트랜잭션을 처리해야 하거나 전체 트랜잭션의 일부를 승인하고자 할 때 트랜잭션 처리가 비효율적으로 처리되는 단점을 해결하고 트랜잭션 처리의 효율성과 무결성을 동시에 처리하기 위한 내포 트랜잭션을 지원하는 분산 트랜잭션 승인 규약 처리 방법이 제시된다.The present invention relates to a distributed transaction processing method, wherein in a transaction processing for which integrity data processing is desired, a long transaction must be processed in an existing manner of selecting either the whole distributed transaction is approved or the whole is withdrawn. The distributed transaction acknowledgment processing method is proposed to solve the disadvantage that transaction processing is inefficient when trying to approve a part of the whole transaction and to support nested transactions to simultaneously handle the efficiency and integrity of transaction processing.

Description

내포 트랜잭션을 지원하는 분산 트랜잭션 승인 규약 처리 방법How to handle distributed transaction acknowledgment protocols that support nested transactions

본 발명은 분산 트랜잭션 처리 방법에 관한 것으로, 특히 내포 트랜잭션을 수행하는 분산 트랜잭션 승인 규약 처리 방법에 관한 것이다.The present invention relates to a distributed transaction processing method, and more particularly, to a distributed transaction approval protocol processing method for performing a nested transaction.

본 발명은 내포 트랜잭션 모델(nested transaction model)을 지원하는 분산 트랜잭션 처리에서 전체 트랜잭션의 승인 규약(commit protocol)을 제시한다. 이단계 승인 규약(two-phase commit protocol)으로 불리는 일반적인 분산 트랜잭션 승인 규약은 잘 알려져 있으며, 그 최적화된 규격은 사용 트랜잭션 처리 시스템에서 널리 사용되고 있다. 내포 트랜잭션 모델은 컴퓨터 지원 설계(Computer Aided Design)와 같이 전체 트랜잭션의 수행 시간이 긴 환경이나 일부 트랜잭션의 실패에도 불구하고 나머지 트랜잭션 부분을 살리고자 하는 경우에 활용된다. 응용 프로그램이 고기능화되고 멀티미디어 데이터가 일반화 됨에 따라 내포 트랜잭션의 요구가 점증하고 있다. 그러나, 아직 내포 트랜잭션을 지원하는 분산 트랜잭션의 승인 프로토콜은 발표된 사례가 없다.The present invention proposes a commit protocol for an entire transaction in distributed transaction processing that supports a nested transaction model. Common distributed transaction approval protocols, known as two-phase commit protocols, are well known and their optimized specifications are widely used in transaction processing systems in use. The nested transaction model is used in environments with long execution times of entire transactions, such as Computer Aided Design, or to save the rest of transactions despite the failure of some transactions. As applications become more functional and multimedia data become more common, the demand for nested transactions is increasing. However, there have been no published public announcement protocols for distributed transactions that support nested transactions.

트랜잭션 처리 응용의 고기능화 추세에 따라 내포 트랜잭션 모델을 지원하기 위해서는 분산 트랜잭션의 조정자가 내리는 전체 트랜잭션의 승인에 대한 판단 기준이 종래의 만장일치 투표방식에서 바뀌어야 한다.In order to support the nested transaction model in accordance with the trend of high functionalization of transaction processing applications, the criterion for approval of the entire transaction issued by the coordinator of the distributed transaction must be changed from the conventional unanimous voting method.

종래의 분산 트랜잭션 처리 방법은 제1도를 이용하여 설명하기로 한다.A conventional distributed transaction processing method will be described with reference to FIG.

제1도는 일반적인 플랫 트랜잭션을 지원하는 이단계 승인 규약의 흐름도로서, 그 동작의 주요 부분, 즉부분만을 설명하면 다음과 같다. 조정자는 각 참여자가 투표한 결과 중 하나 이상의 철회 투표가 있을 경우에는 철회(abort)를 로그에 기록하고 각 참여자에게 전체 철회(global abort) 메시지를 보낸다(109). 그렇지 않고 참여자 모두가 승인 투표를 했다면, 승인(commit)을 로그에 기록한 후 각 참여자에게 전체 승인(global commit) 메시지를 보낸다(110). 조정자로부터의 전체 트랜잭션 승인 여부에 관한 통보를 받은 후 참여자가 취하는 행위는 본 발명의 경우를 도시한 제4도와 동일하며, 조정자의 결정에 따라 지역 트랜잭션을 승인 혹은 철회시키고, 그 결과를 로그에 기록한 후 확인(acknowledge)메시지를 보낸다. 조정자는 모든 참여자로부터 확인(acknowledge)메시지를 받으면 트랜잭션의 종료를 로그에 기록한다(113). 이로써 전체 트랜잭션의 승인 처리가 종료된다.Figure 1 is a flow diagram of a two-stage approval protocol that supports general flat transactions, the main part of its operation, i.e. If only part is described as follows. The coordinator logs the abort in the log and sends a global abort message to each participant if there is more than one withdrawal vote among the results of each participant voting (109). Otherwise, if all the participants voted for approval, record the commit in the log and send a global commit message to each participant (110). The action taken by the participant after being informed of the approval of the entire transaction from the coordinator is the same as that of FIG. 4, which illustrates the case of the present invention. It sends an acknowledgment message. When the coordinator receives an acknowledgment message from all participants, it logs 113 the end of the transaction. This completes the approval process for the entire transaction.

트랜잭션 처리는 무결성있는 데이터 처리가 목적이다. 그러나 이러한 목적을 위한 기존의 방식은 트랜잭션 전체가 처리되던지, 혹은 전체가 철회되던지 둘중의 하나를 선택하는 방식이었다. 그러나 트랜잭션 처리에 많은 시간이 소요되는 긴 트랜잭션(long transaction)을 처리해야 하거나 전체 트랜잭션의 일부를 승인하고자 하는 응용에서는 이러한 종래의 방식이 트랜잭션 처리의 비효율성을 초래한다. 왜냐하면, 장시간 수행되던 트랜잭션이 사소한 오류로 인해 전체가 철회될 수밖에 없기 때문이다. 예를 들어 내포 트랜잭션이 아닌 플랫 트랜잭션만으로 여행 예약 처리 프로그램을 수행시킨다면, 항공편 예약이 성공적으로 수행되었다 할지라도 원하는 호텔의 예약을 할 수 없다면 항공편 예약까지도 취소되는 비효율성을 초래하게 된다. 그러므로 트랜잭션 처리의 유연성과 무결성을 동시에 처리하기 위해서는 새로운 트랜잭션 모델과 이의 특성을 고려한 전체 트랜잭션 승인 프로토콜을 제시해야 하는 과제를 제기하게 된다.Transaction processing aims at integrity data processing. However, the existing approach for this purpose was to choose whether the whole transaction would be processed or the whole would be withdrawn. However, in applications that need to handle long transactions that take a long time for transaction processing or want to approve a portion of an entire transaction, this conventional approach leads to inefficiencies in transaction processing. This is because transactions that have been running for a long time can only be canceled due to minor errors. For example, if a travel reservation processing program is executed only by a flat transaction instead of a nested transaction, even if the flight reservation is successfully performed, the flight reservation may be canceled if the desired hotel cannot be made. Therefore, in order to simultaneously handle the flexibility and integrity of transaction processing, the challenge is to present a new transaction model and a complete transaction approval protocol considering its characteristics.

따라서, 본 발명은 내포 트랜잭션 모델의 특성을 고려한 새로운 전체 트랜잭션의 승인 규약 처리 방법을 제공하는 데 그 목적이 있다.Accordingly, an object of the present invention is to provide a method for processing an approval protocol for a whole new transaction in consideration of the characteristics of a nested transaction model.

상술한 목적을 달성하기 위한 본 발명은 조정자 및 참여자의 초기 상태에서 조정자가 로그에 시작 레코드를 기록한 후 각 참여자에게 준비 메시지를 전송하는 단계와, 상기 준비 메시지를 수신한 참여자는 트랜잭션을 정상적으로 수행할 수 있는지를 검사하여 정상적으로 수행할 수 있을 경우 승인 메시지를 조정자에게 전송하는 단계와, 상기 트랜잭션을 정상적으로 수행할 수 있는 지의 검사 결과 정상적으로 수행할 수 없을 경우 철회 메시지를 조정자에게 전송하는 단계와, 상기 조정자가 참여자로부터 수신한 메시지에서 투표 결과에 철회가 있는지를 검사하는 단계와, 상기 투표 결과에 철회가 있는지의 검사 결과 철회가 없을 경우 전체 트랜잭션을 승인하는 단계와, 상기 투표 결과에 철회가 있는지의 검사 결과 철회가 있을 경우 플랫 트랜잭션이 철회 투표한 것인지를 검사하는 단계와, 상기 플랫 트랜잭션이 철회 투표한 것인지의 검사 결과 하나 이상의 플랫 트랜잭션이 철회 투표를 했을 경우 조정자는 전체를 철회하는 단계와, 상기 플랫 트랜잭션이 철회 투표한 것인지의 검사 결과 내포 트랜잭션만이 철회 투표를 했을 경우 조정자는 전체 트랜잭션을 승인하는 단계와, 상기 승인 여부를 결정한 조정자는 상기 결정 사항을 로그에 기록하고 참여자들에게 메시지를 전송하는 단계와, 상기 조정자의 승인 여부 결정 사항을 수신한 참여자는 상기 결정 사항을 토대로 자신의 트랜잭션을 승인 혹은 철회 시킨 후 이를 로그에 기록하고 조정자에게 확인 메시지를 전송하는 단계와, 상기 확인 메시지를 수신한 조정자는 로그에 트랜잭션 종료를 기록한 후 전체 승인 프로토콜을 종료하는 단계들로 구성되어 있는 것을 그 특징으로 한다.According to the present invention for achieving the above object, the coordinator and the partner in the initial state of the coordinator writes a start record in the log and transmits a preparation message to each participant, the participant receiving the preparation message can perform the transaction normally Transmitting a confirmation message to the coordinator if it is possible to perform the transaction normally, and if the transaction is not normally performed as a result of checking whether the transaction can be performed normally, sending a revocation message to the coordinator; Checking whether there is a withdrawal in the voting result in a message received from the participant, approving the entire transaction if there is no withdrawal as a result of the check that the voting result is withdrawn, and checking whether the voting result is withdrawn Flat transaction if there is a retraction of results Checking if the withdrawal ballot has been withdrawn; if at least one flat transaction has had a withdrawal vote as a result of the check that the flat transaction has withdrawn withdrawal, the coordinator withdraws the whole; and withdraws the withdrawal vote with the flat transaction. If only the nested transaction has a withdrawal vote, the coordinator approves the entire transaction; if the coordinator decides whether to approve the transaction, the coordinator logs the decision and sends a message to the participants; Upon receiving the decision, the participant approves or withdraws the transaction based on the decision, records it in the log, and sends a confirmation message to the coordinator. The coordinator receiving the confirmation message records the transaction termination in the log. Steps to terminate the entire authorization protocol And in that the property to its features.

제1도는 종래의 플랫 트랜잭션을 지원하는 이단계 승인 규약 처리 방법의 흐름도.1 is a flow diagram of a two-step authorization protocol processing method supporting a conventional flat transaction.

제2도는 본 발명이 적용되는 내포 트랜잭션 개념을 설명하기 위해 도시한 블록도.2 is a block diagram illustrating the concept of a nested transaction to which the present invention is applied.

제3도는 본 발명이 적용되는 내포 트랜잭션을 지원하는 분산 시스템 예를 도시한 블록도.3 is a block diagram illustrating an example of a distributed system supporting nested transactions to which the present invention is applied.

제4도는 본 발명에 따른 내포 트랜잭션을 지원하는 분산 트랜잭션의 이단계 승인 규약 처리 방법의 흐름도.4 is a flow chart of a two-step authorization protocol processing method of a distributed transaction supporting a nested transaction according to the present invention.

* 도면의 주요부분에 대한 부호의 설명* Explanation of symbols for main parts of the drawings

31 : 클라이언트 사이트 32 : 서버 사이트31: client site 32: server site

종래 기술의 문제점, 즉 플랫 트랜잭션만을 지원하는 트랜잭션 시스템에서 제공되는 이단계 승인 프로토콜은 내포된 트랜잭션을 효과적으로 지원할 수 없다는 문제점을 해결하기 위하여, 본 발명에서 강구한 기술적 수단은 첫째 내포 트랜잭션 모델의 특성을 분석하고, 그 특성을 살리기 위해 트랜잭션 조정자가 전체 트랜잭션을 승인하기 위해 고려해야 할 점을 승인 판단의 기준으로 삼게 하였다. 이렇게 함으로써 긴 시간 동안 수행한 트랜잭션을 사소한 오류로 인해 전체적인 트랜잭션을 철회시켜야 하는 비효율성을 피할 수 있게 된다.In order to solve the problems of the prior art, that is, the two-stage acknowledgment protocol provided in a transaction system that supports only flat transactions cannot effectively support nested transactions, the technical means devised in the present invention is to first characterize the nested transaction model. In order to make use of the characteristics, the transaction coordinator used the criteria for approval decision to consider to approve the entire transaction. This avoids the inefficiency of having to withdraw the entire transaction due to minor errors in long-running transactions.

이러한 문제의 구체적인 해결 방법은 참여자로부터의 투표 결과에서 철회 투표를 한 경우가 있을 경우 무조건 철회시키지 않고, 그 참여자가 내포 트랜잭션을 처리하는 것인지 혹은 플랫 트랜잭션을 처리하는 것인지를 판단하여, 플랫 트랜잭션인 경우에만 전체 트랜잭션을 철회하도록 한다.The specific solution to this problem is to determine whether the participant handles a nested transaction or a flat transaction without retracting if there is a withdrawal vote in the result of the vote from the participant. Only retract the entire transaction.

분산 트랜잭션은 트랜잭션 처리 프로그램의 하나 이상의 실행문이 여러 사이트에 분산된 데이터를 처리하는 트랜잭션을 말한다. 고급 트랜잭션 모델의 하나인 내포 트랜잭션 모델은 제2도에 도시된 바와 같이 한 트랜잭션내에 서브 트랜잭션(subtransaction)을 정의할 수있게 하는 것이다.A distributed transaction is a transaction in which one or more execution statements of a transaction processing program process data distributed to multiple sites. The nested transaction model, one of the advanced transaction models, allows one to define a subtransaction within a transaction, as shown in FIG.

내포 트랜잭션은 아래와 같은 특징을 가지고 있다.Nested transactions have the following characteristics:

1) 트랜잭션의 원자성(atomicity), 분리성(isolation), 동시성(concurrency) 특성을 지원한다.1) It supports the atomicity, isolation, and concurrency characteristics of transactions.

2) 트랜잭션의 지속성(durability)은 부모 트랜잭션의 승인 여부에 좌우된다. 만약 부모 트랜잭션이 승인되면, 내포 트랜잭션의 변화는 지속성을 가진다. 또한, 부모 트랜잭션이 철회(abort)되면, 내포 트랜잭션의 변화는 같이 철회된다.2) The durability of a transaction depends on the approval of the parent transaction. If the parent transaction is approved, the change in the nested transaction is persistent. Also, if the parent transaction is aborted, the change in the nested transaction is also withdrawn.

3) 트랜잭션의 내포는 임의 깊이를 갖는 트랜잭션 트리를 구성할 수 있다.3) Nesting of transactions can constitute a transaction tree with any depth.

제3도는 본 발명이 적용되는　 내포 트랜잭션을 지원하는 분산 트랜잭션 클라이언트 프로그램을 수행하는 분산 시스템 환경을 도시한 블록도이다. 아래와 같은 프로그램을 수행할 때 서버(32) A와 B는 플랫 트랜잭션을 수행하고, 서버(32) C, D는 내포 트랜잭션을 수행한다. 클라이언트 사이트(31)는 조정자(coordinator)가 되며, 서버 사이트(33) A, B, C, D는 참여자(participant)가 된다.3 is a block diagram illustrating a distributed system environment for executing a distributed transaction client program that supports nested transactions to which the present invention is applied. When executing the following program, servers 32 A and B perform a flat transaction, and servers 32 C and D perform a nested transaction. The client site 31 becomes a coordinator, and the server sites 33 A, B, C, and D become participants.

일반적인 분산 트랜잭션의 승인은 트랜잭션에 참여한 참여자 모두가 만장 일치로 승인을 결정해야만 전체 트랜잭션이 승인된다. 그러나 내포 트랜잭션을 지원할 경우는 아래와 같은 조건에 따라 분산 트랜잭션의 승인 여부를 결정해야 한다.In general, the approval of a distributed transaction requires that all participants in the transaction decide the approval by unanimous agreement. However, when supporting nested transactions, it is necessary to determine whether to approve distributed transactions according to the following conditions.

1) 만약 모든 참가자들이 승인하도록 투표하면, 조정자는 전체 승인 결정을 내린다.1) If all participants vote to approve, the coordinator makes a full approval decision.

2) 만약 하나 이상의 플랫 트랜잭션이 트랜잭션을 철회하도록 투표하면 조정자는 전체적인 철회(global abort)결정을 내린다.2) If more than one flat transaction votes to withdraw the transaction, the coordinator makes a global abort decision.

3) 만약 하나 이상의 내포 트랜잭션이 트랜잭션을 철회하도록 투표하고, 모든 플랫 트랜잭션이 승인 투표를 하면 조정자는 전체적인 승인 결정을 내린다.3) If more than one nested transaction votes to withdraw the transaction and all flat transactions vote for approval, the coordinator makes an overall approval decision.

제4도는 본 발명에 다른 내포 트랜잭션을 지원하는 이단계 승인 규약 처리 방법의 흐름도로서, 아래와 같은 방식으로 승인 결정 과정이 이루어진다. 하나의 분산 트랜잭션 처리에는 하나의 트랜잭션 조정자와 다수의 참여자로 구성된다. 일반적으로 조정자는 클라이언트 프로그램을 수행하는 사이트가 되며, 서버 사이트는 참여자가 된다. 조정자의 역할은 각 참여자에게 각자가 맡은 트랜잭션의 부분에 대해 승인 여부를 투표하게 하여 각 참여자의 투표 결과를 토대로 전체 트랜잭션을 승인할 것인지의 여부를 결정하는 것이다. 제4도에서 타원은 승인 프로토콜의 각 상태를, 직사각형은 승인 프로토콜이 중단되는 문제가 발생시 트랜잭션을 회복(recovery)하기 위한 로그 데이터를 기록하는 부분이다. 마름모꼴은 승인 결정을 위한 판단의 기준을 나타내고, 점선 부분은 조정자와 참여자가 주고받는 메시지와 그 방향성을 나타낸다. 그림3의 좌하단에 강조된부분은 제1도에서 설명된 종래 기술과 다른 내용이다. 제4도에 나타난 승인 규약 처리 방법의 수행 과정을 단계별로 설명하면 다음과 같다. 승인 프로토콜의 시작을 위한 조정자의 초기 상태(401)와 참여자의 초기 상태(402)에서 조정자가 로그 시작(begin) 레코드를 기록한 후 각 참여자에게 준비(prepare) 메시지를 보낸다(403). 준비(prepare) 메시지를 수신한 참여자는 자신이 맡은 트랜잭션 부분을 정상적으로 수행할 수 있는지를 판단하여(404) 트랜잭션 부분을 정상적으로 수행하고 승인 과정에 참여할 수 있으면 로그 준비(ready) 레코드를 기록하고 승인(commit) 메시지를 조정자에게 보낸다(405). 판단 결과 그렇지 못할 경우에는 철회(abort) 레코드를 기록하고 철회(abort) 메시지를 보낸 후(406) 철회한다(419). 여기까지의 과정은 승인 규약 처리 방법의 제1단계에 해당한다. 이후 부분은 승인 규약 처리 방법의 제2단계에 속한다. 참여자로부터 철회 및 승인 메시지를 수신한 조정자는 대기 상태(407)에서 각 참여자가 보낸 메시지를 검토하여 먼저 투표결과에 철회가 있는지 확인한다(408). 철회가 없다면 로그 승인 레코드를 기록하고(411) 준비 상태(415)의 참여자에게 포괄적인 승인 메시지를 송신한 후 전체 트랜잭션을 승인하고(412) 종료한다(414). 철회 투표가 있다면 그 중 플랫 트랜잭션이 철회 투표를 한 것이 있는지 확인한다(409). 하나 이상의 플랫 트랜잭션이 철회 투표를 했다면 조정자는 로그 철회 레코드를 기록한 후(410) 전체를 철회하고(413) 종료한다(414). 그렇지 않고, 내포 트랜잭션들만이 철회 투표를 하였다면, 조정자는 전체 트랜잭션 승인을 결정하여 상기 단계(411), (412) 및 (414)를 수행한다. 조정자는 승인 여부에 관한 결정 사항을 로그에 기록하고, 참여자들에게 결정 사항을 전체 승인(global-commit)혹은 전체 철회(global-abort) 메시지를 참여자들에게 보낸다(411). 참여자들은 통보받은 결과를 토대로 자신이 수행한 트랜잭션을 승인 혹은 철회 시킨다. 대기 상태(415)에서 메시지를 수신한 참여자는 수신한 메시지의 종류를 검사한다(416). 검사 결과 승인 메시지일 경우 로그 승인 레코드를 기록한 후(418) 조정자에게 확인 메시지를 송신하고 승인한다(420). 메시지 종류의 검사 결과 철회 메시지일 경우 로그 철회 레코드를 기록하고(417), 로그 철회 레코드를 기록한 후(417) 철회한다(419). 조정자는 참여자에게서 확인(acknowledge)메시지를 받으면 로그에 트랜잭션 종료를 기록함으로써 전체 승인 프로토콜이 종료된다(414).4 is a flow chart of a two-step approval protocol processing method supporting another nested transaction in the present invention, the approval decision process is made in the following manner. One distributed transaction process consists of one transaction coordinator and multiple participants. Typically, the coordinator will be the site running the client program, and the server site will be the participant. The coordinator's role is to have each participant vote on the part of the transaction they are in charge of, thus determining whether to approve the entire transaction based on each participant's voting result. In FIG. 4, an ellipse indicates each state of the approval protocol, and a rectangle indicates log data for recovering a transaction when a problem occurs that the approval protocol is interrupted. The lozenge represents the criterion for the decision to approve the decision, and the dashed line represents the message and direction between the coordinator and the participant. Highlighted at the bottom left of Figure 3 The part is different from the prior art described in FIG. The following describes the process of performing the approval protocol processing method shown in FIG. 4 as follows. In the initial state 401 of the coordinator and the initial state 402 of the participant for the start of the acknowledgment protocol, the coordinator records a log begin record and then sends a ready message to each participant (403). The participant who receives the ready message determines whether he can perform the part of his transaction normally (404), records the log ready record and approves if he can perform the part of the transaction normally and participate in the approval process. commit) sends a message to the coordinator (405). If it is not determined, record an abort record, send an abort message (406), and withdraw (419). The process up to this point corresponds to the first stage of the approval protocol processing method. The subsequent part belongs to the second stage of the approval protocol processing method. Having received the withdrawal and approval message from the participant, the coordinator first examines the message sent by each participant in the waiting state 407 to see if there is a withdrawal in the voting result (408). If there is no revocation, a log acknowledgment record is recorded (411), a comprehensive acknowledgment message is sent to the participant in the ready state (415), then the entire transaction is approved (412) and terminated (414). If there is a withdrawal ballot, check to see if any of the flat transactions has withdrawn it (409). If one or more flat transactions have voted for a withdrawal, the coordinator records the log withdrawal record (410) and then withdraws (413) the whole and terminates (414). Otherwise, if only nested transactions had a withdrawal vote, the coordinator determines the overall transaction approval and performs the steps 411, 412, and 414 above. The coordinator logs the decision on whether to approve and logs the decision to the participants (global-commit or global-abort) message to the participants (411). Participants will either approve or withdraw their transactions based on the notified results. The participant who receives the message in the waiting state 415 checks the type of the received message (416). If the check result is an approval message, after recording the log approval record (418), and sends a confirmation message to the coordinator (420). If the message type check result is a revocation message, a log revocation record is recorded (417), and a log revocation record is recorded (417) and then retracted (419). When the coordinator receives an acknowledgment message from the participant, the overall acknowledgment protocol is terminated by recording the transaction termination in the log (414).

상술한 바와 같이 본 발명에 의하면 트랜잭션 처리의 효율성을 높일 수 있는 효과가 있다. 여행 예약 처리 응용에서와 같이 호텔 예약이나 항공편 예약들을 내포 트랜잭션으로 처리할 수 있게 함으로써 응용 프로그램의 모든 일이 모두 다 만족되지 않더라도 일부 일을 할 수 있다. 즉 계좌 이체만 혹은 계좌 이체와 항공편 예약(혹은 호텔 예약)만이라도 트랜잭션적으로 승인될 수 있는 효과를 가져온다. 실패한 내포 트랜잭션은 그 부분만 다시 수행시킬 수 있으므로 전체 트랜잭션을 다시 수행하지 않아도 되는 효율성이 있다.As described above, the present invention has the effect of increasing the efficiency of transaction processing. As in the travel booking processing application, you can process hotel bookings or flight bookings in nested transactions so that you can do some work if not all of the applications are satisfied. In other words, only the transfer of money or only the transfer and flight booking (or hotel reservation) can be approved transactionally. Failed nested transactions can be redone only in part, thus eliminating the need to redo entire transactions.

Claims (1)

조정자 및 참여자의 초기 상태에서 조정자가 로그에 시작 레코드를 기록한 후 각 참여자에게 준비 메시지를 전송하는 단계와, 상기 준비 메시지를 수신한 참여자는 트랜잭션을 정상적으로 수행할 수 있는 지를 검사하여 정상적으로 수행할 수 있을 경우 승인 메시지를 조정자에게 전송하는 단계와, 상기 트랜잭션을 정상적으로 수행할 수 있는지의 검사 결과 정상적으로 수행할 수 없을 경우 철회 메시지를 조정자에게 전송하는 단계와, 상기 조정자가 참여자로부터 수신한 메시지에서 투표 결과에 철회가 있는지를 검사하는 단계와, 상기 투표 결과에 철회가 있는지의 검사 결과 철회가 없을 경우 전체 트랜잭션을 승인하는 단계와, 상기 투표 결과에 철회가 있는지의 검사 결과 철회가 있을 경우 플랫 트랜잭션이 철회 투표한 것인지를 검사하는 단계와, 상기 플랫 트랜잭션이 철회 투표한 것인지의 검사 결과 하나 이상의 플랫 트랜잭션이 철회 투표를 했을 경우 조정자는 전체를 철회하는 단계와, 상기 플랫 트랜잭션이 철회 투표한 것인지의 검사 결과 내포 트랜잭션만이 철회 투표를 했을 경우 조정자는 전체 트랜잭션을 승인하는 단계와, 상기 승인 여부를 결정한 조정자는 상기 결정 사항을 로그에 기록하고 참여자들에게 메시지를 전송하는 단계와, 상기 조정자의 승인 여부 결정 사항을 수신한 참여자는 상기 결정사항을 토대로 자신의 트랜잭션을 승인 혹은 철회시킨 후 이를 로그에 기록하고 조정자에게 확인 메시지를 전송하는 단계와, 상기 확인 메시지를 수신한 조정자는 로그에 트랜잭션 종료를 기록한 후 전체 승인 프로토콜을 종료하는 것을 특징으로 하는 내포 트랜잭션을 지원하는 분산 트랜잭션 승인 규약 처리 방법.In the initial state of the coordinator and the participant, the coordinator writes a start record in the log, and then sends a ready message to each participant, and the participant receiving the ready message can check whether the transaction can be performed normally. If it is not possible to perform the transaction normally, and if it cannot be performed normally, sending a revocation message to the coordinator; Checking if there is a withdrawal, approving the entire transaction if there is no withdrawal as a result of the inspection of the withdrawal of the ballot, and if the withdrawal of the result as a result of the inspection withdrawal of the ballot with the withdrawal result To check whether the The coordinator withdraws the whole if one or more of the flat transactions has a withdrawal vote as a result of the check that the flat transaction has withdrawn the vote, and only the nested transaction has withdrawn the withdrawal result as a result of the check whether the flat transaction has withdrawn the vote. If the coordinator approves the entire transaction, the coordinator who determines whether to approve the transaction records the decision in a log and sends a message to the participants, and the participant who receives the coordinator's approval decision is determined by the coordinator. Acknowledging or withdrawing the transaction based on the matter, recording it in a log and sending a confirmation message to the coordinator, and the coordinator receiving the confirmation message ends the entire acknowledgment protocol after recording the transaction termination in the log. Distributed support for nested transactions Transaction authorization protocol processing method.
KR1019960064144A 1996-12-11 1996-12-11 Processing method of distributed commit protocol concering the nested transaction KR100198809B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1019960064144A KR100198809B1 (en) 1996-12-11 1996-12-11 Processing method of distributed commit protocol concering the nested transaction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1019960064144A KR100198809B1 (en) 1996-12-11 1996-12-11 Processing method of distributed commit protocol concering the nested transaction

Publications (2)

Publication Number Publication Date
KR19980045899A KR19980045899A (en) 1998-09-15
KR100198809B1 true KR100198809B1 (en) 1999-06-15

Family

ID=19487124

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019960064144A KR100198809B1 (en) 1996-12-11 1996-12-11 Processing method of distributed commit protocol concering the nested transaction

Country Status (1)

Country Link
KR (1) KR100198809B1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100304122B1 (en) * 1999-09-09 2001-11-07 이계철 Method for processing transaction in ldap

Also Published As

Publication number Publication date
KR19980045899A (en) 1998-09-15

Similar Documents

Publication Publication Date Title
US6684223B1 (en) Performing 2-phase commit with presumed prepare
CA2413615C (en) Conflict resolution for collaborative work system
US6493726B1 (en) Performing 2-phase commit with delayed forget
US6662196B2 (en) Collision avoidance in bidirectional database replication
Abdallah et al. One-phase commit: does it make sense?
US20060190504A1 (en) Simulating multi-user activity while maintaining original linear request order for asynchronous transactional events
Al-Houmaily et al. Two-phase commit in gigabit-networked distributed databases
Holliday Replicated database recovery using multicast communication
CN101350022B (en) Changing process method based on database logical lock
JP3525933B2 (en) Synchronization procedure at the routing node
US11775509B1 (en) Systems and methods to fully process an initially incomplete replicated and committed transaction for a non-static application by using a plurality of transaction pattern tables
US6330686B1 (en) Handling protected conversation messages across IMS restart in shared queues environment
Padhye et al. Scalable transaction management with snapshot isolation for NoSQL data storage systems
Al-Houmaily et al. 1-2PC: the one-two phase atomic commit protocol
Georgakopoulos Multidatabase Recoverability and Recovery.
Al-Houmaily et al. An argument in favor of the presumed commit protocol
Alkhatib et al. Transaction management in distributed database systems: the case of oracle’s two-phase commit
KR100198809B1 (en) Processing method of distributed commit protocol concering the nested transaction
CN111127088B (en) Method, device, computer equipment and storage medium for realizing final consistency
Grefen et al. Integrity constraint checking in federated databases
Younas et al. A formal treatment of a SACReD protocol for multidatabase web transactions
Abdallah et al. Dictatorial transaction processing: Atomic commitment without veto right
Al-Houmaily et al. Atomicity with incompatible presumptions
Abdallah et al. A single-phase non-blocking atomic commitment protocol
WO2017135978A1 (en) Two-phase commit protocol mixing for distributed transactions

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20080303

Year of fee payment: 10

LAPS Lapse due to unpaid annual fee