JP2007293650A - Distributed transaction control system and its method - Google Patents

Distributed transaction control system and its method Download PDF

Info

Publication number
JP2007293650A
JP2007293650A JP2006121534A JP2006121534A JP2007293650A JP 2007293650 A JP2007293650 A JP 2007293650A JP 2006121534 A JP2006121534 A JP 2006121534A JP 2006121534 A JP2006121534 A JP 2006121534A JP 2007293650 A JP2007293650 A JP 2007293650A
Authority
JP
Japan
Prior art keywords
transaction
end server
commit
distributed
processing
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
JP2006121534A
Other languages
Japanese (ja)
Inventor
Katsuhide Amatsu
克秀 天津
Tetsuya Suzuki
哲也 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Software Engineering Co Ltd
Hitachi Ltd
Original Assignee
Hitachi Software Engineering Co Ltd
Hitachi Ltd
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 Hitachi Software Engineering Co Ltd, Hitachi Ltd filed Critical Hitachi Software Engineering Co Ltd
Priority to JP2006121534A priority Critical patent/JP2007293650A/en
Publication of JP2007293650A publication Critical patent/JP2007293650A/en
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To recover transaction while holding the consistency of data only at an operating site even when any failure occurs in a specific site, and to continue task processing even when the defective site is not recovered in a distributed transaction system configured of a plurality of computers. <P>SOLUTION: In a transaction commit processing in a distributed transaction system, in instructing commit guarantee from a front end server to a back end server, the information of all back end servers communicating with the front end server is distributed to each back end server so that transaction settlement processing can be achieved only by the back end servers. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

本発明は、並列処理型データベース管理システムにおける分散トランザクションのコミット処理、特にシステムの部分障害の発生に対する耐久性を向上させたデータベース管理システムに関する。   The present invention relates to a database management system with improved durability against a commit process of a distributed transaction in a parallel processing type database management system, in particular, the occurrence of a partial failure of the system.

従来、並列処理型データベース管理システムにおける分散トランザクション処理での障害復旧の技術については、特許文献１に記載のものが知られている。下記特許文献１に記載のものは、複数の計算機からなる分散トランザクションシステムで、計算機間に渡る障害発生に備えて、システム内でトランザクションごとに一意の通番をファイルで管理し、障害復旧後にデータの一貫性を回復することができる。   Conventionally, as a failure recovery technique in distributed transaction processing in a parallel processing database management system, the one described in Patent Document 1 is known. The one described in Patent Document 1 below is a distributed transaction system composed of a plurality of computers. In preparation for the occurrence of a failure between computers, a unique serial number is managed in a file for each transaction in the system, and data is restored after failure recovery. Consistency can be restored.

特開平９−２０４３４１号公報JP-A-9-204341

しかしながら、上記特許文献１に記載の技術は、障害が発生した計算機が障害復旧する場合に有効な技術であり、システム上の部分的な障害が発生した状態でも業務処理を続行するという用途には適用できない。   However, the technique described in Patent Document 1 is a technique that is effective when a computer in which a failure has occurred is recovered from a failure, and is used for continuing business processing even when a partial failure on the system has occurred. Not applicable.

本発明の目的は、複数の計算機からなる分散トランザクションシステムで、特定の部位にて障害が発生した状態でも、稼動している部位のみでデータの一貫性を保ちつつトランザクションの回復を行い、かつ障害が発生した部位が復旧しなくても業務処理を続行することにある。   An object of the present invention is a distributed transaction system composed of a plurality of computers. Even when a failure occurs in a specific part, the transaction is recovered while maintaining data consistency only in the part that is operating, and This is to continue the business process even if the part where the error occurs is not recovered.

