JP2011180649A - データ処理システム、データ処理方法およびデータ処理プログラム - Google Patents

Abstract

【課題】プロセスを段階的に実行するシステムにおいて、処理の高速化を図るとともに、他のシステムとの連携を容易に実現する。
【解決手段】インメモリＤＢ２０およびディスク型ＤＢ３０を参照／更新しながら業務処理を実行するＡＰ実行部１２３と、業務処理の出力データをデータバッファ１５に格納するバッファ格納部１２４と、業務処理の処理終了通知を発行する応答送信部１２２と、データバッファ１５に格納された出力データを暫定ファイル５２に格納する暫定ファイル格納部１１３と、ディスク型ＤＢ３０のコミット要求を送信する要求送信部１１１と、制御テーブル３１を更新してディスク型ＤＢ３０をコミットするディスク型ＤＢコミット部１２５と、暫定ファイル５２を正規ファイル５２に変更する正規ファイル格納部１１４と、インメモリＤＢ２０をコミットするインメモリＤＢコミット部１１５とを備える。
【選択図】図２

Description

本発明は、データ処理システム、データ処理方法およびデータ処理プログラムに関する。

例えば業務処理等のデータ処理を行うシステムの中には、システム内の処理を複数のプロセスに分割し、各プロセスを段階的に実行することでシステムに課せられた処理を遂行するものがある。このようなシステムでは、各プロセスに割り当てられた処理を実行するとともに、その処理結果として出力されたデータを後続のプロセスに提供することになる。後続のプロセスでは、先行するプロセスから提供されたデータを参照して処理を実行することになる。下記特許文献１には、システム内の処理を複数のサービス（プロセス）に分割し、サービス単位で段階的に処理を実行するシステムが開示されている。

特許第４１４００１４号公報

業務処理等のデータ処理を行うシステムには、処理の高速化が要求されるため、プロセスごとの処理をより高速に実行する必要がある。また、業務が多様化しているため、例えば一つのシステムで処理されたデータを他のシステムでも参照することができるように、複数のシステム間でデータを連携させることも要求される。

本発明は、上述した課題を解決するためになされたものであり、プロセスを段階的に実行するシステムにおいて、処理の高速化を図るとともに、他のシステムとの連携を容易に実現することができるデータ処理システム、データ処理方法およびデータ処理プログラムを提供することを目的とする。

本発明のデータ処理システムは、データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行部と、前記実行部によって実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納部と、前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行部と、前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納部と、前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求部と、前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミット部と、前記第１のコミット部による前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納部と、前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミット部と、を備える。

本発明のデータ処理方法は、データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行ステップと、前記実行ステップにおいて実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納ステップと、前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行ステップと、前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納ステップと、前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求ステップと、前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミットステップと、前記第１のコミットステップにおける前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納ステップと、前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミットステップと、を含む。

本発明のデータ処理プログラムは、上記データ処理方法に含まれる各ステップをコンピュータに実行させる。

本発明によれば、プロセスを段階的に実行するシステムにおいて、処理の高速化を図るとともに、他のシステムとの連携を容易に実現することができる。

実施形態におけるデータ処理システムの概要構成を例示するブロック図である。 第１実施形態におけるサーバ装置の機能構成を例示するブロック図である。 データバッファ管理テーブルのデータ構成を例示する図である。 データバッファテーブルのデータ構成を例示する図である。 制御ファイルのデータ構成を例示する図である。 制御テーブルのデータ構成を例示する図である。 第１実施形態におけるデータ処理の処理手順を例示するフローチャートである。 第２実施形態におけるサーバ装置の機能構成を例示するブロック図である。 第２実施形態におけるデータ処理の処理手順を例示するフローチャートである（その１）。 第２実施形態におけるデータ処理の処理手順を例示するフローチャートである（その２）。

以下、添付図面を参照して、本発明に係るデータ処理システム、データ処理方法およびデータ処理プログラムの好適な実施形態について説明する。

