JP2015170056A - トランザクション処理装置、トランザクション処理プログラム及び分散処理システム - Google Patents

Abstract

【課題】分散トランザクション処理におけるデータの整合性を簡便に保証する。【解決手段】トランザクション処理装置は、処理の対象となる対象データを保持する保持装置と、対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の第１の処理装置として動作する処理装置である。処理装置は、要求部、送信部、取得部を備える。要求部は、保持装置に、対象データに対する第１の更新処理を要求する。送信部は、第１の更新処理の終了後に、第２の処理装置に、第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を送信する。取得部は、対象データに対して行われている処理の要求元の処理装置の情報を、保持装置から取得する。第２の更新処理の要求後に、第１の処理装置により要求された処理が対象データに対して行われていることを示す情報を、取得部が取得した場合、要求部は、対象データを第１の更新処理の前の状態に戻す要求を、保持装置に出す。【選択図】図１

Description

この発明は、トランザクション処理に関する。

データベースを使用する処理で、分散トランザクションが使用されることがある。分散トランザクション処理は、１つのトランザクション中に、複数のサーバにより、データベースが参照又は更新される不可分な一連の情報処理である。不可分な一連の情報処理の例として、銀行の口座Ａから口座Ｂに金銭を振り込む場合が挙げられる。

ここで、口座のデータを管理するシステムは、例えば、銀行の口座のデータを保持するデータベースを備えるＤＢサーバと、データベースの更新処理をする複数のサーバを備えるものとする。口座Ａから口座Ｂに金銭を振り込む分散トランザクション処理では、口座Ａのデータから取引金額分を減算する減算要求をＤＢサーバに出すサーバと、口座Ｂのデータに取引金額分を加算する加算要求をＤＢサーバに出すサーバとが異なる。減算要求を出すサーバは、まず、ＤＢサーバに、口座Ａのデータから取引金額分を減算させる減算要求を出す。ＤＢサーバは、要求に応じて、口座Ａのデータから取引金額分を減算させる処理を実行する。減算要求を出すサーバは、データベースに対する減算処理をコミット（確定処理）する。減算要求を出すサーバからのコミットにより、更新されたデータは、永続化される。次に、加算要求を出すサーバは、ＤＢサーバに、口座Ｂのデータに取引金額分を加算させる加算要求を出す。ＤＢサーバは、要求に応じて、口座Ｂのデータに取引金額分を加算させる処理を実行する。加算要求を出すサーバは、データベースへの加算処理をコミットする。このように、加算処理及び減算処理が正常に終了した振込み処理では、口座間のデータの整合性が保証される。

銀行の口座に関する処理では、処理が失敗した場合に誤って２重に引き落としなどを発生させることを防ぐため、エラーを検出したサーバは、データベースの内容を処理前の状態に戻す（ロールバック）ことが多い。しかし、支払い元の口座中の金銭の減算と、支払い先の口座への加算が異なるサーバによって行われることにより、整合がとれなくなることがある。口座Ａへの減算処理がコミットされ、口座Ｂへの加算処理が失敗した場合、ＤＢサーバは、処理に失敗した口座Ｂのデータをロールバックする。すると、口座Ｂへの加算処理がロールバックされたにも関わらず、口座Ａへの減算処理がロールバックされないという事態が起こりうる。このような不整合を防止するため、加算処理と減算処理とをデータベースに行い、どちらかの処理が失敗した場合に、両方の処理をロールバックする２フェーズコミットの技術が知られている。

データの整合性を保つトランザクション処理について、トランザクションをグループに分割し、各グループをセットとして処理することで、ＡＣＩＤ処理結果を保証する技術が知られている（例えば、特許文献１を参照）。

トランザクション処理に関する技術として、同期点処理の間に個別に動作するメンバーが互いに通信する処理を減らす技術が知られている（例えば、特許文献２を参照）。

トランザクション処理に関する技術として、複数のエージェントから使用可能か不可能かの信号を受信し、コーディネータによるコミット又はバックアウトの判断をすることで、トランザクション処理を同期する技術が知られている（例えば、特許文献３を参照）。

特許公開平１０−０６９４１８号公報 特許公開２００１−３０６３８１号公報 特許公表平１０−５１０６５１号公報

１つのトランザクション処理に含まれる加算処理又は減算処理のうち、どちらかの処理が失敗した場合に、両方の処理がロールバックされなければ、データの整合性を保証できない。分散トランザクションを行うときに整合性を担保するためには、システム中のサーバを、２フェーズコミットに対応したサーバに置き換えることになる。しかし、こうしたサーバは２フェーズコミットに対応していないサーバに比べて非常に高価であったり、置き換えに煩雑な作業を要したりすることがある。例えば、作業中に口座のデータを保持するデータベースが更新されると不具合が発生する可能性が高いため、データベースを使用できないようにすることになる。すると、２フェーズコミットに対応したシステムの追加が終了するまで、システム全体が使用できなくなる。また、作業中に行われた口座間の取引のデータなどを、データベースに反映させる作業も起こりうる。このため、全てのサーバを２フェーズコミットに対応したサーバに置き換えることは困難である。また、口座に限らず、分散トランザクションを、２フェーズコミットに対応していないサーバで行う場合には同様の問題が発生しうる。

１つの側面において、本発明の目的は、簡便に分散トランザクションでのデータの整合性を保証することである。

トランザクション処理装置は、処理の対象となる対象データを保持する保持装置と、対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の第１の処理装置として動作する処理装置である。処理装置は、要求部、送信部、取得部を備える。要求部は、保持装置に、対象データに対する第１の更新処理を要求する。送信部は、第１の更新処理の終了後に、第２の処理装置に、第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を送信する。取得部は、対象データに対して行われている処理の要求元の処理装置の情報を、保持装置から取得する。第２の更新処理の要求後に、第１の処理装置により要求された処理が対象データに対して行われていることを示す情報を、取得部が取得した場合、要求部は、対象データを第１の更新処理の前の状態に戻す要求を、保持装置に出す。

分散トランザクション処理におけるデータの整合性を簡便に保証することである。

本実施形態に係る分散トランザクション処理の例を説明するシステムの図である。 サーバ及びＤＢサーバのハードウェア構成の例を示す。 障害がない場合の分散トランザクション処理の例を説明するシーケンス図である。 ハンドシェークが失敗した場合にシステムで行われる処理の例（その１）を説明するシーケンス図である。 ハンドシェークが失敗した場合にシステムで行われる処理の例（その２）を説明するシーケンス図である。 トランザクション処理が失敗したことを示す応答信号が送信された場合の例を説明するシーケンス図である。 応答信号が遅延した場合のトランザクション処理の例（その１）を説明するシーケンス図である。 応答信号が遅延した場合のトランザクション処理の例（その２）を説明するシーケンス図である。 本実施形態に係るサーバＡ側のトランザクション処理の例を説明するフローチャートである。 本実施形態に係るサーバＡ側のトランザクション処理の例を説明するフローチャートである。 本実施形態に係るサーバＡ側のトランザクション処理の例を説明するフローチャートである。 本実施形態に係るサーバＡ側のトランザクション処理の例を説明するフローチャートである。 本実施形態に係るサーバＢ側のトランザクション処理の例を説明するフローチャートである。 本実施形態に係るサーバＢ側のトランザクション処理の例を説明するフローチャートである。 ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その１）を説明するシーケンス図である。 ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その２）を説明するシーケンス図である。 ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その３）を説明するシーケンス図である。 ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その４）を説明するシーケンス図である。 ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その５）を説明するシーケンス図である。

以下、本実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態に係る分散トランザクション処理の例を説明するシステム構成図である。図１を参照しながら、分散トランザクション処理が口座Ａから口座Ｂに金銭を振り込む処理である場合の例について説明する。口座のデータを管理するシステム１００は、例えば、銀行の口座のデータを保持するデータベース１２１を備えるＤＢサーバ１２０と、データベース１２１の更新処理をする複数のサーバ１１０（１１０ａ、１１０ｂ）を備える。サーバ１１０とＤＢサーバ１２０とは、ネットワークで接続されている。ＤＢサーバ１２０は、全サーバ１１０が参照可能なデータを記憶する記憶領域を保持する。ＤＢサーバ１２０及びサーバ１１０は、サーバの数を限定するものではない。