本発明は、並列処理型データベース管理システムにおけるトランザクションコミット処理において、フロントエンドサーバからバックエンドサーバへコミット保証指示を行う際に、フロントエンドサーバが通信を行っている全てのバックエンドサーバの情報を各々のバックエンドサーバへ分配する機構を用意して、バックエンドサーバのみでトランザクション決着処理を可能とすることを特徴とする。   In the transaction commit processing in the parallel processing type database management system, the present invention provides information on all back-end servers with which the front-end server communicates when issuing a commit guarantee instruction from the front-end server to the back-end server. It is characterized in that a mechanism for distributing to the back-end servers is prepared so that transaction settlement processing can be performed only by the back-end servers.

本発明によれば、ネットワーク上に分散配置されたサーバにてトランザクション処理を行う並列処理型データベース管理システムにおいて、フロントエンドサーバにて障害が発生した状態でも、稼動している他のサーバでデータの一貫性を保ちつつトランザクションの回復を行い、かつ障害が発生したフロントエンドサーバが復旧しなくても業務処理を続行できるという効果が有る。   According to the present invention, in a parallel processing database management system that performs transaction processing on servers distributed on a network, even if a failure occurs in a front-end server, Transactions can be recovered while maintaining consistency, and business processing can be continued even if the failed front-end server does not recover.

さらに、フロントエンドサーバではログを取得しないため、フロントエンドサーバのログファイル用意する必要が無く、バックエンドサーバにログ情報を集約できるという効果も有る。   Furthermore, since the front-end server does not acquire the log, there is no need to prepare the log file of the front-end server, and there is an effect that the log information can be collected on the back-end server.

以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。   Hereinafter, an embodiment for carrying out the present invention will be specifically described with reference to the drawings.

図１は、本発明の実施の並列処理型データベース管理システムの構成を示すブロック図である。本並列処理型データベース管理システムは、図１に示すように、トランザクションを管理するフロントエンドサーバが、個々にデータベースを管理しているバックエンドサーバと相互に通信を行って、アプリケーションプログラムからのデータ操作の要求を処理する。Ａノード１においてアプリケーションプログラム２からデータ操作の要求が発生すると、Ｂノード１１における本並列処理型データベース管理システムのトランザクション管理を行うフロントエンドサーバ１２がデータ操作要求の内容を解析し、該当するデータベースに対してデータ操作の要求を行う。フロントエンドサーバ１２からのデータ操作要求は、Ｅノード４１またはＦノード５１におけるバックエンドサーバ(４２，５２)が受け、該当するデータベース(４３，５３)にアクセスする。   FIG. 1 is a block diagram showing a configuration of a parallel processing database management system according to the embodiment of the present invention. As shown in FIG. 1, the parallel processing database management system is configured such that a front-end server that manages a transaction communicates with a back-end server that individually manages a database to manipulate data from an application program. Process the request. When a data operation request is generated from the application program 2 in the A node 1, the front-end server 12 that performs transaction management of the parallel processing type database management system in the B node 11 analyzes the content of the data operation request, and stores it in the corresponding database. A data operation request is made to the server. A data operation request from the front-end server 12 is received by the back-end server (42, 52) in the E node 41 or F node 51, and the corresponding database (43, 53) is accessed.

データ操作処理が完了し、アプリケーションプログラム２からコミット要求が発生すると、フロントエンドサーバ１２はバックエンドサーバ(４２，５２)と通信を行っているというトランザクションの構成情報と共に、バックエンドサーバ(４２，５２)にコミット指示を送信する。バックエンドサーバ(４２，５２)では、ログ情報管理処理部(４４，５４)がデータベース更新履歴とトランザクション構成情報をログファイル(４５，５５)に取得し、データベース(４３，５３)に対する処理が完了した後、コミット処理完了をフロントエンドサーバ１２に報告して一連のトランザクション処理を完了する。   When the data operation process is completed and a commit request is generated from the application program 2, the front-end server 12 and the back-end server (42, 52) together with the configuration information of the transaction that is communicating with the back-end server (42, 52). ) Send a commit instruction. In the back-end server (42, 52), the log information management processing unit (44, 54) acquires the database update history and transaction configuration information in the log file (45, 55), and the processing for the database (43, 53) is completed. After that, the completion of the commit process is reported to the front end server 12 to complete a series of transaction processes.

Ｃノード２１においてアプリケーションプログラム２２からデータ操作の要求が発生した場合は、Ｄノード３１のフロントエンドサーバ３２がデータ操作要求の内容を解析し、同様の処理を行う。   When a data operation request is generated from the application program 22 in the C node 21, the front end server 32 of the D node 31 analyzes the contents of the data operation request and performs the same processing.

図２はトランザクション構成情報の分配を行わない従来のトランザクション処理方式の流れを示すフローチャートであり、図３はその構成を示すブロック図である。以降、図２、図３を参照して説明する。   FIG. 2 is a flowchart showing a flow of a conventional transaction processing method in which transaction configuration information is not distributed, and FIG. 3 is a block diagram showing the configuration. Hereinafter, description will be made with reference to FIGS.

まず、アプリケーションプログラム３０２よりステップ２０１において、データ操作要求が発生する。これを受けて、フロントエンドサーバ３１２がステップ２０２でトランザクション開始処理を行う。次に、ステップ２０３でデータベース操作指示を、バックエンドサーバ(３４２，３５２)に送信する。   First, in step 201, a data operation request is generated from the application program 302. In response to this, the front-end server 312 performs a transaction start process in step 202. Next, in step 203, a database operation instruction is transmitted to the back-end servers (342, 352).

バックエンドサーバ(３４２，３５２)では、データベース操作指示を受け、ステップ２０４においてデータベース(３４３，３５３)の操作処理を行う。   The back-end server (342, 352) receives a database operation instruction, and performs operation processing of the database (343, 353) in step 204.

データベース操作処理(ステップ２０４)が終了すると、バックエンドサーバ(３４２，３５２)は処理完了をフロントエンドサーバ３１２に報告し、フロントエンドサーバ３１２に制御を戻す。これにより、フロントエンドサーバ３１２ではステップ２０５にてデータ操作成功の応答をアプリケーションプログラム３０２に返す。   When the database operation process (step 204) ends, the back-end server (342, 352) reports the process completion to the front-end server 312 and returns control to the front-end server 312. As a result, the front end server 312 returns a data operation success response to the application program 302 in step 205.

アプリケーションプログラム３０２では、次のステップ２０６においてコミット要求を送り、これを受けたフロントエンドサーバ３１２では、ステップ２０７でコミット保証指示をバックエンドサーバ(３４２，３５２)に送信する。   The application program 302 sends a commit request in the next step 206, and the front end server 312 that receives this sends a commit guarantee instruction to the back end servers (342, 352) in step 207.

バックエンドサーバ(３４２，３５２)では、ステップ２０８でログ情報管理処理部(３４４，３５４)において、データベース更新履歴をログファイル(３４５，３５５)に取得する。データベース更新履歴を取得した後、バックエンドサーバ(３４２，３５２)は、ステップ２０９でコミット保証処理成功応答をフロントエンドサーバ３１２に返す。   In the back-end server (342, 352), in step 208, the log information management processing unit (344, 354) acquires the database update history in the log file (345, 355). After acquiring the database update history, the back-end server (342, 352) returns a commit guarantee process success response to the front-end server 312 in step 209.

フロントエンドサーバ３１２では、ステップ２１０においてコミット保証成功応答によりコミット決定を行う。続いて、ステップ２１１でログ情報管理処理部３１３において、コミット決定履歴とバックエンドサーバ(３４２，３５２)と通信を行っているというトランザクション構成情報をログファイル３１４に取得する処理を行う。さらに、ステップ２１２においてコミット指示をバックエンドサーバ(３４２，３５２)に送信する。   In step 210, the front-end server 312 determines a commit based on a commit guarantee success response. Subsequently, in step 211, the log information management processing unit 313 performs processing for acquiring transaction configuration information in the log file 314 that communication is performed with the commit determination history and the back-end servers (342 and 352). In step 212, a commit instruction is transmitted to the back-end servers (342, 352).

バックエンドサーバ(３４２，３５２)ではコミット指示を受信すると、ステップ２１３においてログ情報管理処理部(３４４，３５４)がログファイル(３４５，３５５)にコミット決定履歴を取得する。そして、ステップ２１４においてデータベース(３４３，３５３)の実更新を行う。データベース(３４３，３５３)の実更新の終了後、フロントエンドサーバ３１２に制御を戻す。   When the back-end server (342, 352) receives the commit instruction, in step 213, the log information management processing unit (344, 354) acquires the commit determination history in the log file (345, 355). In step 214, the database (343, 353) is actually updated. After the actual update of the databases (343, 353) is completed, control is returned to the front-end server 312.

フロントエンドサーバ３１２では、ステップ２１５においてトランザクション終了処理を行い、次のステップ２１６でアプリケーションプログラム３０２にコミット成功の応答を返す。アプリケーションプログラム３０２がコミット成功の応答を受け、ステップ２１７においてコミットを完了し、１トランザクションは終了する。   The front end server 312 performs transaction end processing in step 215, and returns a commit success response to the application program 302 in the next step 216. The application program 302 receives the response of the commit success, completes the commit in step 217, and one transaction ends.

このようにして、各ノードのサーバは二相コミットプロトコルにしたがって互いに通信を行い、１つのトランザクション処理を行う。   In this way, the servers of each node communicate with each other according to the two-phase commit protocol and perform one transaction process.

以上のようなトランザクション構成情報の分配を行わない従来のトランザクション処理方式では、ステップ２０８からステップ２１２の間にフロントエンドサーバ３１２やＢノード３１１で処理続行不可能な障害が発生した場合、障害部位が復旧されなければバックエンドサーバ(３４２，３５２)はデータベース(３４３，３５３)の実更新の可否を判断できず、障害部位の復旧まで待ち合わせなければならない。このため、Ｄノード３３１のフロントエンドサーバ３３２が稼動していても、バックエンドサーバ(３４２，３５２)へのデータ操作が不可能となり、業務処理を続行できない状態となる。   In the conventional transaction processing method that does not distribute transaction configuration information as described above, when a failure that cannot be continued in the front-end server 312 or the B node 311 occurs between step 208 and step 212, the failure part is If it is not restored, the back-end servers (342, 352) cannot determine whether or not the database (343, 353) can be actually updated, and must wait until the failure site is restored. For this reason, even if the front-end server 332 of the D node 331 is operating, data operation to the back-end servers (342, 352) becomes impossible, and the business process cannot be continued.

一方、図４は本発明であるトランザクション構成情報の分配を行うトランザクション処理方式の流れを示すフローチャートである。以降、図１、図４を参照して説明する。   On the other hand, FIG. 4 is a flowchart showing the flow of a transaction processing method for distributing transaction configuration information according to the present invention. Hereinafter, a description will be given with reference to FIGS. 1 and 4.

アプリケーションプログラム２よりステップ４０１において、データ操作要求が発生すれば、フロントエンドサーバ１２はステップ４０２からのトランザクション処理の開始を行う。まず、ステップ４０２でトランザクション開始処理を行い、次にステップ４０３でデータベース操作指示を、バックエンドサーバ(４２，５２)に送信する。   If a data operation request is generated from the application program 2 in step 401, the front end server 12 starts transaction processing from step 402. First, in step 402, transaction start processing is performed, and in step 403, a database operation instruction is transmitted to the back-end servers (42, 52).

バックエンドサーバ(４２，５２)では、データベース操作指示を受け、ステップ４０４においてデータベース(４３，５３)の操作処理を行う。データベース操作処理(ステップ４０４)が終了すると、バックエンドサーバ(４２，５２)は処理完了をフロントエンドサーバ１２に報告し、フロントエンドサーバ１２に制御を戻す。これにより、フロントエンドサーバ１２ではステップ４０５にてデータ操作成功の応答をアプリケーションプログラム２に返す。   The back-end server (42, 52) receives a database operation instruction, and performs operation processing of the database (43, 53) in step 404. When the database operation process (step 404) ends, the back-end server (42, 52) reports the process completion to the front-end server 12, and returns control to the front-end server 12. As a result, the front end server 12 returns a data operation success response to the application program 2 in step 405.

アプリケーションプログラム２では、次のステップ４０６においてコミット要求を送り、これを受けたフロントエンドサーバ１２では、ステップ４０７でコミット保証指示と共に、バックエンドサーバ(４２，５２)と通信を行っているというトランザクション構成情報を、バックエンドサーバ(４２，５２)に送信する。   The application program 2 sends a commit request in the next step 406, and the front-end server 12 that has received the request transmits a commit guarantee instruction in step 407 and communicates with the back-end server (42, 52). Information is transmitted to the backend servers (42, 52).

バックエンドサーバ(４２，５２)では、ステップ４０８でログ情報管理処理部(４４，５４)において、データベース更新履歴とフロントエンドサーバ１２から受けたトランザクション構成情報をログファイル(４５，５５)に取得する。データベース更新履歴とトランザクション構成情報を取得した後、バックエンドサーバ(４２，５２)は、ステップ４０９でコミット保証処理成功応答をフロントエンドサーバ１２に返す。   In the back-end server (42, 52), in step 408, the log information management processing unit (44, 54) acquires the database update history and the transaction configuration information received from the front-end server 12 in the log file (45, 55). . After acquiring the database update history and transaction configuration information, the back-end server (42, 52) returns a commit guarantee process success response to the front-end server 12 in step 409.

フロントエンドサーバ１２では、ステップ４１０においてコミット保証成功応答によりコミット決定を行う。続いて、ステップ４１１においてコミット指示をバックエンドサーバ(４２，５２)に送信する。   In the front end server 12, in step 410, a commit decision is made based on a commit guarantee success response. Subsequently, in step 411, a commit instruction is transmitted to the back-end server (42, 52).

バックエンドサーバ(４２，５２)ではコミット指示を受信すると、ステップ４１２においてログ情報管理処理部(４４，５４)がログファイル(４５，５５)にコミット決定履歴を取得する。そして、ステップ４１３においてデータベース(４３，５３)の実更新を行う。データベース(４３，５３)の実更新の終了後、フロントエンドサーバ１２に制御を戻す。   When the back-end server (42, 52) receives the commit instruction, the log information management processing unit (44, 54) acquires the commit determination history in the log file (45, 55) in step 412. In step 413, the database (43, 53) is actually updated. After the actual update of the database (43, 53) is completed, control is returned to the front-end server 12.

フロントエンドサーバ１２では、ステップ４１４においてトランザクション終了処理を行い、次のステップ４１５でアプリケーションプログラム２にコミット成功の応答を返す。アプリケーションプログラム２がコミット成功の応答を受け、ステップ４１６においてコミットを完了し、１トランザクションは終了する。   The front-end server 12 performs a transaction end process in step 414 and returns a response indicating that the commit is successful to the application program 2 in the next step 415. The application program 2 receives the response of the commit success, completes the commit in step 416, and one transaction ends.

以上のようなトランザクション構成情報の分配を行うトランザクション処理方式では、ステップ４０８からステップ４１１の間にフロントエンドサーバ１２やＢノード１１で処理続行不可能な障害が発生した場合でも、バックエンドサーバ(４２，５２)の各々でトランザクションを構成しているサーバが判明しているので、バックエンドサーバ(４２，５２)同士で通信を行い、トランザクションの決着方法を決定することができる。このため、Ｄノード３１のフロントエンドサーバ３２のように障害部位以外に稼動しているフロントエンドサーバがあれば、バックエンドサーバ(４２，５２)へのデータ操作が可能であり、業務処理を続行することができる。   In the transaction processing method that distributes the transaction configuration information as described above, even if a failure that cannot be continued in the front-end server 12 or the B node 11 occurs between step 408 and step 411, the back-end server (42 , 52), the servers constituting the transaction are known, so that the back-end servers (42, 52) can communicate with each other to determine the transaction settlement method. For this reason, if there is a front-end server operating other than the faulty part, such as the front-end server 32 of the D node 31, data operation to the back-end servers (42, 52) is possible, and business processing is continued. can do.