[第１実施形態]
まず、図１を参照して、第１実施形態におけるデータ処理システムの概要構成について説明する。図１に示すように、データ処理システム１は、複数のサーバ装置１０およびインメモリＤＢ（Database）２０をそれぞれに含む三つのノード５と、ディスク型ＤＢ３０と、入力装置４０と、ストレージ５０と、を有する。インメモリＤＢ２０は、全てのデータを主記憶装置（例えば、ＲＡＭ（Random Access Memory）等の半導体メモリ）に格納し、主記憶装置に全データを保持しながら動作するデータベースである。ディスク型ＤＢ３０は、全てのデータを補助記憶装置（例えば、ＨＤＤ（Hard Disk Drive）やストレージ）に格納し、補助記憶装置にデータを保持しながら動作するデータベースである。ディスク型ＤＢとしては、例えば、ＲＤＢ（Relational Database）が該当する。

ここで、本実施形態におけるデータ処理システム１は、システム内の処理を三つのプロセスに分割し、各プロセスを段階的に実行するシステムである。各プロセスは、そのプロセスに対応して設けられたノード５内のいずれかのサーバ装置１０で実行される。なお、プロセスおよびノードは三つであることには限定されない。プロセスは、システム内の処理内容に応じて最適な数に適宜分割することができる。ノードは、分割したプロセスと同数設けることができる。

データ処理システム１におけるデータ処理の一例について説明する。データ処理としては、例えば、業務処理が該当する。以下においては、データ処理が業務処理である場合について説明する。例えば、最初に、第一のノード５に属するいずれかのサーバ装置１０が、入力装置４０から入力される入力データ４１を用いて第一のプロセスに対応する業務処理を実行し、その業務処理の出力データをストレージ５０のデータファイル５２に格納する。第一のノード５に属するサーバ装置１０は、第二のノード５に属するいずれかのサーバ装置１０に第一のデータファイル５２に関する情報を通知する。通知を受けた第二のノード５に属するサーバ装置１０は、第一のデータファイル５２に格納されたデータを用いて第二のプロセスに対応する業務処理を実行し、その業務処理の出力データをストレージ５０の第二のデータファイル５２に格納する。以下、同様にして、第三のノード５に属するサーバ装置１０は、第二のデータファイル５２に格納されたデータを用いて第三のプロセスに対応する業務処理を実行し、その業務処理の出力データをストレージ５０の第三のデータファイル５２に格納する。

図２を参照して、第１実施形態におけるサーバ装置１０の機能構成について説明する。なお、図２に示すサーバ装置１０の機能構成は、図１に示す各サーバ装置１０において共通である。

ここで、サーバ装置１０は、物理的には、例えば、ＣＰＵ（Central Processing Unit）と、記憶装置と、入出力インターフェースとを含んで構成される。記憶装置には、例えば、ＣＰＵで処理されるプログラムやデータを記憶するＲＯＭ（Read Only Memory）やＨＤＤ、主として制御処理のための各種作業領域として使用されるＲＡＭ（Random Access Memory）等が含まれる。これらの要素は、互いにバスを介して接続されている。ＣＰＵが、ＲＯＭに記憶されたプログラムを実行し、入出力インターフェースを介して受信されたメッセージや、ＲＡＭに展開されたデータを処理することで、後述するサーバ装置１０の各部の機能を実現することができる。

図２に示すように、サーバ装置１０は、機能的には、例えば、制御スレッド部１１と、ＡＰ（Application Program）スレッド部１２とを、有する。

制御スレッド部１１は、要求送信部１１１と、応答受信部１１２と、暫定ファイル格納部１１３と、正規ファイル格納部１１４と、インメモリＤＢコミット部１１５と、を有する。

要求送信部１１１は、全てのＡＰスレッド部１２に対して業務処理を開始するように要求する処理開始要求を送信する。要求送信部１１１は、全てのＡＰスレッド部１２に対してディスク型ＤＢ３０をコミットするように要求するコミット要求を送信する。応答受信部１１２は、ＡＰスレッド部１２から送信されるコミット完了通知（後述）を受信する。

暫定ファイル格納部１１３は、後述するＡＰスレッド部１２のバッファ格納部１２４によってデータバッファ１５に格納された出力データを、他のプロセスから参照不可能なディレクトリにあるデータファイル（以下、「暫定ファイル」という。）５２に格納する。

暫定ファイル格納部１１３は、制御ファイル５１の処理進行状況を更新（例えばインクリメント）する。図３を参照して、制御ファイル５１のデータ構成について説明する。制御ファイル５１は、プロセス単位で業務処理の進行状況を管理するためのテーブルである。図３は、制御ファイル５１のデータ構成を例示する図である。

図３に示すように、制御ファイル５１は、データ項目として、例えば、処理進行状況項目を有する。処理進行状況項目は、一つの業務処理が全てのＡＰスレッド部１２で終了するごとにインクリメントされるカウント情報を格納する。一つの業務処理は、処理開始要求を受信することで開始し、処理終了通知を送信することで終了する。

図２に示す正規ファイル格納部１１４は、ＡＰスレッド部１２に送信した全てのコミット要求に対するコミット完了通知（後述）を受信した場合に、暫定ファイル５２のディレクトリを、他のプロセスから参照可能なディレクトリに変更する。これにより、ＡＰスレッド部１２からの出力データを、他のプロセスから参照可能なディレクトリにあるデータファイル（以下、「正規ファイル」という。）５２に格納することができる。なお、正規ファイルにデータを格納する方法は、上述したディレクトリを変更する方法には限定されない。例えば、暫定ファイルと正規ファイルとを予め設けておき、暫定ファイルから正規ファイルにデータに格納する方法を採用することもできる。

インメモリＤＢコミット部１１５は、ＡＰスレッド部１２からの出力データが正規ファイル５２に格納された場合に、インメモリＤＢ２０をコミットする。

ＡＰスレッド部１２は、要求受信部１２１と、応答送信部１２２と、ＡＰ実行部１２３と、バッファ格納部１２４と、ディスク型ＤＢコミット部１２５と、を有する。

要求受信部１２１は、制御スレッド部１１から送信される処理開始要求およびコミット要求を受信する。

ＡＰ実行部１２３は、インメモリＤＢ２０のデータテーブル２１およびディスク型ＤＢ３０のデータテーブル３２を参照／更新しながら業務処理を行うアプリケーションプログラム（以下、「ＡＰ」という。）を実行する。インメモリＤＢ２０のデータテーブル２１およびディスク型ＤＢ３０のデータテーブル３２は、同じデータ項目を設けて設計してもよいし、それぞれ異なるデータ項目を設けて設計してもよい。異なるデータ項目を設ける場合には、例えば、以下のようにデータ項目を設けることが好ましい。インメモリＤＢ２０のデータテーブル２１は、業務処理に用いるデータのデータ項目を設ける。ディスク型ＤＢ３０のデータテーブル３２は、他のシステムとの連携に必要なデータのデータ項目を設ける。

バッファ格納部１２４は、業務処理の出力データを、ＡＰごとに区別してデータバッファ１５に格納する。図４および図５を参照して、データバッファ１５のデータ構成について説明する。データバッファ１５には、バッファ管理テーブルおよびバッファテーブルが設けられている。バッファ管理テーブルは、データバッファ１５に設けられるバッファ領域を管理するためのテーブルである。バッファテーブルは、バッファ領域に格納されるデータを管理するためのテーブルである。図４は、バッファ管理テーブルのデータ構成を例示する図である。図５は、バッファテーブルのデータ構成を例示する図である。

図４に示すように、バッファ管理テーブルは、データ項目として、例えば、バッファＩＤ項目、バッファサイズ項目、更新フラグ項目および使用フラグ項目を有する。バッファＩＤ項目は、バッファ領域を一意に特定するためのＩＤを格納する。バッファサイズ項目は、バッファ領域の大きさを格納する。更新フラグ項目および使用フラグ項目は、フラグ情報として、例えばＯＮ／ＯＦＦを格納する。

図５に示すように、バッファテーブルは、データ項目として、例えば、バッファＩＤ項目、ブロックＩＤ項目、ＡＰ識別子項目、有効フラグ項目およびデータ領域項目を有する。バッファＩＤ項目は、バッファ領域を一意に特定するためのＩＤを格納する。ブロックＩＤ項目は、バッファ領域をブロック単位に分割した分割ブロックを特定するためのＩＤを格納する。ＡＰ識別子項目は、分割ブロックにデータを格納したＡＰを一意に特定するための情報を格納する。有効フラグ項目は、フラグ情報として、例えばＯＮ／ＯＦＦを格納する。データ領域項目は、ＡＰに対応する業務処理の出力データを格納する。

図５に示す有効フラグ項目は、例えば、以下のように利用することができる。制御スレッド部１１が、全てのＡＰスレッド部１２から処理完了通知を受信した場合に、各ＡＰスレッド部１２からの出力データを格納したバッファレコードの有効フラグをＯＮにする。暫定ファイル格納部１１３は、有効フラグがＯＮのバッファレコードのデータ領域に格納されているデータを暫定ファイル５２に格納する。これにより、暫定ファイル格納部１１３が、各ＡＰスレッド部１２のバッファ格納部１２４によってデータバッファ１５に格納された出力データを暫定ファイル５２に格納することができる。また、正規ファイル格納部１１４は、バッファレコードの各有効フラグをＯＦＦにしてから、暫定ファイル５２を正規ファイル５２に変更して出力データを確定させる。これにより、次回の業務処理を実行する前に、有効フラグをリセットすることができる。

図２に示すディスク型ＤＢコミット部１２５は、コミット要求を受信した場合に、ＡＰごとに区別してディスク型ＤＢ３０の制御テーブル３１に格納されている処理進行状況を更新（例えばインクリメント）し、ディスク型ＤＢ３０をコミットする。図６を参照して、制御テーブル３１のデータ構成について説明する。制御テーブル３１は、ＡＰ単位で業務処理の進行状況を管理するためのテーブルである。図６は、制御テーブル３１のデータ構成を例示する図である。

図６に示すように、制御テーブル３１は、データ項目として、例えば、ＡＰ識別子項目および処理進行状況項目を有する。ＡＰ識別子項目は、業務処理を実行するＡＰを一意に特定するための情報を格納する。処理進行状況項目は、一つの業務処理がＡＰスレッド部１２で終了するごとにインクリメントされるカウント情報を格納する。

図６に示す制御テーブル３１の各処理進行状況と図３に示す制御ファイル５１の処理進行状況は、業務処理が行われていないときに同時にリセットする。これにより、業務処理中に障害等が発生した場合に、それぞれの処理進行状況を確認することで、ＡＰごとの業務処理の進捗状況を把握することが可能となる。

図２に示す応答送信部１２２は、ＡＰ実行部１２３によって実行される業務処理が終了した場合に、業務処理が終了したことを示す処理終了通知を発行し、制御スレッド部１１に送信する。応答送信部１２２は、ディスク型ＤＢコミット部１２５によってディスク型ＤＢ３０のコミットが完了した場合に、コミットが完了したことを示すコミット完了通知を発行し、制御スレッド部１１に送信する。

次に、図７を参照して、第１実施形態におけるデータ処理システム１の動作について説明する。図７は、第１実施形態におけるデータ処理の処理手順を例示するフローチャートである。

最初に、制御スレッド部１１は、入力装置４０から入力データ４１を読み込む（ステップＳ１０１）。

続いて、制御スレッド部１１の要求送信部１１１は、全てのＡＰスレッド部１２に対して業務処理を開始するように要求する処理開始要求を送信する（ステップＳ１０２）。これにより、各ＡＰスレッド部１２の要求受信部１２１は、制御スレッド部１１から送信された処理開始要求をそれぞれ受信する。

続いて、各ＡＰスレッド部１２のＡＰ実行部１２３は、インメモリＤＢ２０のデータテーブル２１およびディスク型ＤＢ３０のデータテーブル３２を参照／更新しながら業務処理をそれぞれ実行する（ステップＳ１０３）。

続いて、各ＡＰスレッド部１２のバッファ格納部１２４は、業務処理の出力データをそれぞれデータバッファ１５に格納する（ステップＳ１０４）。

続いて、業務処理が終了したＡＰスレッド部１２の応答送信部１２２は、業務処理が終了したことを示す処理終了通知を発行し、制御スレッド部１１に送信する（ステップＳ１０５）。これにより、制御スレッド部１１の応答受信部１１２は、各ＡＰスレッド部１２から送信された処理終了通知を受信する。

続いて、制御スレッド部１１は、業務処理を実行中のＡＰスレッド部１２が存在するか否かを判定し（ステップＳ１０６）、この判定がＮＯである場合（ステップＳ１０６；ＮＯ）に、データバッファ１５の各有効フラグをＯＮにする（ステップＳ１０７）。

続いて、制御スレッド部１１の暫定ファイル格納部１１３は、上記ステップＳ１０４でデータバッファ１５に格納された出力データのうち、有効フラグがＯＮのバッファレコードのデータ領域に格納されている出力データを、暫定ファイル５２に格納する（ステップＳ１０８）。

続いて、制御スレッド部１１の暫定ファイル格納部１１３は、制御ファイル５１の処理進行状況を更新する（ステップＳ１０９）。

続いて、制御スレッド部１１の要求送信部１１１は、全てのＡＰスレッド部１２に対してディスク型ＤＢ３０をコミットするように要求するコミット要求を送信する（ステップＳ１１０）。これにより、各ＡＰスレッド部１２の要求受信部１２１は、制御スレッド部１１から送信されたコミット要求をそれぞれ受信する。

続いて、各ＡＰスレッド部１２のディスク型ＤＢコミット部１２５は、ディスク型ＤＢ３０の制御テーブル３１に格納されている処理進行状況を更新し、ディスク型ＤＢ３０をコミットする（ステップＳ１１１）。

続いて、各ＡＰスレッド部１２の応答送信部１２２は、コミットが完了したことを示すコミット完了通知を発行し、制御スレッド部１１に送信する（ステップＳ１１２）。これにより、制御スレッド部１１の応答受信部１１２は、各ＡＰスレッド部１２から送信されたコミット完了通知を受信する。

続いて、制御スレッド部１１の正規ファイル格納部１１４は、データバッファ１５の各有効フラグをＯＦＦにする（ステップＳ１１３）。

続いて、制御スレッド部１１の正規ファイル格納部１１４は、暫定ファイル５２のディレクトリを他のプロセスから参照可能なディレクトリに変更することで、暫定ファイル５２を正規ファイル５２に変更し、出力データを確定する（ステップＳ１１４）。

続いて、制御スレッド部１１は、後続のプロセスに出力データ情報を通知する（ステップＳ１１５）。出力データ情報には、例えば、正規ファイル５２のディレクトリ情報等が含まれる。

続いて、制御スレッド部１１のインメモリＤＢコミット部１１５は、インメモリＤＢ２０をコミットする（ステップＳ１１６）。これにより、一つのプロセスで実行される業務処理の出力データが確定する。

上述してきたように、第１実施形態におけるデータ処理システム１によれば、各ＡＰスレッド部１２で業務処理を実行する際に、インメモリＤＢ２０を用いて処理することができるため、業務処理の高速化を図ることができる。また、各ＡＰスレッド部１２で業務処理を実行する際に、ディスク型ＤＢ３０を用いて処理することができるため、他のシステムとの連携を容易に実現することができる。

また、第１実施形態におけるデータ処理システム１によれば、ＡＰスレッド部１２ごとに処理進行状況を管理し、この処理進行状況を格納する制御テーブル３１と業務処理データを格納するディスク型ＤＢ３０のデータテーブル３２とを同時にコミットすることができ、さらに、このコミット完了時に他のプロセスに引き渡す正規ファイル５２を確定し、業務処理データを格納するインメモリＤＢ２０のデータテーブル２１をコミットすることができる。したがって、一つのプロセスに含まれる、ディスク型ＤＢ３０のデータと、正規ファイル５２のデータと、インメモリＤＢ２０のデータとの間の一貫性の有無を、業務処理単位で確実に把握することが可能となる。これにより、障害時のリカバリを簡易に行うことが可能となる。
[第２実施形態]

本発明の第２実施形態について説明する。第２実施形態におけるデータ処理システムは、例えば、業務処理を実行する一部のＡＰスレッド部１２間でデッドロックが発生し、一部のＡＰスレッド部１２から処理完了通知が送信されない事態に対処するための機能を有する点で、上述した第１実施形態におけるデータ処理システムと異なる。

図８は、第２実施形態におけるデータ処理システムのサーバ装置１０の機能構成を例示する図である。第２実施形態におけるサーバ装置１０は、制御スレッド部１１にタイマ部１１６をさらに有する点で第１実施形態におけるサーバ装置１０の機能構成と異なる。それ以外の構成は、第１実施形態における各構成と同様であるため、各構成要素には同一の符合を付しその説明は省略するとともに、以下においては、主に第１実施形態との相違点について説明する。

制御スレッド部１１のタイマ部１１６は、ＡＰスレッド部１２から送信されてくる処理終了通知を待機する時間（以下、「待機時間」という。）を計測する。待機時間は、任意に設定することができる。本実施形態における待機時間は、例えば、デッドロック等の障害が発生して一部の処理終了通知が送信されない、または大幅に遅延している、と見込める時間に設定する。

第２実施形態における制御スレッド部１１の要求送信部１１１は、待機時間中に処理終了通知を発行したＡＰスレッド部１２にのみ、コミット要求を送信する。

第２実施形態におけるＡＰスレッド部１２のディスク型ＤＢコミット部１２５は、ディスク型ＤＢ３０の制御テーブル３１に格納されている処理進行状況のうち、待機時間中に処理終了通知を発行したＡＰスレッド部１２に対応する処理進行状況のみを更新する。

次に、図９および図１０を参照して、第２実施形態におけるデータ処理システム１の動作について説明する。図９および図１０は、第２実施形態におけるデータ処理の処理手順を例示するフローチャートである。

最初に、制御スレッド部１１は、入力装置４０から入力データ４１を読み込む（ステップＳ２０１）。

続いて、制御スレッド部１１の要求送信部１１１は、全てのＡＰスレッド部１２に対して業務処理を開始するように要求する処理開始要求を送信する（ステップＳ２０２）。これにより、各ＡＰスレッド部１２の要求受信部１２１は、制御スレッド部１１から送信された処理開始要求をそれぞれ受信する。

続いて、制御スレッド部１１のタイマ部１１６は、待機時間の計測を開始する（ステップＳ２０３）。

続いて、各ＡＰスレッド部１２のＡＰ実行部１２３は、インメモリＤＢ２０のデータテーブル２１およびディスク型ＤＢ３０のデータテーブル３２を参照／更新しながら業務処理をそれぞれ実行する（ステップＳ２０４）。

続いて、各ＡＰスレッド部１２のバッファ格納部１２４は、業務処理の出力データをそれぞれデータバッファ１５に格納する（ステップＳ２０５）。

続いて、業務処理が終了したＡＰスレッド部１２の応答送信部１２２は、業務処理が終了したことを示す処理終了通知を発行し、制御スレッド部１１に送信する（ステップＳ２０６）。これにより、制御スレッド部１１の応答受信部１１２は、一または複数のＡＰスレッド部１２から送信された処理終了通知を受信する。

続いて、制御スレッド部１１のタイマ部１１６は、待機時間がタイムアップしたか否かを判定し（ステップＳ２０７）、この判定がＹＥＳである場合（ステップＳ２０７；ＹＥＳ）に、今回の待機時間中に処理終了通知を発行したＡＰスレッド部１２に対応するデータバッファ１５の各有効フラグをＯＮにする（ステップＳ２０８）。なお、上記ステップＳ２０７の判定で、待機時間がタイムアップする前に、全てのＡＰスレッド部１２から処理終了通知を受信した場合には、待機時間の計測をキャンセルし、上記ステップＳ２０８に処理を移行することとしてもよい。

続いて、制御スレッド部１１の暫定ファイル格納部１１３は、上記ステップＳ２０５でデータバッファ１５に格納された出力データのうち、有効フラグがＯＮのバッファレコードのデータ領域に格納されている出力データを、暫定ファイル５２に格納する（ステップＳ２０９）。

続いて、制御スレッド部１１の暫定ファイル格納部１１３は、初回の待機時間経過後である場合にのみ、制御ファイル５１の処理進行状況を更新する（ステップＳ２１０）。

続いて、制御スレッド部１１の要求送信部１１１は、今回の待機時間中に処理終了通知を発行したＡＰスレッド部１２に対してディスク型ＤＢ３０をコミットするように要求するコミット要求を送信する（ステップＳ２１１）。これにより、一または複数のＡＰスレッド部１２の要求受信部１２１は、制御スレッド部１１から送信されたコミット要求をそれぞれ受信する。

続いて、各ＡＰスレッド部１２のディスク型ＤＢコミット部１２５は、ディスク型ＤＢ３０の制御テーブル３１に格納されている処理進行状況のうち、今回の待機時間中に処理終了通知を発行したＡＰスレッド部１２に対応する処理進行状況を更新し、ディスク型ＤＢ３０をコミットする（ステップＳ２１２）。