サーバ１１０は、制御部１１１、要求部１１２、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）送信部１１３、ＲＰＣ受信部１１４、処理部１１５、記憶部１１６を有する。制御部１１１は、データベース１２１のデータを更新する際に、他のプロセスとの競合を避けるために用いる同期プリミティブを制御する。また、制御部１１１に含まれる取得部１１７は、制御情報１２２の情報を取得する。要求部１１２は、ＤＢサーバ１２０に、データベース１２１のデータの更新要求を出力する。

ＲＰＣ送信部１１３とＲＰＣ受信部１１４は、サーバ１１１ａとサーバ１１１ｂ間で整合性を取るために実施されるサーバ間での呼び出し処理に用いられるメッセージ（ＲＰＣ）の送受信を行う。一例として、ＲＰＣは、サーバ１１１ｂで実行される処理を、サーバ１１１ａ側からサーバ１１１ｂに要求する要求信号である。処理部１１５は、ＲＰＣより要求された処理を実行する。記憶部１１６は、制御部１１１、要求部１１２、ＲＰＣ送信部１１３、ＲＰＣ受信部１１４、処理部１１５で使用するデータを記憶する。

次に、ＤＢサーバ１２０は、記憶部１２１と、処理部１２４を備える。処理部１２４は、サーバ１１０からの要求に応じた処理を実行する。記憶部１２１は、制御情報１２２とデータベース１２３を有する。制御情報１２２は、制御部１１１から送信されてきた同期プリミティブにより更新される制御情報であり、各サーバが、更新中のデータの状況をチェックするために用いられる。データベース１２３は、例えば、口座の残金などの情報を保持する。制御情報１２２は、各サーバ１１１から共通でアクセス可能な記憶領域に記憶されている。

口座Ａから口座Ｂに金銭を振り込む分散トランザクション処理は、口座Ａのデータから取引金額分を減算する減算要求と、口座Ｂのデータに取引金額分を加算する加算要求を、ＤＢサーバ１２０に通知する不可分の処理である。

以下の（Ａ１）〜（Ａ１４）に、本実施形態に係る障害がない場合の分散トランザクション処理を順に説明する。口座Ａの減算処理と口座Ｂの加算処理の一連の不可分な処理では、まず、サーバ１１０ａ側から、分散トランザクション処理を開始するプログラムが起動される。

（Ａ１）サーバ１１０ａの制御部１１１ａは、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が開始されたことをチェックするために用いる情報であるチェックレコードをＤＢサーバ１２０に書き込む信号を、ＤＢサーバ１２０に通知する。チェックレコードを書き込む信号は、プリミティブで実現される。チェックレコードを書き込む信号のプリミティブには、一例として、putIfAbsent命令が用いられる。putIfAbsent命令は、トランザクション処理が完了するまで、他のプロセスからはその途中データを観測できないようにする性質を持つ命令である。以降、putIfAbsent命令を用いたプリミティブを、プリミティブ（putIfAbsent）と記載する。

（Ａ２）ＤＢサーバ１２０の処理部１２４は、記憶部１２１に、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報を記憶させる。制御情報には、サーバ１１０ａからの要求処理であることを示す情報が含まれてもよい。

（Ａ３）サーバ１１０ａの要求部１１２ａは、ＤＢサーバ１２０に、口座Ａのデータから取引金額分を減算させる減算要求を出す。

（Ａ４）ＤＢサーバ１２０の処理部１２３は、要求に応じて、口座Ａのデータから取引金額分を減算させる処理を実行する。この時点で、サーバ１１０ａは、口座Ａのデータの更新をコミットしない。

（Ａ５）口座Ａの減算処理と口座Ｂの加算処理は、一連の不可分な処理である。そのため、サーバ１１０ａのＲＰＣ送信部１１３ａは、口座Ａのデータをコミットする前に、口座Ｂのデータ更新をするサーバ１１０ｂにＲＰＣ信号を送信する。ＲＰＣ信号は、口座Ａからの減算分を口座Ｂに加算する処理を開始する要求である。サーバ１１０ｂのＲＰＣ受信部１１３ｂは、ＲＰＣ信号を受信する。

（Ａ６）サーバ１１０ｂは、トランザクション処理を開始する。サーバ１１０ｂの制御部１１１ｂは、サーバ１１０ｂがＲＰＣ処理を開始したことを示す信号をＤＢサーバ１２０に通知する。ＲＰＣ処理を開始したことを示す信号は、例えば、プリミティブで実現される。ＲＰＣ処理を開始したことを示す信号のプリミティブには、一例としてremove命令が用いられる。remove命令は、プリミティブ（putIfAbsent）による、他のプロセスからは途中データが観測できない状態を解除する命令である。以降、remove命令を用いたプリミティブを、プリミティブ（remove）と記載する。

（Ａ７）ＤＢサーバ１２０の処理部１２４は、記憶部１２１から、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を削除する。

（Ａ８）サーバ１１０ｂの制御部１１１ｂは、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が失敗したかのチェックをするために用いる情報であるキャンセルレコードをＤＢサーバ１２０に書き込む信号を、ＤＢサーバ１２０に通知する。キャンセルレコードを書き込む信号は、プリミティブで実現される。キャンセルレコードを書き込む信号のプリミティブには、一例として、putIfAbsent命令が用いられる。ＤＢサーバ１２０の処理部１２４は、記憶部１２１に、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が失敗したかのチェックをするために用いる制御情報（キャンセルレコード）を記憶させる。

（Ａ９）サーバ１１０ｂのＲＰＣ送信部１１３ｂは、ＲＰＣ信号を正常に受信したことを示すＲＰＣ＿ＡＣＫ信号を、サーバ１１０ａに送信する。サーバ１１０ａのＲＰＣ受信部１１４ａは、ＲＰＣ＿ＡＣＫ信号を受信する。

（Ａ１０）サーバ１１０ｂの要求部１１２ｂは、ＤＢサーバ１２０に、口座Ｂのデータに取引金額分を加算させる加算要求を出す。

（Ａ１１）ＤＢサーバ１２０の処理部１２３は、要求に応じて、口座Ｂのデータに取引金額分を加算させる処理を実行する。

（Ａ１２）サーバ１１０ｂの処理部１１５ｂは、口座Ｂのデータの更新をコミットする。

（Ａ１３）サーバ１１０ｂのＲＰＣ送信部１１３ｂは、ＲＰＣ信号から呼び出された処理が正常に終了したことを示す情報を含む応答信号をサーバ１１０ａに送信する。応答信号は、（Ａ５）で受信したＲＰＣ信号に対する処理の成否応答である。サーバ１１０ａのＲＰＣ受信部１１４ａは、応答信号を受信する。

（Ａ１４）サーバ１１０ａの処理部１１５ａは、口座Ａのデータの更新をコミットする。

（Ａ１）〜（Ａ１４）の処理により、ＲＰＣの呼び出し元のサーバ１１０ａは、ＲＰＣの呼び出し先のサーバ１１０ｂ側の処理がコミットされた後から、自身の処理をコミットする。これにより、呼び出し元の口座Ａのデータと呼び出し先の口座Ｂのデータは、整合性を取ることができる。なお、（Ａ１４）で一連のトランザクション処理が終了すると、（Ａ８）で記憶部に記憶されたキャンセルレコードは、削除される。

以下に、サーバ１１０ｂ側の処理について、障害が発生した場合の分散トランザクション処理を順に説明する。なお、（Ａ１）〜（Ａ７）の処理が、（Ｂ１）の処理の前に行われる。

（Ｂ１）（Ａ８）又は（Ａ９）で処理が失敗した場合、サーバ１１０ｂのＲＰＣ送信部１１３ｂは、ＲＰＣ信号を正常に受信したことを示すＲＰＣ＿ＡＣＫ信号を、サーバ１１０ａに送信しない。サーバ１１０ｂの要求部１１２ｂは、口座Ｂに関するトランザクション処理を、（Ａ５）のＲＰＣ信号を受信した時点までロールバックする要求をＤＢサーバ１２０に出す。ＤＢサーバ１２０は、ロールバックの要求を受けると、（Ａ７）で削除されたサーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を再生成する。ＤＢサーバ１２０は、（Ａ５）の時点の制御情報及び口座Ｂのデータを記憶している。

（Ｂ２）ＲＰＣ信号から呼び出された処理が失敗したことを示す情報を含む応答信号を、サーバ１１０ａのＲＰＣ受信部１１４ａが受信した場合、サーバ１１０ａの処理部１１５ａは、サーバ１１０ｂ側の処理が失敗し、サーバ１１０ｂから要求された処理が、ＤＢサーバ１２０でロールバックされたと判定する。

