JP4291060B2 - トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム - Google Patents
トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム Download PDFInfo
- Publication number
- JP4291060B2 JP4291060B2 JP2003189312A JP2003189312A JP4291060B2 JP 4291060 B2 JP4291060 B2 JP 4291060B2 JP 2003189312 A JP2003189312 A JP 2003189312A JP 2003189312 A JP2003189312 A JP 2003189312A JP 4291060 B2 JP4291060 B2 JP 4291060B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- processing
- message
- server
- chained
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は，複数サーバに分散されたデータベース（ＤＢ）を扱うトランザクション処理技術に関し，特に，システム全体のトランザクション処理のスループットを向上させるトランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラムに関する。
【０００２】
【従来の技術】
１つのトランザクション処理において複数のサーバのデータベースを扱う場合の技術として，分散トランザクション技術がある（例えば，特許文献１参照）。従来の分散トランザクション処理システムでは，要求された１つのトランザクション（これをグローバルトランザクションという）を処理するために，メインのサーバが他の１または複数のサーバに処理を依頼し，依頼された各サーバでは，それぞれローカルトランザクションとして依頼された処理を実行し，２フェーズコミットメント方式によるトランザクション制御を行っている。
【０００３】
図２２は，従来の分散トランザクション技術を示す図である。４００はサーバＤ，４０１はサーバＥ，４０２はサーバＦ，４０３はサーバＧ，１０４はトランザクション処理を要求するメッセージである。４１０はサーバＤ４００内のトランザクション処理を実行するプロセス（以下，実行プロセスという），４１１はサーバＥ４０１内の実行プロセス，４１２はサーバＥ４０１内のデータベース（ＤＢ），４１３はサーバＦ４０２内の実行プロセス，４１４はサーバＦ４０２内のデータベース，４１５はサーバＧ４０３内の実行プロセス，４１６はサーバＧ４０３内のデータベースである。
【０００４】
また，５００はグローバルトランザクションであり，実行プロセス４１０上で処理される。５０１，５０２，５０３は各サーバに割り当てられた処理を実行するための個別のトランザクションであるローカルトランザクションであり，それぞれ実行プロセス４１１，実行プロセス４１３，実行プロセス４１５上で処理される。
【０００５】
図２２に示すように，サーバＤ４００内の実行プロセス４１０は，メッセージ１０４を受信した後，グローバルトランザクション５００において必要な処理をサーバＥ４０１，サーバＦ４０２，サーバＧ４０３に分散し，各サーバ内でローカルトランザクションとして処理させ，処理結果を各サーバから受信する。
【０００６】
例えば，サーバＤ４００内の実行プロセス４１０は，メッセージ１０４を受信すると，グローバルトランザクション５００を開始し，サーバＥ４０１が保持するデータベース４１２にアクセスする必要がある場合には，処理依頼命令（ｃａｌｌ Ｅ）によって，サーバＥ４０１の実行プロセス４１１にトランザクション処理を依頼する（ステップＳ１００）。実行プロセス４１１は，ローカルトランザクション５０１によってデータベース４１２をアクセスし，その処理結果を実行プロセス４１０に返す（ステップＳ１０１）。
【０００７】
同様にして，実行プロセス４１０は，サーバＦ４０２の実行プロセス４１３，サーバＧ４０３内の実行プロセス４１５に，例えば，それぞれ「ｃａｌｌ Ｆ」，「ｃａｌｌ Ｇ」により，トランザクション処理を依頼し（ステップＳ１０２，Ｓ１０４），実行プロセス４１３からローカルトランザクション５０２の処理結果の返信を受け，実行プロセス４１５からローカルトランザクション５０３の処理結果の返信を受ける（ステップＳ１０３，Ｓ１０５）。
【０００８】
サーバＤ４００内の実行プロセス４１０は，トランザクション処理を依頼したすべての実行プロセス（実行プロセス４１１，４１３，４１５）から処理結果の返信を受け，すべてのローカルトランザクションの処理が正常に完了したことを確認した場合には，各実行プロセス４１１，４１３，４１５に対してコミット指示を出し，コミットさせる。
【０００９】
一方，サーバＤ４００内の実行プロセス４１０は，処理結果の返信により，実行プロセス４１１，実行プロセス４１３，実行プロセス４１５のいずれかによるローカルトランザクションの処理の途中で異常が生じたことを検出すると，各実行プロセス４１１，４１３，４１５に対してロールバック指示を出し，ロールバックさせる。
【００１０】
実行プロセス４１０は，実行プロセス４１１，４１３，４１５による一連の処理がすべて完了（コミットまたはロールバック）した後に開放される。
【００１１】
【特許文献１】
特開平７−２６２０７３号公報
【００１２】
【発明が解決しようとする課題】
上記従来技術では，関与するサーバ間での一連の処理がすべて完了（コミットまたはロールバック）するまで，各サーバの実行プロセスは開放されない。例えば，図２２において，サーバＤ４００の実行プロセス４１０は，サーバＥ〜Ｆの各実行プロセスにおけるローカルトランザクションの処理がコミットまたはロールバックするまで開放されず，その間は新たなトランザクション処理を開始することができない。
【００１３】
このため，従来技術では，トランザクションの実行多重度は上がらず，システム全体のスループットも上がらないという問題があった。特に，処理に関与するサーバが増加するに従い，実行プロセスの処理時間（開放されるまでの時間）が延び，システム全体としてスループットが劣化するという問題があった。
【００１４】
本発明は，上記従来技術の問題点を解決し，トランザクション処理に関与するサーバ数が増えても，システム全体のトランザクション処理のスループット（平均処理時間）が低くならないようにし，分散トランザクション処理におけるトランザクションのレスポンスを向上させることを目的とする。
【００１５】
【課題を解決するための手段】
上記課題を解決するため，本発明は，複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するためのトランザクション制御装置であって，
各サーバにおける処理を特定する処理種別情報とその処理結果の組の情報が設定される管理部が付加されたメッセージを受信するメッセージ受信手段と，
前記メッセージ受信手段が受信したメッセージにシステム内で一意に第１のトランザクションを識別するための連鎖トランザクション識別子が設定されていない場合には新しい連鎖トランザクション識別子を付与して前記メッセージ内の管理部に設定し，前記メッセージの処理種別情報で指定された処理を第２のトランザクションとして処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放し，前記メッセージ内に未処理の処理種別情報がある場合に，その未処理の処理種別情報によって特定されるサーバに対するトランザクションの処理を要求する前記連鎖トランザクション識別子を含むメッセージを作成し，前記メッセージ内に未処理の処理種別情報がない場合または前記第２のトランザクションの処理結果が異常であった場合に，当該第１のトランザクションに関与したすべてのサーバに対する処理結果の正常または異常を示す結果メッセージを作成するトランザクション管理手段と，
前記トランザクション管理手段が作成したメッセージまたは結果メッセージを送信する前記メッセージ送信手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を前記連鎖トランザクション識別子と共に記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記連鎖トランザクション識別子に基づいて前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを前記連鎖トランザクション識別子と共に保存し，前記第１のトランザクションの処理が正常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段とを備えることを特徴とする。
【００１６】
従来技術と本発明との違いは，以下のとおりである。従来技術では，グローバルトランザクションが複数のローカルトランザクションから構成され，すべてのローカルトランザクションがコミットされるか，いずれかで異常が発生しロールバックされるまで，グローバルトランザクションおよび各ローカルトランザクションを処理するプロセスは，次のトランザクション処理依頼を受け付けることができなかった。
【００１７】
これに対し，本発明では，複数のサーバに処理が跨がるトランザクションを，それぞれのサーバにおけるローカルトランザクションの連鎖によって処理し，それぞれのサーバでは，自サーバにおけるトランザクション処理が完了すると，直ちにローカルトランザクションのコミットまたはロールバックを行う。これより，そのサーバは，新しい他のトランザクション処理依頼を受付可能な状態になる。また，トランザクションの連鎖にあたり，ローカルトランザクションを処理すべきサーバの処理を特定する処理種別情報とメッセージ本文とを含むメッセージを，順次，サーバ間で送受信するとともに，最初のトランザクション処理を要求するメッセージの受信時には，システム内で一意にトランザクションを識別するための連鎖トランザクション識別子をメッセージ内に設定することを行う。
【００１８】
さらに，本発明では，全体のローカルトランザクションの連鎖（これを連鎖トランザクションと呼ぶことにする）を管理し，連鎖トランザクションの処理が完了するまで，ローカルトランザクションにおいてアクセスされたデータの排他制御および更新前データのログの保存を行う。連鎖トランザクションのすべての処理が正常に終了したならば，これらの排他制御の解除およびログの消去を行い，連鎖トランザクションにおけるいずれかのローカルトランザクションにおいて異常が発生した場合には，更新前データのログを利用して，関連する更新データを連鎖トランザクション開始前の状態に復元する。
【００１９】
すなわち，従来のグローバルトランザクションでは，そのコミット処理と各ローカルトランザクションにおけるコミット処理とが同期して行われていたのに対し，本発明によるトランザクション処理方法では，各ローカルトランザクションにおけるコミット処理が，逐次的に非同期に行われる点が大きく異なる。
【００２０】
【発明の実施の形態】
以下に，図を用いて，本発明の実施の形態について説明する。図１は，本発明の概要を示す図である。図１において，１はサーバＡ，２はサーバＢ，３はサーバＣである。
【００２１】
サーバＡ１内において，１０は一連のローカルトランザクション群によって構成され複数サーバに跨って処理される連鎖トランザクションを制御する機能を持つトランザクション制御部，１１はトランザクション処理依頼のメッセージを受信するメッセージ受信部，１２はメッセージを送信するメッセージ送信部，１３はサーバＡ１においてローカルトランザクションを処理するアプリケーションのプロセス，１４はデータベース管理システム（ＤＢＭＳ）である。
【００２２】
トランザクション制御部１０内において，２０は排他情報を管理する排他制御部，２１はデータベース（ＤＢ）１４０の更新前データをログデータとして管理するログ制御部，２２はアプリケーションのスケジュールや排他制御／ログ制御のスケジュールなどを行うトランザクション管理部である。
【００２３】
また，１１０はメッセージ受信部１１が受信したメッセージ１０４が格納されるメッセージキュー，１４０はＤＢＭＳ１４が管理するデータベース（ＤＢ）である。１０４はトランザクション処理依頼の入力事象であるメッセージ，１０５は出力事象，１０６はメッセージ１０４中の連鎖トランザクション管理テーブルである。また，１３０はサーバＡ１に割り当てられた処理を行うローカルトランザクションである。
【００２４】
サーバＢ２は，サーバＢ２においてローカルトランザクションを処理するアプリケーションのプロセス１５と，ＤＢＭＳ１６，ＤＢ１６０以外はサーバＡ１と同様の構成を有し，サーバＣ３は，サーバＣ３においてローカルトランザクションを処理するアプリケーションのプロセス１７と，ＤＢＭＳ１８，ＤＢ１８０以外はサーバＡ１と同様の構成を有する。また，１５０はサーバＢ２に割り当てられた処理を行うローカルトランザクション，１７０はサーバＣ３に割り当てられた処理を行うローカルトランザクションである。
【００２５】
各部の詳細を説明するに先立ち，図１に示すトランザクション処理システムの処理概要を簡単に説明する。
【００２６】
（１）トランザクション処理として，複数のサーバＡ１〜Ｃ３に跨がりデータベース処理を依頼するメッセージ１０４をサーバＡ１が受信したとする。サーバＡ１のトランザクション管理部２２は，そのトランザクションに対してサーバ間で一意の識別子を付加する。この識別子を連鎖トランザクションＩＤという。
【００２７】
（２）トランザクション管理部２２は，アプリケーションのプロセス１３にメッセージ１０４を渡し，アプリケーションのプロセス１３は，ローカルトランザクション１３０を開始し，メッセージ１０４で依頼された処理を実行する。ローカルトランザクション１３０において，ＤＢＭＳ１４を介してＤＢ１４０を更新する場合，ログ制御部２１は，更新前データを取得し，連鎖トランザクションＩＤとともに保存する。
【００２８】
（３）上記（２）のサーバＡ１におけるデータベース１４０への処理が完了した場合，アプリケーションのプロセス１３のローカルトランザクション１３０（ＤＢＭＳ１４のリソースマネージャが提供するトランザクション）は一旦コミットして，そのアプリケーションのプロセス１３の実行権を開放し，他の使用者がアプリケーションのプロセス１３を使用可能状態とする。すなわち，新しいトランザクション処理依頼を受付可能状態とする。
【００２９】
（４）上記（３）で，リソースマネージャのトランザクションはコミットしたが，複数のサーバに跨がった連鎖トランザクションによる一連のデータ処理は完了していないため，上記（２）で更新したデータに対する他の使用者からのアクセスをガードする必要がある。このため，他の使用者がアクセス時にアクセス可否を判定するための排他制御部２０を設け，排他制御部２０は，連鎖トランザクションが完了（コミットまたはロールバック）するまで，更新データの排他制御情報を記録し，更新されたデータに対する他のトランザクションからのアクセスを禁止する。
【００３０】
（５）サーバＡ１からサーバＢ２に対する処理の受け渡しは，従来からあるメッセージ送信部１２，メッセージ受信部１１を用いて非同期メッセージ通信により行う。サーバＢ２おいてもサーバＡ１と同様にローカルトランザクション１５０によってデータベース１６０に対する処理を行う。さらに，サーバＢ２からサーバＣ３へメッセージ通信により処理を受け渡す。
【００３１】
（６）このような連鎖トランザクションによる複数サーバに跨がる一連の処理が正常終了した場合，サーバＣ３のトランザクション管理部２２からそれまでに関与したサーバＡ１，サーバＢ２への処理結果の通知を連鎖トランザクションＩＤを指定して行い，その通知を受けたサーバＡ１，サーバＢ２のトランザクション管理部２２は，通知された連鎖トランザクションＩＤをもとに，更新前データの廃棄および更新データに対する排他制御の解除を行う（連鎖トランザクションのコミット）。
【００３２】
（７）また，上記連鎖トランザクションによる複数サーバに跨がる一連の処理のどこかで何からの原因によりローカルトランザクションが異常終了した場合，それまでに関与したサーバに対し，連鎖トランザクションＩＤとともに異常を通知する。異常の通知を受けたサーバは，更新前データを元にデータベースの復旧を行い，その後に更新前データの廃棄および更新データに対する排他制御解除を行う（連鎖トランザクションのロールバック）。
【００３３】
以上の処理機構によって，各サーバにおけるローカルトランザクションのコミットは，連鎖トランザクションのコミットとは非同期に早期に行われるため，システム全体のスループットが向上する。また，各サーバにおけるＤＢＭＳとは別に，トランザクション制御部１０において排他制御部２０による更新データの排他制御およびログ制御部２１による更新前データの記録・管理が行われるので，複数サーバに跨がったデータ処理の一貫性／整合性が保証される。
【００３４】
サーバＡ１（他のサーバも同様）におけるアプリケーションのプロセス１３は，図１では説明を簡単にするため１つだけ起動されている状態を示しているが，複数起動されていてもよい。トランザクション制御部１０の実装方法としては，各種の形態を取り得る。例えばトランザクション制御部１０におけるトランザクション管理部２２，排他制御部２０，ログ制御部２１を，リエントラントなプログラム群によって実現し，これらのプログラムの全部または一部が，アプリケーションのプロセス１３と同一のプロセス上で動作するように，トランザクション制御部１０をサーバ・システム内に実装することができる。また，トランザクション制御部１０を実現するプログラムを，ライブラリ化して提供することもできる。
【００３５】
図１に示すシステムの実現方法について，さらに詳しく説明する。以上のような連鎖トランザクションによるサーバ間の処理の引き継ぎのために，メッセージ１０４内に連鎖トランザクション管理テーブル１０６が設けられる。この連鎖トランザクション管理テーブル１０６は，トランザクション処理依頼元が最初に作成してもよく，また，最初に処理依頼を受けるサーバ（例えばサーバＡ１）のトランザクション管理部２２が作成するようにしてよい。
【００３６】
連鎖トランザクション管理テーブル１０６には，例えば，どの順序でどのサーバがどの処理を行うかについてのルーティング情報と，各サーバにおいて，ローカルトランザクションの処理が正常に完了（ＯＫ）したか，処理途中で異常が発生（ＮＧ）したか，未処理であるかについての処理結果情報が設定される。
【００３７】
サーバＡ１のメッセージ受信部１１は，メッセージ１０４を受信し，メッセージキュー１１０に格納する。キューイングされたメッセージ１０４は，メッセージキュー１１０の先頭から順次，トランザクション制御部１０に渡される。なお，必要に応じてメッセージ分配処理部（図示省略）が，メッセージ１０４中で指定された処理内容に応じたメッセージ分配処理を行うようにしてもよいが，このようなメッセージ分配処理については従来のメッセージ制御と同様であり，本発明において本質的なことではないので詳しい説明は省略する。また，メッセージ通信におけるメッセージの保証についても従来技術を用いて実現されているものとする。
【００３８】
メッセージ１０４を受信したトランザクション制御部１０内のトランザクション管理部２２は，連鎖トランザクションを一意に特定する識別子である連鎖トランザクションＩＤを生成して，メッセージ１０４中の連鎖トランザクション管理テーブル１０６に設定する。そして，アプリケーションのプロセス１３にメッセージ１０４を渡して，サーバＡ１に割り当てられたローカルトランザクション１３０の処理を依頼する。
【００３９】
トランザクション制御部１０のログ制御部２１は，アプリケーションのプロセス１３がＤＢ１４０のデータの更新をする前に，ＤＢＭＳ１４から更新前データを取得し，連鎖トランザクションＩＤとともにログデータとして管理する。また，排他制御部２０は，他のユーザがＤＢ１４０へアクセスする時にアクセス可否を判定するための更新データに対する排他情報を取得して管理する。
【００４０】
トランザクション制御部１０内のトランザクション管理部２２は，サーバＡ１に割り当てられたローカルトランザクション１３０の処理が正常に終了すると，このローカルトランザクション１３０のコミット指示をＤＢＭＳ１４へ出して，このプロセスの実行権を開放する。これにより，アプリケーションのプロセス１３は，他のトランザクションの新たな処理依頼を受付可能な状態になる。
【００４１】
トランザクション管理部２２は，連鎖トランザクション管理テーブル１０６に設定されたルーティング情報に基づいて，自サーバの次にトランザクション処理を行うサーバに対し，メッセージ１０４をメッセージ送信部１２を通じて送信する。
【００４２】
例えば，連鎖トランザクション管理テーブル１０６に，ルーティング情報として，サーバＡ１において処理されたローカルトランザクション１３０の次の処理を行うサーバがサーバＢ２であることが設定されている場合には，トランザクション管理部２２は，サーバＢ２宛てにメッセージ１０４を送信する。
【００４３】
サーバＢ２内においても，サーバＡ１と同様にして，アプリケーションのプロセス１５はサーバＢ２に割り当てられたローカルトランザクション１５０の処理を行う。サーバＢ２のトランザクション管理部２２は，連鎖トランザクション管理テーブル１０６の設定内容に基づいて，例えば次のサーバＣ３にメッセージ１０４を送信する。
【００４４】
サーバＣ３において，アプリケーションのプロセス１７は，トランザクション管理部２２からメッセージ１０４を受信して，サーバＣ３に割り当てられたローカルトランザクション１７０の処理を行う。サーバＣ３に割り当てられたローカルトランザクション１７０の処理が正常に終了した場合には，トランザクション制御部１０内のトランザクション管理部２２は，連鎖トランザクション管理テーブル１０６の設定内容を参照して，次に処理を行うサーバを確認する。
【００４５】
例えば，連鎖トランザクション管理テーブル１０６の設定内容を参照して，自サーバ（サーバＣ３）が処理を行った最終のサーバであることを確認した場合には，自サーバの前に処理を行ったサーバＢ２およびサーバＡ１のトランザクション管理部２２に対して，サーバＡ１，サーバＢ２，サーバＣ３に跨がって処理された一連のトランザクションである連鎖トランザクションのコミット指示を出す。
【００４６】
この連鎖トランザクションのコミット指示は，具体的には，連鎖トランザクションＩＤの情報と自サーバにおける処理が正常に完了した（ＯＫ）という情報とから構成される結果メッセージの送信により行われる。
【００４７】
サーバＣ３からこの結果メッセージを受けたサーバＡ１およびサーバＢ２のトランザクション管理部２２は，結果メッセージ中の連鎖トランザクションＩＤに基づいて，ログ制御部２１が管理するログデータ（更新前データ），排他制御部２０が管理する排他情報を破棄して，連鎖トランザクションのコミットを行う。排他情報の破棄により，排他が解除される。また，出力事象１０５は，サーバＣ３のアプリケーションのプロセス１７から出力される。
【００４８】
また，例えば，サーバＣ３におけるローカルトランザクション１７０の処理途中で異常が発生した場合には，現在のローカルトランザクション１７０に関するロールバック処理を行うとともに，サーバＣ３の連鎖トランザクション管理テーブル１０６の設定内容に基づいて，自サーバの前に処理を行ったサーバＢ２，サーバＡ１のトランザクション管理部２２に対して，ＤＢ１４０，ＤＢ１６０の復旧指示を行う。
【００４９】
この復旧指示は，具体的には，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生した（ＮＧ）という情報とから構成される結果メッセージの送信により行われる。
【００５０】
サーバＢ２，サーバＡ１においては，トランザクション管理部２２が，この結果メッセージに含まれる連鎖トランザクションＩＤに基づいて，ログ制御部２１が管理するログデータを用いてＤＢ１６０，ＤＢ１４０の復旧処理を行う。その後，排他制御部２０において排他情報が破棄される。
【００５１】
このように，本発明の実施の形態によれば，各サーバは，自サーバに割り当てられたローカルトランザクションの処理が正常に完了すると，このローカルトランザクションをコミットして当該プロセスの実行権を開放し，連鎖トランザクションが正常に完了した場合に，最終に処理を行ったサーバからのコミット指示に基づいて連鎖トランザクションのコミットを行う。
【００５２】
このため，トランザクション処理に関与するサーバ数に大きく依存することなく，複数サーバに跨がったシステム全体で処理されるトランザクションである連鎖トランザクションのスループット（平均処理時間）を向上させることができる。
【００５３】
また，図２は，本発明による効果を従来技術と比較して説明する図である。本発明によれば，上述したように，各サーバにおけるローカルトランザクションのコミットが早期に行われ，システム全体のトランザクション処理のスループットが向上するという効果に加えて，分散トランザクションにかかる通信回数の削減によるトランザクションのレスポンス向上という効果もある。
【００５４】
図２（Ａ）は，図２２に示す従来技術のシステム構成と同じ数の４台のサーバを用いた従来技術による分散トランザクション処理を行う場合の通信回数を示している。また，図２（Ｂ）は，４台のサーバを用いた場合の本発明による連鎖トランザクション処理を行う場合の通信回数を示している。図２中のＭ１，Ｍ３，Ｍ５は処理依頼メッセージ，Ｍ２，Ｍ４，Ｍ６は処理結果メッセージ，Ｍ７，Ｍ９，Ｍ１１はコミット指示メッセージ，Ｍ８，Ｍ１０，Ｍ１２はコミット応答メッセージを表す。また，Ｍ０１，Ｍ０２，Ｍ０３は処理伝達メッセージ，Ｍ０４，Ｍ０５，Ｍ０６はコミット通知メッセージを表す。
【００５５】
図２（Ａ）の従来技術の場合，図２２においても説明したように，サーバＤ４００のグローバルトランザクションがコミットするまでの通信回数は，Ｍ１〜Ｍ１２の１２回となる。これに対し，本発明の場合，図２（Ｂ）に示すように，サーバＤ’において連鎖トランザクションが開始してから，サーバＧ’からサーバＤ’へ連鎖トランザクションのコミット通知メッセージＭ０４が送信され，連鎖トランザクションがコミットされるまでの間の通信にかかる時間は，Ｍ０１〜Ｍ０４の４回分の通信の時間となる。したがって，本発明によれば，図２（Ａ）に示す従来技術に比べて，１トランザクションで発生する通信時間による遅延が大幅に削減でき，トランザクションのレスポンスの向上を図ることができる。また，システム全体における通信量も従来技術では，１２回の通信回数分の通信量になるのに対し，本発明では，サーバＧ’からサーバＥ’，Ｆ’へのコミット通知メッセージＭ０５，Ｍ０６を含めて６回分の通信量となり，通信量の削減によってネットワークの負荷も軽減されることになる。
【００５６】
図３は，本発明の実施の形態におけるシステム構成の詳細を示す図である。ここでは，サーバＡ１の構成を例にとって説明する。図３において，１０１はアプリケーションのプロセス１３から依頼を受けてＤＢＭＳ１４へのアクセスを行う統一データアクセス部である。１４１は排他情報が格納される排他情報テーブル，１４２は更新前データをログデータとして記録するログファイルである。
【００５７】
トランザクション管理部２２内の２２０は連鎖トランザクションＩＤの生成を行う連鎖トランザクションＩＤ管理部，２２１はアプリケーションのスケジュールをするアプリケーションスケジュール部，２２２は排他制御／ログ制御のスケジュールをする排他制御／ログ制御スケジュール部である。
【００５８】
２２３はＤＢＭＳ１４へのアクセス制御をするＤＢＭＳアクセス制御部，２２４はメッセージ１０４をどのサーバに送信するかのルーティングを制御するメッセージルーティング制御部，２２５はメッセージ１０４または結果メッセージを他のサーバとの間で送受信するメッセージ送受信部である。
【００５９】
排他制御部２０は，排他情報テーブル１４１の参照，更新を行い，他のユーザがアクセス時にアクセス可否を判定する手段である。各サーバにおいて，ローカルトランザクションをコミットしても，連鎖トランザクションは完了していないため，更新したデータに対する他のユーザからのアクセスをガードする必要があることから，トランザクション制御部１０は排他制御部２０を備えている。
【００６０】
排他制御部２０は，ＤＢＭＳ１４の排他制御（ローカルトランザクションの間の排他）とは別に，連鎖トランザクションが動作している間，排他情報を管理する。排他情報は，排他情報テーブル１４１に格納されて不揮発データとして管理される。本実施の形態では，排他情報テーブル１４１を，ＤＢ１４０と同一ＤＢＭＳ１４上に作成するようにしているが，もちろん他の不揮発記憶媒体を用いてもよい。
【００６１】
ログ制御部２１は，ＤＢＭＳ１４から更新前データ（ログ）を取得して，ログデータとしてログファイル１４２に記録する。連鎖トランザクションの処理における異常発生時には，このログデータを元にＤＢ１４０のデータを復元する。本実施の形態では，例えば，ログファイル１４２を，ＤＢ１４０と同一ＤＢＭＳ１４上に作成している。これも同一ＤＢ１４０に限らず，他の不揮発記憶媒体上に作成してもよい。
【００６２】
統一データアクセス部１０１は，本発明に必須ではないが，本実施の形態では，連鎖トランザクションの制御の実装およびアプリケーションからのＤＢ１４０に対するアクセスを容易にするための手段として設けている。統一データアクセス部１０１は，アプリケーションのプロセス１３からＳＱＬなどのアクセス命令を直接発行することなく，レコード番号やデータの項目名の指定によりＤＢＭＳ１４へアクセスする仕組み，すなわち，データアクセス装置専用のアプリケーション・インタフェース（ＡＰＩ）を提供する。
【００６３】
統一データアクセス部１０１は，例えば，アプリケーションのプロセス１３から受け取ったアクセス要求項目に基づいてＤＢＭＳ１４のアクセス命令を組み立て，ＤＢＭＳ１４へアクセスする。なお，サーバＢ２またはサーバＣ３のトランザクション管理部，統一データアクセス部も上記図３に示すサーバＡ１のトランザクション制御部１０，統一データアクセス部１０１と同一の構成を有する。
【００６４】
図４は，本発明の実施の形態におけるメッセージの形式を示す図である。メッセージ１０４は，連鎖トランザクション管理テーブル１０６から構成される管理部とメッセージ部とからなる。管理部（連鎖トランザクション管理テーブル１０６）は，例えば，連鎖トランザクションを一意に特定する識別子である「連鎖トランザクションＩＤ」と，「処理種別」と「処理結果」の組の項目から構成される。
【００６５】
連鎖トランザクション管理テーブル１０６の「処理種別」の項目に設定された処理は，例えば，入金処理や現金引き落とし処理というような，各サーバに割り当てられたローカルトランザクション処理を意味する。そして，「処理種別」の項目に設定された順序で各処理が行われる。従って，この連鎖トランザクション管理テーブル１０６の「処理種別」の項目は，どの順序でどの処理を行うかのルーティング情報を提供することとなる。
【００６６】
「処理種別」の項目には，具体的な処理名が設定されてもよいし，処理の識別番号が設定されてもよい。また，処理名または処理の識別番号とともに，当該処理を行うサーバ名またはサーバの識別番号などが設定されてもよい。連鎖トランザクション管理テーブル１０６とは別に，処理種別情報とそれを処理するサーバ情報との対応情報をテーブル化して持つようにしてもよい。
【００６７】
また，連鎖トランザクション管理テーブル１０６の「処理結果」の項目には，「処理種別」の項目に設定された処理の処理結果が設定される。例えば，処理が正常に完了した場合には「ＯＫ」と設定され，処理途中に異常が生じた場合には「ＮＧ」と設定され，未処理である場合には「未」と設定される。
【００６８】
例えば，図４に示す管理部（連鎖トランザクション管理テーブル１０６）には，処理ＡをサーバＡ１が処理し，その次に，処理ＢをサーバＢ２が処理し，それぞれ正常に処理が完了したこと，また，処理Ｂの次に行われる処理ＣはサーバＣ３が処理する処理であり，未処理であることが設定されている。
【００６９】
メッセージ１０４は，連鎖トランザクションで動作する処理間（複数サーバ間）で持ち回る。また，メッセージ１０４内の連鎖トランザクション管理テーブル１０６の設定内容は，各サーバにおいて更新され，例えば，サーバＣ３が処理Ｃを正常に完了させた場合には，図４に示す連鎖トランザクション管理テーブル１０６において，処理Ｃの「処理結果」の項目に「ＯＫ」が記録される。
【００７０】
また，例えば，サーバＣ３による処理Ｃの処理途中で異常が発生した場合には，図４に示す連鎖トランザクション管理テーブル１０６において，処理Ｃの「処理結果」の項目に「ＮＧ」が記録される。
【００７１】
従って，メッセージ１０４を受信したサーバは，メッセージ１０４内の連鎖トランザクション管理テーブル１０６の設定内容を参照することにより，連鎖トランザクションの処理結果情報や，次の処理を行うサーバがどのサーバであるかなどのルーティング情報を取得することができる。
【００７２】
本発明の実施の形態においては，例えば，連鎖トランザクション管理テーブル１０６に，当初から，サーバＡ１，サーバＢ２，サーバＣ３の順序で処理を行うというルーティング情報が設定されていてもよい。
【００７３】
また，例えば，サーバＡ１において，アプリケーションから受け取ったルーティングの追加／変更情報に基づいて，トランザクション管理部２２のメッセージルーティング制御部２２４が，ルーティング情報を追加／変更してもよい。すなわち，サーバＡ１のアプリケーションのプロセス１３が，アプリケーションの処理内容に応じて次にメッセージ１０４を引き渡すサーバの処理（例えば，サーバＢ２の処理Ｂ）を決定し，メッセージルーティング制御部２２４に通知し，連鎖トランザクション管理テーブル１０６に「処理Ｂ（サーバＢ）」の情報を動的に設定するようにしてもよい。
【００７４】
図５は，トランザクション制御部１０のトランザクション管理処理フローの一例を示す図である。まず，トランザクション制御部１０のトランザクション管理部２２は，メッセージ受信部１１よりメッセージ１０４を受信する（ステップＳ１）。
【００７５】
受信したメッセージ１０４内の連鎖トランザクション管理テーブル１０６には，例えば，図６（Ａ）に示すように，最初に処理ＡをサーバＡ１が行い，未処理状態であることが設定されている。また，図６（Ａ）には，サーバＡ１が処理Ａを行った後にサーバＢ２が処理Ｂを行い，サーバＢ２が処理Ｂを行った後にサーバＣ３が処理Ｃを行うことが設定されている。
【００７６】
なお，本発明においては，図６（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６に，当初は，処理ＡをサーバＡ１が行うことだけが設定されており，アプリケーションのプロセス１３からのルーティングの追加／変更情報に基づいて，サーバＡ１内のメッセージルーティング制御部２２４が，連鎖トランザクション管理テーブル１０６のルーティング情報を動的に設定するようにしてもよい。このルーティング情報の動的な設定（追加／変更）については，後述する。
【００７７】
また，他の実施の形態として，最初のサーバＡ１が受信するメッセージ１０４には，連鎖トランザクション管理テーブル１０６がない場合もある。この場合には，メッセージ本体の処理依頼内容からサーバＡ１における処理内容が決定され，トランザクション管理部２２が，連鎖トランザクション管理テーブル１０６を生成してメッセージ本体に付加する。
【００７８】
次に，メッセージ１０４内に連鎖トランザクションＩＤがあるかを判断し（ステップＳ２），連鎖トランザクションＩＤがなければ連鎖トランザクション取得用テーブルのカウンタ部に１加算後，連鎖トランザクションＩＤを取得し（ステップＳ１０），メッセージ１０４内に連鎖トランザクションＩＤを設定して（ステップＳ１１），ステップＳ３に進む。
【００７９】
図７は，連鎖トランザクション取得用テーブルの一例を示す図である。連鎖トランザクション取得用テーブルは，トランザクション管理部２２の連鎖トランザクションＩＤ管理部２２０が管理する。
【００８０】
連鎖トランザクションＩＤは，固定部とカウンタ部からなる。固定部には，連鎖トランザクションが動作する最初のサーバを識別できる値が設定され，例えば，ＩＰアドレスなどが設定される。固定部は，サーバ識別番号でもよい。
【００８１】
カウンタ部は，連鎖トランザクションＩＤの取得の契機で１を加算する。そして，加算後に「固定部＋カウンタ部」で連鎖トランザクションＩＤとして管理する。上記ステップＳ１１の処理により，例えば，図８（Ａ）に示すように，連鎖トランザクションＩＤ「１９２．２３１．６．２．１」が連鎖トランザクション管理テーブル１０６に設定される。
【００８２】
ステップＳ２において，メッセージ１０４内に連鎖トランザクションＩＤがある場合には，アプリケーションの呼び出しを行い（ステップＳ３），連鎖トランザクション管理テーブル１０６の「処理種別」の項目に設定された処理を依頼する。すなわち，アプリケーションのプロセス１３に処理Ａを依頼する。アプリケーションのプロセス１３において処理Ａが行われ，アプリケーションのプロセス１３から復帰したならば，当該処理の結果をメッセージに設定する（ステップＳ４）。
【００８３】
例えば，サーバＡ１のアプリケーションのプロセス１３による処理Ａが正常に完了した場合には，図８（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６の処理Ａの「処理結果」の項目に「ＯＫ」が設定される。サーバＡ１による処理Ａの途中で異常が発生した場合には，「ＮＧ」が設定される。
【００８４】
なお，後述するように，例えば，アプリケーションのプロセス１３からのルーティングの追加／変更指示があった場合には，ステップＳ４において，連鎖トランザクション管理テーブル１０６の「処理種別」項目の設定内容を追加／変更することを通じて，ルーティング情報を追加／変更してもよい。
【００８５】
次に，処理結果がＯＫかを判断し（ステップＳ５），処理結果がＯＫである場合には，ＤＢＭＳ１４へコミット指示を行い（ステップＳ６），ステップＳ７へ進む。
【００８６】
ステップＳ７では，メッセージ１０４内に次の処理があるか，すなわち，連鎖トランザクション管理テーブル１０６に次に行う処理が設定されているかを判断する。
【００８７】
メッセージ１０４内に次の処理がある場合には，次の処理を行うサーバ宛てのメッセージ１０４を作成して（ステップＳ８），メッセージ送信部１２に対してメッセージ１０４を送信する（ステップＳ９）。
【００８８】
例えば，図８（Ｂ）に示す連鎖トランザクション管理テーブル１０６の設定内容から，サーバＡ１が処理Ａを処理した後にサーバＢ２が処理Ｂを処理することがわかるため，トランザクション制御部１０のトランザクション管理部２２は，サーバＢ２宛てのメッセージをメッセージ送信部１２に送信する。メッセージ１０４を受信したサーバＢ２では処理Ｂが行われることになる。
【００８９】
ステップＳ９でメッセージ１０４を送信した後，メッセージ受信部１１の受信メッセージを削除して（ステップＳ１６），処理を終了する。
【００９０】
ステップＳ１６で受信メッセージを削除する理由は，以下のとおりである。本実施の形態におけるメッセージ受信部１１では，システム障害などによるサーバのダウン時に，メッセージが消失してしまわないようにメッセージキュー１１０を不揮発性の記憶媒体に保存し，メッセージが喪失しないように保証している。このメッセージ保証機構を連鎖トランザクションのメッセージ処理中における障害対策にも利用する。このため，ステップＳ１において，メッセージ受信部１１からトランザクション制御部１０がメッセージを受信しても，メッセージキュー１１０において受信メッセージは削除しないで，受信済みにしておく。サーバにおける処理が完了したときに，受信メッセージを削除する（ステップＳ１６）。こうすることにより，サーバが障害でダウンし，その後に再起動したときに，サーバ内のメッセージ１０４の有無により，そのサーバでトランザクション処理の実施の有無を判断することができる。
【００９１】
ステップＳ７において，メッセージ１０４内に次の処理がない場合には，当該連鎖トランザクション処理に関与したサーバに対する結果メッセージを作成する（ステップＳ１４）。この場合の結果メッセージは，連鎖トランザクションのコミット指示を行うためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理が正常に完了した（ＯＫ）という情報とから構成される。そして，メッセージ送信部１２に対して結果メッセージを送信し（ステップＳ１５），処理済みの受信メッセージを削除し（ステップＳ１６），処理を終了する。
【００９２】
ステップＳ５において，当該処理の結果がＮＧの場合には，ＤＢＭＳ１４へロールバック指示を行い（ステップＳ１２），排他制御部２０へ排他解除依頼を行う（ステップＳ１３）。そして，当該連鎖トランザクション処理に関与したサーバに対する結果メッセージを作成する（ステップＳ１４）。
【００９３】
この場合の結果メッセージは，上記連鎖トランザクション処理に関与したサーバ内のデータベースの復旧を指示するためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生した（ＮＧ）という情報とから構成される。そして，メッセージ送信部１２に対してこの結果メッセージを送信し（ステップＳ１５），受信メッセージを削除して（ステップＳ１６），処理を終了する。
【００９４】
サーバＡ１における処理が正常に終了し，サーバＢ２へメッセージ１０４が送信されて，同様にサーバＢ２内で処理Ｂがされた後に，上述したステップＳ７〜Ｓ９の処理により，連鎖トランザクション管理テーブル１０６の設定内容に従って，サーバＢ２からサーバＣ３にメッセージ１０４が送信されると，サーバＣ３において処理Ｃが行われる。そして，サーバＣ３における処理Ｃが正常に完了した後には，連鎖トランザクション管理テーブル１０６は，例えば図９（Ａ）に示すような内容が設定されている。
【００９５】
そこで，サーバＣ３のトランザクション管理部２２は，上記図９（Ａ）に示す連鎖トランザクション管理テーブル１０６を参照して，次の処理がないこと，すなわち，自サーバが最終に処理を行ったサーバであることを確認すると，連鎖トランザクション管理テーブル１０６において自サーバより前に処理を行ったサーバとして記録されているサーバＢ２とサーバＡ１に対して結果メッセージを送信してコミット指示を出す。
【００９６】
例えば，サーバＡ１，サーバＢ２，サーバＣ３の順に各サーバに割り当てられた処理を行ってきた場合，サーバＣ３における処理結果がＮＧであると，図９（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６の処理Ｃの「処理結果」の項目に「ＮＧ」が設定されている。
【００９７】
この場合，サーバＣ３のトランザクション管理部２２は，ＤＢＭＳ１４へロールバック指示をするとともに，排他制御部２０へ排他解除依頼をする。そして，図９（Ｂ）に示す連鎖トランザクション管理テーブル１０６を参照して，自サーバの前に処理を行ったサーバＢ２とサーバＡ１宛てにデータベースの復旧を指示するための結果メッセージを送信する。
【００９８】
次に，トランザクション制御部１０の排他制御処理について説明する。本実施の形態における排他制御処理は，アプリケーションのプロセス１３と同一プロセスで実行してもよいし，排他制御処理自体を独立したサーバ（排他専用サーバ）で行ってもよい。
【００９９】
本処理の入力情報は，例えば，排他要求の項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤである。排他制御部２０が管理する排他情報が格納される排他情報テーブル１４１の一例を図１０に示す。
【０１００】
図１０に示すように，排他情報は，例えば，項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤの組の情報から構成される。排他情報の項目名は，ＤＢＭＳにおけるアクセスの排他制御単位となるデータを識別するものであり，レコード単位で排他制御が行われる場合には，レコード識別子（レコード番号等）のようなものでもよい。
【０１０１】
図１１（Ａ）は，排他獲得時のトランザクション制御部１０の動作処理フローの一例を示す図である。排他獲得要求時の入力情報は，排他情報テーブル１４１における排他情報と同じ，排他要求の項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤである。排他獲得要求に対し，排他制御部２０は，排他情報テーブル１４１の検索を行い（ステップＳ２１），同じ項目名の排他情報があるか否かを調べる（ステップＳ２２）。該当する排他情報がなければ，排他情報テーブル１４１の空きエントリに，入力情報の排他情報を設定して管理し（ステップＳ２５），排他獲得処理を終了する。
【０１０２】
ステップＳ２２の判定において，同じ項目名の排他情報があれば，排他的なアクセスモードかを判断する（ステップＳ２３）。入力情報のアクセスモードと，排他情報テーブル１４１中の排他情報のアクセスモードの少なくともいずれかが，「更新」であれば排他的なアクセスモードと判断し，両方とも「参照」の場合には，排他的なアクセスモードではないと判断する。
【０１０３】
排他的なアクセスモードでなければ，ステップＳ２１へ戻り，他の該当する排他情報の検索を続ける。排他的なアクセスモードであれば，排他解除通知が来るまで，排他待ちを行い（ステップＳ２４），ステップＳ２１へ戻る。
【０１０４】
図１１（Ｂ）は，排他解除時のトランザクション制御部１０の動作処理フローを示す図である。排他解除のときの入力情報は，連鎖トランザクションＩＤである。排他解除時には，排他制御部２０は，連鎖トランザクションＩＤをキーに排他情報テーブル１４１の検索を行う（ステップＳ３１）。入力情報と同じ連鎖トランザクションＩＤの排他情報がない場合，排他解除処理を終了する（ステップＳ３２）。同じ連鎖トランザクションＩＤの排他情報がある場合には，その排他情報を排他情報テーブル１４１から削除し（ステップＳ３３），排他待ち相手に排他解除通知を行う（ステップＳ３４）。その後，ステップＳ３１へ戻ってすべての該当する排他情報を削除するまで処理を繰り返す。
【０１０５】
次に，トランザクション制御部１０のログ制御処理について説明する。ログ制御処理では，ログデータの管理および管理したログデータに基づくＤＢ１４０の復旧を行う。前述したように，ログ（更新前データ）を管理するログファイル１４２は，更新するＤＢ１４０と同一ＤＢＭＳ１４上に事前に作成し，ログは不揮発データとして管理する。
【０１０６】
本処理の入力情報は，連鎖トランザクションＩＤ，更新前データの位置情報を一意に識別する項目名，ログデータ，処理要求（ログ書出し／ログ削除／ＤＢ復旧）である。また，ログファイル１４２上では，図１２に示すように，連鎖トランザクションＩＤ，項目名，ログデータが管理される。
【０１０７】
図１３（Ａ）は，トランザクション制御部１０のログ制御部２１によるログ書出し処理フローの一例を示す図である。ログ制御部２１は，ログ書出し要求に対して，まず，ログデータの組み立てを行い（ステップＳ４１），ＤＢＭＳ１４へ書き込み依頼を行って（ステップＳ４２），処理を終了する。
【０１０８】
図１３（Ｂ）は，トランザクション制御部１０のログ制御部２１によるログ削除処理フローの一例を示す図である。ログ制御部２１は，ログ削除要求に対して削除データの組み立てを行い（ステップＳ５１），ＤＢＭＳ１４へ削除依頼を行って（ステップＳ５２），処理を終了する。
【０１０９】
図１４は，ＤＢの復旧時のトランザクション制御部１０のログ制御部２１によるＤＢ復旧処理フローの一例を示す図である。ＤＢ復旧時の入力情報は，連鎖トランザクションＩＤである。
【０１１０】
ログ制御部２１は，連鎖トランザクションＩＤの入力によるＤＢ復旧依頼に対し，入力した連鎖トランザクションＩＤをキーとしてログデータの検索をＤＢＭＳ１４へ依頼する（ステップＳ６１）。該当するログデータがない場合には（ステップＳ６２），処理を終了する。
【０１１１】
該当するログデータがあった場合，ログデータからＤＢＭＳ１４のアクセス命令の組み立てを行い（ステップＳ６３），ＤＢＭＳ１４へ書き込み依頼を行う（ステップＳ６４）。この処理によりＤＢ１４０が連鎖トランザクションによる更新前の状態に復旧される。その後，ＤＢＭＳ１４へログデータの削除依頼を行って（ステップＳ６５），ステップＳ６１へ戻る。該当するすべてのログデータについて同様に処理を繰り返す。
【０１１２】
次に，トランザクション制御部１０のメッセージルーティング制御について説明する。このメッセージルーティング制御は，アプリケーションのプロセス１３からのルーティングの追加／変更指示を受けて，トランザクション制御部１０内のメッセージルーティング制御部２２４が行う。
【０１１３】
図１５は，メッセージルーティング制御処理フローの一例を示す図である。まず，アプリケーションのプロセス１３からＡＰＩで受け取ったルーティングの追加／変更指示情報の解析を行う（ステップＳ７１）。解析結果に基づき，メッセージの連鎖トランザクション管理テーブル１０６にルーティング情報を設定して（ステップＳ７２），処理を終了する。例えば，図１６（Ｂ）に示すアプリケーションからの指示を解析して，「次の処理Ｂ（サーバＢ）の情報を設定」というルーティングの追加指示情報を得たとする。この場合，ステップＳ７２では，図１６（Ａ）に示す連鎖トランザクション管理テーブル１０６の「処理種別」の項目に，「処理Ｂ（サーバＢ）」という情報を追加設定する。
【０１１４】
図１７は，トランザクション制御部１０による連鎖トランザクションのコミット処理フローまたはＤＢの復旧処理フローの一例を示す図である。他のサーバから連鎖トランザクションの結果メッセージを受信すると（ステップＳ８１），その結果メッセージから処理が正常に完了した旨を通知する正常終了通知（ＯＫ）か異常終了通知（ＮＧ）かを判定する（ステップＳ８２）。正常終了通知である場合には，連鎖トランザクションのコミット指示がなされたことを意味するので，結果メッセージ中の連鎖トランザクションＩＤを指定してログ制御部２１へログデータの削除依頼を行い（ステップＳ８３），その後，排他制御部２０へ排他解除依頼を行って（ステップＳ８４），処理を終了する。
【０１１５】
ステップＳ８２の判定において，正常終了通知でなく，処理結果が「ＮＧ」である旨の通知であることがわかった場合には，結果メッセージ中の連鎖トランザクションＩＤを指定してログ制御部２１へＤＢ復旧依頼を行い，（ステップＳ８５），その後に排他制御部２０へ排他解除を依頼し（ステップＳ８４），処理を終了する。
【０１１６】
次に，統一データアクセス制御について説明する。本処理の入力情報は，アクセスする項目名，アクセス要求（参照または更新），更新データ（更新時）である。また，出力情報は，読込みデータ（読込み要求時）である。
【０１１７】
図１８は，統一データアクセス部１０１の統一データアクセス制御処理フローの一例を示す図である。まず，排他獲得要求で排他制御部２０の排他制御処理の呼び出しを行う（ステップＳ９１）。次に，アプリケーションのプロセス１３からのアクセス要求項目より，ＤＢＭＳ１４のアクセス命令の組み立てを行い（ステップＳ９２），ＤＢＭＳ１４へ組み立てたアクセス命令を発行し，該当レコードの読込みを行う（ステップＳ９３）。アプリケーションからのアクセス要求が参照（読込み要求）の場合，読み込んだレコードは，出力情報としての読込みデータとなる。アクセス要求が更新（書出し要求）の場合，読み込んだレコードは，更新前データとしてログする。
【０１１８】
そのため，アクセス要求がデータの書出し要求か読込み要求かを判定する（ステップＳ９４）。データの書出し要求である場合には，ログ書出し要求でログ制御処理の呼び出しを行い，ステップＳ９３で読み込んだデータをログ制御部２１を呼び出してログファイル１４２に記録し（ステップＳ９５），また，ＤＢＭＳ１４へ更新データの書込みを依頼して（ステップＳ９６），処理を終了する。また，アクセス要求がデータの読込み要求の場合には，読込みデータをアクセス要求元のアプリケーションへ渡す復帰情報に設定して（ステップＳ９７），処理を終了する。
【０１１９】
図１９は，ローカルトランザクションをコミットする場合の各サーバ内での動作シーケンスの一例を示す。ここでは，サーバＡ１内の動作処理を例にして，図１９に示すシーケンスａ〜ｎに従って説明する。
【０１２０】
（ａ）トランザクション制御部１０が，メッセージ受信部１１にメッセージ受信を要求し，メッセージ受信部１１からメッセージ１０４を受信する。
【０１２１】
（ｂ）受信したメッセージ１０４中の連鎖トランザクション管理テーブル１０６に連鎖トランザクションＩＤを設定して，ローカルトランザクション（ＤＢトランザクション）の開始を宣言する。なお，受信したメッセージ１０４中にトランザクション管理テーブル１０６が付加されていない場合には，連鎖トランザクション管理テーブル１０６を付加した後に，連鎖トランザクションＩＤを設定する。
【０１２２】
（ｃ）アプリケーションを呼び出し，アプリケーションのプロセス１３においてメッセージ１０４で要求された処理を開始する。
【０１２３】
（ｄ）アプリケーションのプロセス１３がＤＢ１４０のデータを更新する場合，統一データアクセス部１０１にＤＢ１４０の更新要求を行う。
【０１２４】
（ｅ）統一データアクセス部１０１は，トランザクション制御部１０に排他獲得およびログ要求を行う。
【０１２５】
（ｆ）〜（ｈ）この要求に対して，トランザクション制御部１０は，排他情報テーブル１４１に該当する更新データの排他情報がないことを確認して，排他情報テーブル１４１に排他情報を設定する。また，トランザクション制御部１０は，ＤＢ１４０から更新前データを読み込み，ログファイル１４２に更新前データのログを書き出す。その後に，トランザクション制御部１０は，統一データアクセス部１０１に排他／ログ終了を通知する。
【０１２６】
（ｉ）統一データアクセス部１０１は，排他／ログ終了通知を受け付けると，ＳＱＬ文を発行するなどしてＤＢ１４０を更新する。
【０１２７】
（ｊ）アプリケーションのプロセス１３は，ローカルトランザクションの処理を完了する前に，連鎖トランザクション管理テーブル１０６におけるルーティング情報の追加／変更指示をトランザクション制御部１０へ通知する。この指示に従って，トランザクション制御部１０は，連鎖トランザクション管理テーブル１０６のルーティング情報を追加／変更する。
【０１２８】
（ｋ）アプリケーションの処理を終了し，トランザクション制御部１０に復帰する。
【０１２９】
（ｌ）トランザクション制御部１０は，アプリケーションから復帰した後，アプリケーションの処理結果を連鎖トランザクション管理テーブル１０６に設定する。
【０１３０】
（ｍ）設定された処理結果が「ＯＫ」の場合，トランザクション制御部１０は，ＤＢＭＳ１４に対してローカルトランザクションのコミット指示を出す。
【０１３１】
（ｎ）トランザクション制御部１０は，連鎖トランザクション管理テーブル１０６の設定内容に基づいて，次の処理を行うサーバへメッセージを送信することをメッセージ送信部１２に指示する。自サーバが最終のトランザクション処理を行ったサーバである場合には，自サーバの前に処理を行ったすべてのサーバに連鎖トランザクションのコミット指示をする結果メッセージを送信する。
【０１３２】
図２０は，連鎖トランザクションをコミットする場合の各サーバ内での動作シーケンスの一例を示す図である。以下の（ａ’）および（ｂ’）の処理は，アプリケーションの処理とは非同期に行われる。
【０１３３】
（ａ’）トランザクション制御部１０は，連鎖トランザクションのコミットを指示する結果メッセージを受信する。
【０１３４】
（ｂ’）トランザクション制御部１０は，コミットを指示する結果メッセージの受信により，ログファイル１４２から該当する連鎖トランザクションのログデータを削除し，排他情報テーブル１４１から該当する連鎖トランザクションの排他情報を削除する。
【０１３５】
次に，本発明の実施の形態において，連鎖トランザクション処理中にサーバがダウンし，その後にサーバが再起動したときの処理について説明する。連鎖トランザクション処理中にサーバがダウンした場合には，処理の実行状態によりその後の振る舞い（処理継続／ロールバック）が異なる。例えば，サーバＡ１，Ｂ２，Ｃ３と処理を行う連鎖トランザクションにおいて，サーバＣ３の処理を実施中に，サーバＢ２がダウンしたとする。
【０１３６】
この場合には，サーバＢ２の処理は完結しているため，サーバＢ２では再起動後に結果メッセージの到着を待ち，その結果メッセージの指示（ＯＫ／ＮＧ）に従う。
【０１３７】
サーバＣ３がダウンした場合には，ダウン時にサーバＣ３で処理が行われていたか否かにより，その後の振る舞いが異なる。例えば，メッセージ受信部１１にメッセージ１０４があるが，一切処理を行っていない状態でダウンした場合には，サーバＣ３は，ダウン後のシステム再起動後に，引き続きそのメッセージ１０４に従った処理を実施すればよく，サーバＣ３で処理中にダウンした場合には，処理中であったトランザクションのリカバリ処理が必要となる。
【０１３８】
ダウン時に処理中であったか否かを判断するため，連鎖トランザクションＩＤで排他情報テーブル１４１を検索し，当該連鎖トランザクションＩＤの排他情報があれば，処理中にダウンしたと判断して，一旦サーバＣ３で実施した処理をロールバック（ログデータからＤＢ復旧）する。
【０１３９】
このとき，連鎖トランザクション自体をロールバックするか否かは，いずれでも構わない。連鎖トランザクション自体をロールバックする場合には，連鎖トランザクション処理に関与したサーバに対して，処理途中で異常が発生（ダウン）し，処理結果が「ＮＧ」であることを示す結果メッセージを送信すればよい。また，処理を継続する場合には，再度メッセージを読み込み，その処理を実行すればよい。ここまでの処理をダウン後の再起動時の初期処理で実施する。
【０１４０】
図２１は，連鎖トランザクションの処理中にサーバがダウンし，ダウン後に再起動した時のサーバにおける初期処理のフローの一例を示す図である。
【０１４１】
まず，メッセージ受信部１１よりメッセージを受信する（ステップＳ１１１）。そして，メッセージ受信部１１にメッセージがあるかを判断する（ステップＳ１１２）。メッセージがない場合には，処理を終了する。メッセージがある場合には，結果メッセージかを判断する（ステップＳ１１３）。
【０１４２】
結果メッセージである場合には，ステップＳ１１１へ戻り，メッセージ受信部１１からの次のメッセージの受信処理を行う。結果メッセージではなく，連鎖トランザクションの処理要求のメッセージ１０４である場合には，排他情報テーブル１４１を，メッセージ１０４中の連鎖トランザクションＩＤで検索し（ステップＳ１１４），排他情報があるかを判断する（ステップＳ１１５）。
【０１４３】
排他情報がない場合には，このサーバは処理を実施していない状態でダウンしたことになるので，ステップＳ１１１へ戻る。
【０１４４】
排他情報がある場合には，ダウン時に処理中であったことになるので，ログ制御部２１へＤＢ復旧依頼を行い（ステップＳ１１６），排他制御部２０へ排他解除依頼をする（ステップＳ１１７）。
【０１４５】
続いて，当該連鎖トランザクション処理に関与したサーバに対する結果（ＮＧ）メッセージを作成する（ステップＳ１１８）。この場合の結果メッセージは，当該連鎖トランザクション処理に関与したサーバ内のデータベースの復旧を指示し，連鎖トランザクションのロールバックを行うためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生（ダウン）した（ＮＧ）という情報とから構成される。メッセージ送信部１２に対してこの結果メッセージを送信し（ステップＳ１１９），受信メッセージを削除して（ステップＳ１２０），ステップＳ１１１へ戻る。
【０１４６】
メッセージ受信部１１が受信済みのすべてのメッセージについて，以上の処理を行った後（ステップＳ１１２），再起動後の初期処理を終了する。その後，図５に示した通常のトランザクション管理処理を行う。このとき，図２１の初期処理でトランザクション制御部１０がメッセージ受信部１１から受信し処理したメッセージについては，ステップＳ１２０で削除したものを除き，受信済みとしないで，再度受信対象とし，各々のメッセージ１０４について処理を行う。
【０１４７】
以上説明した仕組みにより，複数サーバに跨ったデータ処理の一貫性／整合性を保証しつつ，システム全体のスループットとトランザクション処理のレスポンスの向上が図られる。
【０１４８】
以上の本発明による連鎖トランザクションの処理は，各サーバのコンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【０１４９】
以上から把握できるように，本発明の実施形態の特徴を述べると，以下のとおりである。
【０１５０】
（付記１）複数のサーバによってトランザクションを処理するトランザクション処理方法において，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，
前記複数のサーバは，各サーバ毎に，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する
ことを特徴とするトランザクション処理方法。
【０１５１】
（付記２）付記１記載のトランザクション処理方法において，
前記第２のトランザクションの処理では，当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行うとともに，当該第２のトランザクション内で更新されるデータの更新前データを保存し，
前記第１のトランザクションの処理が正常終了した場合に，前記記録した排他情報および前記保存した更新前データを廃棄し，
前記第１のトランザクションの処理が異常終了した場合に，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄する
ことを特徴とするトランザクション処理方法。
【０１５２】
（付記３）付記２記載のトランザクション処理方法において，
前記第１のトランザクションに，システム内で一意にトランザクションを識別するための連鎖トランザクション識別子を付与し，
前記連鎖トランザクション識別子と，各サーバにおける処理および処理結果の組の情報とをサーバ間のメッセージに付加してメッセージ通信を行うことにより，前記第１のトランザクションを，前記第２のトランザクションの連鎖で処理する
ことを特徴とするトランザクション処理方法。
【０１５３】
（付記４）付記３記載のトランザクション処理方法において，
前記第１のトランザクションの処理が正常終了した場合に，連鎖する第２のトランザクションのうち最後のトランザクションを処理したサーバが，前記第１のトランザクションの処理に係る各サーバに対して，前記記録した排他情報および前記保存した更新前データを廃棄するように通信を行う
ことを特徴とするトランザクション処理方法。
【０１５４】
（付記５）付記３記載のトランザクション処理方法において，
前記第１のトランザクションの処理が異常終了した場合に，連鎖する第２のトランザクションのうち異常終了したトランザクションを処理したサーバが，前記第１のトランザクションの処理に係る各サーバに対して，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するように通信を行う
ことを特徴とするトランザクション処理方法。
【０１５５】
（付記６）複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するためのトランザクション制御装置であって，
他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放するトランザクション管理手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを保存し，前記第１のトランザクションの処理が正常終了した場合に，前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段とを備える
ことを特徴とするトランザクション制御装置。
【０１５６】
（付記７）複数のサーバによってトランザクションを処理するトランザクション処理方法を，各サーバが備えるコンピュータに実行させるためのトランザクション制御プログラムであって，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する処理を，
コンピュータに実行させるためのトランザクション制御プログラム。
【０１５７】
（付記８）複数のサーバによってトランザクションを処理するトランザクション処理方法を，各サーバが備えるコンピュータに実行させるためのトランザクション制御プログラムを記録したコンピュータ読取り可能な記録媒体であって，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する処理を，
コンピュータに実行させるためのプログラムを記録した
ことを特徴とするトランザクション制御プログラムの記録媒体。
【０１５８】
【発明の効果】
本発明によれば，連鎖トランザクションに関与したサーバ間の一連の処理の同期が不要となり，各サーバのデータベースアクセス処理が非同期に動作することで，同時実行多重度が上がり，システム全体のトランザクションのスループットが向上する。
【０１５９】
また，本発明によれば，トランザクションがコミットするまでの通信回数を従来技術より大幅に減少させることができるため，分散トランザクション処理における，トランザクションのレスポンスを向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるシステム構成の一例を示す図である。
【図２】本発明による効果を従来技術と比較して説明する図である。
【図３】本発明の実施の形態におけるシステム構成の詳細を示す図である。
【図４】本発明の実施の形態におけるメッセージの形式を示す図である。
【図５】トランザクション制御部のトランザクション管理処理フローの一例を示す図である。
【図６】連鎖トランザクション管理テーブルの一例を示す図である。
【図７】連鎖トランザクション取得用テーブルの一例を示す図である。
【図８】連鎖トランザクション管理テーブルの一例を示す図である。
【図９】連鎖トランザクション管理テーブルの一例を示す図である。
【図１０】排他情報テーブルの一例を示す図である。
【図１１】トランザクション制御部の排他制御部による処理フローの一例を示す図である。
【図１２】ログファイルの一例を示す図である。
【図１３】ログ書出し処理およびログ削除処理フローの一例を示す図である。
【図１４】ログ制御部によるＤＢ復旧処理フローの一例を示す図である。
【図１５】メッセージルーティング制御処理フローの一例を示す図である。
【図１６】ルーティングの追加／変更処理の一例を示す図である。
【図１７】連鎖トランザクションのコミット処理フローまたはＤＢの復旧処理フローの一例を示す図である。
【図１８】統一データアクセス制御処理フローの一例を示す図である。
【図１９】各サーバ内での動作シーケンスの一例を示す図である。
【図２０】各サーバ内での動作シーケンスの一例を示す図である。
【図２１】ダウン後に再起動した時のサーバにおける初期処理のフローの一例を示す図である。
【図２２】従来の分散トランザクション技術を示す図である。
【符号の説明】
１ サーバＡ
２ サーバＢ
３ サーバＣ
１０ トランザクション制御部
１１ メッセージ受信部
１２ メッセージ送信部
１３，１５，１７ アプリケーションのプロセス
１４，１６，１８ ＤＢＭＳ
２０ 排他制御部
２１ ログ制御部
２２ トランザクション管理部
１０１ 統一データアクセス部
１０４ メッセージ
１０５ 出力事象
１０６ 連鎖トランザクション管理テーブル
１１０ メッセージキュー
１３０，１５０，１７０，５０１，５０２，５０３ ローカルトランザクション
１４０，１６０，１８０，４１２，４１４，４１６ データベース（ＤＢ）
１４１ 排他情報テーブル
１４２ ログファイル
２２０ 連鎖トランザクションＩＤ管理部
２２１ アプリケーションスケジュール部
２２２ 排他制御／ログ制御スケジュール部
２２３ ＤＢＭＳアクセス制御部
２２４ メッセージルーティング制御部
２２５ メッセージ送受信部
４００〜４０３ サーバ
４１０，４１１，４１３，４１５ 実行プロセス
５００ グローバルトランザクション
【発明の属する技術分野】
本発明は，複数サーバに分散されたデータベース（ＤＢ）を扱うトランザクション処理技術に関し，特に，システム全体のトランザクション処理のスループットを向上させるトランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラムに関する。
【０００２】
【従来の技術】
１つのトランザクション処理において複数のサーバのデータベースを扱う場合の技術として，分散トランザクション技術がある（例えば，特許文献１参照）。従来の分散トランザクション処理システムでは，要求された１つのトランザクション（これをグローバルトランザクションという）を処理するために，メインのサーバが他の１または複数のサーバに処理を依頼し，依頼された各サーバでは，それぞれローカルトランザクションとして依頼された処理を実行し，２フェーズコミットメント方式によるトランザクション制御を行っている。
【０００３】
図２２は，従来の分散トランザクション技術を示す図である。４００はサーバＤ，４０１はサーバＥ，４０２はサーバＦ，４０３はサーバＧ，１０４はトランザクション処理を要求するメッセージである。４１０はサーバＤ４００内のトランザクション処理を実行するプロセス（以下，実行プロセスという），４１１はサーバＥ４０１内の実行プロセス，４１２はサーバＥ４０１内のデータベース（ＤＢ），４１３はサーバＦ４０２内の実行プロセス，４１４はサーバＦ４０２内のデータベース，４１５はサーバＧ４０３内の実行プロセス，４１６はサーバＧ４０３内のデータベースである。
【０００４】
また，５００はグローバルトランザクションであり，実行プロセス４１０上で処理される。５０１，５０２，５０３は各サーバに割り当てられた処理を実行するための個別のトランザクションであるローカルトランザクションであり，それぞれ実行プロセス４１１，実行プロセス４１３，実行プロセス４１５上で処理される。
【０００５】
図２２に示すように，サーバＤ４００内の実行プロセス４１０は，メッセージ１０４を受信した後，グローバルトランザクション５００において必要な処理をサーバＥ４０１，サーバＦ４０２，サーバＧ４０３に分散し，各サーバ内でローカルトランザクションとして処理させ，処理結果を各サーバから受信する。
【０００６】
例えば，サーバＤ４００内の実行プロセス４１０は，メッセージ１０４を受信すると，グローバルトランザクション５００を開始し，サーバＥ４０１が保持するデータベース４１２にアクセスする必要がある場合には，処理依頼命令（ｃａｌｌ Ｅ）によって，サーバＥ４０１の実行プロセス４１１にトランザクション処理を依頼する（ステップＳ１００）。実行プロセス４１１は，ローカルトランザクション５０１によってデータベース４１２をアクセスし，その処理結果を実行プロセス４１０に返す（ステップＳ１０１）。
【０００７】
同様にして，実行プロセス４１０は，サーバＦ４０２の実行プロセス４１３，サーバＧ４０３内の実行プロセス４１５に，例えば，それぞれ「ｃａｌｌ Ｆ」，「ｃａｌｌ Ｇ」により，トランザクション処理を依頼し（ステップＳ１０２，Ｓ１０４），実行プロセス４１３からローカルトランザクション５０２の処理結果の返信を受け，実行プロセス４１５からローカルトランザクション５０３の処理結果の返信を受ける（ステップＳ１０３，Ｓ１０５）。
【０００８】
サーバＤ４００内の実行プロセス４１０は，トランザクション処理を依頼したすべての実行プロセス（実行プロセス４１１，４１３，４１５）から処理結果の返信を受け，すべてのローカルトランザクションの処理が正常に完了したことを確認した場合には，各実行プロセス４１１，４１３，４１５に対してコミット指示を出し，コミットさせる。
【０００９】
一方，サーバＤ４００内の実行プロセス４１０は，処理結果の返信により，実行プロセス４１１，実行プロセス４１３，実行プロセス４１５のいずれかによるローカルトランザクションの処理の途中で異常が生じたことを検出すると，各実行プロセス４１１，４１３，４１５に対してロールバック指示を出し，ロールバックさせる。
【００１０】
実行プロセス４１０は，実行プロセス４１１，４１３，４１５による一連の処理がすべて完了（コミットまたはロールバック）した後に開放される。
【００１１】
【特許文献１】
特開平７−２６２０７３号公報
【００１２】
【発明が解決しようとする課題】
上記従来技術では，関与するサーバ間での一連の処理がすべて完了（コミットまたはロールバック）するまで，各サーバの実行プロセスは開放されない。例えば，図２２において，サーバＤ４００の実行プロセス４１０は，サーバＥ〜Ｆの各実行プロセスにおけるローカルトランザクションの処理がコミットまたはロールバックするまで開放されず，その間は新たなトランザクション処理を開始することができない。
【００１３】
このため，従来技術では，トランザクションの実行多重度は上がらず，システム全体のスループットも上がらないという問題があった。特に，処理に関与するサーバが増加するに従い，実行プロセスの処理時間（開放されるまでの時間）が延び，システム全体としてスループットが劣化するという問題があった。
【００１４】
本発明は，上記従来技術の問題点を解決し，トランザクション処理に関与するサーバ数が増えても，システム全体のトランザクション処理のスループット（平均処理時間）が低くならないようにし，分散トランザクション処理におけるトランザクションのレスポンスを向上させることを目的とする。
【００１５】
【課題を解決するための手段】
上記課題を解決するため，本発明は，複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するためのトランザクション制御装置であって，
各サーバにおける処理を特定する処理種別情報とその処理結果の組の情報が設定される管理部が付加されたメッセージを受信するメッセージ受信手段と，
前記メッセージ受信手段が受信したメッセージにシステム内で一意に第１のトランザクションを識別するための連鎖トランザクション識別子が設定されていない場合には新しい連鎖トランザクション識別子を付与して前記メッセージ内の管理部に設定し，前記メッセージの処理種別情報で指定された処理を第２のトランザクションとして処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放し，前記メッセージ内に未処理の処理種別情報がある場合に，その未処理の処理種別情報によって特定されるサーバに対するトランザクションの処理を要求する前記連鎖トランザクション識別子を含むメッセージを作成し，前記メッセージ内に未処理の処理種別情報がない場合または前記第２のトランザクションの処理結果が異常であった場合に，当該第１のトランザクションに関与したすべてのサーバに対する処理結果の正常または異常を示す結果メッセージを作成するトランザクション管理手段と，
前記トランザクション管理手段が作成したメッセージまたは結果メッセージを送信する前記メッセージ送信手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を前記連鎖トランザクション識別子と共に記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記連鎖トランザクション識別子に基づいて前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを前記連鎖トランザクション識別子と共に保存し，前記第１のトランザクションの処理が正常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段とを備えることを特徴とする。
【００１６】
従来技術と本発明との違いは，以下のとおりである。従来技術では，グローバルトランザクションが複数のローカルトランザクションから構成され，すべてのローカルトランザクションがコミットされるか，いずれかで異常が発生しロールバックされるまで，グローバルトランザクションおよび各ローカルトランザクションを処理するプロセスは，次のトランザクション処理依頼を受け付けることができなかった。
【００１７】
これに対し，本発明では，複数のサーバに処理が跨がるトランザクションを，それぞれのサーバにおけるローカルトランザクションの連鎖によって処理し，それぞれのサーバでは，自サーバにおけるトランザクション処理が完了すると，直ちにローカルトランザクションのコミットまたはロールバックを行う。これより，そのサーバは，新しい他のトランザクション処理依頼を受付可能な状態になる。また，トランザクションの連鎖にあたり，ローカルトランザクションを処理すべきサーバの処理を特定する処理種別情報とメッセージ本文とを含むメッセージを，順次，サーバ間で送受信するとともに，最初のトランザクション処理を要求するメッセージの受信時には，システム内で一意にトランザクションを識別するための連鎖トランザクション識別子をメッセージ内に設定することを行う。
【００１８】
さらに，本発明では，全体のローカルトランザクションの連鎖（これを連鎖トランザクションと呼ぶことにする）を管理し，連鎖トランザクションの処理が完了するまで，ローカルトランザクションにおいてアクセスされたデータの排他制御および更新前データのログの保存を行う。連鎖トランザクションのすべての処理が正常に終了したならば，これらの排他制御の解除およびログの消去を行い，連鎖トランザクションにおけるいずれかのローカルトランザクションにおいて異常が発生した場合には，更新前データのログを利用して，関連する更新データを連鎖トランザクション開始前の状態に復元する。
【００１９】
すなわち，従来のグローバルトランザクションでは，そのコミット処理と各ローカルトランザクションにおけるコミット処理とが同期して行われていたのに対し，本発明によるトランザクション処理方法では，各ローカルトランザクションにおけるコミット処理が，逐次的に非同期に行われる点が大きく異なる。
【００２０】
【発明の実施の形態】
以下に，図を用いて，本発明の実施の形態について説明する。図１は，本発明の概要を示す図である。図１において，１はサーバＡ，２はサーバＢ，３はサーバＣである。
【００２１】
サーバＡ１内において，１０は一連のローカルトランザクション群によって構成され複数サーバに跨って処理される連鎖トランザクションを制御する機能を持つトランザクション制御部，１１はトランザクション処理依頼のメッセージを受信するメッセージ受信部，１２はメッセージを送信するメッセージ送信部，１３はサーバＡ１においてローカルトランザクションを処理するアプリケーションのプロセス，１４はデータベース管理システム（ＤＢＭＳ）である。
【００２２】
トランザクション制御部１０内において，２０は排他情報を管理する排他制御部，２１はデータベース（ＤＢ）１４０の更新前データをログデータとして管理するログ制御部，２２はアプリケーションのスケジュールや排他制御／ログ制御のスケジュールなどを行うトランザクション管理部である。
【００２３】
また，１１０はメッセージ受信部１１が受信したメッセージ１０４が格納されるメッセージキュー，１４０はＤＢＭＳ１４が管理するデータベース（ＤＢ）である。１０４はトランザクション処理依頼の入力事象であるメッセージ，１０５は出力事象，１０６はメッセージ１０４中の連鎖トランザクション管理テーブルである。また，１３０はサーバＡ１に割り当てられた処理を行うローカルトランザクションである。
【００２４】
サーバＢ２は，サーバＢ２においてローカルトランザクションを処理するアプリケーションのプロセス１５と，ＤＢＭＳ１６，ＤＢ１６０以外はサーバＡ１と同様の構成を有し，サーバＣ３は，サーバＣ３においてローカルトランザクションを処理するアプリケーションのプロセス１７と，ＤＢＭＳ１８，ＤＢ１８０以外はサーバＡ１と同様の構成を有する。また，１５０はサーバＢ２に割り当てられた処理を行うローカルトランザクション，１７０はサーバＣ３に割り当てられた処理を行うローカルトランザクションである。
【００２５】
各部の詳細を説明するに先立ち，図１に示すトランザクション処理システムの処理概要を簡単に説明する。
【００２６】
（１）トランザクション処理として，複数のサーバＡ１〜Ｃ３に跨がりデータベース処理を依頼するメッセージ１０４をサーバＡ１が受信したとする。サーバＡ１のトランザクション管理部２２は，そのトランザクションに対してサーバ間で一意の識別子を付加する。この識別子を連鎖トランザクションＩＤという。
【００２７】
（２）トランザクション管理部２２は，アプリケーションのプロセス１３にメッセージ１０４を渡し，アプリケーションのプロセス１３は，ローカルトランザクション１３０を開始し，メッセージ１０４で依頼された処理を実行する。ローカルトランザクション１３０において，ＤＢＭＳ１４を介してＤＢ１４０を更新する場合，ログ制御部２１は，更新前データを取得し，連鎖トランザクションＩＤとともに保存する。
【００２８】
（３）上記（２）のサーバＡ１におけるデータベース１４０への処理が完了した場合，アプリケーションのプロセス１３のローカルトランザクション１３０（ＤＢＭＳ１４のリソースマネージャが提供するトランザクション）は一旦コミットして，そのアプリケーションのプロセス１３の実行権を開放し，他の使用者がアプリケーションのプロセス１３を使用可能状態とする。すなわち，新しいトランザクション処理依頼を受付可能状態とする。
【００２９】
（４）上記（３）で，リソースマネージャのトランザクションはコミットしたが，複数のサーバに跨がった連鎖トランザクションによる一連のデータ処理は完了していないため，上記（２）で更新したデータに対する他の使用者からのアクセスをガードする必要がある。このため，他の使用者がアクセス時にアクセス可否を判定するための排他制御部２０を設け，排他制御部２０は，連鎖トランザクションが完了（コミットまたはロールバック）するまで，更新データの排他制御情報を記録し，更新されたデータに対する他のトランザクションからのアクセスを禁止する。
【００３０】
（５）サーバＡ１からサーバＢ２に対する処理の受け渡しは，従来からあるメッセージ送信部１２，メッセージ受信部１１を用いて非同期メッセージ通信により行う。サーバＢ２おいてもサーバＡ１と同様にローカルトランザクション１５０によってデータベース１６０に対する処理を行う。さらに，サーバＢ２からサーバＣ３へメッセージ通信により処理を受け渡す。
【００３１】
（６）このような連鎖トランザクションによる複数サーバに跨がる一連の処理が正常終了した場合，サーバＣ３のトランザクション管理部２２からそれまでに関与したサーバＡ１，サーバＢ２への処理結果の通知を連鎖トランザクションＩＤを指定して行い，その通知を受けたサーバＡ１，サーバＢ２のトランザクション管理部２２は，通知された連鎖トランザクションＩＤをもとに，更新前データの廃棄および更新データに対する排他制御の解除を行う（連鎖トランザクションのコミット）。
【００３２】
（７）また，上記連鎖トランザクションによる複数サーバに跨がる一連の処理のどこかで何からの原因によりローカルトランザクションが異常終了した場合，それまでに関与したサーバに対し，連鎖トランザクションＩＤとともに異常を通知する。異常の通知を受けたサーバは，更新前データを元にデータベースの復旧を行い，その後に更新前データの廃棄および更新データに対する排他制御解除を行う（連鎖トランザクションのロールバック）。
【００３３】
以上の処理機構によって，各サーバにおけるローカルトランザクションのコミットは，連鎖トランザクションのコミットとは非同期に早期に行われるため，システム全体のスループットが向上する。また，各サーバにおけるＤＢＭＳとは別に，トランザクション制御部１０において排他制御部２０による更新データの排他制御およびログ制御部２１による更新前データの記録・管理が行われるので，複数サーバに跨がったデータ処理の一貫性／整合性が保証される。
【００３４】
サーバＡ１（他のサーバも同様）におけるアプリケーションのプロセス１３は，図１では説明を簡単にするため１つだけ起動されている状態を示しているが，複数起動されていてもよい。トランザクション制御部１０の実装方法としては，各種の形態を取り得る。例えばトランザクション制御部１０におけるトランザクション管理部２２，排他制御部２０，ログ制御部２１を，リエントラントなプログラム群によって実現し，これらのプログラムの全部または一部が，アプリケーションのプロセス１３と同一のプロセス上で動作するように，トランザクション制御部１０をサーバ・システム内に実装することができる。また，トランザクション制御部１０を実現するプログラムを，ライブラリ化して提供することもできる。
【００３５】
図１に示すシステムの実現方法について，さらに詳しく説明する。以上のような連鎖トランザクションによるサーバ間の処理の引き継ぎのために，メッセージ１０４内に連鎖トランザクション管理テーブル１０６が設けられる。この連鎖トランザクション管理テーブル１０６は，トランザクション処理依頼元が最初に作成してもよく，また，最初に処理依頼を受けるサーバ（例えばサーバＡ１）のトランザクション管理部２２が作成するようにしてよい。
【００３６】
連鎖トランザクション管理テーブル１０６には，例えば，どの順序でどのサーバがどの処理を行うかについてのルーティング情報と，各サーバにおいて，ローカルトランザクションの処理が正常に完了（ＯＫ）したか，処理途中で異常が発生（ＮＧ）したか，未処理であるかについての処理結果情報が設定される。
【００３７】
サーバＡ１のメッセージ受信部１１は，メッセージ１０４を受信し，メッセージキュー１１０に格納する。キューイングされたメッセージ１０４は，メッセージキュー１１０の先頭から順次，トランザクション制御部１０に渡される。なお，必要に応じてメッセージ分配処理部（図示省略）が，メッセージ１０４中で指定された処理内容に応じたメッセージ分配処理を行うようにしてもよいが，このようなメッセージ分配処理については従来のメッセージ制御と同様であり，本発明において本質的なことではないので詳しい説明は省略する。また，メッセージ通信におけるメッセージの保証についても従来技術を用いて実現されているものとする。
【００３８】
メッセージ１０４を受信したトランザクション制御部１０内のトランザクション管理部２２は，連鎖トランザクションを一意に特定する識別子である連鎖トランザクションＩＤを生成して，メッセージ１０４中の連鎖トランザクション管理テーブル１０６に設定する。そして，アプリケーションのプロセス１３にメッセージ１０４を渡して，サーバＡ１に割り当てられたローカルトランザクション１３０の処理を依頼する。
【００３９】
トランザクション制御部１０のログ制御部２１は，アプリケーションのプロセス１３がＤＢ１４０のデータの更新をする前に，ＤＢＭＳ１４から更新前データを取得し，連鎖トランザクションＩＤとともにログデータとして管理する。また，排他制御部２０は，他のユーザがＤＢ１４０へアクセスする時にアクセス可否を判定するための更新データに対する排他情報を取得して管理する。
【００４０】
トランザクション制御部１０内のトランザクション管理部２２は，サーバＡ１に割り当てられたローカルトランザクション１３０の処理が正常に終了すると，このローカルトランザクション１３０のコミット指示をＤＢＭＳ１４へ出して，このプロセスの実行権を開放する。これにより，アプリケーションのプロセス１３は，他のトランザクションの新たな処理依頼を受付可能な状態になる。
【００４１】
トランザクション管理部２２は，連鎖トランザクション管理テーブル１０６に設定されたルーティング情報に基づいて，自サーバの次にトランザクション処理を行うサーバに対し，メッセージ１０４をメッセージ送信部１２を通じて送信する。
【００４２】
例えば，連鎖トランザクション管理テーブル１０６に，ルーティング情報として，サーバＡ１において処理されたローカルトランザクション１３０の次の処理を行うサーバがサーバＢ２であることが設定されている場合には，トランザクション管理部２２は，サーバＢ２宛てにメッセージ１０４を送信する。
【００４３】
サーバＢ２内においても，サーバＡ１と同様にして，アプリケーションのプロセス１５はサーバＢ２に割り当てられたローカルトランザクション１５０の処理を行う。サーバＢ２のトランザクション管理部２２は，連鎖トランザクション管理テーブル１０６の設定内容に基づいて，例えば次のサーバＣ３にメッセージ１０４を送信する。
【００４４】
サーバＣ３において，アプリケーションのプロセス１７は，トランザクション管理部２２からメッセージ１０４を受信して，サーバＣ３に割り当てられたローカルトランザクション１７０の処理を行う。サーバＣ３に割り当てられたローカルトランザクション１７０の処理が正常に終了した場合には，トランザクション制御部１０内のトランザクション管理部２２は，連鎖トランザクション管理テーブル１０６の設定内容を参照して，次に処理を行うサーバを確認する。
【００４５】
例えば，連鎖トランザクション管理テーブル１０６の設定内容を参照して，自サーバ（サーバＣ３）が処理を行った最終のサーバであることを確認した場合には，自サーバの前に処理を行ったサーバＢ２およびサーバＡ１のトランザクション管理部２２に対して，サーバＡ１，サーバＢ２，サーバＣ３に跨がって処理された一連のトランザクションである連鎖トランザクションのコミット指示を出す。
【００４６】
この連鎖トランザクションのコミット指示は，具体的には，連鎖トランザクションＩＤの情報と自サーバにおける処理が正常に完了した（ＯＫ）という情報とから構成される結果メッセージの送信により行われる。
【００４７】
サーバＣ３からこの結果メッセージを受けたサーバＡ１およびサーバＢ２のトランザクション管理部２２は，結果メッセージ中の連鎖トランザクションＩＤに基づいて，ログ制御部２１が管理するログデータ（更新前データ），排他制御部２０が管理する排他情報を破棄して，連鎖トランザクションのコミットを行う。排他情報の破棄により，排他が解除される。また，出力事象１０５は，サーバＣ３のアプリケーションのプロセス１７から出力される。
【００４８】
また，例えば，サーバＣ３におけるローカルトランザクション１７０の処理途中で異常が発生した場合には，現在のローカルトランザクション１７０に関するロールバック処理を行うとともに，サーバＣ３の連鎖トランザクション管理テーブル１０６の設定内容に基づいて，自サーバの前に処理を行ったサーバＢ２，サーバＡ１のトランザクション管理部２２に対して，ＤＢ１４０，ＤＢ１６０の復旧指示を行う。
【００４９】
この復旧指示は，具体的には，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生した（ＮＧ）という情報とから構成される結果メッセージの送信により行われる。
【００５０】
サーバＢ２，サーバＡ１においては，トランザクション管理部２２が，この結果メッセージに含まれる連鎖トランザクションＩＤに基づいて，ログ制御部２１が管理するログデータを用いてＤＢ１６０，ＤＢ１４０の復旧処理を行う。その後，排他制御部２０において排他情報が破棄される。
【００５１】
このように，本発明の実施の形態によれば，各サーバは，自サーバに割り当てられたローカルトランザクションの処理が正常に完了すると，このローカルトランザクションをコミットして当該プロセスの実行権を開放し，連鎖トランザクションが正常に完了した場合に，最終に処理を行ったサーバからのコミット指示に基づいて連鎖トランザクションのコミットを行う。
【００５２】
このため，トランザクション処理に関与するサーバ数に大きく依存することなく，複数サーバに跨がったシステム全体で処理されるトランザクションである連鎖トランザクションのスループット（平均処理時間）を向上させることができる。
【００５３】
また，図２は，本発明による効果を従来技術と比較して説明する図である。本発明によれば，上述したように，各サーバにおけるローカルトランザクションのコミットが早期に行われ，システム全体のトランザクション処理のスループットが向上するという効果に加えて，分散トランザクションにかかる通信回数の削減によるトランザクションのレスポンス向上という効果もある。
【００５４】
図２（Ａ）は，図２２に示す従来技術のシステム構成と同じ数の４台のサーバを用いた従来技術による分散トランザクション処理を行う場合の通信回数を示している。また，図２（Ｂ）は，４台のサーバを用いた場合の本発明による連鎖トランザクション処理を行う場合の通信回数を示している。図２中のＭ１，Ｍ３，Ｍ５は処理依頼メッセージ，Ｍ２，Ｍ４，Ｍ６は処理結果メッセージ，Ｍ７，Ｍ９，Ｍ１１はコミット指示メッセージ，Ｍ８，Ｍ１０，Ｍ１２はコミット応答メッセージを表す。また，Ｍ０１，Ｍ０２，Ｍ０３は処理伝達メッセージ，Ｍ０４，Ｍ０５，Ｍ０６はコミット通知メッセージを表す。
【００５５】
図２（Ａ）の従来技術の場合，図２２においても説明したように，サーバＤ４００のグローバルトランザクションがコミットするまでの通信回数は，Ｍ１〜Ｍ１２の１２回となる。これに対し，本発明の場合，図２（Ｂ）に示すように，サーバＤ’において連鎖トランザクションが開始してから，サーバＧ’からサーバＤ’へ連鎖トランザクションのコミット通知メッセージＭ０４が送信され，連鎖トランザクションがコミットされるまでの間の通信にかかる時間は，Ｍ０１〜Ｍ０４の４回分の通信の時間となる。したがって，本発明によれば，図２（Ａ）に示す従来技術に比べて，１トランザクションで発生する通信時間による遅延が大幅に削減でき，トランザクションのレスポンスの向上を図ることができる。また，システム全体における通信量も従来技術では，１２回の通信回数分の通信量になるのに対し，本発明では，サーバＧ’からサーバＥ’，Ｆ’へのコミット通知メッセージＭ０５，Ｍ０６を含めて６回分の通信量となり，通信量の削減によってネットワークの負荷も軽減されることになる。
【００５６】
図３は，本発明の実施の形態におけるシステム構成の詳細を示す図である。ここでは，サーバＡ１の構成を例にとって説明する。図３において，１０１はアプリケーションのプロセス１３から依頼を受けてＤＢＭＳ１４へのアクセスを行う統一データアクセス部である。１４１は排他情報が格納される排他情報テーブル，１４２は更新前データをログデータとして記録するログファイルである。
【００５７】
トランザクション管理部２２内の２２０は連鎖トランザクションＩＤの生成を行う連鎖トランザクションＩＤ管理部，２２１はアプリケーションのスケジュールをするアプリケーションスケジュール部，２２２は排他制御／ログ制御のスケジュールをする排他制御／ログ制御スケジュール部である。
【００５８】
２２３はＤＢＭＳ１４へのアクセス制御をするＤＢＭＳアクセス制御部，２２４はメッセージ１０４をどのサーバに送信するかのルーティングを制御するメッセージルーティング制御部，２２５はメッセージ１０４または結果メッセージを他のサーバとの間で送受信するメッセージ送受信部である。
【００５９】
排他制御部２０は，排他情報テーブル１４１の参照，更新を行い，他のユーザがアクセス時にアクセス可否を判定する手段である。各サーバにおいて，ローカルトランザクションをコミットしても，連鎖トランザクションは完了していないため，更新したデータに対する他のユーザからのアクセスをガードする必要があることから，トランザクション制御部１０は排他制御部２０を備えている。
【００６０】
排他制御部２０は，ＤＢＭＳ１４の排他制御（ローカルトランザクションの間の排他）とは別に，連鎖トランザクションが動作している間，排他情報を管理する。排他情報は，排他情報テーブル１４１に格納されて不揮発データとして管理される。本実施の形態では，排他情報テーブル１４１を，ＤＢ１４０と同一ＤＢＭＳ１４上に作成するようにしているが，もちろん他の不揮発記憶媒体を用いてもよい。
【００６１】
ログ制御部２１は，ＤＢＭＳ１４から更新前データ（ログ）を取得して，ログデータとしてログファイル１４２に記録する。連鎖トランザクションの処理における異常発生時には，このログデータを元にＤＢ１４０のデータを復元する。本実施の形態では，例えば，ログファイル１４２を，ＤＢ１４０と同一ＤＢＭＳ１４上に作成している。これも同一ＤＢ１４０に限らず，他の不揮発記憶媒体上に作成してもよい。
【００６２】
統一データアクセス部１０１は，本発明に必須ではないが，本実施の形態では，連鎖トランザクションの制御の実装およびアプリケーションからのＤＢ１４０に対するアクセスを容易にするための手段として設けている。統一データアクセス部１０１は，アプリケーションのプロセス１３からＳＱＬなどのアクセス命令を直接発行することなく，レコード番号やデータの項目名の指定によりＤＢＭＳ１４へアクセスする仕組み，すなわち，データアクセス装置専用のアプリケーション・インタフェース（ＡＰＩ）を提供する。
【００６３】
統一データアクセス部１０１は，例えば，アプリケーションのプロセス１３から受け取ったアクセス要求項目に基づいてＤＢＭＳ１４のアクセス命令を組み立て，ＤＢＭＳ１４へアクセスする。なお，サーバＢ２またはサーバＣ３のトランザクション管理部，統一データアクセス部も上記図３に示すサーバＡ１のトランザクション制御部１０，統一データアクセス部１０１と同一の構成を有する。
【００６４】
図４は，本発明の実施の形態におけるメッセージの形式を示す図である。メッセージ１０４は，連鎖トランザクション管理テーブル１０６から構成される管理部とメッセージ部とからなる。管理部（連鎖トランザクション管理テーブル１０６）は，例えば，連鎖トランザクションを一意に特定する識別子である「連鎖トランザクションＩＤ」と，「処理種別」と「処理結果」の組の項目から構成される。
【００６５】
連鎖トランザクション管理テーブル１０６の「処理種別」の項目に設定された処理は，例えば，入金処理や現金引き落とし処理というような，各サーバに割り当てられたローカルトランザクション処理を意味する。そして，「処理種別」の項目に設定された順序で各処理が行われる。従って，この連鎖トランザクション管理テーブル１０６の「処理種別」の項目は，どの順序でどの処理を行うかのルーティング情報を提供することとなる。
【００６６】
「処理種別」の項目には，具体的な処理名が設定されてもよいし，処理の識別番号が設定されてもよい。また，処理名または処理の識別番号とともに，当該処理を行うサーバ名またはサーバの識別番号などが設定されてもよい。連鎖トランザクション管理テーブル１０６とは別に，処理種別情報とそれを処理するサーバ情報との対応情報をテーブル化して持つようにしてもよい。
【００６７】
また，連鎖トランザクション管理テーブル１０６の「処理結果」の項目には，「処理種別」の項目に設定された処理の処理結果が設定される。例えば，処理が正常に完了した場合には「ＯＫ」と設定され，処理途中に異常が生じた場合には「ＮＧ」と設定され，未処理である場合には「未」と設定される。
【００６８】
例えば，図４に示す管理部（連鎖トランザクション管理テーブル１０６）には，処理ＡをサーバＡ１が処理し，その次に，処理ＢをサーバＢ２が処理し，それぞれ正常に処理が完了したこと，また，処理Ｂの次に行われる処理ＣはサーバＣ３が処理する処理であり，未処理であることが設定されている。
【００６９】
メッセージ１０４は，連鎖トランザクションで動作する処理間（複数サーバ間）で持ち回る。また，メッセージ１０４内の連鎖トランザクション管理テーブル１０６の設定内容は，各サーバにおいて更新され，例えば，サーバＣ３が処理Ｃを正常に完了させた場合には，図４に示す連鎖トランザクション管理テーブル１０６において，処理Ｃの「処理結果」の項目に「ＯＫ」が記録される。
【００７０】
また，例えば，サーバＣ３による処理Ｃの処理途中で異常が発生した場合には，図４に示す連鎖トランザクション管理テーブル１０６において，処理Ｃの「処理結果」の項目に「ＮＧ」が記録される。
【００７１】
従って，メッセージ１０４を受信したサーバは，メッセージ１０４内の連鎖トランザクション管理テーブル１０６の設定内容を参照することにより，連鎖トランザクションの処理結果情報や，次の処理を行うサーバがどのサーバであるかなどのルーティング情報を取得することができる。
【００７２】
本発明の実施の形態においては，例えば，連鎖トランザクション管理テーブル１０６に，当初から，サーバＡ１，サーバＢ２，サーバＣ３の順序で処理を行うというルーティング情報が設定されていてもよい。
【００７３】
また，例えば，サーバＡ１において，アプリケーションから受け取ったルーティングの追加／変更情報に基づいて，トランザクション管理部２２のメッセージルーティング制御部２２４が，ルーティング情報を追加／変更してもよい。すなわち，サーバＡ１のアプリケーションのプロセス１３が，アプリケーションの処理内容に応じて次にメッセージ１０４を引き渡すサーバの処理（例えば，サーバＢ２の処理Ｂ）を決定し，メッセージルーティング制御部２２４に通知し，連鎖トランザクション管理テーブル１０６に「処理Ｂ（サーバＢ）」の情報を動的に設定するようにしてもよい。
【００７４】
図５は，トランザクション制御部１０のトランザクション管理処理フローの一例を示す図である。まず，トランザクション制御部１０のトランザクション管理部２２は，メッセージ受信部１１よりメッセージ１０４を受信する（ステップＳ１）。
【００７５】
受信したメッセージ１０４内の連鎖トランザクション管理テーブル１０６には，例えば，図６（Ａ）に示すように，最初に処理ＡをサーバＡ１が行い，未処理状態であることが設定されている。また，図６（Ａ）には，サーバＡ１が処理Ａを行った後にサーバＢ２が処理Ｂを行い，サーバＢ２が処理Ｂを行った後にサーバＣ３が処理Ｃを行うことが設定されている。
【００７６】
なお，本発明においては，図６（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６に，当初は，処理ＡをサーバＡ１が行うことだけが設定されており，アプリケーションのプロセス１３からのルーティングの追加／変更情報に基づいて，サーバＡ１内のメッセージルーティング制御部２２４が，連鎖トランザクション管理テーブル１０６のルーティング情報を動的に設定するようにしてもよい。このルーティング情報の動的な設定（追加／変更）については，後述する。
【００７７】
また，他の実施の形態として，最初のサーバＡ１が受信するメッセージ１０４には，連鎖トランザクション管理テーブル１０６がない場合もある。この場合には，メッセージ本体の処理依頼内容からサーバＡ１における処理内容が決定され，トランザクション管理部２２が，連鎖トランザクション管理テーブル１０６を生成してメッセージ本体に付加する。
【００７８】
次に，メッセージ１０４内に連鎖トランザクションＩＤがあるかを判断し（ステップＳ２），連鎖トランザクションＩＤがなければ連鎖トランザクション取得用テーブルのカウンタ部に１加算後，連鎖トランザクションＩＤを取得し（ステップＳ１０），メッセージ１０４内に連鎖トランザクションＩＤを設定して（ステップＳ１１），ステップＳ３に進む。
【００７９】
図７は，連鎖トランザクション取得用テーブルの一例を示す図である。連鎖トランザクション取得用テーブルは，トランザクション管理部２２の連鎖トランザクションＩＤ管理部２２０が管理する。
【００８０】
連鎖トランザクションＩＤは，固定部とカウンタ部からなる。固定部には，連鎖トランザクションが動作する最初のサーバを識別できる値が設定され，例えば，ＩＰアドレスなどが設定される。固定部は，サーバ識別番号でもよい。
【００８１】
カウンタ部は，連鎖トランザクションＩＤの取得の契機で１を加算する。そして，加算後に「固定部＋カウンタ部」で連鎖トランザクションＩＤとして管理する。上記ステップＳ１１の処理により，例えば，図８（Ａ）に示すように，連鎖トランザクションＩＤ「１９２．２３１．６．２．１」が連鎖トランザクション管理テーブル１０６に設定される。
【００８２】
ステップＳ２において，メッセージ１０４内に連鎖トランザクションＩＤがある場合には，アプリケーションの呼び出しを行い（ステップＳ３），連鎖トランザクション管理テーブル１０６の「処理種別」の項目に設定された処理を依頼する。すなわち，アプリケーションのプロセス１３に処理Ａを依頼する。アプリケーションのプロセス１３において処理Ａが行われ，アプリケーションのプロセス１３から復帰したならば，当該処理の結果をメッセージに設定する（ステップＳ４）。
【００８３】
例えば，サーバＡ１のアプリケーションのプロセス１３による処理Ａが正常に完了した場合には，図８（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６の処理Ａの「処理結果」の項目に「ＯＫ」が設定される。サーバＡ１による処理Ａの途中で異常が発生した場合には，「ＮＧ」が設定される。
【００８４】
なお，後述するように，例えば，アプリケーションのプロセス１３からのルーティングの追加／変更指示があった場合には，ステップＳ４において，連鎖トランザクション管理テーブル１０６の「処理種別」項目の設定内容を追加／変更することを通じて，ルーティング情報を追加／変更してもよい。
【００８５】
次に，処理結果がＯＫかを判断し（ステップＳ５），処理結果がＯＫである場合には，ＤＢＭＳ１４へコミット指示を行い（ステップＳ６），ステップＳ７へ進む。
【００８６】
ステップＳ７では，メッセージ１０４内に次の処理があるか，すなわち，連鎖トランザクション管理テーブル１０６に次に行う処理が設定されているかを判断する。
【００８７】
メッセージ１０４内に次の処理がある場合には，次の処理を行うサーバ宛てのメッセージ１０４を作成して（ステップＳ８），メッセージ送信部１２に対してメッセージ１０４を送信する（ステップＳ９）。
【００８８】
例えば，図８（Ｂ）に示す連鎖トランザクション管理テーブル１０６の設定内容から，サーバＡ１が処理Ａを処理した後にサーバＢ２が処理Ｂを処理することがわかるため，トランザクション制御部１０のトランザクション管理部２２は，サーバＢ２宛てのメッセージをメッセージ送信部１２に送信する。メッセージ１０４を受信したサーバＢ２では処理Ｂが行われることになる。
【００８９】
ステップＳ９でメッセージ１０４を送信した後，メッセージ受信部１１の受信メッセージを削除して（ステップＳ１６），処理を終了する。
【００９０】
ステップＳ１６で受信メッセージを削除する理由は，以下のとおりである。本実施の形態におけるメッセージ受信部１１では，システム障害などによるサーバのダウン時に，メッセージが消失してしまわないようにメッセージキュー１１０を不揮発性の記憶媒体に保存し，メッセージが喪失しないように保証している。このメッセージ保証機構を連鎖トランザクションのメッセージ処理中における障害対策にも利用する。このため，ステップＳ１において，メッセージ受信部１１からトランザクション制御部１０がメッセージを受信しても，メッセージキュー１１０において受信メッセージは削除しないで，受信済みにしておく。サーバにおける処理が完了したときに，受信メッセージを削除する（ステップＳ１６）。こうすることにより，サーバが障害でダウンし，その後に再起動したときに，サーバ内のメッセージ１０４の有無により，そのサーバでトランザクション処理の実施の有無を判断することができる。
【００９１】
ステップＳ７において，メッセージ１０４内に次の処理がない場合には，当該連鎖トランザクション処理に関与したサーバに対する結果メッセージを作成する（ステップＳ１４）。この場合の結果メッセージは，連鎖トランザクションのコミット指示を行うためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理が正常に完了した（ＯＫ）という情報とから構成される。そして，メッセージ送信部１２に対して結果メッセージを送信し（ステップＳ１５），処理済みの受信メッセージを削除し（ステップＳ１６），処理を終了する。
【００９２】
ステップＳ５において，当該処理の結果がＮＧの場合には，ＤＢＭＳ１４へロールバック指示を行い（ステップＳ１２），排他制御部２０へ排他解除依頼を行う（ステップＳ１３）。そして，当該連鎖トランザクション処理に関与したサーバに対する結果メッセージを作成する（ステップＳ１４）。
【００９３】
この場合の結果メッセージは，上記連鎖トランザクション処理に関与したサーバ内のデータベースの復旧を指示するためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生した（ＮＧ）という情報とから構成される。そして，メッセージ送信部１２に対してこの結果メッセージを送信し（ステップＳ１５），受信メッセージを削除して（ステップＳ１６），処理を終了する。
【００９４】
サーバＡ１における処理が正常に終了し，サーバＢ２へメッセージ１０４が送信されて，同様にサーバＢ２内で処理Ｂがされた後に，上述したステップＳ７〜Ｓ９の処理により，連鎖トランザクション管理テーブル１０６の設定内容に従って，サーバＢ２からサーバＣ３にメッセージ１０４が送信されると，サーバＣ３において処理Ｃが行われる。そして，サーバＣ３における処理Ｃが正常に完了した後には，連鎖トランザクション管理テーブル１０６は，例えば図９（Ａ）に示すような内容が設定されている。
【００９５】
そこで，サーバＣ３のトランザクション管理部２２は，上記図９（Ａ）に示す連鎖トランザクション管理テーブル１０６を参照して，次の処理がないこと，すなわち，自サーバが最終に処理を行ったサーバであることを確認すると，連鎖トランザクション管理テーブル１０６において自サーバより前に処理を行ったサーバとして記録されているサーバＢ２とサーバＡ１に対して結果メッセージを送信してコミット指示を出す。
【００９６】
例えば，サーバＡ１，サーバＢ２，サーバＣ３の順に各サーバに割り当てられた処理を行ってきた場合，サーバＣ３における処理結果がＮＧであると，図９（Ｂ）に示すように，連鎖トランザクション管理テーブル１０６の処理Ｃの「処理結果」の項目に「ＮＧ」が設定されている。
【００９７】
この場合，サーバＣ３のトランザクション管理部２２は，ＤＢＭＳ１４へロールバック指示をするとともに，排他制御部２０へ排他解除依頼をする。そして，図９（Ｂ）に示す連鎖トランザクション管理テーブル１０６を参照して，自サーバの前に処理を行ったサーバＢ２とサーバＡ１宛てにデータベースの復旧を指示するための結果メッセージを送信する。
【００９８】
次に，トランザクション制御部１０の排他制御処理について説明する。本実施の形態における排他制御処理は，アプリケーションのプロセス１３と同一プロセスで実行してもよいし，排他制御処理自体を独立したサーバ（排他専用サーバ）で行ってもよい。
【００９９】
本処理の入力情報は，例えば，排他要求の項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤである。排他制御部２０が管理する排他情報が格納される排他情報テーブル１４１の一例を図１０に示す。
【０１００】
図１０に示すように，排他情報は，例えば，項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤの組の情報から構成される。排他情報の項目名は，ＤＢＭＳにおけるアクセスの排他制御単位となるデータを識別するものであり，レコード単位で排他制御が行われる場合には，レコード識別子（レコード番号等）のようなものでもよい。
【０１０１】
図１１（Ａ）は，排他獲得時のトランザクション制御部１０の動作処理フローの一例を示す図である。排他獲得要求時の入力情報は，排他情報テーブル１４１における排他情報と同じ，排他要求の項目名，アクセスモード（参照または更新），連鎖トランザクションＩＤである。排他獲得要求に対し，排他制御部２０は，排他情報テーブル１４１の検索を行い（ステップＳ２１），同じ項目名の排他情報があるか否かを調べる（ステップＳ２２）。該当する排他情報がなければ，排他情報テーブル１４１の空きエントリに，入力情報の排他情報を設定して管理し（ステップＳ２５），排他獲得処理を終了する。
【０１０２】
ステップＳ２２の判定において，同じ項目名の排他情報があれば，排他的なアクセスモードかを判断する（ステップＳ２３）。入力情報のアクセスモードと，排他情報テーブル１４１中の排他情報のアクセスモードの少なくともいずれかが，「更新」であれば排他的なアクセスモードと判断し，両方とも「参照」の場合には，排他的なアクセスモードではないと判断する。
【０１０３】
排他的なアクセスモードでなければ，ステップＳ２１へ戻り，他の該当する排他情報の検索を続ける。排他的なアクセスモードであれば，排他解除通知が来るまで，排他待ちを行い（ステップＳ２４），ステップＳ２１へ戻る。
【０１０４】
図１１（Ｂ）は，排他解除時のトランザクション制御部１０の動作処理フローを示す図である。排他解除のときの入力情報は，連鎖トランザクションＩＤである。排他解除時には，排他制御部２０は，連鎖トランザクションＩＤをキーに排他情報テーブル１４１の検索を行う（ステップＳ３１）。入力情報と同じ連鎖トランザクションＩＤの排他情報がない場合，排他解除処理を終了する（ステップＳ３２）。同じ連鎖トランザクションＩＤの排他情報がある場合には，その排他情報を排他情報テーブル１４１から削除し（ステップＳ３３），排他待ち相手に排他解除通知を行う（ステップＳ３４）。その後，ステップＳ３１へ戻ってすべての該当する排他情報を削除するまで処理を繰り返す。
【０１０５】
次に，トランザクション制御部１０のログ制御処理について説明する。ログ制御処理では，ログデータの管理および管理したログデータに基づくＤＢ１４０の復旧を行う。前述したように，ログ（更新前データ）を管理するログファイル１４２は，更新するＤＢ１４０と同一ＤＢＭＳ１４上に事前に作成し，ログは不揮発データとして管理する。
【０１０６】
本処理の入力情報は，連鎖トランザクションＩＤ，更新前データの位置情報を一意に識別する項目名，ログデータ，処理要求（ログ書出し／ログ削除／ＤＢ復旧）である。また，ログファイル１４２上では，図１２に示すように，連鎖トランザクションＩＤ，項目名，ログデータが管理される。
【０１０７】
図１３（Ａ）は，トランザクション制御部１０のログ制御部２１によるログ書出し処理フローの一例を示す図である。ログ制御部２１は，ログ書出し要求に対して，まず，ログデータの組み立てを行い（ステップＳ４１），ＤＢＭＳ１４へ書き込み依頼を行って（ステップＳ４２），処理を終了する。
【０１０８】
図１３（Ｂ）は，トランザクション制御部１０のログ制御部２１によるログ削除処理フローの一例を示す図である。ログ制御部２１は，ログ削除要求に対して削除データの組み立てを行い（ステップＳ５１），ＤＢＭＳ１４へ削除依頼を行って（ステップＳ５２），処理を終了する。
【０１０９】
図１４は，ＤＢの復旧時のトランザクション制御部１０のログ制御部２１によるＤＢ復旧処理フローの一例を示す図である。ＤＢ復旧時の入力情報は，連鎖トランザクションＩＤである。
【０１１０】
ログ制御部２１は，連鎖トランザクションＩＤの入力によるＤＢ復旧依頼に対し，入力した連鎖トランザクションＩＤをキーとしてログデータの検索をＤＢＭＳ１４へ依頼する（ステップＳ６１）。該当するログデータがない場合には（ステップＳ６２），処理を終了する。
【０１１１】
該当するログデータがあった場合，ログデータからＤＢＭＳ１４のアクセス命令の組み立てを行い（ステップＳ６３），ＤＢＭＳ１４へ書き込み依頼を行う（ステップＳ６４）。この処理によりＤＢ１４０が連鎖トランザクションによる更新前の状態に復旧される。その後，ＤＢＭＳ１４へログデータの削除依頼を行って（ステップＳ６５），ステップＳ６１へ戻る。該当するすべてのログデータについて同様に処理を繰り返す。
【０１１２】
次に，トランザクション制御部１０のメッセージルーティング制御について説明する。このメッセージルーティング制御は，アプリケーションのプロセス１３からのルーティングの追加／変更指示を受けて，トランザクション制御部１０内のメッセージルーティング制御部２２４が行う。
【０１１３】
図１５は，メッセージルーティング制御処理フローの一例を示す図である。まず，アプリケーションのプロセス１３からＡＰＩで受け取ったルーティングの追加／変更指示情報の解析を行う（ステップＳ７１）。解析結果に基づき，メッセージの連鎖トランザクション管理テーブル１０６にルーティング情報を設定して（ステップＳ７２），処理を終了する。例えば，図１６（Ｂ）に示すアプリケーションからの指示を解析して，「次の処理Ｂ（サーバＢ）の情報を設定」というルーティングの追加指示情報を得たとする。この場合，ステップＳ７２では，図１６（Ａ）に示す連鎖トランザクション管理テーブル１０６の「処理種別」の項目に，「処理Ｂ（サーバＢ）」という情報を追加設定する。
【０１１４】
図１７は，トランザクション制御部１０による連鎖トランザクションのコミット処理フローまたはＤＢの復旧処理フローの一例を示す図である。他のサーバから連鎖トランザクションの結果メッセージを受信すると（ステップＳ８１），その結果メッセージから処理が正常に完了した旨を通知する正常終了通知（ＯＫ）か異常終了通知（ＮＧ）かを判定する（ステップＳ８２）。正常終了通知である場合には，連鎖トランザクションのコミット指示がなされたことを意味するので，結果メッセージ中の連鎖トランザクションＩＤを指定してログ制御部２１へログデータの削除依頼を行い（ステップＳ８３），その後，排他制御部２０へ排他解除依頼を行って（ステップＳ８４），処理を終了する。
【０１１５】
ステップＳ８２の判定において，正常終了通知でなく，処理結果が「ＮＧ」である旨の通知であることがわかった場合には，結果メッセージ中の連鎖トランザクションＩＤを指定してログ制御部２１へＤＢ復旧依頼を行い，（ステップＳ８５），その後に排他制御部２０へ排他解除を依頼し（ステップＳ８４），処理を終了する。
【０１１６】
次に，統一データアクセス制御について説明する。本処理の入力情報は，アクセスする項目名，アクセス要求（参照または更新），更新データ（更新時）である。また，出力情報は，読込みデータ（読込み要求時）である。
【０１１７】
図１８は，統一データアクセス部１０１の統一データアクセス制御処理フローの一例を示す図である。まず，排他獲得要求で排他制御部２０の排他制御処理の呼び出しを行う（ステップＳ９１）。次に，アプリケーションのプロセス１３からのアクセス要求項目より，ＤＢＭＳ１４のアクセス命令の組み立てを行い（ステップＳ９２），ＤＢＭＳ１４へ組み立てたアクセス命令を発行し，該当レコードの読込みを行う（ステップＳ９３）。アプリケーションからのアクセス要求が参照（読込み要求）の場合，読み込んだレコードは，出力情報としての読込みデータとなる。アクセス要求が更新（書出し要求）の場合，読み込んだレコードは，更新前データとしてログする。
【０１１８】
そのため，アクセス要求がデータの書出し要求か読込み要求かを判定する（ステップＳ９４）。データの書出し要求である場合には，ログ書出し要求でログ制御処理の呼び出しを行い，ステップＳ９３で読み込んだデータをログ制御部２１を呼び出してログファイル１４２に記録し（ステップＳ９５），また，ＤＢＭＳ１４へ更新データの書込みを依頼して（ステップＳ９６），処理を終了する。また，アクセス要求がデータの読込み要求の場合には，読込みデータをアクセス要求元のアプリケーションへ渡す復帰情報に設定して（ステップＳ９７），処理を終了する。
【０１１９】
図１９は，ローカルトランザクションをコミットする場合の各サーバ内での動作シーケンスの一例を示す。ここでは，サーバＡ１内の動作処理を例にして，図１９に示すシーケンスａ〜ｎに従って説明する。
【０１２０】
（ａ）トランザクション制御部１０が，メッセージ受信部１１にメッセージ受信を要求し，メッセージ受信部１１からメッセージ１０４を受信する。
【０１２１】
（ｂ）受信したメッセージ１０４中の連鎖トランザクション管理テーブル１０６に連鎖トランザクションＩＤを設定して，ローカルトランザクション（ＤＢトランザクション）の開始を宣言する。なお，受信したメッセージ１０４中にトランザクション管理テーブル１０６が付加されていない場合には，連鎖トランザクション管理テーブル１０６を付加した後に，連鎖トランザクションＩＤを設定する。
【０１２２】
（ｃ）アプリケーションを呼び出し，アプリケーションのプロセス１３においてメッセージ１０４で要求された処理を開始する。
【０１２３】
（ｄ）アプリケーションのプロセス１３がＤＢ１４０のデータを更新する場合，統一データアクセス部１０１にＤＢ１４０の更新要求を行う。
【０１２４】
（ｅ）統一データアクセス部１０１は，トランザクション制御部１０に排他獲得およびログ要求を行う。
【０１２５】
（ｆ）〜（ｈ）この要求に対して，トランザクション制御部１０は，排他情報テーブル１４１に該当する更新データの排他情報がないことを確認して，排他情報テーブル１４１に排他情報を設定する。また，トランザクション制御部１０は，ＤＢ１４０から更新前データを読み込み，ログファイル１４２に更新前データのログを書き出す。その後に，トランザクション制御部１０は，統一データアクセス部１０１に排他／ログ終了を通知する。
【０１２６】
（ｉ）統一データアクセス部１０１は，排他／ログ終了通知を受け付けると，ＳＱＬ文を発行するなどしてＤＢ１４０を更新する。
【０１２７】
（ｊ）アプリケーションのプロセス１３は，ローカルトランザクションの処理を完了する前に，連鎖トランザクション管理テーブル１０６におけるルーティング情報の追加／変更指示をトランザクション制御部１０へ通知する。この指示に従って，トランザクション制御部１０は，連鎖トランザクション管理テーブル１０６のルーティング情報を追加／変更する。
【０１２８】
（ｋ）アプリケーションの処理を終了し，トランザクション制御部１０に復帰する。
【０１２９】
（ｌ）トランザクション制御部１０は，アプリケーションから復帰した後，アプリケーションの処理結果を連鎖トランザクション管理テーブル１０６に設定する。
【０１３０】
（ｍ）設定された処理結果が「ＯＫ」の場合，トランザクション制御部１０は，ＤＢＭＳ１４に対してローカルトランザクションのコミット指示を出す。
【０１３１】
（ｎ）トランザクション制御部１０は，連鎖トランザクション管理テーブル１０６の設定内容に基づいて，次の処理を行うサーバへメッセージを送信することをメッセージ送信部１２に指示する。自サーバが最終のトランザクション処理を行ったサーバである場合には，自サーバの前に処理を行ったすべてのサーバに連鎖トランザクションのコミット指示をする結果メッセージを送信する。
【０１３２】
図２０は，連鎖トランザクションをコミットする場合の各サーバ内での動作シーケンスの一例を示す図である。以下の（ａ’）および（ｂ’）の処理は，アプリケーションの処理とは非同期に行われる。
【０１３３】
（ａ’）トランザクション制御部１０は，連鎖トランザクションのコミットを指示する結果メッセージを受信する。
【０１３４】
（ｂ’）トランザクション制御部１０は，コミットを指示する結果メッセージの受信により，ログファイル１４２から該当する連鎖トランザクションのログデータを削除し，排他情報テーブル１４１から該当する連鎖トランザクションの排他情報を削除する。
【０１３５】
次に，本発明の実施の形態において，連鎖トランザクション処理中にサーバがダウンし，その後にサーバが再起動したときの処理について説明する。連鎖トランザクション処理中にサーバがダウンした場合には，処理の実行状態によりその後の振る舞い（処理継続／ロールバック）が異なる。例えば，サーバＡ１，Ｂ２，Ｃ３と処理を行う連鎖トランザクションにおいて，サーバＣ３の処理を実施中に，サーバＢ２がダウンしたとする。
【０１３６】
この場合には，サーバＢ２の処理は完結しているため，サーバＢ２では再起動後に結果メッセージの到着を待ち，その結果メッセージの指示（ＯＫ／ＮＧ）に従う。
【０１３７】
サーバＣ３がダウンした場合には，ダウン時にサーバＣ３で処理が行われていたか否かにより，その後の振る舞いが異なる。例えば，メッセージ受信部１１にメッセージ１０４があるが，一切処理を行っていない状態でダウンした場合には，サーバＣ３は，ダウン後のシステム再起動後に，引き続きそのメッセージ１０４に従った処理を実施すればよく，サーバＣ３で処理中にダウンした場合には，処理中であったトランザクションのリカバリ処理が必要となる。
【０１３８】
ダウン時に処理中であったか否かを判断するため，連鎖トランザクションＩＤで排他情報テーブル１４１を検索し，当該連鎖トランザクションＩＤの排他情報があれば，処理中にダウンしたと判断して，一旦サーバＣ３で実施した処理をロールバック（ログデータからＤＢ復旧）する。
【０１３９】
このとき，連鎖トランザクション自体をロールバックするか否かは，いずれでも構わない。連鎖トランザクション自体をロールバックする場合には，連鎖トランザクション処理に関与したサーバに対して，処理途中で異常が発生（ダウン）し，処理結果が「ＮＧ」であることを示す結果メッセージを送信すればよい。また，処理を継続する場合には，再度メッセージを読み込み，その処理を実行すればよい。ここまでの処理をダウン後の再起動時の初期処理で実施する。
【０１４０】
図２１は，連鎖トランザクションの処理中にサーバがダウンし，ダウン後に再起動した時のサーバにおける初期処理のフローの一例を示す図である。
【０１４１】
まず，メッセージ受信部１１よりメッセージを受信する（ステップＳ１１１）。そして，メッセージ受信部１１にメッセージがあるかを判断する（ステップＳ１１２）。メッセージがない場合には，処理を終了する。メッセージがある場合には，結果メッセージかを判断する（ステップＳ１１３）。
【０１４２】
結果メッセージである場合には，ステップＳ１１１へ戻り，メッセージ受信部１１からの次のメッセージの受信処理を行う。結果メッセージではなく，連鎖トランザクションの処理要求のメッセージ１０４である場合には，排他情報テーブル１４１を，メッセージ１０４中の連鎖トランザクションＩＤで検索し（ステップＳ１１４），排他情報があるかを判断する（ステップＳ１１５）。
【０１４３】
排他情報がない場合には，このサーバは処理を実施していない状態でダウンしたことになるので，ステップＳ１１１へ戻る。
【０１４４】
排他情報がある場合には，ダウン時に処理中であったことになるので，ログ制御部２１へＤＢ復旧依頼を行い（ステップＳ１１６），排他制御部２０へ排他解除依頼をする（ステップＳ１１７）。
【０１４５】
続いて，当該連鎖トランザクション処理に関与したサーバに対する結果（ＮＧ）メッセージを作成する（ステップＳ１１８）。この場合の結果メッセージは，当該連鎖トランザクション処理に関与したサーバ内のデータベースの復旧を指示し，連鎖トランザクションのロールバックを行うためのものであり，連鎖トランザクションＩＤの情報と自サーバにおける処理途中で異常が発生（ダウン）した（ＮＧ）という情報とから構成される。メッセージ送信部１２に対してこの結果メッセージを送信し（ステップＳ１１９），受信メッセージを削除して（ステップＳ１２０），ステップＳ１１１へ戻る。
【０１４６】
メッセージ受信部１１が受信済みのすべてのメッセージについて，以上の処理を行った後（ステップＳ１１２），再起動後の初期処理を終了する。その後，図５に示した通常のトランザクション管理処理を行う。このとき，図２１の初期処理でトランザクション制御部１０がメッセージ受信部１１から受信し処理したメッセージについては，ステップＳ１２０で削除したものを除き，受信済みとしないで，再度受信対象とし，各々のメッセージ１０４について処理を行う。
【０１４７】
以上説明した仕組みにより，複数サーバに跨ったデータ処理の一貫性／整合性を保証しつつ，システム全体のスループットとトランザクション処理のレスポンスの向上が図られる。
【０１４８】
以上の本発明による連鎖トランザクションの処理は，各サーバのコンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【０１４９】
以上から把握できるように，本発明の実施形態の特徴を述べると，以下のとおりである。
【０１５０】
（付記１）複数のサーバによってトランザクションを処理するトランザクション処理方法において，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，
前記複数のサーバは，各サーバ毎に，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する
ことを特徴とするトランザクション処理方法。
【０１５１】
（付記２）付記１記載のトランザクション処理方法において，
前記第２のトランザクションの処理では，当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行うとともに，当該第２のトランザクション内で更新されるデータの更新前データを保存し，
前記第１のトランザクションの処理が正常終了した場合に，前記記録した排他情報および前記保存した更新前データを廃棄し，
前記第１のトランザクションの処理が異常終了した場合に，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄する
ことを特徴とするトランザクション処理方法。
【０１５２】
（付記３）付記２記載のトランザクション処理方法において，
前記第１のトランザクションに，システム内で一意にトランザクションを識別するための連鎖トランザクション識別子を付与し，
前記連鎖トランザクション識別子と，各サーバにおける処理および処理結果の組の情報とをサーバ間のメッセージに付加してメッセージ通信を行うことにより，前記第１のトランザクションを，前記第２のトランザクションの連鎖で処理する
ことを特徴とするトランザクション処理方法。
【０１５３】
（付記４）付記３記載のトランザクション処理方法において，
前記第１のトランザクションの処理が正常終了した場合に，連鎖する第２のトランザクションのうち最後のトランザクションを処理したサーバが，前記第１のトランザクションの処理に係る各サーバに対して，前記記録した排他情報および前記保存した更新前データを廃棄するように通信を行う
ことを特徴とするトランザクション処理方法。
【０１５４】
（付記５）付記３記載のトランザクション処理方法において，
前記第１のトランザクションの処理が異常終了した場合に，連鎖する第２のトランザクションのうち異常終了したトランザクションを処理したサーバが，前記第１のトランザクションの処理に係る各サーバに対して，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するように通信を行う
ことを特徴とするトランザクション処理方法。
【０１５５】
（付記６）複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するためのトランザクション制御装置であって，
他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放するトランザクション管理手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを保存し，前記第１のトランザクションの処理が正常終了した場合に，前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段とを備える
ことを特徴とするトランザクション制御装置。
【０１５６】
（付記７）複数のサーバによってトランザクションを処理するトランザクション処理方法を，各サーバが備えるコンピュータに実行させるためのトランザクション制御プログラムであって，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する処理を，
コンピュータに実行させるためのトランザクション制御プログラム。
【０１５７】
（付記８）複数のサーバによってトランザクションを処理するトランザクション処理方法を，各サーバが備えるコンピュータに実行させるためのトランザクション制御プログラムを記録したコンピュータ読取り可能な記録媒体であって，
複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放する処理を，
コンピュータに実行させるためのプログラムを記録した
ことを特徴とするトランザクション制御プログラムの記録媒体。
【０１５８】
【発明の効果】
本発明によれば，連鎖トランザクションに関与したサーバ間の一連の処理の同期が不要となり，各サーバのデータベースアクセス処理が非同期に動作することで，同時実行多重度が上がり，システム全体のトランザクションのスループットが向上する。
【０１５９】
また，本発明によれば，トランザクションがコミットするまでの通信回数を従来技術より大幅に減少させることができるため，分散トランザクション処理における，トランザクションのレスポンスを向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるシステム構成の一例を示す図である。
【図２】本発明による効果を従来技術と比較して説明する図である。
【図３】本発明の実施の形態におけるシステム構成の詳細を示す図である。
【図４】本発明の実施の形態におけるメッセージの形式を示す図である。
【図５】トランザクション制御部のトランザクション管理処理フローの一例を示す図である。
【図６】連鎖トランザクション管理テーブルの一例を示す図である。
【図７】連鎖トランザクション取得用テーブルの一例を示す図である。
【図８】連鎖トランザクション管理テーブルの一例を示す図である。
【図９】連鎖トランザクション管理テーブルの一例を示す図である。
【図１０】排他情報テーブルの一例を示す図である。
【図１１】トランザクション制御部の排他制御部による処理フローの一例を示す図である。
【図１２】ログファイルの一例を示す図である。
【図１３】ログ書出し処理およびログ削除処理フローの一例を示す図である。
【図１４】ログ制御部によるＤＢ復旧処理フローの一例を示す図である。
【図１５】メッセージルーティング制御処理フローの一例を示す図である。
【図１６】ルーティングの追加／変更処理の一例を示す図である。
【図１７】連鎖トランザクションのコミット処理フローまたはＤＢの復旧処理フローの一例を示す図である。
【図１８】統一データアクセス制御処理フローの一例を示す図である。
【図１９】各サーバ内での動作シーケンスの一例を示す図である。
【図２０】各サーバ内での動作シーケンスの一例を示す図である。
【図２１】ダウン後に再起動した時のサーバにおける初期処理のフローの一例を示す図である。
【図２２】従来の分散トランザクション技術を示す図である。
【符号の説明】
１ サーバＡ
２ サーバＢ
３ サーバＣ
１０ トランザクション制御部
１１ メッセージ受信部
１２ メッセージ送信部
１３，１５，１７ アプリケーションのプロセス
１４，１６，１８ ＤＢＭＳ
２０ 排他制御部
２１ ログ制御部
２２ トランザクション管理部
１０１ 統一データアクセス部
１０４ メッセージ
１０５ 出力事象
１０６ 連鎖トランザクション管理テーブル
１１０ メッセージキュー
１３０，１５０，１７０，５０１，５０２，５０３ ローカルトランザクション
１４０，１６０，１８０，４１２，４１４，４１６ データベース（ＤＢ）
１４１ 排他情報テーブル
１４２ ログファイル
２２０ 連鎖トランザクションＩＤ管理部
２２１ アプリケーションスケジュール部
２２２ 排他制御／ログ制御スケジュール部
２２３ ＤＢＭＳアクセス制御部
２２４ メッセージルーティング制御部
２２５ メッセージ送受信部
４００〜４０３ サーバ
４１０，４１１，４１３，４１５ 実行プロセス
５００ グローバルトランザクション
Claims (3)
- 複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するための，メッセージ受信手段と，メッセージ送信手段と，トランザクション管理手段と，排他制御手段と，ログ制御手段とを備える前記サーバが実行するトランザクション処理方法であって，
前記メッセージ受信手段が，各サーバにおける処理を特定する処理種別情報とその処理結果の組の情報が設定される管理部が付加されたメッセージを受信する過程と，
前記トランザクション管理手段が，前記メッセージ受信手段により受信したメッセージにシステム内で一意に第１のトランザクションを識別するための連鎖トランザクション識別子が設定されていない場合には新しい連鎖トランザクション識別子を付与して前記メッセージ内の管理部に設定し，前記メッセージの処理種別情報で指定された処理を第２のトランザクションとして処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放し，前記メッセージ内に未処理の処理種別情報がある場合に，その未処理の処理種別情報によって特定されるサーバに対するトランザクションの処理を要求する前記連鎖トランザクション識別子を含むメッセージを作成し，前記メッセージ内に未処理の処理種別情報がない場合または前記第２のトランザクションの処理結果が異常であった場合に，当該第１のトランザクションに関与したすべてのサーバに対する処理結果の正常または異常を示す結果メッセージを作成する過程と，
前記メッセージ送信手段が，前記トランザクション管理手段が作成したメッセージまたは結果メッセージを送信する過程と，
前記排他制御手段が，前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を前記連鎖トランザクション識別子と共に記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記連鎖トランザクション識別子に基づいて前記記録した排他情報を廃棄し排他制御を解除する過程と，
前記ログ制御手段が，前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを前記連鎖トランザクション識別子と共に保存し，前記第１のトランザクションの処理が正常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄する過程とを有する
ことを特徴とするトランザクション処理方法。 - 複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するためのトランザクション制御装置であって，
各サーバにおける処理を特定する処理種別情報とその処理結果の組の情報が設定される管理部が付加されたメッセージを受信するメッセージ受信手段と，
前記メッセージ受信手段が受信したメッセージにシステム内で一意に第１のトランザクションを識別するための連鎖トランザクション識別子が設定されていない場合には新しい連鎖トランザクション識別子を付与して前記メッセージ内の管理部に設定し，前記メッセージの処理種別情報で指定された処理を第２のトランザクションとして処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放し，前記メッセージ内に未処理の処理種別情報がある場合に，その未処理の処理種別情報によって特定されるサーバに対するトランザクションの処理を要求する前記連鎖トランザクション識別子を含むメッセージを作成し，前記メッセージ内に未処理の処理種別情報がない場合または前記第２のトランザクションの処理結果が異常であった場合に，当該第１のトランザクションに関与したすべてのサーバに対する処理結果の正常または異常を示す結果メッセージを作成するトランザクション管理手段と，
前記トランザクション管理手段が作成したメッセージまたは結果メッセージを送信する前記メッセージ送信手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を前記連鎖トランザクション識別子と共に記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記連鎖トランザクション識別子に基づいて前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを前記連鎖トランザクション識別子と共に保存し，前記第１のトランザクションの処理が正常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段とを備える
ことを特徴とするトランザクション制御装置。 - 複数のサーバによってトランザクションを処理するトランザクション処理システムにおけるサーバにおいて，複数のサーバに分散されたデータベースを扱う第１のトランザクションを，各サーバがそれぞれのサーバ内で個別に処理する第２のトランザクションの連鎖で処理するための，各サーバが備えるコンピュータに実行させるトランザクション制御プログラムであって，
前記コンピュータを，
各サーバにおける処理を特定する処理種別情報とその処理結果の組の情報が設定される管理部が付加されたメッセージを受信するメッセージ受信手段と，
前記メッセージ受信手段が受信したメッセージにシステム内で一意に第１のトランザクションを識別するための連鎖トランザクション識別子が設定されていない場合には新しい連鎖トランザクション識別子を付与して前記メッセージ内の管理部に設定し，前記メッセージの処理種別情報で指定された処理を第２のトランザクションとして処理し，他のサーバにおけるトランザクション処理の完了同期を待ち合わせずに，自サーバにおける前記第２のトランザクションの処理が完了した時点で，前記第２のトランザクションを処理するプロセスの実行権を開放し，前記メッセージ内に未処理の処理種別情報がある場合に，その未処理の処理種別情報によって特定されるサーバに対するトランザクションの処理を要求する前記連鎖トランザクション識別子を含むメッセージを作成し，前記メッセージ内に未処理の処理種別情報がない場合または前記第２のトランザクションの処理結果が異常であった場合に，当該第１のトランザクションに関与したすべてのサーバに対する処理結果の正常または異常を示す結果メッセージを作成するトランザクション管理手段と，
前記トランザクション管理手段が作成したメッセージまたは結果メッセージを送信する前記メッセージ送信手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内でアクセスされるデータベースのデータに対する排他情報を前記連鎖トランザクション識別子と共に記録し，他の第２のトランザクションとの間でそのデータに対する排他制御を行い，前記第１のトランザクションの処理が完了したときに前記連鎖トランザクション識別子に基づいて前記記録した排他情報を廃棄し排他制御を解除する排他制御手段と，
前記第２のトランザクションの処理において当該第２のトランザクション内で更新されるデータの更新前データを前記連鎖トランザクション識別子と共に保存し，前記第１のトランザクションの処理が正常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データを廃棄し，前記第１のトランザクションの処理が異常終了した場合に，その連鎖トランザクション識別子に対応する前記保存した更新前データに基づいて前記データベースを復旧し，その後に前記記録した排他情報および前記保存した更新前データを廃棄するログ制御手段として，
機能させるためのトランザクション制御プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189312A JP4291060B2 (ja) | 2003-07-01 | 2003-07-01 | トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム |
| US10/850,699 US7328213B2 (en) | 2003-07-01 | 2004-05-21 | Transaction processing method, transaction control apparatus and program thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189312A JP4291060B2 (ja) | 2003-07-01 | 2003-07-01 | トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005025432A JP2005025432A (ja) | 2005-01-27 |
| JP4291060B2 true JP4291060B2 (ja) | 2009-07-08 |
Family
ID=33549779
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003189312A Expired - Fee Related JP4291060B2 (ja) | 2003-07-01 | 2003-07-01 | トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7328213B2 (ja) |
| JP (1) | JP4291060B2 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7290015B1 (en) * | 2003-10-02 | 2007-10-30 | Progress Software Corporation | High availability via data services |
| JP4628830B2 (ja) * | 2005-03-17 | 2011-02-09 | 株式会社野村総合研究所 | Ｄｂｍｓに格納されたデータの整合性を担保するためのシステム |
| US7865684B2 (en) * | 2005-06-27 | 2011-01-04 | Ab Initio Technology Llc | Managing message queues |
| JP4677355B2 (ja) * | 2006-03-03 | 2011-04-27 | キヤノン株式会社 | Ｗｅｂサービス装置及び順次処理移譲方法 |
| US8190682B2 (en) * | 2006-03-31 | 2012-05-29 | Amazon Technologies, Inc. | Managing execution of programs by multiple computing systems |
| US7613814B2 (en) * | 2006-06-20 | 2009-11-03 | Microsoft Corporation | Discovering transactions silently propagated off-machine |
| US20080140734A1 (en) * | 2006-12-07 | 2008-06-12 | Robert Edward Wagner | Method for identifying logical data discrepancies between database replicas in a database cluster |
| US8126848B2 (en) * | 2006-12-07 | 2012-02-28 | Robert Edward Wagner | Automated method for identifying and repairing logical data discrepancies between database replicas in a database cluster |
| JP4877526B2 (ja) * | 2008-02-12 | 2012-02-15 | 日本電気株式会社 | クライアントサーバシステムおよびクライアントサーバシステムのデータ処理方法 |
| US10230611B2 (en) * | 2009-09-10 | 2019-03-12 | Cisco Technology, Inc. | Dynamic baseline determination for distributed business transaction |
| US8938533B1 (en) * | 2009-09-10 | 2015-01-20 | AppDynamics Inc. | Automatic capture of diagnostic data based on transaction behavior learning |
| US9167028B1 (en) * | 2009-09-10 | 2015-10-20 | AppDynamics, Inc. | Monitoring distributed web application transactions |
| JP5377672B2 (ja) * | 2010-02-15 | 2013-12-25 | 東芝ソリューション株式会社 | データベース管理システム |
| US9063969B2 (en) * | 2010-12-28 | 2015-06-23 | Sap Se | Distributed transaction management using optimization of local transactions |
| US9110851B2 (en) * | 2011-09-29 | 2015-08-18 | Oracle International Corporation | System and method for persisting transaction records in a transactional middleware machine environment |
| US9311598B1 (en) | 2012-02-02 | 2016-04-12 | AppDynamics, Inc. | Automatic capture of detailed analysis information for web application outliers with very low overhead |
| US9596294B2 (en) | 2012-05-11 | 2017-03-14 | Google Inc. | System and method for committing transactions on remote servers |
| JP2014085896A (ja) * | 2012-10-25 | 2014-05-12 | International Business Maschines Corporation | トランザクション処理方法、プログラム及びシステム |
| JP6064734B2 (ja) * | 2013-03-27 | 2017-01-25 | 富士通株式会社 | ワークフロー制御プログラム、装置および方法 |
| US9881044B2 (en) | 2013-12-31 | 2018-01-30 | Reduxio Systems Ltd. | Techniques for ensuring consistency of data updates transactions in a distributed storage system |
| JP6248747B2 (ja) * | 2014-03-28 | 2017-12-20 | 富士通株式会社 | 情報処理装置、制御方法および制御プログラム |
| US9535688B2 (en) * | 2014-07-23 | 2017-01-03 | Verizon Patent And Licensing Inc. | Efficient deployment of application revisions and implementation of application rollbacks across multiple application servers |
| US9811356B2 (en) | 2015-01-30 | 2017-11-07 | Appdynamics Llc | Automated software configuration management |
| JP6023858B1 (ja) | 2015-08-17 | 2016-11-09 | 日本電信電話株式会社 | 計算システム、計算装置、その方法、およびプログラム |
| US20170169425A1 (en) * | 2015-12-11 | 2017-06-15 | Paypal, Inc. | Selective encryption of transactional information for different participants of an electronic transaction |
| US10346420B2 (en) * | 2016-05-30 | 2019-07-09 | Sap Se | Database integration system |
| CN107679051B (zh) * | 2016-12-14 | 2019-02-01 | 平安科技（深圳）有限公司 | 交易***错误检测方法和装置 |
| CN110764933B (zh) * | 2019-10-23 | 2022-12-27 | 北京证大向上金融信息服务有限公司 | 一种消息处理方法、装置、***及计算设备 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3513550B2 (ja) | 1994-03-18 | 2004-03-31 | 富士通株式会社 | トランザクション続行方法およびそのためのリソースマネージャ |
| US6330582B1 (en) * | 1994-03-21 | 2001-12-11 | International Business Machines Corporation | Apparatus and method enabling a client to control transaction message traffic between server and client processes |
| US5978577A (en) * | 1995-03-17 | 1999-11-02 | Csg Systems, Inc. | Method and apparatus for transaction processing in a distributed database system |
| US5799305A (en) * | 1995-11-02 | 1998-08-25 | Informix Software, Inc. | Method of commitment in a distributed database transaction |
| GB2346985B (en) * | 1999-02-19 | 2003-07-09 | Ibm | Client/server transaction data processing system with optimum selection of last agent |
| US20020116205A1 (en) * | 2000-05-19 | 2002-08-22 | Ankireddipally Lakshmi Narasimha | Distributed transaction processing system |
| US7103586B2 (en) * | 2001-03-16 | 2006-09-05 | Gravic, Inc. | Collision avoidance in database replication systems |
| US7426730B2 (en) * | 2001-04-19 | 2008-09-16 | Wre-Hol Llc | Method and system for generalized and adaptive transaction processing between uniform information services and applications |
| US6816873B2 (en) * | 2001-05-15 | 2004-11-09 | International Business Machines Corporation | Method for managing distributed savepoints across multiple DBMS's within a distributed transaction |
| US7080119B2 (en) * | 2001-07-17 | 2006-07-18 | Bea Systems, Inc. | System and method for transaction processing with delegated commit feature |
| US7103597B2 (en) * | 2002-10-03 | 2006-09-05 | Mcgoveran David O | Adaptive transaction manager for complex transactions and business process |
| GB0302926D0 (en) * | 2003-02-08 | 2003-03-12 | Grex Games Ltd | System architecture and engine for massively multi-user operation |
| JP4117299B2 (ja) * | 2005-02-28 | 2008-07-16 | インターナショナル・ビジネス・マシーンズ・コーポレーション | サーバの多重度の上限値を制御するための方法、管理サーバ、サーバ、およびプログラム |
-
2003
- 2003-07-01 JP JP2003189312A patent/JP4291060B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-21 US US10/850,699 patent/US7328213B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7328213B2 (en) | 2008-02-05 |
| US20050004952A1 (en) | 2005-01-06 |
| JP2005025432A (ja) | 2005-01-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4291060B2 (ja) | トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム | |
| JP4594928B2 (ja) | フラッシュバックデータベース | |
| JP3779263B2 (ja) | 共同作業システムのためのコンフリクトの解決 | |
| WO2019154394A1 (zh) | 分布式数据库集群***、数据同步方法及存储介质 | |
| US5835915A (en) | Remote duplicate database facility with improved throughput and fault tolerance | |
| US5740433A (en) | Remote duplicate database facility with improved throughput and fault tolerance | |
| US7461103B2 (en) | System and method for reconciling transactions between a replication system and a recovered database | |
| JP5008991B2 (ja) | データのリカバリを制御する装置及び方法 | |
| CN101334797B (zh) | 一种分布式文件***及其数据块一致性管理的方法 | |
| CN101334778B (zh) | 管理数据库连接的方法和*** | |
| JP4621273B2 (ja) | データ同期方法、データ同期プログラム、データベースサーバ装置、および、データベースシステム | |
| JP4461147B2 (ja) | リモートデータミラーリングを用いたクラスタデータベース | |
| JP5467625B2 (ja) | トランザクションを処理する本番システムと該本番システムのバックアップ・システムである代行システムとを含む本番−代行システム | |
| JP2006202337A (ja) | データ処理の方法及び装置 | |
| US20060190460A1 (en) | Method and mechanism of handling reporting transactions in database systems | |
| US7290100B2 (en) | Computer system for managing data transfer between storage sub-systems | |
| US6330686B1 (en) | Handling protected conversation messages across IMS restart in shared queues environment | |
| US7072912B1 (en) | Identifying a common point in time across multiple logs | |
| US20090248760A1 (en) | Backup method of computer system | |
| US7406486B1 (en) | Transforming transactions to increase parallelism when replicating | |
| KR20180095004A (ko) | 고 쓰루풋, 고 신뢰성의 데이터 처리 시스템 | |
| JP2002297429A (ja) | 分散トランザクション処理システム、分散トランザクション処理方法及び分散トランザクション処理プログラム | |
| JP5480046B2 (ja) | 分散トランザクション処理システム、装置、方法およびプログラム | |
| JPH10289141A (ja) | マルチシステム環境のログ・ストリームを管理する方法 | |
| JPH08212119A (ja) | トランザクション処理システム及びトランザクションのコミット制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051026 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081127 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081209 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090209 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20090209 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090209 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090331 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090402 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120410 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120410 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130410 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140410 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |