JPH11161530A - トランザクション処理システム - Google Patents

Abstract

(57)【要約】 【課題】 複数のリソース間での分散デッドロックの発
生を回避することが可能なトランザクション処理システ
ムを提供する。 【解決手段】 遅延更新管理処理４３は、データベース
管理システムにトランザクション開始の宣言４３ａを行
い、未処理電文読込み４３ｂに移行する。この処理４３
ｂでは、仕向側データベース４５内の電文テーブル４９
にアクセスし、完了フラグが「未完了」の電文を検索し
未処理電文として読込む。該当する宛先への電文送信及
び結果受信４３ｃの処理では、上記読込んだ未処理電文
を「送信元」と「電文ＩＤ」と共に、宛先とサービス名
とに従って処理装置Ｆ側に送信する。振替入金５１での
処理結果が送信されるのを受信する。完了フラグを
「済」にするための更新４３ｄでは、処理４３ｃで受信
した該当電文に対する振替入金５１での処理結果を電文
テーブル４９の「完了フラグ」に書込む。正しく処理さ
れたときのみ「未完了」を「完了」に変更する。この処
理４３ｄが終了するとデータベース管理システムに、ト
ランザクション完了の宣言４３ｅを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、トランザクション
処理システムの改良に関するものである。以下、ユーザ
が銀行口座にオンラインで預金や振込等の取引を行う処
理を例にとり説明する。

【０００２】

【従来の技術】従来、複数の処理装置を備えるオンライ
ントランザクション処理システムにおいて、データベー
ス等のリソースを各処理装置に分散した環境で各処理装
置により分散処理されるトランザクションの整合性を保
障するために、図１に示す２フェーズ（２相）コミット
方式を採用したシステムが知られている。

【０００３】上記システムでは、システムを構成する複
数の端末（図示しない）のいずれかからトランザクショ
ンの要求が送信されると、それを複数の処理装置（符号
Ａ、Ｂで示す２台のみ図示）のうちの処理装置Ａが受付
ける。そして、一連の処理を実行すべく、処理装置Ａの
業務アプリケーション（業務ＡＰ）である振替支払処理
１と、処理装置Ｂの業務ＡＰである振替入金処理７とが
起動する。

【０００４】

【発明が解決しようとする課題】ところで、図１のシス
テムにおいては、トランザクションの原子性（トランザ
クションが分割できない１つの処理単位であるというこ
と）を保全するため、処理装置Ｂの処理が処理装置Ａの
延長で同一トランザクションとして実行される。換言す
れば、振替支払処理１がリソースマネージャ３から振替
支払用テーブル５にアクセス（矢印２）して行う一連の
処理と、振替入金処理７がリソースマネージャ９から振
替入金用テーブル１１にアクセス（矢印８）して行う一
連の処理とを、処理１から処理７への呼出し処理（矢印
６）により同期処理としている。

【０００５】このように、処理装置Ａ側の処理と処理装
置Ｂ側の処理とを同期処理としているので、処理装置Ａ
側での一連の処理と処理装置Ｂ側での一連の処理とが共
に完了するまでは、関連する全ての環境が上記各一連の
処理のために運用可能でなければならない。よって、処
理装置Ａ、Ｂは自己の処理を夫々独立して行うことがで
きない。そのため、処理装置Ａ、Ｂのいずれか一方での
処理が不適切であったときは、トランザクションの要求
を発した端末に対し、応答できないという問題が生じ
る。

【０００６】また、振替支払処理１と振替入金処理７と
を同期処理とするために必要なリソースマネージャ３、
９間の同期は、２相コミット方式により保障されてい
る。しかし、２相コミット方式では、コーディネータで
あるデータベース管理システム（ＤＢＭＳ）によって行
われる２相コミットメント処理が準備段階（仮更新）と
実施段階（実更新）との２相に分割される。

【０００７】そのため、トランザクションのコミットフ
ェーズ中に、トランザクションコーディネータ１０とリ
ソースマネージャ３及び９との間において夫々行われる
通信処理が、準備段階と実施段階とで各１往復ずつ、合
計２往復必要になる。また、各リソース（テーブル５、
１１等）で準備段階と実施段階とで各１回ずつ、合計２
回のディスクアクセスを行わなくてはならない。よっ
て、コミット処理の負荷が大きくなる。