続いて、各ＡＰスレッド部１２の応答送信部１２２は、コミットが完了したことを示すコミット完了通知を発行し、制御スレッド部１１に送信する（ステップＳ２１３）。これにより、制御スレッド部１１の応答受信部１１２は、一または複数のＡＰスレッド部１２から送信されたコミット完了通知を受信する。

続いて、制御スレッド部１１の正規ファイル格納部１１４は、データバッファ１５の各有効フラグをＯＦＦにする（ステップＳ２１４）。

続いて、制御スレッド部１１は、業務処理を実行中のＡＰスレッド部１２が存在するか否かを判定し（ステップＳ２１５）、この判定がＹＥＳである場合（ステップＳ２１５；ＹＥＳ）には、上述したステップＳ２０３に処理を移行する。

一方、上記ステップＳ２１５の判定で業務処理を実行中のＡＰスレッド部１２が存在しないと判定された場合（ステップＳ２１５；ＮＯ）に、制御スレッド部１１の正規ファイル格納部１１４は、暫定ファイル５２のディレクトリを他のプロセスから参照可能なディレクトリに変更することで、暫定ファイル５２を正規ファイル５２に変更し、出力データを確定する（ステップＳ２１６）。

なお、ＡＰスレッド部１２が、例えばデッドロック等によってフリーズしたと判定できる場合には、当該ＡＰスレッド部１２の業務処理を停止状態に設定することができる。この場合、上記ステップＳ２１５の判定でＮＯと判定されるため、処理を上記ステップＳ２１６以降に移行することができる。これにより、一部のＡＰスレッド部１２が停止状態に陥ったとしても、正常に業務処理が完了したデータのみを後続のプロセスに提供することが可能となる。

続いて、制御スレッド部１１は、後続のプロセスに出力データ情報を通知する（ステップＳ２１７）。

続いて、制御スレッド部１１のインメモリＤＢコミット部１１５は、インメモリＤＢ２０をコミットする（ステップＳ２１８）。これにより、一つのプロセスで実行される業務処理の出力データが確定する。

上述してきたように、第２実施形態におけるデータ処理システム１によれば、上述した第１実施形態におけるデータ処理システム１の効果に加え、以下の効果を有する。デッドロック等の障害が発生して一部のＡＰスレッド部１２が停止状態に陥った場合であっても、正常に業務処理を終了したＡＰスレッド部１２から出力されたデータについては、正規ファイル５２に格納することができる。これにより、障害が発生した場合に、リカバリを行う前に、一部の正常なデータを後続のプロセスに提供することが可能となる。
[変形例]

なお、上述した各実施形態は、単なる例示に過ぎず、各実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。

例えば、上述した各実施形態におけるサーバ装置１０が、各ＡＰスレッド部１２の状態を管理する状態管理テーブルと、この状態管理テーブルの内容に応じてリカバリを行うリカバリ部と、をさらに備えることとしてもよい。状態管理テーブルは、各ＡＰスレッド部１２の状態を、例えば、処理待機中、処理実行中、処理正常完了、処理異常完了、コミット中、コミット成功、コミット失敗、ロールバック中、ロールバック失敗、ロールバック成功等の各種の状態で管理する。リカバリ部は、各ＡＰスレッド部の状態に応じて、ロールバックやコミット等を行うリカバリ処理を実行する。リカバリ処理としては、例えば、業務処理の途中で障害が発生したと判定できる場合にはロールバックを行い、業務処理が終了してから障害が発生したと判定できる場合にはコミットする等がある。なお、リカバリ部によるリカバリ処理は、従来の種々のリカバリ処理と同様の方法を採用することができる。

最後に、上記の各実施形態の一部または全部は、以下の付記のようにも記載され得るが、本発明を以下に限定するものではない。

（付記１） データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行部と、前記実行部によって実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納部と、前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行部と、前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納部と、前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求部と、前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミット部と、前記第１のコミット部による前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納部と、前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミット部と、を備えることを特徴とするデータ処理システム。

（付記２） 前記アプリケーションの処理開始要求が前記アプリケーションに付与されてから所定時間に到達するまでを計測するタイマ部をさらに備え、前記第１の格納部は、前記バッファに格納された前記出力データのうち、前記タイマ部により前記計測が行われている間に前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、前記第１のファイルに格納することを特徴とする付記１記載のデータ処理システム。

