(57)【要約】【課題】  ２フェーズ・コミットを適用することができない分散システムにおいて、トランザクション障害が発生し、アプリケーションシステムとサブシステムのデータベース間でデータ不整合が生じた場合に、データ不整合が発生したことを検知し、データ不整合箇所を特定し、さらに不整合となったデータを修復して、システム全体のデータ整合性を保つ。【解決手段】  ネットワーク上で映像等のコンテンツを配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うコンテンツ配信システムであって、前記メインシステムは、アプリケーションが行う個別処理を前記サブシステムから呼び出す個別処理呼出手段と、前記個別処理呼出手段で呼び出した個別処理の開始通知および終了通知を蓄積する通知蓄積手段と、前記通知蓄積手段に蓄積された前記個別処理の開始通知及び終了通知に基づいて前記個別処理の障害を判定する障害判定手段とを備えるコンテンツ配信システムである。【選択図】        図１
2005339091.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上で映像等のコンテンツを配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うコンテンツ配信システムであって、
前記メインシステムは、アプリケーションが行う個別処理を前記サブシステムから呼び出す個別処理呼出手段と、
前記個別処理呼出手段で呼び出した個別処理の開始通知および終了通知を蓄積する通知蓄積手段と、
前記通知蓄積手段に蓄積された前記個別処理の開始通知及び終了通知に基づいて前記個別処理の障害を判定する障害判定手段とを備えることを特徴とするコンテンツ配信システム。
【請求項２】
前記通知蓄積手段は、前記個別処理の開始通知および終了通知に加え、前記メインシステムのアプリケーションの処理の開始通知および終了通知を、前記個別処理の開始通知及び終了通知と関連づけて蓄積することを特徴とする請求項１に記載のコンテンツ配信システム。
【請求項３】
前記メインシステムは、前記各手段に加え、前記アプリケーションのデータベースに蓄積されたコンテンツ情報のレコードあるいはデータ項目を特定する参照テーブルを保持する参照テーブル保持手段を備えることを特徴とする請求項１または請求項２に記載のコンテンツ配信システム。
【請求項４】
ネットワーク上で映像等のコンテンツを販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムの障害を検出する障害検出方法であって、
前記メインシステムのアプリケーションが前記サブシステムの個別処理の呼び出しを行うステップ１と、
前記個別処理の処理開始時に前記個別処理の開始通知を行うステップ２、および前記個別処理の開始通知の蓄積を行うステップ３と、
前記個別処理の終了時に前記個別処理の終了通知を行うステップ４、および前記個別処理の終了通知の蓄積を行うステップ５と、
前記個別処理が終了して前記アプリケーションに復帰をするステップ６と、
蓄積した前記個別処理の開始通知と前記個別処理の終了通知を検索して前記個別処理の開始通知に対応する終了通知が存在するか否かの検査を行うステップ７と、
前記個別処理の開始通知に対応する終了通知が存在する場合に前記個別処理を正常と判定し、前記個別処理の開始通知に対応する終了通知が存在しない場合に個別処理を障害と判定するステップ８とを有することを特徴とする障害検出方法。
【請求項５】
前記ステップ１乃至ステップ６を、複数のアプリケーションに対して行った場合、
前記ステップ７は、各アプリケーションが呼び出した個別処理毎に、前記開始通知と前記開始通知に対応する終了通知が存在するか否かの検査を行い、
前記ステップ８は、各アプリケーションが呼び出した個別処理毎に、前記開始通知と対応する終了通知が存在する場合は前記個別処理を正常と判定し、前記個別処理の開始通知に対応する終了通知が存在しない場合に個別処理を障害と判定することを特徴とする請求項４に記載の障害検出方法。
【請求項６】
前記ステップ１の前に、前記アプリケーションの処理開始時に、処理の開始通知を行うステップ９、および前記アプリケーションの処理の開始通知の蓄積を行うステップ１０を有し、
前記ステップ６とステップ７の間に、前記アプリケーションの処理の終了通知を行うステップ１１、および前記アプリケーションの処理の終了通知の蓄積を行うステップ１２を有し、
前記ステップ７は、前記アプリケーション毎に、蓄積した前記各アプリケーションの処理の開始通知と前記アプリケーションの処理の終了通知を検索して前記処理の開始通知に対応する前記処理の終了通知が存在するか否かの検査を行い、かつ、蓄積した前記アプリケーションが呼び出した個別処理の開始通知と前記個別処理の終了通知を検索して前記個別処理の開始通知に対応する終了通知が存在するか否かの検査を行い、
前記ステップ８は、前記アプリケーションの処理の開始通知に対応する終了通知が存在し、かつ、前記個別処理の開始通知に対応する終了通知が存在する場合は前記アプリケーションの個別処理を正常と判定し、前記アプリケーションの処理の開始通知に対応する終了通知が存在しない場合、または、前記個別処理の開始通知に対応する終了通知が存在しない場合は前記アプリケーションの個別処理を障害と判定することを特徴とする請求項５に記載の障害検出方法。
【請求項７】
ネットワーク上で映像等のコンテンツを販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムで、メインシステムの複数のアプリケーションの各データベースに蓄積されたデータの不整合を検出する障害検出方法であって、
前記メインシステムの各アプリケーションのデータベースに蓄積された各コンテンツ情報のレコードまたはデータ項目と、前記各アプリケーションのデータベースに蓄積された各レコードまたはデータ項目を参照項目として特定する参照テーブルを参照するステップと、
検索すべき対象として、前記各データベースのレコードまたはデータ項目を前記参照テーブルにより特定するステップと、
前記データベース毎に前記レコードまたはデータ項目を検索するステップと、
検索した前記各データベースのレコードまたはデータ項目のうちのいずれかが存在しない場合、障害と判定するステップとを有することを特徴とする障害検出方法。
【請求項８】
ネットワーク上で映像コンテンツ等を販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムで、障害を検出するステップ、およびデータの不整合を検出するステップ、ならびに前記障害からの回復およびデータの整合化を行うステップとを有する障害回復方法であって、
障害を検出するステップは、請求項４乃至請求項６のいずれかに記載の障害検出方法により障害を検出し、
前記データの不整合を検出するステップは、請求項７に記載の障害検出方法によりデータの不整合を検出し、
前記障害からの回復およびデータの整合化を行うステップは、前記メインシステムのアプリケーションの開始時に復帰することにより障害回復を行うステップ、または、障害が発生したメインシステムのアプリケーションを再実行し正常に終了することにより障害回復を行うステップを有することを特徴とする障害回復方法。
【請求項９】
請求項４乃至請求項６のいずれかに記載の障害検出方法の各ステップと、前記請求項７に記載の障害検出方法の各ステップをコンピュータに実行させる障害検出プログラム。
【請求項１０】
請求項９に記載の障害検出プログラムが、前記コンピュータによる読み取りが可能な状態で記録された記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システム、障害検出方法、障害検出プログラム、及び記録媒体に関し、特に、メインのアプリケーションシステムとアプリケーションシステムからの実行命令により特定の処理を実行するサブシステム群からなる分散システムで、アプリケーションシステムとサブシステムでの複数の処理からなるトランザクション（必ずワンセットで実行されなければ意味のない、連続した更新処理グループ）を実行するコンテンツ配信システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
従来、ネットワーク上で映像コンテンツ等を販売・配信するシステムで、メインのアプリケーションシステムとアプリケーションシステムからの実行命令により特定の処理を実行するサブシステム群からなる分散システムであって、アプリケーションシステム側での処理とサブシステム側でのアプリケーションより命令された特定の処理という複数の処理からなるトランザクションにおいて、処理障害（トランザクション障害）が発生すると、アプリケーションシステムとサブシステムのデータベース間でデータ不整合が生ずる可能性がある。
【０００３】
従来、一般には、複数のサブシステムからなる分散システムにおいて、トランザクションにおけるサブシステム間のデータ整合性を保証するためには、各サブシステム側のデータベースでコミットする、言い換えるとデータ更新を確定する以前の予約状態を保持し、全てのサブシステムでコミット可能な状態であれば一斉にコミットする２フェーズ・コミットという手法を用いていた（たとえば、特許文献１を参照。）。
【０００４】
しかしながら、前記２フェーズ・コミットが使えるのは全てのサブシステムのコミットを一元的に制御できる場合のみであり、例えば、機能的に独立した市販のサブシステムを用いて構成されている分散システムでは、サブシステム側データベースのコミットはサブシステム側で行うため、アプリケーションシステムからはサブシステム側データベースのコミットを制御できないため、２フェーズ・コミットは適用できない。
【特許文献１】特開平８−２７８９０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明が解決しようとする問題点は、前記背景技術で説明したように、前記分散システムにおける前記サブシステムが機能的に独立した市販品などの場合には、データベースのコミットタイミングは、市販品サブシステムに委ねられており、メインのアプリケーションからは制御できないので前記２フェーズ・コミットという手法は使えないという点である。
【０００６】
本発明の目的は、前記２フェーズ・コミットを適用することができない分散システムにおいて、トランザクション障害が発生し、アプリケーションシステムとサブシステムのデータベース間でデータ不整合が生じた場合に、データ不整合が発生したことを検知し、データ不整合箇所を特定し、さらに不整合となったデータを修復して、システム全体のデータ整合性を保つことが可能な技術を提供することにある。
【０００７】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかになるであろう。
【課題を解決するための手段】
【０００８】
本願において開示される発明の概略を説明すれば、以下の通りである。
【０００９】
（１）  ネットワーク上で映像等のコンテンツを配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うコンテンツ配信システムであって、前記メインシステムは、アプリケーションが行う個別処理を前記サブシステムから呼び出す個別処理呼出手段と、前記個別処理呼出手段で呼び出した個別処理の開始通知および終了通知を蓄積する通知蓄積手段と、前記通知蓄積手段に蓄積された前記個別処理の開始通知及び終了通知に基づいて前記個別処理の障害を判定する障害判定手段とを備えるコンテンツ配信システムである。
【００１０】
（２）  前記（１）のコンテンツ配信システムにおいて、前記通知蓄積手段は、前記個別処理の開始通知および終了通知に加え、前記メインシステムのアプリケーションの処理の開始通知および終了通知を、前記個別処理の開始通知及び終了通知と関連づけて蓄積する。
【００１１】
（３）  前記（１）または（２）のコンテンツ配信システムにおいて、前記メインシステムは、前記各手段に加え、前記アプリケーションのデータベースに蓄積されたコンテンツ情報のレコードあるいはデータ項目を特定する参照テーブルを保持する参照テーブル保持手段を備える。
【００１２】
（４）  ネットワーク上で映像等のコンテンツを販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムの障害を検出する障害検出方法であって、前記メインシステムのアプリケーションが前記サブシステムの個別処理の呼び出しを行うステップ１と、前記個別処理の処理開始時に前記個別処理の開始通知を行うステップ２、および前記個別処理の開始通知の蓄積を行うステップ３と、前記個別処理の終了時に前記個別処理の終了通知を行うステップ４、および前記個別処理の終了通知の蓄積を行うステップ５と、前記個別処理が終了して前記アプリケーションに復帰をするステップ６と、蓄積した前記個別処理の開始通知と前記個別処理の終了通知を検索して前記個別処理の開始通知に対応する終了通知が存在するか否かの検査を行うステップ７と、前記個別処理の開始通知に対応する終了通知が存在する場合に前記個別処理を正常と判定し、前記個別処理の開始通知に対応する終了通知が存在しない場合に個別処理を障害と判定するステップ８とを有する障害検出方法である。
【００１３】
（５）  前記（４）の障害検出方法において、前記ステップ１乃至ステップ６を、複数のアプリケーションに対して行った場合、前記ステップ７は、各アプリケーションが呼び出した個別処理毎に、前記開始通知と前記開始通知に対応する終了通知が存在するか否かの検査を行い、前記ステップ８は、各アプリケーションが呼び出した個別処理毎に、前記開始通知と対応する終了通知が存在する場合は前記個別処理を正常と判定し、前記個別処理の開始通知に対応する終了通知が存在しない場合に個別処理を障害と判定する。
【００１４】
（６）  前記（５）の障害検出方法において、前記ステップ１の前に、前記アプリケーションの処理開始時に、処理の開始通知を行うステップ９、および前記アプリケーションの処理の開始通知の蓄積を行うステップ１０を有し、前記ステップ６とステップ７の間に、前記アプリケーションの処理の終了通知を行うステップ１１、および前記アプリケーションの処理の終了通知の蓄積を行うステップ１２を有し、前記ステップ７は、前記アプリケーション毎に、蓄積した前記各アプリケーションの処理の開始通知と前記アプリケーションの処理の終了通知を検索して前記処理の開始通知に対応する前記処理の終了通知が存在するか否かの検査を行い、かつ、蓄積した前記アプリケーションが呼び出した個別処理の開始通知と前記個別処理の終了通知を検索して前記個別処理の開始通知に対応する終了通知が存在するか否かの検査を行い、前記ステップ８は、前記アプリケーションの処理の開始通知に対応する終了通知が存在し、かつ、前記個別処理の開始通知に対応する終了通知が存在する場合は前記アプリケーションの個別処理を正常と判定し、前記アプリケーションの処理の開始通知に対応する終了通知が存在しない場合、または、前記個別処理の開始通知に対応する終了通知が存在しない場合は前記アプリケーションの個別処理を障害と判定する。
【００１５】
（７）  ネットワーク上で映像等のコンテンツを販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムで、メインシステムの複数のアプリケーションの各データベースに蓄積されたデータの不整合を検出する障害検出方法であって、前記メインシステムの各アプリケーションのデータベースに蓄積された各コンテンツ情報のレコードまたはデータ項目と、前記各アプリケーションのデータベースに蓄積された各レコードまたはデータ項目を参照項目として特定する参照テーブルを参照するステップと、検索すべき対象として、前記各データベースのレコードまたはデータ項目を前記参照テーブルにより特定するステップと、前記データベース毎に前記レコードまたはデータ項目を検索するステップと、検索した前記各データベースのレコードまたはデータ項目のうちのいずれかが存在しない場合、障害と判定するステップとを有する障害検出方法である。
【００１６】
（８）  ネットワーク上で映像コンテンツ等を販売・配信し、メインシステムのアプリケーションと、前記アプリケーションに呼出され、個別処理を行うサブシステムとにより前記コンテンツ配信を行うシステムで、障害を検出するステップ、およびデータの不整合を検出するステップ、ならびに前記障害からの回復およびデータの整合化を行うステップとを有する障害回復方法であって、障害を検出するステップは、前記（４）から（６）のいずれかの障害検出方法により障害を検出し、前記データの不整合を検出するステップは、前記（７）の障害検出方法によりデータの不整合を検出し、前記障害からの回復およびデータの整合化を行うステップは、前記メインシステムのアプリケーションの開始時に復帰することにより障害回復を行うステップ、または、障害が発生したメインシステムのアプリケーションを再実行し正常に終了することにより障害回復を行うステップを有する障害回復方法である。
【発明の効果】
【００１７】
本発明のコンテンツ配信システムは、前記（１）の手段のように、メインシステムに、前記アプリケーションが呼び出した個別処理の開始通知および終了通知を蓄積する通知蓄積手段を備えるので、前記アプリケーションの終了時に、前記アプリケーションが呼び出した個別処理の開始通知に対応する終了通知の有無を調べることで、前記個別処理の障害の有無を調べることができる。また、前記（２）の手段のように、前記通知蓄積手段に前記アプリケーションの処理の開始通知および終了通知も蓄積しておけば、複数のアプリケーションで同じ個別処理を呼び出した場合にも、どのアプリケーションが呼び出した個別処理において障害が発生したかがわかる。また、前記（３）の手段のように前記参照テーブルを保持しておけば、どのアプリケーションのデータベースのデータに不整合が生じているかがわかる。
【００１８】
また、前記（１）から（３）のコンテンツ配信システムを用いて前記個別処理の障害を検出するときには、前記（４）から（６）のいずれかの障害検出方法を実行すればよい。また、データの不整合を検出するときには、前記（７）の障害検出方法を実行すればよい。また、これらの方法で前記個別処理の障害あるいはデータの不整合を検出した場合、前記（８）の障害回復方法を実行すればよい。
【００１９】
本発明のコンテンツ配信システムにおける障害検出方法は、前記メインシステムのアプリケーションによる処理と前記サブシステムでの個別処理という複数の処理からなるトランザクションが開始された時点で、トランザクション開始通知（ログ）レコードを記録し、トランザクションが終了した時点でトランザクション終了通知（ログ）レコードを記録する。このとき、前記トランザクションの単位は、メインシステムのアプリケーションとサブシステムのデータベース間でデータ不整合が生じる処理の単位であり、前記トランザクションが障害となった場合、ロールバックもしくはロールフォワードして障害を回復する単位は前記トランザクションだけではなく、もう一段上位の、言い換えるともう一段大きな単位のトランザクションとなる場合がある。例えば、会員登録などの業務メニューに、複数のアプリケーションシステムとサブシステムのデータベース間でデータ不整合が生じるトランザクションが含まれ、そのうちの一つのトランザクションが障害となった場合、ロールバックもしくはロールフォワードして障害を回復する単位は障害が発生したトランザクションだけではなく、もう一段上位のトランザクションである業務メニューとする必要がある。そのため、業務メニュー開始時と終了時に業務メニュー名を含むログレコードをトランザクション開始終了ログと同様、記録する。ある時点において、トランザクション開始ログレコードとトランザクション終了ログレコードを照合し、トランザクション開始ログレコードに対応するトランザクション終了ログレコードが存在しない場合、あるいはトランザクション開始ログレコードとトランザクション終了ログレコードは対応しているが、トランザクション終了ログレコードに処理結果がエラーであると記録されていた場合、前記トランザクションが障害となったと特定できる。また、前記業務メニューのログもトランザクションログと同様、ある時点において、業務メニュー開始ログレコードと業務メニュー終了ログレコードを照合し、業務メニュー開始ログレコードに対応する業務メニュー終了ログレコードが存在しない場合、業務メニューに含まれるトランザクションが障害となったと特定できる。これらのログにより、障害が生じた業務メニューおよびトランザクションが特定できる。
【００２０】
また、情報的にアプリケーションのデータベースとサブシステムの個別処理のデータベースに対し、対象個別処理、対象データ構造をテーブル化しておき、データ不整合の検出処理において、このテーブルを参照して処理を行うことにより、効率的にデータ不整合検出処理を行うことができる。さらに、メインシステムのアプリケーションの開始時に復帰することにより障害回復を行う、または、前記メインシステムの次に実行すべきアプリケーションに進むことにより障害回復を行うことでデータ不整合の回復を行うことができる。
【００２１】
以下、本発明について、図面を参照して実施の形態（実施例）とともに詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは、同一符号を付け、その繰り返しの説明は省略する。
【発明を実施するための最良の形態】
【００２２】
本発明のコンテンツ配信システムにおける障害検出方法では、メインシステムのアプリケーションが個別処理を呼び出すときに個別処理の開始通知および終了通知を蓄積することで、前記個別処理の障害を検出する。また、参照テーブルを用いて各アプリケーションのデータベースに蓄積されたコンテンツ情報のレコードまたはデータ項目を特定し、検索することで、データの不整合を検出する。このようにすることで、２フェーズ・コミットを適用できない分散環境においてトランザクション障害が発生し、アプリケーションシステムとサブシステムのデータベース間でデータ不整合が生じた場合でも、データ不整合が発生したことを検知し、データ不整合箇所を特定し、さらに不整合となったデータを修復して、システム全体のデータ整合性を保つことができる。
【００２３】
また、前記メインシステムのアプリケーションは、映像等の配信システムにおいては、メニューまたはシナリオと呼ぶこともある。また、前記メインシステムのアプリケーションによる処理の具体的な例としては、ユーザ登録処理、商品購入・コース契約等がある。また、サブシステムの個別処理はトランザクションと呼ぶこともあり、実例として契約トランザクション、契約解除トランザクション、購入トランザクション等がある。
【００２４】
図１は、本発明にかかわるコンテンツ配信システムの概略構成を示す模式図である。
図１において、１はメインシステム、１０１はアプリケーション、ＡＰＬ１は第１アプリケーション、ＡＰＬ２は第２アプリケーション、１０２は個別処理呼出手段、１０３は通知蓄積手段、１０４は障害判定手段、１０５は参照テーブル保持手段、１０６は処理制御手段、２Ａ，２Ｂ，２ｎはサブシステム、３はユーザ端末である。
【００２５】
本発明のコンテンツ配信システムは、図１に示すように、メインシステム１と複数のサブシステム２Ａ，２Ｂ，２ｎからなる分散システムである。このとき、前記メインシステム１のアプリケーション１０１は、第１アプリケーションＡＰＬ１，第２アプリケーションＡＰＬ２等の複数のアプリケーションを有し、前記ユーザ端末３からの要求に応じて、いずれかのアプリケーションの処理が実行される。またこのとき、前記各アプリケーションは、必要に応じて前記サブシステム２Ａ，２Ｂ，２ｎのいずれかを呼び出し、個別処理を実行する。またこのとき、前記メインシステム１のアプリケーション１０１とサブシステム２Ａ，２Ｂ，２ｎでの個別処理からなるトランザクションは、必ずワンセットで実行されなければ意味のない、連続した更新処理グループであるとする。そのため、前記メインシステム１は、たとえば、図１に示すように、前記各アプリケーションＡＰＬ１，ＡＰＬ２等からサブシステム２Ａ，２Ｂ，２ｎの個別処理を呼び出す個別処理呼出手段１０２を備える。また、前記メインシステム１は、その他に、前記個別処理呼出手段１０２で呼び出した個別処理の開始通知及び終了通知等を蓄積する通知蓄積手段１０３と、前記通知蓄積手段１０３に蓄積された開始通知及び終了通知を用いてトランザクション障害やデータの不整合を検出する障害判定手段１０４とを備える。また、前記メインシステム１は、前記各手段に加え、前記データの不整合を検出する際に各アプリケーションＡＰＬ１，ＡＰＬ２のデータベース（ＤＢ）のレコードまたはデータ項目を特定するための参照テーブルを保持する参照テーブル保持手段１０５を備える。また、その他に、前記メインシステム１の前記アプリケーションおよび前記各手段で行う処理を制御する処理制御手段１０６を備える。またこのとき、前記通知蓄積手段１０３には、前記個別処理の開始通知および終了通知の他に、たとえば、前記アプリケーションＡＰＬ１，ＡＰＬ２の処理の開始通知および終了通知を蓄積することもできるとする。
【００２６】
以下、図１に示したコンテンツ配信システムにおけるトランザクション障害やデータ不整合の検出方法について説明する。
【実施例１】
【００２７】
図２は、本発明による実施例１の障害検出方法を説明するためのフロー図である。
【００２８】
本実施例１の障害検出方法は、前記メインシステム１で処理を行うアプリケーションが１つの場合に、前記個別処理の開始通知および終了通知からトランザクション障害を検出する方法である。以下、前記メインシステム１において第１アプリケーションＡＰＬ１の処理を行う場合を例に挙げ、本実施例１の前記トランザクション障害の検出方法を説明する。
【００２９】
本実施例１の障害検出方法では、まず、たとえば、図１に示したように、前記ユーザ端末３が前記メインシステム１にアクセス要求をした場合に、前記処理制御手段１０６は、前記第１アプリケーションＡＰＬ１に処理を実行させる。このとき、前記第１アプリケーションＡＰＬ１において、前記サブシステムのいずれか、たとえば、第１サブシステム２Ａによる個別処理が必要な場合、前記第１アプリケーションＡＰＬ１は前記個別処理呼出手段１０２を用いて、図２に示すように、前記第１サブシステム２Ａの個別処理（トランザクション）を呼び出す（ステップ４０１）。
【００３０】
このとき、前記第１サブシステム２Ａは、前記個別処理呼出手段１０２により呼び出された個別処理を開始する際に、前記個別処理呼出手段１０２に対して前記個別処理の開始通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記個別処理の開始通知を受信すると、前記開始通知を通知蓄積手段１０３に蓄積する（ステップ４０２）。その後、前記メインシステム１は、前記第１サブシステム２Ａにおける個別処理が終了するのを待つ（ステップ４０３）。
【００３１】
前記第１サブシステム２Ａは、前記個別処理が終了したら、前記メインシステム１の個別処理呼出手段１０２に対して個別処理の終了通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記個別処理の終了通知を受信すると、前記終了通知を通知蓄積手段１０３に蓄積する（ステップ４０４）。その後、前記メインシステム１は、前記個別処理から前記第１アプリケーションＡＰＬ１の処理に復帰する（ステップ４０５）。
【００３２】
前記ステップ４０５で第１アプリケーションＡＰＬ１に復帰した後、前記第１アプリケーションＡＰＬ１の処理が終了すると、前記メインシステム１では、次に、前記障害判定手段１０４において、前記通知蓄積手段１０３に蓄積した個別処理の開始通知と終了通知の検索を行う（ステップ４０６）。そして、前記障害判定手段１０４は、前記個別処理の開始通知と対応する終了通知が蓄積されているか否かを判定し（ステップ４０７）、蓄積されている場合は前記個別処理（トランザクション）が正常であると判定して処理を終了する（ステップ４０８）。一方、蓄積されていない場合は前記個別処理（トランザクション）が異常であると判定して障害の発生を通知した後、処理を終了する（ステップ４０９）。
【００３３】
以上説明したように、本実施例１の障害検出方法によれば、個別処理を呼び出したときに、前記個別処理の開始通知および終了通知を前記メインシステム１に蓄積し、蓄積した前記開始通知および終了通知から個別処理（トランザクション）の障害の有無を検出するので、前記サブシステム２Ａ，２Ｂ，２ｎが機能的に独立した市販品等であっても、前記個別処理の障害の有無を検出できる。
【実施例２】
【００３４】
図３は、本発明による実施例２の障害検出方法を説明するためのフロー図である。
【００３５】
本実施例２の障害検出方法は、前記メインシステム１で処理を行うアプリケーションが２つの場合に、第１アプリケーションＡＰＬ１が呼び出した個別処理の開始通知および終了通知と、第２アプリケーションＡＰＬ２が呼び出した個別処理の開始通知および終了通知から、前記第１アプリケーションＡＰＬ１あるいは第２アプリケーションＡＰＬ２のトランザクション障害を検出する方法である。以下、前記メインシステム１において前記第１アプリケーションＡＰＬ１、前記第２アプリケーションＡＰＬ２の順に処理を行う場合を例に挙げ、本実施例２のトランザクション障害の検出方法を説明する。
【００３６】
本実施例２の障害検出方法では、たとえば、図１に示したように、前記ユーザ端末３が前記メインシステム１にアクセス要求をした場合に、前記処理制御手段１０６は、まず、前記第１アプリケーションＡＰＬ１に処理を実行させる。このとき、前記第１アプリケーションＡＰＬ１において、前記サブシステムのいずれか、たとえば、前記第１サブシステム２Ａによる個別処理（以下、第１個別処理という）が必要な場合、前記第１アプリケーションＡＰＬ１は前記個別処理呼出手段１０２を用いて、図３に示すように、前記第１サブシステム２Ａの第１個別処理（トランザクション）を呼び出す（ステップ４０１１）。
【００３７】
このとき、前記第１サブシステム２Ａは、前記個別処理呼出手段１０２により呼び出された第１個別処理を開始する際に、前記個別処理呼出手段１０２に対して前記第１個別処理の開始通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記第１個別処理の開始通知を受信すると、前記開始通知を通知蓄積手段１０３に蓄積する（ステップ４０２１）。その後、前記メインシステム１は、前記第１サブシステム２Ａにおける個別処理が終了するのを待つ。
【００３８】
前記第１サブシステム２Ａは、前記第１個別処理が終了したら、前記メインシステム１の個別処理呼出手段１０２に対して個別処理の終了通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記個別処理の終了通知を受信すると、前記終了通知を通知蓄積手段１０３に蓄積する（ステップ４０４１）。その後、前記メインシステム１は前記第１個別処理から第１アプリケーションＡＰＬ１の処理に復帰する（ステップ４０５１）。
【００３９】
前記ステップ４０５１で第１アプリケーションＡＰＬ１に復帰した後、前記第１アプリケーションＡＰＬ１の処理が終了すると、前記メインシステム１では、次に、第２アプリケーションＡＰＬ２の処理を実行する。このとき、前記メインシステム１では、前記第１アプリケーションＡＰＬ１の処理と同様の処理が行われる。そして、前記第２アプリケーションＡＰＬ２において、前記サブシステムのいずれか、たとえば、第２サブシステム２Ｂによる個別処理（以下、第２個別処理という）が必要な場合、前記第２アプリケーションＡＰＬ２は前記個別処理呼出手段１０２を用いて、図３に示すように、前記第２サブシステム２Ｂの第２個別処理（トランザクション）を呼び出す（ステップ４０１２）。
【００４０】
このとき、前記第２サブシステム２Ｂは、前記個別処理呼出手段１０２により呼び出された第２個別処理を開始する際に、前記個別処理呼出手段１０２に対して前記第２個別処理の開始通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記第２個別処理の開始通知を受信すると、前記開始通知を通知蓄積手段１０３に蓄積する（ステップ４０２２）。その後、前記メインシステム１は、前記第２サブシステム２Ｂにおける個別処理が終了するのを待つ。
【００４１】
前記第２サブシステム２Ｂは、前記第２個別処理が終了したら、前記メインシステム１の個別処理呼出手段１０２に対して第２個別処理の終了通知を送信する。そして、前記メインシステム１の個別処理呼出手段１０２は、前記第２個別処理の終了通知を受信すると、前記終了通知を通知蓄積手段１０３に蓄積する（ステップ４０４２）。その後、前記メインシステム１は前記第２個別処理から第２アプリケーションＡＰＬ２の処理に復帰する（ステップ４０５２）。
【００４２】
前記ステップ４０５２で第２アプリケーションＡＰＬ２に復帰した後、前記第２アプリケーションＡＰＬ２の処理が終了すると、前記メインシステム１では、次に、前記障害判定手段１０４において、前記通知蓄積手段１０３に蓄積した個別処理の開始通知と終了通知の検索を行う（ステップ４０６）。本実施例２の場合、前記ステップ４０６は、アプリケーション毎の検索、すなわち前記第１アプリケーションＡＰＬ１が呼び出した第１個別処理の開始通知および終了通知の検索と、前記第２アプリケーションＡＰＬ２が呼び出した第２個別処理の開始通知および終了通知の検索を行う。そして、前記障害判定手段１０４は、前記アプリケーション毎に、前記各個別処理の開始通知と対応する終了通知が蓄積されているか否かを判定し（ステップ４０７）、蓄積されている場合は前記各個別処理（トランザクション）が正常であると判定して処理を終了する（ステップ４０８）。つまり、前記第１アプリケーションＡＰＬ１が呼び出した第１個別処理の開始通知に対応する終了通知が存在し、かつ、前記第２アプリケーションＡＰＬ２が呼び出した第２個別処理の開始通知に対応する終了通知が存在する場合は、前記各個別処理が正常であると判定して処理を終了する。
【００４３】
一方、前記第１アプリケーションＡＰＬ１が呼び出した第１個別処理の開始通知に対応する終了通知が存在しない場合、または前記第２アプリケーションＡＰＬ２が呼び出した第２個別処理の開始通知に対応する終了通知が存在しない場合は、終了通知が存在しない個別処理（トランザクション）が異常であると判定して障害の発生を通知した後、処理を終了する（ステップ４０８）。
【００４４】
以上説明したように、本実施例２の障害検出方法によれば、個別処理を呼び出したときに、前記個別処理の開始通知および終了通知を前記メインシステムに蓄積し、蓄積した前記開始通知および終了通知から個別処理（トランザクション）の障害の有無を検出するので、サブシステムが機能的に独立した市販品等であっても、前記個別処理の障害の有無を検出できる。
【００４５】
また、本実施例２では、前記第１アプリケーションＡＰＬ１および第２アプリケーションＡＰＬ２の２つのアプリケーションを連続して実行する場合を例に挙げて説明したが、これに限らず、３つ以上のアプリケーションを連続して実行する場合にも、本実施例２と同様の手順でトランザクション障害を検出することができる。
【実施例３】
【００４６】
図４は、本発明による実施例３の障害検出方法を説明するためのフロー図である。
【００４７】
本実施例３の障害検出方法は、前記実施例２と同様に、前記メインシステム１で処理を行うアプリケーションが２つの場合に、第１アプリケーションＡＰＬ１が呼び出した個別処理の開始通知および終了通知と、第２アプリケーションＡＰＬ２が呼び出した個別処理の開始通知および終了通知から、前記第１アプリケーションＡＰＬ１あるいは第２アプリケーションＡＰＬ２のトランザクション障害を検出する方法である。ただし、本実施例３の障害検出方法では、前記実施例２の障害検出方法と異なり、前記各アプリケーションＡＰＬ１，ＡＰＬ２が呼び出す個別処理の開始通知および終了通知に加え、前記メインシステム１で行う各アプリケーションＡＰＬ１，ＡＰＬ２の処理の開始通知および終了通知も蓄積し、トランザクション障害の検出に用いる。以下、前記メインシステム１において前記第１アプリケーションＡＰＬ１、前記第２アプリケーションＡＰＬ２の順に処理を行う場合を例に挙げ、本実施例３のトランザクション障害の検出方法を説明する。
【００４８】
本実施例３の障害検出方法では、たとえば、図１に示したように、前記ユーザ端末３が前記メインシステム１にアクセス要求をした場合に、前記処理制御手段１０６は、まず、前記第１アプリケーションＡＰＬ１に処理を実行させる。このとき、前記第１アプリケーションＡＰＬ１は、図４に示すように、たとえば、前記処理制御手段１０６に対して処理の開始を通知し、前記通知蓄積手段１０６に蓄積させる（ステップ４１０１）。
【００４９】
その後、前記第１アプリケーションＡＰＬ１の処理において、前記サブシステム２Ａ，２Ｂ，２ｎのいずれかによる個別処理が必要な場合、前記第１アプリケーションＡＰＬ１は前記個別処理呼出手段１０２を用いて個別処理（トランザクション）を呼び出し、前記サブシステムに個別処理を実行させる。このとき、前記メインシステム１では、たとえば、前記実施例２で説明したステップ４０１１からステップ４０５１までの処理を行う（ステップ４１１１）。
【００５０】
前記ステップ４１１１、すなわち前記実施例２で説明したステップ４０１１からステップ４０５１までの処理が済み、前記個別処理から第１アプリケーションＡＰＬ１に復帰した後、前記第１アプリケーションＡＰＬ１の処理が終了すると、前記第１アプリケーションＡＰＬ１は、たとえば、前記処理制御手段１０６に対して処理の終了を通知し、前記通知蓄積手段１０３に蓄積させる（ステップ４１２１）。
【００５１】
前記メインシステム１では、前記第１アプリケーションＡＰＬ１の処理が終了すると、次に、第２アプリケーションＡＰＬ２の処理を実行する。このとき、前記メインシステム１では、前記第１アプリケーションＡＰＬ１の処理と同様の処理が行われ、前記第２アプリケーションＡＰＬ２は、まず、たとえば、前記処理制御手段１０６に対して処理の開始を通知し、前記通知蓄積手段１０３に蓄積させる（ステップ４１０２）。
【００５２】
その後、前記第２アプリケーションＡＰＬ２の処理において、前記サブシステム２Ａ，２Ｂ，２ｎのいずれかによる個別処理が必要な場合、前記第２アプリケーションＡＰＬ２は前記個別処理呼出手段１０２を用いて個別処理（トランザクション）を呼び出し、前記サブシステムに個別処理を実行させる。このとき、前記メインシステム１では、たとえば、前記実施例２で説明したステップ４０１２からステップ４０５２までの処理を行う（ステップ４１１２）。
【００５３】
前記ステップ４１１２、すなわち前記実施例２で説明したステップ４０１２からステップ４０５２の処理が済み、前記個別処理から第２アプリケーションＡＰＬ２に復帰した後、前記第２アプリケーションＡＰＬ２の処理が終了すると、前記第２アプリケーションＡＰＬ２は、たとえば、前記処理制御手段１０６に対して処理の終了を通知し、前記通知蓄積手段１０３に蓄積させる（ステップ４１２２）。
【００５４】
前記ステップ４１２２で前記第２アプリケーションＡＰＬ２の処理の終了通知を蓄積すると、前記メインシステム１では、次に、前記障害判定手段１０４において、前記通知蓄積手段１０３に蓄積した個別処理の開始通知と終了通知の検索を行う（ステップ４０６）。本実施例３の場合も、前記ステップ４０６は、前記実施例２の場合と同様に、アプリケーション毎の検索を行う。ただし、本実施例３の場合は、前記第１アプリケーションＡＰＬ１の処理の開始通知および終了通知と前記第１アプリケーションＡＰＬ１が呼び出した個別処理の開始通知および終了通知、前記第２アプリケーションＡＰＬ２の処理の開始通知および終了通知と前記第２アプリケーションＡＰＬ２が呼び出した個別処理の開始通知および終了通知の検索をする。
【００５５】
そして、前記障害判定手段１０４は、前記アプリケーション毎に、前記個別処理の開始通知と対応する終了通知が蓄積されているか否かを判定し（ステップ４０７）、蓄積されている場合は前記個別処理（トランザクション）が正常であると判定して処理を終了する（ステップ４０８）。つまり、前記第１アプリケーションＡＰＬ１の処理の開始通知に対応する終了通知が存在し、かつ、前記第１アプリケーションＡＰＬ１が呼び出した個別処理の開始通知に対応する終了通知が存在する場合、前記第１アプリケーションＡＰＬ１が呼び出した個別処理が正常であると判断する。同様に、前記第２アプリケーションＡＰＬ２の処理の開始通知に対応する終了通知が存在し、かつ、前記第２アプリケーションＡＰＬ２が呼び出した個別処理の開始通知に対応する終了通知が存在する場合、前記第２アプリケーションＡＰＬ２が呼び出した個別処理が正常であると判断する。
【００５６】
一方、前記第１アプリケーションＡＰＬ１の処理の開始通知に対応する終了通知、あるいは前記第１アプリケーションＡＰＬ１が呼び出した個別処理の開始通知に対応する終了通知のいずれかまたは両方が存在しない場合、前記第１アプリケーションＡＰＬ１が呼び出した個別処理が異常であると判定して障害の発生を通知した後、処理を終了する（ステップ４０９）。同様に、前記第２アプリケーションＡＰＬ２の処理の開始通知に対応する終了通知、あるいは前記第２アプリケーションＡＰＬ２が呼び出した個別処理の開始通知に対応する終了通知のいずれかまたは両方が存在しない場合、前記第２アプリケーションＡＰＬ２が呼び出した個別処理が異常であると判定して障害の発生を通知した後、処理を終了する。
【００５７】
図５は、本実施例３の障害検出方法の作用効果を説明するための模式図であり、図５（ａ）は前記実施例２の方法における判定結果の一例を示す図、図５（ｂ）は前記実施例２の方法における問題点を説明するための図、図５（ｃ）は本実施例３の方法における判定結果の一例を示す図である。
【００５８】
前記実施例２の障害検出方法を用いた場合、たとえば、前記第２アプリケーションＡＰＬ２が呼び出した個別処理が、前記第１アプリケーションＡＰＬ１が呼び出した前記第１個別処理と異なる第２個別処理である場合、図５（ａ）に示すように、前記第１個別処理の開始通知に対応する終了通知がなければ前記第１個別処理に障害が発生したことから、第１アプリケーションＡＰＬ１の実行時に障害が発生したことがわかる。同様に、前記第２個別処理の開始通知に対応する終了通知がなければ前記第２個別処理に障害が発生したことから、第２アプリケーションＡＰＬ２の実行時に障害が発生したことがわかる。
【００５９】
ところが、実際のコンテンツ配信システムでは、たとえば、前記第２アプリケーションＡＰＬ２が、前記第１アプリケーションＡＰＬ１が呼び出した第１個別処理を呼び出すこともある。このような例としては、映像配信システムにおいて、前記第１アプリケーションＡＰＬ１のユーザ登録で契約処理（第１個別処理）を行い、前記第２アプリケーションＡＰＬ２の商品・コース購入で、同じ契約処理（第１個別処理）が行われる場合がある。この例の場合、同じ契約処理（第１個別処理）が実行される。そのため、前記実施例２の障害検出方法の場合、図５（ｂ）に示すように、前記第１アプリケーションＡＰＬ１が呼び出した第１個別処理の開始通知に対応する終了通知、または前記第２アプリケーションＡＰＬ２が呼び出した第１個別処理の開始通知に対応する終了通知のいずれかが存在しない場合、前記第１個別処理でトランザクション障害が発生したことはわかるが、第１アプリケーションＡＰＬ１の処理中の第１個別処理（契約処理）と第２アプリケーションＡＰＬ２の処理中の第１個別処理（契約処理）のどちらで障害が発生したかまではわからない。つまり、前記実施例２の障害検出方法では、複数のアプリケーションで同じ個別処理を呼び出した場合、障害発生箇所の特定ができないという問題がある。
【００６０】
一方、本実施例３の障害検出方法では、前記各アプリケーションの処理の開始通知および終了通知もあわせて判定する。そのため、たとえば、図５（ｃ）に示したように、前記第１アプリケーションＡＰＬ１が呼び出した個別処理の終了通知または前記第１アプリケーションＡＰＬ１の処理の終了通知が存在しなければ、前記第１アプリケーションＡＰＬ１の処理中の個別処理にトランザクション障害が発生したことがわかる。また、前記第２アプリケーションＡＰＬ２が呼び出した個別処理の終了通知または前記第２アプリケーションＡＰＬ２の処理の終了通知が存在しなければ、前記第２アプリケーションＡＰＬ２の処理中の個別処理にトランザクション障害が発生したことがわかる。その結果、前記第１アプリケーションＡＰＬ１および第２アプリケーションＡＰＬ２で同じ個別処理を呼び出した場合でも、障害発生箇所、すなわちどちらのアプリケーションの処理中に前記個別処理の障害が発生したかの特定が可能となる。
【００６１】
以上説明したように、本実施例３の障害検出方法によれば、個別処理を呼び出したときに、前記個別処理の開始通知および終了通知を前記メインシステムに蓄積し、蓄積した前記開始通知および終了通知から個別処理（トランザクション）の障害の有無を検出するので、サブシステムが機能的に独立した市販品等であっても、前記個別処理の障害の有無を検出できる。
【００６２】
また、前記個別処理を呼び出したアプリケーションの処理の開始通知および終了通知を、前記個別処理の開始通知および終了通知と関連づけて蓄積しておくことで、複数のアプリケーションで同じ個別処理を呼び出している場合でも、障害発生箇所の特定が可能となる。
【実施例４】
【００６３】
図６および図７は、本発明による実施例４の障害検出方法を説明するための模式図であり、図６は検出手順を示すフロー図、図７は参照テーブルの一例を示す図である。
【００６４】
前記実施例１乃至実施例３では、前記メインシステムのアプリケーションが呼び出した個別処理の障害（トランザクション障害）の検出方法について説明したが、前記コンテンツ配信システムでは、前記トランザクション障害の他に、たとえば、データの不整合という障害もある。そこで、本実施例４では、前記データ不整合の検出方法について説明する。
【００６５】
本実施例４のデータ不整合の検出処理は、たとえば、前記実施例１乃至実施例３で説明したようなトランザクション障害の検出処理の後に行われる。このとき、前記メインシステム１では、まず、図６に示すように、前記参照テーブル保持手段１０５で保持している参照テーブルを参照して、前記メインシステム１の第１アプリケーションＡＰＬ１のデータベースに蓄積されたコンテンツ情報のレコード（以下、第１レコードという）と、前記メインシステム１の第２アプリケーションＡＰＬ２のデータベースに蓄積されたコンテンツ情報のレコード（以下、第２レコードという）を特定する（ステップ５０１）。前記参照テーブルは、ある情報に関する処理を行う際に、どのデータベースを参照するかをまとめたテーブルであり、たとえば、図７に示すように、エンドユーザ情報に関する処理を行う際には、課金・決済データベースおよび蓄積検索データベースを参照することになる。
【００６６】
前記ステップ５０１で前記第１レコードおよび第２レコードを特定したら、次に、前記第１アプリケーションＡＰＬ１のデータベースの第１レコード、および前記第２アプリケーションＡＰＬ２のデータベースの第２レコードを検索する（ステップ５０２）。そして、前記ステップ５０２で前記各アプリケーションのデータベースを検索した結果、前記第１レコードおよび第２レコードが存在するか否かを判定し（ステップ５０３）、前記第１レコードおよび第２レコードがともに存在する、あるいはともに存在しない場合は正常であると判定して処理を終了する（ステップ５０４）。一方、前記第１レコードまたは第２レコードのいずれかのみが存在する場合、異常であると判定して障害（データ不整合）の発生を通知して処理を終了する（ステップ５０５）。
【００６７】
以上説明したように、本実施例４の障害検出方法によれば、前記メインシステム１の各アプリケーションが持つデータベースのレコードの有無を利用してデータ不整合を検出できる。そのため、前記コンテンツ配信システムが、たとえば、サブシステムが機能的に独立した市販品等の場合のように、従来の２フェーズ・コミットを適用できない分散システムである場合でも、データの不整合を検出することができる。
【００６８】
また、本実施例４の障害検出方法では、前記メインシステムの各アプリケーションが持つデータベースのレコードの有無を利用したが、これに限らず、たとえば、前記データベースに蓄積されたコンテンツ情報のデータ項目を特定してデータ不整合の検出をしても良い。この場合、たとえば、データ項目を参照テーブルに蓄積する方法を用いることにより、実際のアプリケーションにおいて、必要なデータ項目の変更があった場合、参照テーブルを変更することで対応可能であり、柔軟な対応ができるというメリットがある。
【実施例５】
【００６９】
図８は、本発明による実施例５の障害回復方法を説明するためのフロー図である。
【００７０】
前記実施例１乃至実施例３では、メインシステム１のアプリケーションが呼び出した個別処理の障害（トランザクション障害）の検出方法について説明し、前記実施例４では、データ不整合の検出方法について説明した。そこで、本実施例５では、前記各実施例で説明した障害検出方法で障害あるいはデータ不整合を検出した場合に、その障害から回復する方法について説明する。
【００７１】
本実施例５の障害回復方法では、まず、図８に示すように、たとえば、前記実施例３で説明した前記ステップ４１０１からステップ４０９までの処理、すなわち各アプリケーションの処理および個別処理を行った後、前記個別処理の障害（トランザクション障害）の検出処理を行う（ステップ６０１）。なお、前記ステップ６０１は、たとえば、前記実施例１で説明したステップ４０１からステップ４０９の処理、あるいは前記実施例２で説明したステップ４０１１からステップ４０９の処理であってもよい。
【００７２】
前記ステップ６０１で前記トランザクション障害に関する検出を行ったら、次に、前記実施例４で説明したステップ５０１からステップ５０５までの処理を行い、データ不整合の検出処理を行う（ステップ６０２）。
【００７３】
前記ステップ６０１およびステップ６０２の処理が済んだら、前記トランザクション障害あるいはデータ不整合を検出したか否かを判定し（ステップ６０３）、検出しなかった場合は何もせず処理を終了する。
【００７４】
一方、前記トランザクション障害あるいはデータ不整合のいずれか、または両方を検出した場合、前記メインシステム１は、たとえば、ロールバック、すなわちメインシステム１のアプリケーションの開始時に復帰することで障害から回復する（ステップ６０４）。また、前記ステップ６０４では、前記ロールバックの代わりにロールフォワード、すなわち前記メインシステム１の障害が発生したアプリケーションを再実行し正常に終了することで障害から回復してもよい。
【００７５】
以上説明したように、本実施例５の障害回復方法によれば、前記実施例１乃至実施例３で説明した個別処理の障害（トランザクション障害）の検出方法、および前記実施例４で説明したデータ不整合の検出方法を用いて障害を検出している。そのため、前記コンテンツ配信システムが、たとえば、サブシステムが機能的に独立した市販品等の場合のように、従来の２フェーズ・コミットを適用できない分散システムである場合でも、前記トランザクション障害やデータ不整合を検出することができ、前記障害から容易に回復することができる。その結果、前記２フェーズ・コミットを適用できない分散システムにおいても、前記トランザクションにおけるサブシステム間のデータ整合性を保証することができる。
【００７６】
以上、本発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において、種々変更可能であることはもちろんである。
【００７７】
たとえば、前記各実施例で説明した障害検出処理を行うメインシステムは、コンピュータとプログラムを用いて実現することもできる。この場合、前記実施例で説明したような処理手順を前記コンピュータに実行させるプログラムを作成し、前記コンピュータにインストールすればよい。このとき、前記プログラムは、たとえば、磁気的、電気的、あるいは光学的な記録媒体に記録して提供することもできるし、インターネット等のネットワークを介して提供することもできる。
【図面の簡単な説明】
【００７８】
【図１】本発明にかかわるコンテンツ配信システムの概略構成を示す模式図である。
【図２】本発明による実施例１の障害検出方法を説明するためのフロー図である。
【図３】本発明による実施例２の障害検出方法を説明するためのフロー図である。
【図４】本発明による実施例３の障害検出方法を説明するためのフロー図である。
【図５】本実施例３の障害検出方法の作用効果を説明するための模式図であり、図５（ａ）は前記実施例２の方法における判定結果の一例を示す図、図５（ｂ）は前記実施例２の方法における問題点を説明するための図、図５（ｃ）は本実施例３の方法における判定結果の一例を示す図である。
【図６】本発明による実施例４の障害検出方法を説明するための模式図であり、検出手順を示すフロー図である。
【図７】本発明による実施例４の障害検出方法を説明するための模式図であり、参照テーブルの一例を示す図である。
【図８】本発明による実施例５の障害回復方法を説明するためのフロー図である。
【符号の説明】
【００７９】
１…メインシステム
１０１…アプリケーション
１０２…個別処理呼出手段
１０３…通知蓄積手段
１０４…障害判定手段
１０５…参照テーブル保持手段
１０６…処理制御手段
ＡＰＬ１…第１アプリケーション
ＡＰＬ２…第２アプリケーション
２Ａ，２Ｂ，２ｎ…サブシステム
３…ユーザ端末
【図１】
2005339091.tif 000003
【図２】
2005339091.tif 000004
【図３】
2005339091.tif 000005
【図４】
2005339091.tif 000006
【図５】
2005339091.tif 000007
【図６】
2005339091.tif 000008
【図７】
2005339091.tif 000009
【図８】
2005339091.tif 000010