【０００８】また、振替支払処理１がリソースマネージ
ャ３にアクセスするのみならず、振替入金処理７への呼
出し処理６によりリソースマネージャ９にもアクセスす
るため、リソースマネージャ３、９間で分散デッドロッ
クが発生する可能性があり、その場合はスループットが
低下する。分散デッドロックが発生するとスループット
が低下する理由は、以下のようである。即ち、２相コミ
ット方式では通常、分散デッドロックの検出にタイマを
用いるが、タイマによる分散デッドロックの検出には通
常数秒から数十秒もの時間（タイマが切れて分散デッド
ロックと見做されるまでに要する時間）を要する。ＯＬ
ＴＰシステムではデッドロックとなったリソースに対し
ては、デッドロックが解決されるまで他のトランザクシ
ョンからアクセスすることができない。よってこれが原
因でシステムのスループットが著しく低下することがあ
る。

【０００９】更に、分散デッドロックに陥ったトランザ
クションは、上記タイマが切れて分散デッドロックと見
做される上記数秒から数十秒が経過するまでの間、処理
を中断され、処理を完了させることができず、そのため
上記時間が経過するまでは端末に対して応答することが
できない。よって、分散デッドロック時のレスポンスが
遅いという問題もあった。

【００１０】従って、本発明の目的は、複数のリソース
間での分散デッドロックの発生を回避することが可能な
トランザクション処理システムを提供することにある。

【００１１】

【課題を解決するための手段】本発明の第１の側面に従
うトランザクション処理システムは、ネットワーク上の
複数のノードにサーバプロセスが分散されている環境に
おいて、各サーバプロセスが、夫々が存在するノード上
に置かれたリソースにのみアクセスする。

【００１２】上記構成によれば、各サーバプロセスが、
夫々が存在するノード上に置かれたリソースにのみアク
セスするため、同一のリソースに複数の処理装置上のサ
ーバプロセスが同時にアクセスすることがなく、そのた
め、分散デッドロックの発生を防止できる。

【００１３】本発明の第１の側面に係る好適な実施形態
では、サーバプロセスのうちの１つが、ネットワーク上
のクライアントから送出されるトランザクションの要求
を受けて所定の処理を実行し、他のサーバプロセスにト
ランザクションの要求を通知する。また、他のサーバプ
ロセスが、トランザクションの要求を通知したサーバプ
ロセスから独立して所定の処理を実行する。上述した１
つのサーバプロセスは、所定の処理が完了した時点で他
のサーバプロセスの処理結果如何に関わらず、処理結果
をクライアントに回答する。よって、クライアントへの
応答が大幅に遅延することがない。

【００１４】本発明の第２の側面に従うトランザクショ
ン処理システムは、ネットワーク上の複数のノードにサ
ーバプロセスが分散されている環境において、１つのサ
ーバプロセスがリソースにアクセスした後に、別のサー
バプロセスがリソースにアクセスするよう、各サーバプ
ロセスのリソースに対するアクセスを規制する手段を備
える。

【００１５】上記構成によれば、１つのサーバプロセス
がリソースにアクセスした後に、別のサーバプロセスが
リソースにアクセスするよう、各サーバプロセスのリソ
ースに対するアクセスを規制するので、仮に、複数のサ
ーバプロセスが同一のリソースにアクセスしようとして
も、規制手段によりアクセスが規制されるため、分散デ
ッドロックの発生を防止できる。

【００１６】本発明の第２の側面に係る好適な実施形態
では、サーバプロセスのうちの１つが、ネットワーク上
のクライアントから送出されるトランザクションの要求
を受けたとき、リソースにアクセスし処理結果をクライ
アントに回答する。また、規制手段は、任意のタイミン
グで、又は定期的に起動される。別のサーバプロセス
は、規制手段から上記１つのサーバプロセスにおける処
理結果の通知を受けたとき、リソースにアクセスする。

【００１７】また、上記実施形態では、各サーバプロセ
スが実行した処理結果が正常か否かを示すデータを保持
する手段を備える。規制手段は、各サーバプロセスが実
行した処理が正常か否かを判定して、その判定結果をデ
ータ保持手段に書込む。規制手段は、データ保持手段に
書込まれたデータから各サーバプロセスが実行した処理
結果中に正常でないものを見出したときに、対応するサ
ーバプロセスにその旨を再度通知する。

【００１８】また、規制手段は、システムエラーが生じ
たときは、そのエラーが解消した後に再起動するように
なっている。そのため、システム回復後は、必ず処理が
実行される。なお、リソースについては、各ノードに分
散されていても良いし、同一のノードに備えられていて
も差支えない。

【００１９】

【発明の実施の形態】以下、本発明の実施の形態を、図
面により詳細に説明する。

【００２０】図２は、本発明の一実施形態に係るトラン
ザクション処理システムを示すブロック図である。

【００２１】上記システムも、図１に示したシステムと
同様、複数の処理装置（符号Ｃ、Ｄで示す２台のみ図
示）と、オンラインを通じてこれらの処理装置Ｃ、Ｄに
接続される複数の端末（図示しない）とを備える。

【００２２】処理装置Ｃ、Ｄは、各々に分散して割当て
られたデータベース等のリソースを各処理装置Ｃ、Ｄに
おいて個別に処理（分散処理）すべく設置されるもので
ある。処理装置Ｃには、業務ＡＰとしてインストールさ
れる振替支払のための一連の処理（振替支払）２１と、
データベース中にリソースとして格納される振替支払用
テーブル２５と、この振替支払用テーブル２５を管理す
るためのリソースマネージャ２３とを備える。一方、処
理装置Ｄには、業務ＡＰとしてインストールされる振替
入金のための一連の処理（振替入金）２７と、データベ
ース中にリソースとして格納される振替入金用テーブル
３１と、この振替入金用テーブル３１を管理するための
リソースマネージャ２９とを備える。

【００２３】処理装置Ｃにおいて、振替支払２１は、ト
ランザクション開始の宣言２１ａと、振替支払処理２１
ｂと、振替入金処理用メッセージ送信２１ｃと、トラン
ザクション完了の宣言２１ｄの各処理を一連の処理とし
て含む。振替支払２１において、複数の端末（図示しな
い）のいずれかがトランザクションの要求をオンライン
で送信することにより、リソースマネージャ２３へのト
ランザクション開始の宣言２１ａを行う。次いで振替支
払処理２１ｂを実行するときに、矢印２２で示すように
リソースマネージャ２３を通じて振替支払用テーブル２
５にアクセスする。更に、支払処理２１ｂに続く振替入
金処理用メッセージ送信２１ｃを実行するときに、処理
装置Ｃから処理装置Ｄに対するメッセージ送信２６を行
う。

【００２４】一方、処理装置Ｄにおいて、振替入金２７
は、振替入金処理用メッセージ受信２７ａと、トランザ
クション開始の宣言２７ｂと、振替入金処理２７ｃと、
トランザクション完了の宣言２７ｄの各処理を一連の処
理として含む。振替入金２７は、振替入金処理用メッセ
ージ受信２７ａにおいて上記メッセージ送信２６により
処理装置Ｃから送信された振替入金処理用メッセージを
受信することによって起動する。しかし、本実施形態で
は、図１のシステムのように２相コミット方式を採用し
ていないため、トランザクション開始２７ｂに続く振替
入金処理２７ｃ以下の処理は、非同期処理で行われる。

【００２５】ここで、非同期処理とは、振替支払処理２
１ｃにおいて行うリソースマネージャ２３を通じた振替
支払用テーブル２５へのアクセス２２と、振替入金処理
２７において行うリソースマネージャ２９を通じた振替
支払用テーブル３１へのアクセス２８とが、非同期で行
われることをいう。

【００２６】換言すれば、メッセージ送信２６による処
理装置Ｄでの処理結果を、処理装置Ｃが受領すると否と
に関わらず、処理装置Ｃは処理装置Ｄから独立して振替
支払２１に規定された処理を続行し、他方、処理装置Ｄ
は処理装置Ｃから独立して振替入金２７に規定された処
理を続行する。

【００２７】従って、処理装置Ｃは、処理装置Ｄにおけ
る振替入金処理２７ｃの結果を受領しないときでも、振
替入金処理用メッセージ送信２１ｃの処理が終了すると
リソースマネージャ２３に対するトランザクション完了
の宣言２１ｄ以降の処理に移行する。一方、処理装置Ｄ
は、処理装置Ｃ側の処理とは全く無関係に任意のタイミ
ングで振替入金２７の処理を実行し、振替入金処理２７
ｃが完了した時点でタイミングを見計らって、その処理
結果を処理装置Ｃに通知し、リソースマネージャ２９に
対するトランザクション完了の宣言２７ｄ以降の処理に
移行する。