（付記３） 前記タイマ部は、前記コミットが要求された全ての前記アプリケーションにおいて前記コミットが完了した後に、処理中の前記アプリケーションが存在する場合に、前記所定時間の計測を再度行い、前記第１の格納部は、前記バッファに格納された前記出力データのうち、前記タイマ部により再度の前記計測が行われている間に前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、前記第１のファイルに格納することを特徴とする付記２記載のデータ処理システム。

（付記４） データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行ステップと、前記実行ステップにおいて実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納ステップと、前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行ステップと、前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納ステップと、前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求ステップと、前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミットステップと、前記第１のコミットステップにおける前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納ステップと、前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミットステップと、を含むことを特徴とするデータ処理方法。

（付記５） 付記４に記載の各ステップをコンピュータに実行させるためのデータ処理プログラム。

１…データ処理システム、５…ノード、１０…サーバ装置、１１…制御スレッド部、１２…ＡＰスレッド部、１５…データバッファ、２０…インメモリＤＢ、２１…データテーブル、３０…ディスク型ＤＢ、３１…制御テーブル、３２…データテーブル、４０…入力装置、４１…入力データ、５０…ストレージ、５１…制御ファイル、５２…データファイル、１１１…要求送信部、１１２…応答受信部、１１３…暫定ファイル格納部、１１４…正規ファイル格納部、１１５…インメモリＤＢコミット部、１１６…タイマ部、１２１…要求受信部、１２２…応答送信部、１２３…ＡＰ実行部、１２４…バッファ格納部、１２５…ディスク型ＤＢコミット部。

Claims (5)

1. データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行部と、
   前記実行部によって実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納部と、
   前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行部と、
   前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納部と、
   前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求部と、
   前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミット部と、
   前記第１のコミット部による前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納部と、
   前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミット部と、
   を備えることを特徴とするデータ処理システム。
2. 前記アプリケーションの処理開始要求が前記アプリケーションに付与されてから所定時間に到達するまでを計測するタイマ部をさらに備え、
   前記第１の格納部は、前記バッファに格納された前記出力データのうち、前記タイマ部により前記計測が行われている間に前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、前記第１のファイルに格納する
   ことを特徴とする請求項１記載のデータ処理システム。
3. 前記タイマ部は、前記コミットが要求された全ての前記アプリケーションにおいて前記コミットが完了した後に、処理中の前記アプリケーションが存在する場合に、前記所定時間の計測を再度行い、
   前記第１の格納部は、前記バッファに格納された前記出力データのうち、前記タイマ部により再度の前記計測が行われている間に前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、前記第１のファイルに格納する
   ことを特徴とする請求項２記載のデータ処理システム。
4. データを主記憶装置に格納する第１のデータベースおよびデータを補助記憶装置に格納する第２のデータベースを参照／更新しながら一つのプロセス内で複数のアプリケーションを実行する実行ステップと、
   前記実行ステップにおいて実行される前記アプリケーションによる出力データを、前記アプリケーションごとに区別してバッファに格納するバッファ格納ステップと、
   前記アプリケーションによる処理が終了するごとに処理終了通知を発行する発行ステップと、
   前記バッファに格納された前記出力データのうち、前記処理終了通知が発行された前記アプリケーションに対応する前記出力データを、他のプロセスから参照不可能な第１のファイルに格納する第１の格納ステップと、
   前記処理終了通知が発行された前記アプリケーションに対して前記第２のデータベースをコミットするように要求するコミット要求ステップと、
   前記コミットが要求された場合に、前記アプリケーションごとに区別して前記第２のデータベースに格納されている処理進行状況を更新し、前記第２のデータベースをコミットする第１のコミットステップと、
   前記第１のコミットステップにおける前記コミットが全ての前記アプリケーションで完了した場合に、前記第１のファイルに格納されている前記出力データを、他のプロセスから参照可能な第２のファイルに格納する第２の格納ステップと、
   前記第１のファイルの前記出力データが前記第２のファイルに格納された場合に、前記第１のデータベースをコミットする第２のコミットステップと、
   を含むことを特徴とするデータ処理方法。
5. 請求項４に記載の各ステップをコンピュータに実行させるためのデータ処理プログラム。

Images