（Ｂ３）所定の時間が経過しても、ＲＰＣ＿ＡＣＫ信号や応答信号を、サーバ１１０ａのＲＰＣ受信部１１４ａが受信できない場合、サーバ１１０ａの取得部１１７ａは、制御情報１２２から、制御情報を取得する。サーバ１１０ａの制御部１１１ａは、サーバ１１０ｂ側のＲＰＣ処理が行われているにも関わらず、チェックレコードを取得した場合、サーバ１１０ｂ側の処理が失敗し、サーバ１１０ｂから要求された処理が、ＤＢサーバ１２０でロールバックされたと判定する。再生成されたチェックレコードは、サーバ１１０ｂから要求された処理が、ＤＢサーバ１２０でロールバックされたことを示す情報である。

（Ｂ４）サーバ１１０ｂから要求された処理がＤＢサーバ１２０でロールバックされた場合、サーバ１１０ａの要求部１１２ａは、口座Ａに関するトランザクション処理を、（Ａ１）の時点までロールバックする要求をＤＢサーバ１２０に出す。ＤＢサーバ１２０は、（Ａ１）の時点まで口座Ａのデータをロールバックする。

（Ｂ２）の処理により、サーバ１１０ａは、ＤＢサーバ１２０の制御情報に基づいて、サーバ１１０ｂ側から要求された処理がロールバックしたことを検知することができる。そのため、サーバ１１０ａ側も、自身が要求したトランザクション処理をロールバックさせる。このようにしてトランザクション処理は、口座Ａと口座Ｂのデータの整合性が保たれる。また、２フェーズコミットのように、加算及び減算処理を管理する管理サーバを備えなくとも、口座Ａと口座Ｂのデータの整合性が保たれる。

以下に、サーバ１１０ｂ側の処理について、障害が発生した場合の分散トランザクション処理の別の例を順に説明する。なお、（Ａ１）〜（Ａ７）の処理が、（Ｃ１）の処理の前に行われる。（Ｃ１）の処理の後には、（Ｂ２）〜（Ｂ４）の処理が実行される。

（Ｃ１）（Ａ１０）〜（Ａ１１）で処理が失敗した場合、サーバ１１０ｂのＲＰＣ送信部１１３ｂは、ＲＰＣ信号から呼び出された処理が正常に終了したことを示す情報を含む応答信号をサーバ１１０ａ側に送信しない。サーバ１１０ｂの要求部１１２ｂは、口座Ｂに関するトランザクション処理を、（Ａ５）のＲＰＣ信号を受信した時点までロールバックする要求をＤＢサーバ１２０に出す。ＤＢサーバ１２０は、（Ａ５）の時点の制御情報及び口座Ｂのデータを記憶している。そのため、ＤＢサーバ１２０は、口座Ｂのデータを（Ａ５）の時点まで戻す。また、ＤＢサーバ１２０は、（Ａ７）で削除されたチェックレコードを再生成する。サーバ１１０ｂのＲＰＣ送信部１１３ｂが、ＲＰＣ信号から呼び出された処理が失敗したことを示す情報を含む応答信号をサーバ１１０ａに送信してもよい。

ＲＰＣの呼び出し元のサーバ１１０ａは、ＤＢサーバ１２０が処理対象として、サーバ１１０ａからの要求処理であることを示す情報を保持している場合に、ＲＰＣの呼び出し先のサーバから要求された処理がＤＢサーバ１２０でロールバックしていると判定する。その後、呼び出し元のサーバ１１０ａは、自身もロールバックをする要求をＤＢサーバ１２０に出す。ＲＰＣの呼び出し元のサーバ１１０ａは、ＲＰＣの呼び出し先のサーバ１１０ｂが処理をコミットしている場合に、自身も処理をコミットする。このため、ＲＰＣの呼び出し先でロールバックが行われた場合、呼び出し元のサーバもロールバックを行うことができる。トランザクション処理において、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。また、２フェーズコミットのように、呼び出し元の処理と呼び出し先の処理を管理する管理サーバを備えなくとも、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。

図２は、サーバ及びＤＢサーバのハードウェア構成の例を示す。サーバ１１０及びＤＢサーバ１２０は、プロセッサ１１、メモリ１２、バス１５、外部記憶装置１６、ネットワーク接続装置１９を備える。さらにオプションとして、サーバ１１０及びＤＢサーバ１２０は、入力装置１３、出力装置１４、媒体駆動装置１７を備えてもよい。サーバ１１０及びＤＢサーバ１２０は、例えば、コンピュータなどで実現されることがある。

プロセッサ１１は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）を含む任意の処理回路とすることができる。プロセッサ１１は、サーバ１１０内の制御部１１１、要求部１１２、ＲＰＣ送信部１１３、ＲＰＣ受信部１１４、処理部１１５として動作する。プロセッサ１１は、ＤＢサーバ１２０内の処理部１２４として動作する。なお、プロセッサ１１は、例えば、外部記憶装置１６に記憶されたプログラムを実行することができる。メモリ１２は、サーバ１１０内の記憶部１１６として動作する。メモリ１２は、ＤＢサーバ１２０内の記憶部１２４として動作し、データベース１２３、制御情報１２２を保持する。さらに、メモリ１２は、プロセッサ１１の動作により得られたデータや、プロセッサ１１の処理に用いられるデータも、適宜、記憶する。ネットワーク接続装置１９は、他の装置との通信に使用される。

入力装置１３は、例えば、ボタン、キーボード、マウス等として実現され、出力装置１４は、ディスプレイなどとして実現される。バス１５は、プロセッサ１１、メモリ１２、入力装置１３、出力装置１４、外部記憶装置１６、媒体駆動装置１７、ネットワーク接続装置１９の間を相互にデータの受け渡しが行えるように接続する。外部記憶装置１６は、プログラムやデータなどを格納し、格納している情報を、適宜、プロセッサ１１などに提供する。媒体駆動装置１７は、メモリ１２や外部記憶装置１６のデータを可搬記憶媒体１８に出力することができ、また、可搬記憶媒体１８からプログラムやデータ等を読み出すことができる。ここで、可搬記憶媒体１８は、フロッピイディスク、Ｍａｇｎｅｔ−Ｏｐｔｉｃａｌ（ＭＯ）ディスク、Ｃｏｍｐａｃｔ Ｄｓｉｃ Ｒｅｃｏｒｄａｂｅ（ＣＤ−Ｒ）やＤｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ（ＤＶＤ−Ｒ）を含む、持ち運びが可能な任意の記憶媒体とすることができる。

図３は、障害がない場合の分散トランザクション処理の例を説明するシーケンス図である。サーバ１１０ａは、ＤＢサーバ１２０に、口座Ａのデータを対象としたプリミティブ（putIfAbsent）を通知する。ＤＢサーバ１２０は、記憶部１２１に、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を記憶する（ステップＳ１０１）。サーバ１１０ａは、口座Ａのデータを更新するトランザクション処理を開始する。トランザクション処理においてロールバックが実行されると、「begin」で示す時点（ステップＳ１０２）以降の処理は、全て無効とされる。なお、ＤＢサーバ１２０は、「begin」で示す時点の口座Ａのデータ及び制御情報を記憶している。サーバ１１０ａは、ＤＢサーバ１２０に口座Ａのデータから取引金額分を減算させる減算要求を出す。ＤＢサーバ１２０は、要求に応じて、口座Ａのデータから取引金額分を減算させる処理を実行する（ステップＳ１０３）。サーバ１１０ａは、ＲＰＣ信号をサーバ１１０ｂに送信する（ステップＳ１０４）。

ＲＰＣ信号を受信すると、サーバ１１０ｂは、トランザクション処理を開始する。トランザクション処理においてサーバ１１０ｂからロールバックが要求されると、「begin」で示す時点（ステップＳ１０５）以降の処理は、全て無効とされる。サーバ１１０ｂは、プリミティブ（remove）をＤＢサーバ１２０に通知する。ＤＢサーバ１２０は、制御情報１２２から、チェックレコードを削除する（ステップＳ１０６）。サーバ１１０ｂは、ＤＢサーバ１２０に、口座Ｂのデータを対象としたプリミティブ（putIfAbsent）を通知する。ＤＢサーバ１２０は、記憶部１２１に、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が失敗したかのチェックをするために用いる制御情報（キャンセルレコード）を記憶する（ステップＳ１０７）。サーバ１１０ｂは、サーバ１１０ａにＲＰＣ＿ＡＣＫ信号を送信する（ステップＳ１０８）。サーバ１１０ｂは、ＤＢサーバ１２０に口座Ｂのデータに取引金額分を加算させる加算要求を出す。ＤＢサーバ１２０は、要求に応じて、口座Ｂのデータに取引金額分を加算させる処理を実行する（ステップＳ１０９）。サーバ１１０ｂは、口座Ｂの更新後のデータをコミットする（ステップＳ１１０）。サーバ１１０ｂは、ＲＰＣ信号から呼び出された処理が正常に終了したことを示す情報を含む応答信号をサーバ１１０ａに送信する（ステップＳ１１１）。サーバ１１０ａは、口座Ａの更新後のデータをコミットする（ステップＳ１１２）。Ｓ１０１〜Ｓ１１２で、口座Ａから口座Ｂに金銭を振り込む分散トランザクション処理が完了する。分散トランザクション処理の終了に伴い、Ｓ１０７で記憶部１２１に記憶されたキャンセルレコードは削除される。

図４は、ハンドシェークが失敗した場合にシステムで行われる処理の例（その１）を説明するシーケンス図である。ハンドシェークは、サーバ１１０ａとサーバ１１０ｂ間のＲＰＣ信号が正常に送受信されたかの確認処理である。例えば、図３のＳ１０４のＲＰＣ信号をサーバ１１０ｂが受信し、ＲＰＣ信号が正常に受信されたかを示すＳ１０８のＲＰＣ＿ＡＣＫ信号をサーバ１１０ａが受信した場合に、ハンドシェークが成功している。図４のＳ２０１〜Ｓ２０６は、図３のＳ１０１〜Ｓ１０６と同じ処理であるため、説明を省略する。

サーバ１１０ａは、ＲＰＣ＿ＡＣＫ信号を受信できないため、Ｓ２０４のＲＰＣ信号送信後、所定の時間が経過すると、制御情報を確認し、サーバ１１０ｂの処理状況を確認する。サーバ１１０ａは、ＤＢサーバ１２０から、チェックレコード及びキャンセルレコードを取得する（ステップＳ２０７）。サーバ１１０ｂは、ＤＢサーバ１２０に、口座Ｂのデータを対象としたプリミティブ（putIfAbsent）を通知する。ＤＢサーバ１２０は、記憶部１２１に、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が失敗したかのチェックをするために用いる制御情報（キャンセルレコード）を記憶する（ステップＳ２０８）。サーバ１１０ｂは、Ｓ２０８後の処理で失敗したため、Ｓ２０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す要求をＤＢサーバ１２０に出す（ステップＳ２０９）。Ｓ２０９の処理において、サーバ１１０ｂは、Ｓ２０８で記憶部１２１に記憶させた情報を無効とする要求をＤＢサーバ１２０に出す。併せて、サーバ１１０ｂは、Ｓ２０６で削除したサーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を再生成する要求をＤＢサーバ１２０に出す。ＤＢサーバ１２０は、要求されたロールバック処理を行う。

サーバ１１０ａは、Ｓ２０７の制御情報の取得処理をＳ２０７から所定の時間、繰り返す。その結果、サーバ１１０ａは、制御情報１２２に、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）が再生成されていることを検知する。サーバ１１０ａは、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。ＤＢサーバ１２０は、制御情報１２２から、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を削除する。サーバ１１０ａは、Ｓ２０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ２１１）。Ｓ２１１のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ２０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ２０３の処理前の状態とする。また、Ｓ２０２の時点で、ＤＢサーバ１２０は、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を記憶していたため、Ｓ２１１のロールバックで、ＤＢサーバ１２０は、チェックレコードを再生成する。

Ｓ２０７の取得処理を繰り返すことで、サーバ１１０ａは、チェックレコードが再生成されていることを検知することができる。サーバ１１０ａは、チェックレコードが再生成されていることにより、サーバ１１０ｂがロールバックしたことを検知する。そのため、サーバ１１０ｂ側のロールバック処理にあわせて、サーバ１１０ａの口座Ａへのデータ更新処理もロールバックする。これにより、口座Ａと口座Ｂとは整合性が保たれる。

図５は、ハンドシェークが失敗した場合にシステムで行われる処理の例（その２）を説明するシーケンス図である。図５の例では、ロールバックの際に、ロールバックを行う原因となったエラーの情報を、ロールバックの際に削除しないように変形されたシステムの動作例を説明する。なお、図５のＳ３０１〜Ｓ３０６は、図３のＳ１０１〜Ｓ１０６と同じ処理であるため、説明を省略する。

サーバ１１０ａは、Ｓ３０４のＲＰＣ信号送信処理以降、定期的に、ＤＢサーバ１２０から、口座Ａや口座Ｂの状態を示す制御情報を取得する（ステップＳ３０７）。サーバ１１０ｂからのＤＢサーバ１２０へのプリミティブ（putIfAbsent）処理が失敗する。ＤＢサーバ１２０は、記憶部１２１に、キャンセルレコードの生成に失敗したことを示す制御情報を記憶する（ステップＳ３０８）。サーバ１１０ｂは、Ｓ３０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ３０９）。Ｓ３０９のロールバックで、ＤＢサーバ１２０は、Ｓ３０６のチェックレコードの削除処理を無効とし、チェックレコードを再生成する。Ｓ３０９のロールバックで、ＤＢサーバ１２０は、Ｓ３０８のキャンセルレコードの生成に失敗したことを示す制御情報を削除しない。これにより、システムの管理者は、Ｓ３０８の処理でキャンセルレコードの生成に失敗したことを知ることができる。

Ｓ３０７の制御情報の取得処理は、Ｓ３０７の処理以降、所定の時間、処理を繰り返す。その結果、サーバ１１０ａは、制御情報１２２に、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）があることを検知する。サーバ１１０ａは、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。ＤＢサーバ１２０は、制御情報１２２から、チェックレコードを削除する（ステップＳ３１０）。サーバ１１０ａは、Ｓ３０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ３１１）。Ｓ３１１のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ３０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ３０３の処理前の状態とする。次に、Ｓ３１１のロールバックでＤＢサーバ１２０は、Ｓ３０２の時点で記憶されているチェックレコードを再生成しない。キャンセルレコードの生成に失敗したことを示す制御情報が記憶部１２１に記憶されている場合、ＤＢサーバ１２０は、チェックレコードを再生成させないと判定する。

Ｓ３０７の取得処理を繰り返すことで、サーバ１１０ａは、チェックレコードが再生成されていることを検知する。サーバ１１０ａは、チェックレコードが再生成されていることにより、サーバ１１０ｂ側の処理がロールバックしたことを検知する。サーバ１１０ｂ側のロールバックにあわせて、サーバ１１０ａの口座Ａへのデータ更新処理もロールバックする。これにより、口座Ａと口座Ｂとは整合性が保もたれる。なお、図５のトランザクション処理において、管理者は、処理終了後に制御情報を確認することで、Ｓ３０８の口座Ｂに関する制御情報の更新に失敗したことを知ることができる。

図６は、トランザクション処理が失敗したことを示す応答信号が送信された場合の例を説明するシーケンス図である。なお、図５のＳ４０１〜Ｓ４０９は、図３のＳ１０１〜Ｓ１０９と同じであるため、説明を省略する。

Ｓ４０９の処理の後にサーバ１１０ｂで障害が発生したため、サーバ１１０ｂは、Ｓ４０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ４１０）。Ｓ４１０のロールバックで、サーバ１１０ｂは、口座Ｂに関するデータをＳ４０９の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ｂからの要求に応じた処理を実行し、口座ＢのデータをＳ４０９の処理前の状態とする。Ｓ４１０の処理の際、ＤＢサーバ１２０は、Ｓ４０７で記憶部１２１に記憶させた情報を無効とする。併せて、Ｓ４１０の処理において、ＤＢサーバ１２０は、チェックレコードを再生成する。

サーバ１１０ｂは、ＲＰＣ信号から呼び出された処理が失敗したことを示す情報を含む応答信号をサーバ１１０ａに送信する（ステップＳ４１１）。サーバ１１０ａは、Ｓ４０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ４１２）。Ｓ４１２のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ４０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ４０３の処理前の状態とする。ＤＢサーバ１２０は、Ｓ４１２の時点で、チェックレコードを記憶しているため、再生成処理は行わない。サーバ１１０ａは、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。ＤＢサーバ１２０は、制御情報１２２から、チェックレコードを削除する（ステップＳ４１３）。