【００２８】上記システムでは、処理装置Ｃ側の業務Ａ
Ｐである振替支払２１は、処理装置Ｃ側のリソースであ
る振替支払用テーブル２５のみにリソースマネージャ２
３を通じて１相コミット方式でアクセスして振替支払２
１に規定された一連の処理を１つのトランザクションと
して逐次実行する。また、処理装置Ｄ側の業務ＡＰであ
る振替入金２７についても、処理装置Ｄ側のリソースで
ある振替入金用テーブル３１のみにリソースマネージャ
２９を通じて１相コミット方式でアクセスして振替入金
２７に規定された一連の処理を別のトランザクションと
して逐次実行する。そのため、図１のシステムのよう
に、振替支払２１と振替入金２７とを１つのトランザク
ションとして処理する必要がないので、振替支払２１が
振替入金２７を通じて処理装置Ｄ側のリソースである振
替入金用テーブル３１にアクセスすることがない。よっ
て、複数のリソース（この場合は、テーブル２５、３
１）間での分散デッドロックの発生を防止でき、分散デ
ッドロックが原因でシステムのスループットが低下する
ことが防止できる。

【００２９】また、振替支払２１が振替支払用テーブル
２５にアクセスして行う一連の処理と、振替入金２７が
振替入金用テーブル３１にアクセスして行う一連の処理
とは非同期であるため、処理装置Ｃ側のトランザクショ
ン処理については関連するリソースとして振替支払用テ
ーブル２５のみが運用中であれば良い。同様に、処理装
置Ｄ側のトランザクション処理については関連するリソ
ースとして振替入金用テーブル３１のみが運用中であれ
ば良いことになる。

【００３０】更に、上記システムでは、処理装置Ｃが行
う処理（この場合は、振替支払２１）と、処理装置Ｄが
行う処理（この場合は、振替入金２７）とが独立してい
るので、処理装置Ｃでの処理が終了した時点で、処理装
置Ｃから端末（図示しない）に応答できる。そのため、
端末への応答が遅れるのを防止できる。そして、処理装
置Ｄでの処理は、処理装置Ｃでの処理が終了した後の任
意のタイミングで実行することができる。よって、処理
装置Ｄでの処理を、例えば処理装置（Ｃ、Ｄ）の負荷が
低いときを見計らって行うことができるので、システム
を効率的に運用することが可能になる。

【００３１】図３は、本発明の一実施形態の変形例に係
るトランザクション処理システムのブロック図である。

【００３２】図３のシステムは、遅延更新処理方式を採
用したもので、内部的に振替支払処理（仕向側処理）と
振替入金処理（被仕向側処理）とに分かれる銀行の振替
処理に適用されている例を示す。

【００３３】図３において、複数の処理装置Ｅ、Ｆは、
各々が割当てられたリソースを分散処理する環境下に置
かれている。処理装置Ｅには、仕向側処理シーケンスを
実行するための適用業務ＡＰとして上記振替支払２１と
略同様の振替支払４１が、遅延更新管理処理シーケンス
を実行するための適用業務ＡＰとして遅延更新管理処理
４３が、仕向側処理のデータベースとして仕向側データ
ベース４５が、夫々備えられる。また、処理装置Ｆに
は、被仕向側処理シーケンスを実行するための適用業務
ＡＰとして上記振替入金２７と略同様の振替入金５１
が、被仕向側処理のデータベースとして被仕向側データ
ベース５３が、夫々備えられる。

【００３４】処理装置Ｅにおいて、振替支払４１は、ト
ランザクション開始の宣言４１ａと、振替支払処理４１
ｂと、電文挿入４１ｃと、トランザクション完了の宣言
４１ｄの各処理を一連の処理として含む。遅延更新管理
処理４３は、トランザクション開始の宣言４３ａと、未
処理電文読込み４３ｂと、該当する宛先への電文送信及
び結果受信４３ｃと、完了フラグを「済」にするための
更新４３ｄと、トランザクション完了の宣言４３ｄの各
処理を一連の処理として含む。仕向側データベース４５
は、データベース管理システム（図示しない）によって
管理されており、上述した振替支払用テーブル２５と同
様の振替支払用テーブル４７と、電文テーブル４９とを
備える。

【００３５】一方、処理装置Ｆにおいて、振替入金５１
は、トランザクション開始の宣言５１ａと、２重実行チ
ェック５１ｂと、振替入金処理５１ｃと、電文ＩＤ登録
５１ｄと、トランザクション完了の宣言５１ｅの各処理
を一連の処理として含む。被仕向側データベース５３
は、上述したデータベース管理システムとは別のデータ
ベース管理システム（図示しない）によって管理されて
おり、上述した振替入金用テーブル３１と同様の振替入
金用テーブル５５と、完了トランザクションテーブル５
７とを備える。