以上、本発明を実施例にもとづき具体的に説明したが、本発明は前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。   Although the present invention has been specifically described above based on the embodiments, the present invention is not limited to the above embodiments, and various modifications can be made without departing from the scope of the invention.

本発明の一実施の形態の並列処理型データベース管理システムの概略構成を示すブロック図。1 is a block diagram showing a schematic configuration of a parallel processing database management system according to an embodiment of the present invention. トランザクション構成情報の分配を行わない場合の通常のトランザクション処理の流れを示すフローチャート。The flowchart which shows the flow of normal transaction processing when not distributing transaction configuration information. トランザクション構成情報の分配を行わない場合の通常の形態の並列処理型データベース管理システムの概略構成を示すブロック図。The block diagram which shows schematic structure of the parallel processing type database management system of the normal form when distribution of transaction structure information is not performed. トランザクション構成情報の分配を行う場合のトランザクション処理の流れを示すフローチャート。The flowchart which shows the flow of the transaction process in the case of distributing transaction structure information.

符号の説明Explanation of symbols

１，３０１…Ａノード(クライアント側システム)、２１，３２１…Ｃノード(クライアント側システム)、２，２２，３０２，３２２…アプリケーションプログラム、１１，３１１…Ｂノード(フロントエンドサーバ側)、３１，３３１…Ｄノード(フロントエンドサーバ側)、１２，３２，３１２，３３２…フロントエンドサーバ、４１，３４１…Ｅノード(バックエンドサーバ側)、５１，３５１…Ｆノード(バックエンドサーバ側)、４２，５２，３４２，３５２…バックエンドサーバ、４３，５３，３４３，３５３…データベース、４４，５４，３１３，３３３，３４４，３５４…ログ情報管理処理部、４５，５５，３１４，３３４，３４５，３５５…ログファイル。
1, 301 ... A node (client side system), 21, 321 ... C node (client side system), 2, 22, 302, 322 ... application program, 11, 311 ... B node (front end server side), 31, 331 ... D node (front end server side), 12, 32, 312, 332 ... front end server, 41, 341 ... E node (back end server side), 51, 351 ... F node (back end server side), 42 , 52, 342, 352 ... back-end server, 43, 53, 343, 353 ... database, 44, 54, 313, 333, 344, 354 ... log information management processing unit, 45, 55, 314, 334, 345, 355 …logfile.

Claims (3)

ネットワーク上に分散配置されたサーバが、データ操作の要求に対応する通信を相互に行って、各々が並列に操作を行うトランザクション処理において、サーバ間での同期を必要とするトランザクションコミット処理方法としての二相コミット処理を行う際に、コミット保証指示と共にトランザクション構成情報を分配する手段を備え、かつコミット処理における履歴情報と共に分配されたトランザクション構成情報をログ情報としてログファイルに取得する手段を備えた分散トランザクション制御システム。   As a transaction commit processing method that requires synchronization between servers in a transaction processing in which servers distributed in the network perform communication corresponding to data operation requests and perform operations in parallel with each other A distribution that includes means for distributing transaction configuration information together with commit guarantee instructions when performing two-phase commit processing, and means for acquiring transaction configuration information distributed together with history information in commit processing as log information in a log file Transaction control system. ネットワーク上に分散配置されたサーバが、データ操作の要求に対応する通信を相互に行って、各々が並列に操作を行うトランザクション処理において、コミット保証指示と共にトランザクション構成情報を分配することを特徴とし、かつコミット処理における履歴情報と共に分配されたトランザクション構成情報をログ情報としてログファイルに取得することを特徴とする、サーバ間での同期を必要とするトランザクションコミット処理方法としての二相コミット処理方法。   Servers distributed on the network perform communication corresponding to data operation requests to each other, and in transaction processing in which each performs operations in parallel, the transaction configuration information is distributed together with a commit guarantee instruction, A two-phase commit processing method as a transaction commit processing method that requires synchronization between servers, wherein transaction configuration information distributed together with history information in commit processing is acquired in a log file as log information. ネットワーク上に分散配置されたサーバが、データ操作の要求に対応する通信を相互に行って、各々が並列に操作を行うトランザクション処理において、部分障害発生時に分配されたトランザクション構成情報をもとに、障害部位以外でトランザクションを決着する手段を備えた分散トランザクション制御システム。
Based on the transaction configuration information distributed at the time of the partial failure in the transaction processing in which the servers distributed in the network perform communication corresponding to the data operation request and perform operations in parallel with each other, A distributed transaction control system comprising means for ending a transaction at a location other than the fault site.
JP2006121534A 2006-04-26 2006-04-26 Distributed transaction control system and its method Pending JP2007293650A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006121534A JP2007293650A (en) 2006-04-26 2006-04-26 Distributed transaction control system and its method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006121534A JP2007293650A (en) 2006-04-26 2006-04-26 Distributed transaction control system and its method

Publications (1)

Publication Number Publication Date
JP2007293650A true JP2007293650A (en) 2007-11-08

Family

ID=38764222

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006121534A Pending JP2007293650A (en) 2006-04-26 2006-04-26 Distributed transaction control system and its method

Country Status (1)

Country Link
JP (1) JP2007293650A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103885854A (en) * 2012-12-19 2014-06-25 华为技术有限公司 Data backup method, data backup device and data backup system
US9667475B2 (en) 2014-02-28 2017-05-30 Red Hat, Inc. Systems and methods for communicating information of participants registered with a sub-coordinator during distributed transaction processing

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103885854A (en) * 2012-12-19 2014-06-25 华为技术有限公司 Data backup method, data backup device and data backup system
US9667475B2 (en) 2014-02-28 2017-05-30 Red Hat, Inc. Systems and methods for communicating information of participants registered with a sub-coordinator during distributed transaction processing

Similar Documents

Publication Publication Date Title
JP5075736B2 (en) System failure recovery method and system for virtual server
KR101835458B1 (en) Method, system and computer-readable storage medium for restarting data processing systems
US8001075B2 (en) Log file amnesia detection
JP5467625B2 (en) Production-substitution system including a production system that processes transactions and a substitution system that is a backup system of the production system
US7899897B2 (en) System and program for dual agent processes and dual active server processes
US20110184915A1 (en) Cluster restore and rebuild
JP6639245B2 (en) Server system, method and program for controlling server system.
WO2011158387A1 (en) Data processing failure recovery method, system and program
JP2010244486A (en) System and method for processing data, and computer
CN110825562B (en) Data backup method, device, system and storage medium
US20120310885A1 (en) Auto-Correction in Database Replication
US8682842B2 (en) System and method for logging operations
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
US8725708B2 (en) Resolving a unit of work
JP2008033778A (en) Computer system, database restoration method, and database restoration program
JP2007293650A (en) Distributed transaction control system and its method
CN112363873A (en) Distributed consistent backup and recovery system and backup method thereof
US10102084B1 (en) Decoupled maintenance and repository synchronization error detection
US20080178182A1 (en) Work state returning apparatus, work state returning method, and computer product
US20220129446A1 (en) Distributed Ledger Management Method, Distributed Ledger System, And Node
JP2009098715A (en) Redundant system device, job execution method in redundant system device, and execution program
JP6093320B2 (en) Distributed processing system
JP2012230721A (en) System failure recovery method for virtual server and system for the same
JP6237050B2 (en) Database system, database update method, and database update program
CN108763247B (en) Method and device for processing user request in data migration process