サーバ１１０ａは、Ｓ４１１のＲＰＣ信号から呼び出された処理が失敗したことを示す情報を含む応答信号を受信すると、制御情報の取得処理を行う。制御情報の取得処理により、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）が再生成されていることを検知し、サーバ１１０ｂがロールバックしたことを検知できる。このようにして、サーバ１１０ｂ側のロールバックにあわせて、サーバ１１０ａの口座Ａへのデータ更新処理もロールバックするため、口座Ａと口座Ｂとは、整合性が保たれる。

図７は、応答信号が遅延した場合のトランザクション処理の例（その１）を説明するシーケンス図である。図７のシーケンス図では、図５の応答信号（Ｓ４１１）が遅延した場合の例である。なお、図７のＳ５０１〜Ｓ５０９は、図３のＳ１０１〜Ｓ１０９と同じであるため、説明を省略する。

サーバ１１０ａは、Ｓ５０８のＲＰＣ＿ＡＣＫ信号の受信以降、所定の時間を超えても応答信号を受信しない場合、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。プリミティブ（remove）により、サーバ１１０ａは、チェックレコードが再生成されていることとサーバ１１０ｂ側の処理がロールバックされたかを判定できる。しかし、ＤＢサーバ１２０は、記憶部１２１にチェックレコードを記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ５１０）。Ｓ５０９の処理の後にサーバ１１０ｂで障害が発生したため、サーバ１１０ｂは、Ｓ５０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ５１１）。Ｓ５１１のロールバックで、サーバ１１０ｂは、口座ＢのデータをＳ５０９の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＢのデータをＳ５０９の処理前の状態とする。Ｓ５１１の処理において、ＤＢサーバ１２０は、Ｓ５０７で記憶部１２１に記憶させた情報を無効とする。併せて、Ｓ５１１の処理において、ＤＢサーバ１２０は、チェックレコードを再生成する。

Ｓ５１１のロールバックで、チェックレコードが再生成されたため、ＤＢサーバ１２０がＳ５１０で受信したプリミティブ（remove）の処理が実行できる。ＤＢサーバ１２０は、制御情報１２２からチェックレコードを削除し、チェックレコードの削除が成功したことをサーバ１１０ａに通知する（ステップＳ５１２）。サーバ１１０ａは、Ｓ５０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ５１３）。Ｓ５１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ５０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ５０３の処理前の状態とする。また、Ｓ５１３のロールバックで、ＤＢサーバ１２０は、チェックレコードを再生成する。その後、サーバ１１０ｂは、ＲＰＣ信号から呼び出された処理が失敗したことを示す情報を含む応答信号をサーバ１１０ａに送信する（ステップＳ５１４）。

図７のシステムにおいて、サーバ１１０ａは、Ｓ５１２のプリミティブ（remove）の処理が成功したことを受信することにより、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）が再生成されたことを検知できる。更に、チェックレコードが再生成されたことにより、サーバ１１０ｂ側からの処理がロールバックしたことを検知できる。このようにして、サーバ１１０ｂ側からの処理のロールバックにあわせて、サーバ１１０ａの口座Ａへのデータ更新処理もロールバックするため、口座Ａと口座Ｂとは、整合性が保たれる。

図８は、応答信号が遅延した場合のトランザクション処理の例（その２）を説明するシーケンス図である。図８のシーケンス図は、サーバ１１０ｂの更新データがコミットされたにも関わらず、応答信号が遅延した場合の例である。なお、図８のＳ６０１〜Ｓ６１０は、図３のＳ１０１〜Ｓ１１０と同じであるため、説明を省略する。

Ｓ６１０で、サーバ１１０ｂの口座Ｂの更新処理はコミットされている。しかし、図１のＳ１１２のＲＰＣ信号から呼び出された処理が成功したことを示す情報を含む応答信号が遅延し、所定の時間経過しても受信できない場合、サーバ１１０ａは、Ｓ６１１以降の処理を行う。サーバ１１０ａは、所定の時間を超えても応答信号を受信しない場合、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。しかし、ＤＢサーバ１２０は、記憶部１２１にチェックレコードを記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ６１１）。Ｓ６１０で、サーバ１１０ｂの口座Ｂの更新処理はコミットされたため、チェックレコードは再生成されない。そのため、所定の時間が経過しても、プリミティブ（remove）の対象となる制御情報がないため、プリミティブ（remove）処理は失敗する（ステップＳ６１２）。サーバ１１０ａは、Ｓ６０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ６１３）。Ｓ６１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ６０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ６０３の処理前の状態とする。Ｓ６１３のロールバックにおいて、ＤＢサーバ１２０は、チェックレコードを再生成しない。

その後、サーバ１１０ｂは、ＲＰＣ信号から呼び出された処理が成功したことを示す情報を含む応答信号（遅延）をサーバ１１０ａに送信する（ステップＳ６１４）。しかし、サーバ１１０ａ側の処理は既にロールバック処理をしているため、サーバ１１０ｂにデータベースの無効処理を要求する（ステップＳ６１５）。サーバ１１０ｂは、Ｓ６０９のデータベースへの更新処理を無効とする（ステップＳ６１６）。図８のシーケンス図の例は、サーバ１１０ｂ側の処理がコミットされているにも関わらず、サーバ１１０ａ側の処理がロールバックされた場合である。そのため、サーバ１１０ａは、サーバ１１０ｂ側のコミット済みの処理を無効化する。このようにして、サーバ１１０ａ側のロールバックにあわせて、サーバ１１０ｂの口座Ｂへのデータ更新処理もロールバックするため、口座Ａと口座Ｂとは、整合性が保たれる。

図９Ａ〜図９Ｄは、本実施形態に係るサーバＡ側のトランザクション処理の例を説明するフローチャートである。トランザクション処理は、口座Ａから口座Ｂへの金銭の振込み処理についての、不可分な一連の加算処理と減算処理について説明する。

図９Ａは、サーバＡ側のトランザクション処理の例を説明するフローチャートである。サーバ１１０ａの処理部１１５は、サーバ１１０ｂとの通信経路を確保する（ステップＳ１００１）。サーバ１１０ａの処理部１１５は、実行するトランザクション処理のＲＰＣに、識別番号を割り当てる（ステップＳ１００２）。サーバ１１０ａの制御部１１１ａは、サーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）の書き込み命令であるプリミティブ（putIfAbsent）をＤＢサーバ１２０に通知する（ステップＳ１００３）。サーバ１１０ａの処理部１１５は、チェックレコードの書き込み命令がＤＢサーバ１２０側で正常に処理されたかを判定する（ステップＳ１００４）。正常にされている場合、ＤＢサーバ１２０は、チェックレコードが、記憶部１２１に記憶される。サーバ１１０ａの処理部１１５は、トランザクション処理を開始（begin）する (ステップＳ１００５、ステップＳ１００４でＹＥＳ)。

図９Ｂは、図９ＡのＳ１００５後の処理の例を説明するフローチャートである。チェックレコードの書き込み命令がＤＢサーバ１２０側で正常に処理されない場合、ＤＢサーバ１２０は、チェックレコードを、記憶部１２１に記憶していない。サーバ１１０ａの処理部１１５は、トランザクション処理を終了する（ステップＳ１００６、ステップＳ１００４でＮＯ）。サーバ１１０ａの要求部１１２ａは、ＤＢサーバ１２０に、口座Ａのデータから取引金額分を減算させる減算要求を出す（ステップＳ１００７）。ＤＢサーバ１２０の処理部１２３は、要求に応じて、口座Ａのデータから取引金額分を減算させる処理を実行する。口座Ａのデータをコミットする前に、サーバ１１０ａのＲＰＣ送信部１１３ａは、口座Ｂのデータ更新をするサーバ１１０ｂにＲＰＣ信号を送信する（ステップＳ１００８）。口座Ａから口座Ｂへの振込みをする場合、口座Ａの減算処理と口座Ｂの加算処理は、一連の不可分な処理である。ＲＰＣ信号は、まだ実行されていない加算処理を開始する要求である。

サーバ１１０ａの処理部１１５は、サーバ１１０ｂがＲＰＣ信号を正常に受信したことを示すＲＰＣ＿ＡＣＫ信号を、ＲＰＣ受信部１１４ａが受信したかを判定する（ステップＳ１００９）。サーバ１１０ａの処理部１１５は、ＲＰＣ信号を送信してから所定の時間が経過したかを判定する（ステップＳ１０１０、ステップＳ１００９でＮＯ）。Ｓ１０１０で所定の時間が経過している場合、サーバ１１０ａは、処理をＳ１０２１に移行する。Ｓ１０１０で所定の時間が経過していない場合、サーバ１１０ａは、Ｓ１００９の処理を繰り返す。

サーバ１１０ａの処理部１１５は、Ｓ１００８で送信されたＲＰＣ信号により呼び出されたサーバ１１０ｂ側の処理が正常に処理されたかの結果情報を含むレスポンス信号を、ＲＰＣ受信部１１４ａが受信したかを判定する（ステップＳ１０１１、ステップＳ１００９でＹＥＳ）。サーバ１１０ａの処理部１１５は、ＲＰＣ信号を送信してから所定の時間が経過したかを判定する（ステップＳ１０１２、ステップＳ１０１１でＮＯ）。Ｓ１０１２で所定の時間が経過している場合、サーバ１１０ａは、処理をＳ１０３１に移行する。Ｓ１０１２で所定の時間が経過していない場合、サーバ１１０ａは、Ｓ１０１１の処理を繰り返す。

サーバ１１０ａの処理部１１５ａは、受信したレスポンス信号にＲＰＣ信号により呼び出されたサーバ１１０ｂ側の処理が正常に処理されたかの結果が、成功かどうかを判定する（ステップＳ１０１３、ステップＳ１０１１でＹＥＳ）。サーバ１１０ａの処理部１１５ａは、Ｓ１００７で処理された口座Ａのデータの更新をコミットする（ステップＳ１０１４、ステップＳ１０１３でＹＥＳ）。サーバ１１０ａの処理部１１５ａは、Ｓ１０１４で実行されたコミット処理が成功したかを判定する（ステップＳ１０１５）。サーバ１１０ａは、Ｓ１００５以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ１０１６、ステップＳ１０１３でＮＯ、ステップＳ１０１５でＮＯ）。サーバ１１０ａの処理部１１５ａは、トランザクション処理を終了する（ステップＳ１０１５でＹＥＳ）。

図９Ｃは、図９ＢのＳ１０１０でＹＥＳと判定された場合の処理の例を説明するフローチャートである。サーバ１１０ａの取得部１１７ａは、定期的に制御情報１２２を取得する（ステップＳ１０２１）。サーバ１１０ａの制御部１１１ａは、サーバ１１０ｂ側の処理が完了後に、キャンセルレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する（ステップＳ１０２２）。サーバ１１０ａの処理部１１５ａは、キャンセルレコードを対象としたプリミティブ（remove）の処理が実行されたかを判定する（ステップＳ１０２３）。サーバ１１０ａの処理部１１５ａは、サーバ１１０ｂ側のトランザクション処理がロールバックしていることを検知する（ステップＳ１０２４、ステップＳ１０２３でＹＥＳ）。サーバ１１０ａは、Ｓ１００５以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ１０２５）。サーバ１１０ａの処理部１１５ａは、サーバ１１０ｂ側のデータベース更新がコミットされたと判定する（ステップＳ１０２６、ステップＳ１０２３でＮＯ）。サーバ１１０ａは、Ｓ１００５以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ１０２７）。サーバ１１０ａの処理部１１５ａは、Ｓ１００８のＲＰＣ信号から呼び出されたプロシージャから更新された口座Ｂのデータの更新処理を無効化する要求を出す（ステップＳ１０２８）。

図９Ｄは、図９ＢのＳ１０１２でＹＥＳと判定された場合の処理の例を説明するフローチャートである。サーバ１１０ａの制御部１１１ａは、サーバ１１０ｂ側の処理が完了後に、キャンセルレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する（ステップＳ１０３１）。サーバ１１０ａは、Ｓ１００５以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ１０３２）。サーバ１１０ａの処理部１１５ａは、キャンセルレコードを対象としたプリミティブ（remove）の処理が実行されたかを判定する（ステップＳ１０３３）。サーバ１１０ａの処理部１１５ａは、サーバ１１０ｂ側のトランザクション処理がロールバックしていることを検知する（ステップＳ１０３４、ステップＳ１０３３でＹＥＳ）。サーバ１１０ａの処理部１１５ａは、サーバ１１０ｂ側のデータベース更新がコミットされたと判定する（ステップＳ１０３５、ステップＳ１０３３でＮＯ）。サーバ１１０ａの処理部１１５ａは、Ｓ１００８のＲＰＣ信号から呼び出されたプロシージャから更新された口座Ｂのデータの更新処理を無効化する要求を出す（ステップＳ１０３６）。サーバ１１０ａの制御部１１１ａは、サーバ１１０ｂ側の処理が完了後に、キャンセルレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する（ステップＳ１０３７、ステップＳ１３０６処理後）。

図１０Ａ〜図１０Ｂは、本実施形態に係るサーバＢ側のトランザクション処理の例を説明するフローチャートである。トランザクション処理は、口座Ａから口座Ｂへの金銭の振込み処理についての、不可分な一連の加算処理と減算処理について説明する。

サーバ１１０ｂの処理部１１５ｂは、サーバ１１０ａからの通信経路の確保要求を承認する（ステップＳ２００１）。サーバ１１０ｂのＲＰＣ受信部１１４ｂは、サーバ１１０ａから口座Ｂの更新要求を含むＲＰＣ信号を受信する（ステップＳ２００２）。サーバ１１０ｂの処理部１１５ｂは、トランザクション処理を開始（begin）する (ステップＳ２００３)。サーバ１１０ｂの制御部１１１ｂは、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する（ステップＳ２００４）。Ｓ２００４のチェックレコードは、Ｓ２００２で受信したＲＰＣ信号に含まれるＲＰＣ識別番号から判別される。サーバ１１０ｂの処理部１１５ｂは、チェックレコードを対象としたプリミティブ（remove）の処理が実行されたかを判定する（ステップＳ２００５）。サーバ１１０ｂの処理部１１５ｂは、Ｓ２００３以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ２００６、ステップＳ２００５でＮＯ）。サーバ１１０ｂの制御部１１１ｂは、サーバ１１０ａがサーバ１１０ｂ側のＲＰＣ処理が失敗したかのチェックをするために用いる制御情報（キャンセルレコード）の書き込み命令であるプリミティブ（putIfAbsent）をＤＢサーバ１２０に通知する（ステップＳ２００７）。サーバ１１０ｂの処理部１１５ｂは、キャンセルレコードの書き込み命令がＤＢサーバ１２０側で正常に処理されたかを判定する（ステップＳ２００８）。サーバ１１０ｂの処理部１１５ｂは、Ｓ２００３以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ２００９、ステップＳ２００８でＮＯ）。Ｓ２００６及びＳ２００９処理後、サーバ１１０ｂ側のトランザクション処理は終了する。

図１０Ｂは、Ｓ２００８後の処理を示すフローチャートである。サーバ１１０ｂのＲＰＣ送信部１１３ｂは、ＲＰＣ＿ＡＣＫ信号をサーバ１１０ａに送信する（ステップＳ２０１０）。サーバ１１０ｂの要求部１１２ｂは、ＤＢサーバ１２０に、口座Ｂのデータに取引金額分を加算する加算要求を出す（ステップＳ２０１１）。サーバ１１０ｂの処理部１１５ｂは、口座Ｂのデータの加算処理後のデータをコミットする（ステップＳ２０１２）。サーバ１１０ｂの処理部１１５ｂは、コミット処理が成功したかを判定する（ステップＳ２０１３）。サーバ１１０ｂの処理部１１５ｂは、Ｓ２００３以降に実行された処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ２０１４、ステップＳ２０１３でＮＯ）。サーバ１１０ｂのＲＰＣ送信部１１３ｂは、Ｓ２００２で受信したＲＰＣ信号後の処理が成功したかの情報を含む応答信号をサーバ１１０ａに送信する（ステップＳ２０１５、ステップＳ２０１３でＹＥＳ）。

ＲＰＣの呼び出し元のサーバ１１０ａは、ＤＢサーバ１２０が処理対象として、サーバ１１０ａからの要求処理であることを示す情報を保持している場合に、ＲＰＣの呼び出し先のサーバから要求された処理がＤＢサーバ１２０でロールバックしていると判定する。その後、呼び出し元のサーバ１１０ａは、自身もロールバックをする要求をＤＢサーバ１２０に出す。ＲＰＣの呼び出し元のサーバ１１０ａは、ＲＰＣの呼び出し先のサーバ１１０ｂが処理をコミットしている場合に、自身も処理をコミットする。このため、ＲＰＣの呼び出し先でロールバックが行われた場合、呼び出し元のサーバもロールバックを行うことができる。トランザクション処理において、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。また、２フェーズコミットのように、呼び出し元の処理と呼び出し先の処理を管理する管理サーバを備えなくとも、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。

＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例を述べる。

図１１は、ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その１）を説明するシーケンス図である。図１１の分散トランザクション処理には、図１のシステム構成と同様のものを用いてよい。なお、図１１のＳ７０１〜Ｓ７１０は、図３のＳ１０１〜Ｓ１１０と同じであるため、説明を省略する。

サーバ１１０ａは、Ｓ７０８の処理後から所定の時間経過後、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。しかし、ＤＢサーバ１２０は、記憶部１２１にサーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）を記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ７１１）。Ｓ７１１処理後から所定の時間が経過しても、プリミティブ（remove）の対象となるチェックレコードがないため、プリミティブ（remove）処理は失敗する（ステップＳ７１２）。サーバ１１０ａは、記憶部１２１にサーバ１１０ｂ側のＲＰＣ処理が開始されていないことを示す制御情報（チェックレコード）が記憶されていない場合に、サーバ１１０ｂ側のトランザクション処理が正常に終了したと判定する。サーバ１１０ａは、口座Ａの更新後のデータをコミットする（ステップＳ７１３）。

図１２は、ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その２）を説明するシーケンス図である。図１２のシーケンス図は、プリミティブ（putIfAbsent）処理が失敗したことでハンドシェークに失敗した場合のトランザクション処理の例である。なお、図１２のＳ８０１〜Ｓ８０６は、図１１のＳ７０１〜Ｓ７０６と同じであるため、説明を省略する。

サーバ１１０ａは、Ｓ８０４のＲＰＣ信号送信処理以降、定期的に、ＤＢサーバ１２０から、制御情報を取得する（ステップＳ８０７）。サーバ１１０ｂからのＤＢサーバ１２０へのプリミティブ（putIfAbsent）処理が失敗する。ＤＢサーバ１２０は、記憶部１２１に、キャンセルレコードの生成に失敗したことを示す制御情報を記憶する（ステップＳ８０８）。サーバ１１０ｂは、Ｓ８０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ８０９）。Ｓ８０９のロールバックで、ＤＢサーバ１２０は、Ｓ８０６のチェックレコードの削除処理を無効とし、チェックレコードを再生成する。Ｓ８０９のロールバックで、ＤＢサーバ１２０は、Ｓ８０８のキャンセルレコードの生成に失敗したことを示す制御情報を削除しない。これにより、システムの管理者は、Ｓ８０８の処理でキャンセルレコードの生成処理に失敗したことを知ることができる。

サーバ１１０ａは、Ｓ８０７の処理後から所定の時間経過後、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。しかし、ＤＢサーバ１２０は、記憶部１２１にチェックレコードを記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ８１０）。なお、図１２のシーケンス図は、Ｓ８１０の処理がＳ８０９よりも先に処理されている。Ｓ８０９のロールバックで、チェックレコードが再生成されたため、ＤＢサーバ１２０がＳ８１０で受信したプリミティブ（remove）の処理が実行できる。ＤＢサーバ１２０は、制御情報１２２からチェックレコードを削除し、削除が成功したことをサーバ１１０ａに通知する（ステップＳ８１１）。サーバ１１０ａは、Ｓ８０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ８１２）。Ｓ８１２のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ８０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ８０３の処理前の状態とする。次に、Ｓ８１２のロールバックでＤＢサーバ１２０は、Ｓ８０２の時点で記憶されているチェックレコードを再生成しない。キャンセルレコードの生成に失敗したことを示す制御情報が記憶部１２１に記憶されている場合、ＤＢサーバ１２０は、チェックレコードを再生成しないと判定する。

図１３は、ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その３）を説明するシーケンス図である。図１３のシーケンス図は、サーバ１１０ｂ側からサーバ１１０ａ側にＲＰＣ＿ＡＣＫ信号が送信されないために、ハンドシェークに失敗した場合の例である。なお、図１３のＳ９０１〜Ｓ９０６は、図１１のＳ７０１〜Ｓ７０６と同じであるため、説明を省略する。

サーバ１１０ａは、Ｓ９０４のＲＰＣ信号送信処理以降、定期的に、ＤＢサーバ１２０から、制御情報を取得する（ステップＳ９０７）。サーバ１１０ｂは、ＤＢサーバ１２０に、キャンセルレコードの書き込み命令であるプリミティブ（putIfAbsent）を通知する。ＤＢサーバ１２０は、記憶部１２１に、キャンセルレコードを記憶する（ステップＳ９０８）。サーバ１１０ｂは、Ｓ９０５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ９０９）。Ｓ９０９のロールバックで、ＤＢサーバ１２０は、Ｓ９０６のチェックレコードの削除処理を無効とし、チェックレコードを再生する。Ｓ９０９のロールバックで、ＤＢサーバ１２０は、Ｓ９０８で生成されたキャンセルレコードを削除する。

サーバ１１０ａは、Ｓ９０７の処理後から所定の時間経過後、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。しかし、ＤＢサーバ１２０は、記憶部１２１にチェックレコードを記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ９１０）。なお、図１３のシーケンス図は、Ｓ９１０の処理がＳ９０９よりも先に処理されている。Ｓ９０９のロールバックで、チェックレコードが再生成されたため、ＤＢサーバ１２０がＳ９１０で受信したプリミティブ（remove）の処理が実行できる。ＤＢサーバ１２０は、制御情報１２２からチェックレコードを削除し、削除が成功したことをサーバ１１０ａに通知する（ステップＳ９１１）。サーバ１１０ａは、Ｓ９０２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ９１２）。Ｓ９１２のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ９０３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ９０３の処理前の状態とする。次に、Ｓ９１２のロールバックでＤＢサーバ１２０は、Ｓ９０２の時点で記憶されているチェックレコードを再生成する。

図１４は、ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その４）を説明するシーケンス図である。図１４のシーケンス図は、サーバ１１０ｂの口座Ｂのデータの更新処理で失敗した場合の例である。なお、図１４のＳ３００１〜Ｓ３００９は、図１１のＳ７０１〜Ｓ７０９と同じであるため、説明を省略する。

サーバ１１０ｂは、Ｓ３００９の口座Ｂのデータの更新処理中又は処理後に失敗が発生したため、Ｓ３００５の時点まで、サーバ１１０ｂ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ３０１０）。ＤＢサーバ１２０は、サーバ１１０ｂからの要求に応じた処理を実行し、口座ＢのデータをＳ３００９の処理前の状態とする。Ｓ３０１０の処理の際、ＤＢサーバ１２０は、Ｓ３００７で記憶部１２１に記憶させた情報を無効とする。併せて、Ｓ３０１０の処理において、ＤＢサーバ１２０は、Ｓ３００５の時点でＤＢサーバ１２０に記憶されているチェックレコードを再生成する。

サーバ１１０ａは、Ｓ３００８の処理後から所定の時間経過後、チェックレコードを対象としたプリミティブ（remove）をＤＢサーバ１２０に通知する。しかし、ＤＢサーバ１２０は、記憶部１２１にチェックレコードを記憶していないため、プリミティブ（remove）の処理は実行されない（ステップＳ３０１１）。なお、図１４のシーケンス図は、Ｓ３０１１の処理がＳ３０１０よりも先に処理されている。Ｓ３０１０のロールバックで、チェックレコードが再生成されたため、ＤＢサーバ１２０がＳ９１０で受信したプリミティブ（remove）の処理が実行できる。ＤＢサーバ１２０は、制御情報１２２からチェックレコードを削除し、削除が成功したことをサーバ１１０ａに通知する（ステップＳ３０１２）。サーバ１１０ａは、Ｓ３００２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ３０１３）。Ｓ３０１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ３００３の処理前の状態とする。そのため、Ｓ３０１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ３００３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ３００３の処理前の状態とする。Ｓ３００８でＲＰＣ＿ＡＣＫ信号を受信している場合、ＤＢサーバ１２０は、Ｓ３０１３のロールバックで、Ｓ３００２の時点で記憶されているチェックレコードを再生成しない。

図１５は、ＲＰＣ信号に対応する応答信号を使用しない分散トランザクション処理の例（その５）を説明するシーケンス図である。図１５のシーケンス図は、サーバ１１０ｂ側の処理がコミットされたにも関わらず、サーバ１１０ａ側の処理がプリミティブ(remove)に関する処理で失敗し、サーバ１１０ａ側の処理をロールバックした場合の例である。なお、図１５のＳ４００１〜Ｓ４０１２は、図１１のＳ７０１〜Ｓ７１２と同じであるため、説明を省略する。