【００３６】次に、仕向側処理シーケンスを説明する。
仕向側処理シーケンスは、処理装置Ｅ側の適用業務ＡＰ
である振替支払４１によって実行されるシーケンスであ
る。

【００３７】まず、オンラインで接続される複数の端末
（図示しない）のうちのいずれかから、トランザクショ
ンの要求（メッセージ）が送信されると、それを処理装
置Ｅが受信し、振替支払４１が処理装置Ｅ側のデータベ
ース管理システム（図示しない）に対してトランザクシ
ョン開始の宣言４１ａを行う。

【００３８】次に、振替支払側（仕向側）の処理である
振替支払処理４１ｂに移行する。振替支払処理４１ｂで
は、矢印４２で示すようにデータベース管理システムを
通じて、仕向側データベース４５内の振替支払用テーブ
ル４７にアクセスし、振替支払処理４１ｂを行うのに必
要な各種データの検索や、振替支払処理４１ｂの結果得
られたデータによる従前のデータの更新処理を行う。こ
の処理に続いて電文挿入４１ｃに移行する。

【００３９】電文挿入４１ｃでは、矢印４４で示すよう
にデータベース管理システムを通じて、仕向側データベ
ース４５内の電文テーブル４９にアクセスし、電文テー
ブル４９に電文ＩＤや、宛先や、送信先サービス名や、
振替入金側（被仕向側）に送信したい電文や、完了フラ
グ「未完了」を挿入する処理を実行する。この電文挿入
４１ｃの処理が終了すると、振替支払４１は上述したデ
ータベース管理システム（図示しない）に対し、トラン
ザクション完了の宣言４１ｄを行う。

【００４０】ここで、上述した振替支払用テーブル４７
と電文テーブル４９とは、共に仕向側データベース４５
内に格納されているため、同一のデータベース管理シス
テム（図示しない）によって管理されるので、これらの
テーブル４７、４９は一括して確定される。つまり、振
替支払処理４１ｂが成功したときには、電文挿入４１ｃ
も必ず成功し、振替支払処理４１ｂが失敗したときに
は、電文挿入４１ｃも必ず失敗する。よって、電文テー
ブル４９に電文挿入４１ｃを行うのは、振替支払処理４
１ｂが成功して他の処理装置、即ち、処理装置Ｆで振替
入金５１を行う必要が生じたときのみとなり、振替支払
処理４１ｂが失敗したときには電文テーブル４９への電
文挿入を行わない。

【００４１】更に、振替支払４１はトランザクション完
了の宣言４１ｄを行った後、トランザクションの要求を
行った端末（図示しない）に対し、振替支払４１の処理
結果を回答する。この回答では、端末（図示しない）に
は振替支払（仕向側処理）４１の処理結果のみを通知
し、振替入金５１（被仕向側処理）の処理結果は通知し
ない。従って、端末（図示しない）は、振替入金５１
（被仕向側処理）の処理結果については関知しないこと
になる。

【００４２】次に、遅延更新管理処理シーケンスを説明
する。この遅延更新管理処理シーケンスも、上述した仕
向側処理シーケンスと同様、処理装置Ｅ側の適用業務Ａ
Ｐである遅延更新管理処理４３によって実行されるシー
ケンスである。遅延更新管理処理シーケンスは、上述し
た仕向側処理シーケンスと後述する被仕向側処理シーケ
ンスとの間の連携をとるためのもので、例えば上記シス
テムの運用者により任意のタイミングで実行すること
も、タイマ等によって定期的に実行することも可能であ
る。

【００４３】まず、上述したデータベース管理システム
と同一のデータベース管理システム（図示しない）に対
し、トランザクション開始の宣言４３ａを行う。次に、
未処理電文読込み４３ｂに移行する。未処理電文読込み
４３ｂでは、上記データベース管理システムを通じて、
仕向側データベース４５内の電文テーブル４９にアクセ
スする。そして、矢印４６で示すように電文テーブル４
９から未処理電文、即ち完了フラグが「未完了」となっ
ている電文を検索し、読込む。電文の検索及び読込み処
理は、１件毎或いは複数件を纏めて同時に行われる。