サーバ１１０ａは、サーバ１１０ｂ側の処理がコミット済みであるにも関わらず、Ｓ４００２の時点まで、サーバ１１０ａ側からの処理をロールバックする要求をＤＢサーバ１２０に出す（ステップＳ４０１３）。Ｓ４０１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ４００３の処理前の状態とする。そのため、Ｓ４０１３のロールバックで、サーバ１１０ａは、口座ＡのデータをＳ４００３の処理前の状態とする要求をＤＢサーバ１２０に送信する。ＤＢサーバ１２０は、サーバ１１０ａからの要求に応じた処理を実行し、口座ＡのデータをＳ４００３の処理前の状態とする。Ｓ４００８でＲＰＣ＿ＡＣＫ信号を受信しているため、ＤＢサーバ１２０は、Ｓ４０１３のロールバックで、Ｓ４００２の時点で記憶されているチェックレコードを再生成しない。サーバ１１０ａは、サーバ１１０ｂ側の処理がコミット済みであるにも関わらず、サーバ１１０ａ側の処理をロールバックしているため、サーバ１１０ｂ側のS４００９の処理の無効化する命令を出す（ステップS４０１４）。

なお、図７、図１２、図１３、図１４において、サーバ１１０ａは、サーバ１１０ｂ側の処理がロールバックされた後に、プリミティブ（remove）をＤＢサーバ１２０に送信した場合、ＤＢサーバ１２０は、その場で、要求された命令を実行する。

ＲＰＣの呼び出し元のサーバ１１０ａは、ＤＢサーバ１２０が処理対象として、サーバ１１０ａからの要求処理であることを示す情報を保持している場合に、ＲＰＣの呼び出し先のサーバから要求された処理がＤＢサーバ１２０でロールバックしていると判定する。その後、呼び出し元のサーバ１１０ａは、自身もロールバックをする要求をＤＢサーバ１２０に出す。ＲＰＣの呼び出し元のサーバ１１０ａは、ＲＰＣの呼び出し先のサーバ１１０ｂが処理をコミットしている場合に、自身も処理をコミットする。このため、ＲＰＣの呼び出し先でロールバックが行われた場合、呼び出し元のサーバもロールバックを行うことができる。トランザクション処理において、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。また、２フェーズコミットのように、呼び出し元の処理と呼び出し先の処理を管理する管理サーバを備えなくとも、呼び出し元からの処理対象データと呼び出し先の処理対象データの整合性が保たれる。

１１０ サーバ
１１１ 制御部
１１２ 要求部
１１３ ＲＰＣ送信部
１１４ ＲＰＣ受信部
１１５ 処理部
１１６ 記憶部
１１７ 取得部
１２０ ＤＢサーバ
１２１ 記憶部
１２２ 制御情報
１２３ データベース
１２４ 処理部

Claims (11)

1. 処理の対象となる対象データを保持する保持装置と、前記対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の前記第１の処理装置として動作する処理装置であって、
   前記保持装置に、前記対象データに対する第１の更新処理を要求する要求部と、
   前記第１の更新処理の終了後に、前記第２の処理装置に、前記第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を送信する送信部と、
   前記対象データに対して行われている処理の要求元の処理装置の情報を、前記保持装置から取得する取得部と、を備え、
   前記第２の更新処理の要求後に、前記第１の処理装置により要求された処理が前記対象データに対して行われていることを示す情報を、前記取得部が取得した場合、前記要求部は、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   ことを特徴とするトランザクション処理装置。
2. 前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信する受信部を更に備え、
   前記要求部は、
   所定の時間が経過しても前記受信部が前記応答信号を受信できない場合、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   ことを特徴とする請求項１に記載のトランザクション処理装置。
3. 前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信する受信部を更に備え、
   前記要求部は、
   前記第２の更新処理が正常に終了したことを示す応答信号が前記受信部で受信されると、前記第１の更新処理に対する確定処理を行い、
   前記第２の更新処理が失敗したことを示す応答信号が前記受信部で受信されると、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   ことを特徴とする請求項１に記載のトランザクション処理装置。
4. 処理の対象となる対象データを保持する保持装置と、前記対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の前記第２の処理装置として動作する処理装置であって、
   前記保持装置中の前記対象データに対して前記保持装置が行う第１の更新処理が終了した後に、前記第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を受信する受信部と、
   前記保持装置に、前記対象データに対する第２の更新処理を要求する要求部と、
   前記第２の更新処理が正常に実行されない場合に、前記対象データを前記第２の更新処理が開始される前の状態に戻すことと、前記対象データに対する前記第１の更新処理の要求元の処理装置の情報の再生成とを、前記保持装置に要求するための制御を行う制御部と、を備える
   ことを特徴とするトランザクション処理装置。
5. 処理の対象となる対象データを保持する保持装置と、前記対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の前記第１の処理装置として動作する処理装置で実行されるトランザクション処理プログラムであって、
   前記保持装置に、前記対象データに対する第１の更新処理を要求し、
   前記第１の更新処理の終了後に、前記第２の処理装置に、前記第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を送信し、
   前記対象データに対して行われている処理の要求元の処理装置の情報を、前記保持装置から取得し、
   前記第２の更新処理の要求後に、前記第１の処理装置により要求された処理が前記対象データに対して行われていることを示す情報を、取得した場合、前記対象データを前記第１の更新処理の前の状態に戻す要求を前記保持装置に出す
   処理を処理装置に実行させるトランザクション処理プログラム。
6. 前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信し、
   所定の時間が経過しても前記応答信号を受信できない場合、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   処理を処理装置に実行させる請求項５に記載のトランザクション処理プログラム。
7. 前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信し、
   前記第２の更新処理が正常に終了したことを示す応答信号が受信されると、前記第１の更新処理に対する確定処理を行い、
   前記第２の更新処理が失敗したことを示す応答信号が受信されると、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   処理を処理装置に実行させる請求項５に記載のトランザクション処理プログラム。
8. 処理の対象となる対象データを保持する保持装置と、前記対象データへの処理を要求する第１及び第２の処理装置を含むシステム中の前記第２の処理装置として動作する処理装置で実行されるトランザクション処理プログラムであって、
   前記保持装置中の前記対象データに対して前記保持装置が行う第１の更新処理が終了した後に、前記第１の更新処理と不可分な第２の更新処理の開始を要求する要求信号を受信し、
   前記保持装置に、前記対象データに対する第２の更新処理を要求し、
   前記第２の更新処理が正常に実行されない場合に、前記対象データを前記第２の更新処理が開始される前の状態に戻すことと、前記対象データに対する前記第１の更新処理の要求元の処理装置の情報の再生成とを、前記保持装置に要求するための制御を行う
   処理を処理装置に実行させるトランザクション処理プログラム。
9. 処理の対象となる対象データと、前記対象データに対して行われている処理の要求元の処理装置の情報とを保持する保持装置と、
   前記対象データに対する第１の更新処理を前記保持装置に要求する第１の処理装置と、
   前記第１の更新処理と不可分な第２の更新処理を前記対象データに行うことを、前記保持装置に要求する第２の処理装置と、を含むシステムであって、
   前記第２の処理装置は、
   前記第１の更新処理の終了後に前記第１の処理装置から前記第２の更新処理を要求されてから、前記第２の更新処理を前記保持装置に要求し、
   前記第２の更新処理が正常に実行されない場合に、前記対象データを前記第２の更新処理が開始される前の状態に戻すことと、前記対象データに対する前記第１の更新処理の要求元の処理装置の情報の再生成とを、前記保持装置に要求し、
   前記第１の処理装置は、
   前記第２の更新処理の要求後に、前記第１の処理装置により要求された処理が前記対象データに対して行われていることを示す情報を取得した場合、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
   ことを特徴とする分散処理システム。
10. 前記第１の処理装置は、
    前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信し、
    所定の時間が経過しても前記応答信号を受信できない場合、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
    ことを特徴とする請求項９に記載の分散処理システム。
11. 前記第１の処理装置は、
    前記第２の更新処理が正常に終了したかの情報を含む応答信号を、前記第２の処理装置から受信し、
    前記第２の更新処理が正常に終了したことを示す応答信号が受信されると、前記第１の更新処理に対する確定処理を行い、
    前記第２の更新処理が失敗したことを示す応答信号が受信されると、前記対象データを前記第１の更新処理の前の状態に戻す要求を、前記保持装置に出す
    ことを特徴とする請求項９に記載の分散処理システム。

Images