【００４４】次に、該当する宛先への電文送信及び結果
受信４３ｃの処理に移行する。この処理４３ｃでは、上
記未処理電文読込み４３ｂにおいて電文テーブル４９か
ら読込んだ未処理電文を「送信元」と「電文ＩＤ」と共
に、その宛先とサービス名とに従って該当する適用業務
ＡＰである処理装置Ｆ側の振替入金５１に矢印５０で示
すように送信する。上記「送信元」及び「電文ＩＤ」
は、被仕向側処理シーケンスである振替入金５１の２重
実行チェック５１ｂの処理を行うとき、使用される。そ
して、振替入金５１での処理結果が矢印５２で示すよう
に振替入金５１から送信されるのを受信する。なお、電
文の送信及び結果受信は、１件毎に送受信しても良い
し、複数件纏めて送受信しても良い。

【００４５】次に、完了フラグを「済」にするための更
新４３ｄ、即ち、完了フラグ書込みの処理に移行する。
この処理４３ｄでは、処理４３ｃで受信した上記該当電
文に対する振替入金５１（被仕向側）での処理結果を、
矢印４８で示すように電文テーブル４９（仕向側）の
「完了フラグ」に書込む。書込みにおいて、振替入金５
１で正しく処理されたときのみ「未完了」を「完了」に
変更し、処理が失敗したときには上記変更は行わない。
この完了フラグの更新処理４３ｄは、１件の電文毎に行
っても良いし、複数件の電文を一括して行っても良い。
この更新処理４３ｄが終了すると、遅延更新管理処理４
３は、上述したデータベース管理システム（図示しな
い）に対し、トランザクション完了の宣言４３ｅを行
う。

【００４６】上述した遅延更新管理処理４３によれば、
通信障害等が原因で遅延更新管理処理シーケンスが途中
で失敗しても、遅延更新管理処理シーケンスが次回に実
行されるときに、未処理の電文（処理が途中で失敗した
電文も含む）は再度処理対象となる。そのため、通信障
害等の過渡的な障害が発生しても、上記システムの信頼
性が損なわれることはない。但し、適用業務ＡＰにバグ
等の恒久的な障害が発生したときは、自動的に回復させ
ることができないために、オペレータ等により対処する
ことになる。

【００４７】上述した遅延更新管理処理シーケンスを定
期的に実行することにより、通信エラーのような過渡的
なエラーが原因で一時的に未処理となっている電文があ
ったとしても、いずれ処理が実行され、上記システム内
のリソースの一貫性は自動的に復元される。但し、恒久
的なエラーが発生したときには、そのエラーの原因を除
去するための異常系処理を実行した後に、遅延更新管理
処理シーケンスを行う必要がある。

【００４８】次に、被仕向側処理シーケンスを説明す
る。この被仕向側処理シーケンスは、処理装置Ｆ側の適
用業務ＡＰである振替入金５１によって実行されるシー
ケンスである。

【００４９】まず、遅延更新管理処理４３から送信され
る矢印５０で示したメッセージとして、上述した電文を
受信する。送信される電文が１件のときは１件毎に処理
し、送信される電文が複数件纏められているときは、そ
れらを１件毎に逐次処理するか、或いは、それらを並行
して同時処理することになる。

【００５０】次に、処理装置Ｆ側のデータベース管理シ
ステム（図示しない）に対し、トランザクション開始の
宣言５１ａを行い、２重実行チェック５１ｂの処理に移
行する。

【００５１】この２重実行チェック５１ｂでは、上記デ
ータベース管理システムを通じて、被仕向側データベー
ス５３内の完了トランザクションテーブル５７にアクセ
スする。そして、矢印５８で示すように、上記テーブル
５７に記録済みの、処理が完了したトランザクションの
「送信元」及び「電文ＩＤ」の一覧を読出し、その一覧
と、遅延更新管理処理４３から受信した電文の「送信
元」及び「電文ＩＤ」との照合を行う。この照合によ
り、上述した該当電文が既に処理済みか、つまり、該当
電文が２重に実行されてしまう危険性があるか否かをチ
ェックする。このチェックの結果、既に処理済みのとき
は、「完了」として遅延更新管処理４３に処理結果を回
答し、該当電文が２重に実行されるのを回避する。

【００５２】次に、振替入金処理５１ｃに移行する。こ
の振替入金処理５１ｃでは、矢印５４で示すように、上
記データベース管理システムを通じて被仕向側データベ
ース５３内の振替入金用テーブル５５にアクセスし、振
替処理のうちの入金側の処理を行う（支払側の処理につ
いては、振替支払４１で説明した）。即ち、振替入金処
理５１ｃを行うのに必要な各種データの検索や、振替入
金処理５１ｃの結果得られたデータによる従前のデータ
の更新処理を行う。この処理に続いて電文ＩＤ登録５１
ｄに移行する。

【００５３】この電文ＩＤ登録５１ｄでは、矢印５６で
示すように、上記データベース管理システムを通じて完
了トランザクションテーブル５７にアクセスし、テーブ
ル５７に該当電文の「送信元」及び「電文ＩＤ」を登録
する。この電文ＩＤ登録５１ｄが終了すると、振替入金
５１は、上述したデータベース管理システム（図示しな
い）に対し、トランザクション完了の宣言５１ｅを行
う。

【００５４】更に、振替入金５１はトランザクション完
了の宣言５１ｅを行った後、遅延更新管理処理４３に処
理結果を回答する。

【００５５】図４は、図３の遅延更新処理方式を採用し
たトランザクション処理システムに用いられるデータベ
ースの説明図である。

【００５６】電文テーブル４９は、図３において説明し
た内容から明らかなように、被仕向側（受信側）として
の処理装置Ｆに送信する電文を格納するためのテーブル
であり、仕向側（送信側）としての処理装置Ｅのユーザ
データが書込まれる振替支払用テーブル４７と同一のデ
ータベース内に配置される。よって、テーブル４７、４
９が同一のデータベース管理システム（図示しない）に
より管理されるため、１つのトランザクションから両方
のテーブル４７、４９にアクセスしても、これらのデー
タ間の整合性は上記データベース管理システム（図示し
ない）が自動的に保障してくれる。

【００５７】上述したように、電文テーブル４９には、
仕向側の適用業務ＡＰである振替支払４１により、被仕
向側に送信したい電文の「電文ＩＤ」「宛先」「送信先
のサービス名」「電文内容」が書込まれる。電文ＩＤ
は、電文を識別するためのもので、各処理装置Ｅ、Ｆが
各々電文を受付けたとき、各処理装置Ｅ、Ｆにより夫々
付与されるものである。遅延更新管理処理４３によっ
て、完了フラグが「未完了」の電文が検索され、読込ま
れる。この電文が被仕向側に送信され、正常に処理が完
了すると、遅延更新管理処理４３によって完了フラグに
「完了」が書込まれる。

【００５８】完了トランザクションテーブル５７は、完
了したトランザクションを記録するためのテーブルで、
被仕向側（受信側）としての処理装置Ｆのユーザデータ
が書込まれる振替入金用テーブル５５と同一のデータベ
ース内に配置される。よって、テーブル５５、５７が同
一のデータベース管理システム（図示しない）により管
理されるため、１つのトランザクションから両方のテー
ブル５５、５７にアクセスしても、これらのデータ間の
整合性は上記データベース管理システム（図示しない）
が自動的に保障してくれる。

【００５９】上述したように、完了トランザクションテ
ーブル５７には、被仕向側の適用業務ＡＰである振替入
金５１による被仕向側の処理に使用された電文の「送信
元」、「電文ＩＤ」が書込まれる。振替入金５１によっ
て同一電文が過去に既に実行済みのものか否かをチェッ
クするため、テーブル５７に同一「送信元」、同一「電
文ＩＤ」の電文が存在しているか否かが検索される。

【００６０】上述した内容は、あくまで本発明の一実施
形態及びその変形例に関するものであって、本発明が上
記内容のみに限定されることを意味するものでないのは
勿論である。例えば、上述した実施形態では、振替支払
側のデータと振替入金側のデータとが異なるデータベー
スに格納されている場合を例にとって説明したが、これ
ら両データが同一のデータベースに格納されている場合
でも、本発明は適用可能である。また、上記内容は銀行
の振替処理に関するものであったが、本発明の適用範囲
は、銀行の振替処理に限定されないのは勿論である。

【００６１】

【発明の効果】以上説明したように、本発明によれば、
複数のリソース間での分散デッドロックの発生を回避す
ることが可能なトランザクション処理システムを提供す
ることができる。

【図面の簡単な説明】

【図１】２相コミット方式を採用した従来のトランザク
ション処理システムのブロック図。

【図２】本発明の一実施形態に係るトランザクション処
理システムのブロック図。

【図３】一実施形態の変形例に係る、遅延更新処理方式
を採用したトランザクション処理システムのブロック
図。

【図４】図３の遅延更新処理方式に用いられるデータベ
ースの説明図。

【符号の説明】

Ｃ、Ｄ、Ｅ、Ｆ 処理装置 ２１、４１ 振替支払処理 ２３、２９ リソースマネージャ ２５、４７ 振替支払用テーブル ２７、５１ 振替入金処理 ３１、５５ 振替入金用テーブル ４３ 遅延更新管理処理 ４５ 仕向側データベース ４９ 電文テーブル ５３ 被仕向側データベース ５７ 完了トランザクションテーブル

Claims (13)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上の複数のノードにサーバ
   プロセスが分散されている環境において、 各サーバプロセスが、夫々が存在するノード上に置かれ
   たリソースにのみアクセスすることを特徴とするトラン
   ザクション処理システム。
2. 【請求項２】 請求項１記載のトランザクション処理シ
   ステムにおいて、 前記サーバプロセスのうちの１つが、前記ネットワーク
   上のクライアントから送出されるトランザクションの要
   求を受けて、他のサーバプロセスに前記トランザクショ
   ンの要求を通知することを特徴とするトランザクション
   処理システム。
3. 【請求項３】 請求項１又は請求項２記載のトランザク
   ション処理システムにおいて、 他のサーバプロセスが、前記トランザクションの要求を
   通知したサーバプロセスから独立して所定の処理を実行
   することを特徴とするトランザクション処理システム。
4. 【請求項４】 請求項２記載のトランザクション処理シ
   ステムにおいて、 前記１つのサーバプロセスが、所定の処理が完了した時
   点で他のサーバプロセスの処理結果如何に関わらず、処
   理結果を前記クライアントに回答することを特徴とする
   トランザクション処理システム。
5. 【請求項５】 ネットワーク上の複数のノードにサーバ
   プロセスが分散されている環境において、 １つのサーバプロセスがリソースにアクセスした後に、
   別のサーバプロセスがリソースにアクセスするよう、各
   サーバプロセスのリソースに対するアクセスを規制する
   手段を備えることを特徴とするトランザクション処理シ
   ステム。
6. 【請求項６】 請求項５記載のトランザクション処理シ
   ステムにおいて、 前記サーバプロセスのうちの１つが、前記ネットワーク
   上のクライアントから送出されるトランザクションの要
   求を受けたとき、リソースにアクセスし処理結果を前記
   クライアントに回答することを特徴とするトランザクシ
   ョン処理システム。
7. 【請求項７】 請求項５記載のトランザクション処理シ
   ステムにおいて、 前記規制手段が、任意のタイミングで、又は定期的に起
   動することを特徴とするトランザクション処理システ
   ム。
8. 【請求項８】 請求項５又は請求項６記載のトランザク
   ション処理システムにおいて、 前記別のサーバプロセスが、前記規制手段から前記１つ
   のサーバプロセスにおける処理結果の通知を受けたと
   き、リソースにアクセスすることを特徴とするトランザ
   クション処理システム。
9. 【請求項９】 請求項５記載のトランザクション処理シ
   ステムにおいて、 各サーバプロセスが実行した処理結果が正常か否かを示
   すデータを保持する手段を備え、 前記規制手段が、前記各サーバプロセスが実行した処理
   が正常か否かを判定して、その判定結果を前記データ保
   持手段に書込むことを特徴とするトランザクション処理
   システム。
10. 【請求項１０】 請求項９記載のトランザクション処理
    システムにおいて、 前記規制手段が、前記データ保持手段に書込まれたデー
    タから各サーバプロセスが実行した処理結果中に正常で
    ないものを見出したとき、対応するサーバプロセスにそ
    の旨を再度通知することを特徴とするトランザクション
    処理システム。
11. 【請求項１１】 請求項５記載のトランザクション処理
    システムにおいて、 前記規制手段が、システムエラーが生じたときは、上記
    エラーが解消した後に再起動することを特徴とするトラ
    ンザクション処理システム。
12. 【請求項１２】 請求項５記載のトランザクション処理
    システムにおいて、 前記リソースが、各ノードに分散されていることを特徴
    とするトランザクション処理システム。
13. 【請求項１３】 請求項５記載のトランザクション処理
    システムにおいて、 前記リソースが、同一のノードに備えられることを特徴
    とするトランザクション処理システム。