(57)【要約】【課題】  データベース・クライアントに対するデータベースの状態変更の通知メカニズムを提供すること。【解決手段】  本発明の情報管理サーバ１０は、データベースの状態変更の条件と通知アクションとを対応付けて登録する登録部５８と、クライアント９０に対し確立されたデータベース接続を介して、状態変更通知の取得要求を受信する通信部５６と、取得要求の条件に合致する状態変更を検知して、対応する通知アクションを呼び出す変更検知部７０と、通知アクションの結果を含む通知を、通信部５６に対し取得要求への応答としてデータベース接続を介して送信させて、接続の制御を前記クライアントに戻す通知部６４とを含む。【選択図】図２
2010026744.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してクライアントから接続される情報管理サーバであって、
データベースの状態変更と通知アクションとを対応付けて登録する登録部と、
前記クライアントに対し確立されたデータベース接続を介して、状態変更通知の取得要求を受信する通信部と、
登録された前記状態変更の発生を検知して、対応する通知アクションを呼び出す変更検知部と、
前記取得要求の通知アクションの結果を含む通知を、前記通信部に対し前記取得要求への応答として前記データベース接続を介して送信させて、前記接続の制御を前記クライアントに戻す通知部と
を含む、情報管理サーバ。
【請求項２】
前記状態変更通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、前記状態変更通知の取得エラーを前記結果として与える取消部をさらに含む、請求項１に記載の情報管理サーバ。
【請求項３】
前記状態変更通知の取得要求に応答して作動され、満了に応答して前記状態変更通知の取得期限満了を前記結果として与えるタイマ部をさらに含む、請求項１に記載の情報管理サーバ。
【請求項４】
他のデータベース接続を介して受信した中断指令に応答して、前記状態変更通知の取得中断を前記結果として与える中断部をさらに含む、請求項１に記載の情報管理サーバ。
【請求項５】
前記通信部は、前記状態変更通知との依存関係が指定されているデータベース接続の切断に応答して、前記状態変更通知の取得中断を前記結果として与える、請求項１に記載の情報管理サーバ。
【請求項６】
契機とする状態変更および通知アクションからなる状態変更通知を定義付けて持続的に格納させる作成部、定義を読み出して前記契機とする状態変更を前記変更検知部による検知の対象とし、状態変更通知の処理動作を開始させる開始部、および定義を消去して状態変更通知を削除する削除部を含む、請求項１に記載の情報管理サーバ。
【請求項７】
データベースを管理する情報管理サーバと、ネットワークを介して前記情報管理サーバに接続するクライアントとを含む情報処理システムであって、
前記情報管理サーバは、
データベースの状態変更と通知アクションとを対応付けて登録する登録部と、
前記クライアントに対し確立されたデータベース接続を介して、状態変更通知の取得要求を受信する通信部と、
登録された前記状態変更の発生を検知して、対応する通知アクションを呼び出す変更検知部と、
前記取得要求の通知アクションの結果を含む通知を、前記通信部に対し前記取得要求への応答として前記データベース接続を介して送信させて、前記接続の制御を前記クライアントに戻す通知部とを含み、
前記クライアントは、
前記状態変更通知の取得要求を発行し、該取得要求に対する応答として取得した前記通知に従った処理を実行するクライアント・アプリケーションを含む、
情報処理システム。
【請求項８】
前記情報管理サーバが、前記状態変更通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、前記状態変更通知の取得エラーを前記結果として与える取消部をさらに含む、請求項７に記載の情報処理システム。
【請求項９】
ネットワークを介してクライアントから接続される情報管理サーバが実行する通信方法であって、前記情報管理サーバが、
前記クライアントに対し確立されたデータベース接続を介して、データベースの状態変更通知の取得要求を受信するステップと、
登録されたデータベースの状態変更の発生を検知して、前記状態変更と通知アクションとを対応付ける登録を参照して、対応する通知アクションを呼び出すステップと、
前記取得要求の通知アクションの結果を含む通知を、前記取得要求への応答として前記データベース接続を介して送信し、前記接続の制御を前記クライアントに戻すステップと
を実行する、通信方法。
【請求項１０】
前記情報管理サーバが、前記状態変更通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、前記状態変更通知の取得エラーを前記結果として与えるステップをさらに実行する、請求項９に記載の通信方法。
【請求項１１】
前記情報管理サーバが、前記状態変更通知の取得要求に応答してタイマを作動させるステップと、タイマの満了に応答して前記状態変更通知の取得期限満了を前記結果として与えるステップとをさらに実行する、請求項９に記載の通信方法。
【請求項１２】
前記情報管理サーバが、他のデータベース接続を介して受信した中断指令に応答して、前記状態変更通知の取得中断を前記結果として与えるステップをさらに実行する、請求項９に記載の通信方法。
【請求項１３】
前記情報管理サーバが、前記状態変更通知との依存関係が指定されているデータベース接続の切断に応答して、前記状態変更通知の取得中断を前記結果として与えるステップをさらに実行する、請求項９に記載の通信方法。
【請求項１４】
コンピュータ読取可能な記録媒体に記録されたコンピュータ実行可能なプログラムであって、コンピュータに対し、
データベースの状態変更と通知アクションとを対応付けて登録する登録部と、
前記クライアントに対し確立されたデータベース接続を介して、状態変更通知の取得要求を受信する通信部と、
登録された前記状態変更の発生を検知して、対応する通知アクションを呼び出す変更検知部と、
前記取得要求の通知アクションの結果を含む通知を、前記通信部に対し前記取得要求への応答として前記データベース接続を介して送信させて、前記接続の制御を前記クライアントに戻す通知部と
を実現させる、プログラム。
【請求項１５】
前記コンピュータに対し、前記状態変更通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、前記状態変更通知の取得エラーを前記結果として与える取消部をさらに実現させる、請求項１４に記載のプログラム。
【請求項１６】
ネットワークを介してクライアントから接続される情報管理サーバであって、
データベースの状態変更と通知アクションとを対応付けて登録する登録部と、
前記クライアントに対し確立されたデータベース接続を介して、状態変更通知の取得要求を受信する通信部と、
登録された前記状態変更の発生を検知して、対応する通知アクションを呼び出す変更検知部と、
前記取得要求の通知アクションの結果を含む通知を、前記通信部に対し前記取得要求への応答として前記データベース接続を介して送信させて、前記接続の制御を前記クライアントに戻す通知部と、
前記状態変更通知の取得要求に応答して作動され、満了に応答して前記状態変更通知の取得期限満了を前記結果として与えるタイマ部と、
他のデータベース接続を介して受信した中断指令に応答して、前記状態変更通知の取得中断を前記結果として与える中断部と、
契機とする状態変更および通知アクションからなる状態変更通知を定義付けて持続的に格納させる作成部と、
定義を読み出して前記契機とする状態変更を前記変更検知部による検知の対象とし、状態変更通知の処理動作を開始させる開始部と、
定義を消去して状態変更通知を削除する削除部を含み、前記通信部は、前記状態変更通知との依存関係が指定されているデータベース接続の切断に応答して、前記状態変更通知の取得中断を前記結果として与える、情報管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース技術に関し、より詳細には、データベース・クライアントに対するデータベースの状態変更の通知メカニズムに関する。
【背景技術】
【０００２】
近年、官公庁および企業などにおいて、種々の活動に伴って発生する膨大なデータを管理するために、大規模データベース・システムを構築することが広く行われている。さらに、データベースの利用形態も多様化し、一般的な業務データベースの他、活動の計画および実績を記録し、プロジェクトなどの進捗を管理するためのワークフロー管理システムや、製造および出荷履歴や取引履歴など様々な活動の履歴を記録し、必要に応じて迅速に情報にアクセスするためのトレーサビリティシステムを実現する際にもデータベース・システムが利用されている。
【０００３】
例えば上記ワークフロー管理およびトレーサビリティの用途において、データベースの状態変更（追加／更新／削除）に応答して、何らかのアクションを発生させたいという要望がある。例えばワークフロー管理では、業務の完了に応答して続く新たな業務を発生させたり、トレーサビリティでは、状態が時々刻々と変化するなか、登録したイベント発生に応答してアラート等の表示を行いたいという要望もある。また、データベースの状態に応じた表示を行うクライアントＧＵＩ（Graphical User Interface）アプリケーションでは、状態変更を即時的に反映させたいという要望もある。
【０００４】
上記データベースの状態変更に応答したアクションに関連して、従来からのデータベース管理システム（Database Management System：ＤＢＭＳ）には、予め登録されたデータベースの状態更新（追加／更新／削除）に応答して、予め指定した処理を呼び出すトリガ（ＴＲＩＧＧＥＲ）機能を備えている。この機能は、内容が連動する複数のデータベースやテーブルにおいて、１つに対して為された変更を他に反映する処理のために利用されている。
【０００５】
図１２は、トリガ機能を用いるステートメントの例文を示す。図１２（Ａ）には、ＥＭＰＬＯＹＥＥテーブルにレコードが追加された際に、ＣＯＭＰＡＮＹ＿ＳＴＡＴＳテーブルのＮＢＥＭＰの数を１つ増加させるトリガを定義するステートメントの例文が示されている。図１２（Ｂ）には、在庫の数がＭＡＸ＿ＳＴＯＣＫＥＤでなくなった際に、ユーザ定義関数（ＩＳＳＵＥ＿ＳＨＩＰ＿ＲＥＱＵＥＳＴ）により追加部品の注文書を発注先に送信するトリガを定義するステートメントの例文が示されている。このように、ＤＢＭＳのトリガ機能を用いることにより、データベースの状態変更（追加／更新／削除）に応答してアクションを発生させることができる。
【０００６】
一方、上記のようなデータベースの状態変更をデータベース・クライアント（以下、ＤＢクライアントとして参照する。）が検知するメカニズムとしては、一例として、定期的にＳＱＬ文を発行してデータを取得し、データの追加・更新・削除が実行されていないかをチェックする、ポーリング方式を挙げることができる。また、他のデータベースの状態変更を検知するメカニズムとしては、ＤＢＭＳのトリガ機能と、アプリケーション間の通信機能を提供するＭＱ（Message Queuing）機能とを利用し、データベースのトリガによりデータベースの状態変更（追加／更新／削除）を検出して、外部のＭＱを利用してクライアントへメッセージを送信する、外部機構を利用するイベント通知方式を挙げることができる。その他、データベースを利用する複数のアプリケーション間の結合を密にし、データの追加・更新・削除を行ったアプリケーションが、その状態変更に応答して次ぎのアクションを実行するアプリケーションへ通知する、アプリケーション対応方式などを挙げることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記ポーリング方式では、ＤＢＭＳ側のサーバ（以下、サーバとして参照する。）に対し定期的にＳＱＬ文が発行されるため、サーバにかかる負荷が大きく、ネットワーク負荷も大きく、また所定の間隔を空けてポーリングが行われるため、イベント検知の即時性の観点から充分なものではなかった。
【０００８】
上記外部機構を利用するイベント通知方式では、サーバでは、クライアントとイベント通知のメッセージを交換するためのポートを別途オープンする必要があり、セキュリティ脆弱性を引き起こす蓋然性が有り、ネットワーク・セキュリティ上の観点から充分なものではなかった。また、上記イベント通知方式では、外部モジュールのＭＱ機能に適合させてアプリケーションを開発し、かつ、アプリケーションごとにＭＱ経由でやりとりされるデータのフォーマットを定義する必要があった。
【０００９】
また、上記アプリケーション対応方式では、アプリケーション間が密結合となってしまい、またアプリケーション間で連携する仕組みを構築する必要があり、アプリケーションの独立性および拡張性の観点から充分なものではなかった。
【００１０】
本発明は、上記問題点に鑑みてなされたものであり、本発明は、データの追加・更新・削除といったデータベースの状態変更に応答して、ＤＢクライアントに対して該状態変更を通知するイベント通知メカニズムを、低負荷、高セキュリティ、かつ高いアプリケーションの独立性を維持しつつ実現する情報管理サーバ、該情報管理サーバを含む情報処理システム、該情報管理サーバが実行する通信方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明では、上記課題を解決するために、情報管理サーバは、データベース接続を介してクライアントから受信したデータベースの状態変更通知の取得要求に対し、登録された状態変更の発生を検知して呼び出された通知アクションの結果を含む通知を、同データベース接続を介して、接続の制御を前記クライアントに戻すとともに応答する。通知アクションとその契機となるデータベースの状態変更とは、対応付けて登録している。
【００１２】
上記構成により、取得要求で使用したデータベース接続を介して、状態変更に応答した通知が取得要求に対する応答として行われるため、クライアントが必要としてから状態変更が発生するまでの間に、余分なネットワーク・トラフィックや照会処理を発生させる必要がなく、また通知のためのポートを別途開ける必要もなく、またクライアント側のアプリケーション間で密に連携させる必要もなく、クライアントは、要するデータベースの状態変更を知ることが可能となる。したがって、本発明によれば、低負荷、高セキュリティ、かつ高いアプリケーションの独立性を維持しつつ、クライアントに対して状態変更を通知するメカニズムが実現される。
【００１３】
本発明では、さらに、情報管理サーバは、上記状態変更通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、状態変更通知の取得エラーを上記結果として与える取消部をさらに含むことができる。これにより、取得要求の条件に合致する状態変更を検知する前であっても、通知が不要となった場合に、クライアントは、取得要求を撤回することができ、状態変更通知のために維持されていたデータベース接続を他の処理に開放することができる。
【００１４】
本発明では、上記取消部は、状態変更通知の取得要求に応答して作動され満了に応答して状態変更通知の取得期限満了を上記結果として与えるタイマ部とすることができる。さらに本発明では、上記取消部は、他のデータベース接続を介して受信した中断指令に応答して、状態変更通知の取得中断を上記結果として与える中断部とすることができる。また本発明では、上記取消部は、状態変更通知との依存関係が指定されているデータベース接続の切断に応答して、状態変更通知の取得中断を前記結果として与える上記通信部とすることができる。これにより、取得要求された状態変更が検知される前であっても、中断要求により明示的に指定したタイミング、予め定めたタイムアウト期限に達したタイミング、予め依存関係を指定したデータベース接続が切断されたタイミングなど、種々のタイミングで自由度高く取得要求を撤回することができる。
【００１５】
さらに本発明では、情報管理サーバは、契機とする状態変更および通知アクションからなる状態変更通知を定義付けて持続的に格納させる作成部、定義を読み出して契機とする状態変更を変更検知部による検知の対象とし、状態変更通知の処理動作を開始させる開始部、および定義を消去して状態変更通知を削除する削除部を含むことができる。
【００１６】
上記開始部は、データベース接続を介して受信した予め定義されている状態変更通知の開始要求に応答して、クライアントを識別する識別子と、前記変更検知部により書き換えられ状態変更の有無を示すキーと、前記通知アクションの結果とを記憶するための記憶領域を確保して、要求された状態変更通知処理の動作を開始することができる。上記データベースの状態変更は、データベースのテーブルに対し為された要素の追加、更新または削除を含むことができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。なお、以下の実施形態では、情報処理システムの一例として、データベースを管理する情報管理サーバとしてのデータベース・サーバ（以下、サーバとして参照する。）と、ネットワークを介して該サーバと接続するデータベース・クライアント（以下、クライアントとして参照する。）とから構成されたデータベース・システム（以下、ＤＢシステムとして参照する。）を例に説明する。
【００１８】
まず、本実施形態のＤＢシステムを構成するサーバ１０のハードウェアおよびソフトウェア構成について説明する。図１は、サーバ１０のハードウェア構成の実施形態を示す。図１に示すサーバ１０は、概ねパーソナル・コンピュータ、ワークステーションまたはメインフレームなどのコンピュータ装置３４として構成されている。図１に示すコンピュータ装置３４は、中央処理装置（ＣＰＵ）１２と、ＣＰＵ１２が使用するデータの高速アクセスを可能とするＬ１およびＬ２などのレベルを有するキャッシュ・メモリ１４と、ＣＰＵ１２の処理を可能とするＲＡＭ、ＤＲＡＭなどの固体メモリ素子から形成されるシステム・メモリ１６とを備えている。
【００１９】
ＣＰＵ１２、キャッシュ・メモリ１４、およびシステム・メモリ１６は、システム・バス１８を介して、他のデバイスまたはドライバ、例えば、グラフィックス・ドライバ２０およびネットワーク・インタフェース・カード（ＮＩＣ）２２へと接続されている。グラフィックス・ドライバ２０は、バスを介して外部のディスプレイ２４に接続されて、ＣＰＵ１２による処理結果をディスプレイ画面上に表示させることができる。また、ＮＩＣ２２は、物理層レベルおよびデータリンク層レベルでサーバ１０を、ＴＣＰ／ＩＰなどの適切な通信プロトコルを使用するネットワークへと接続している。
【００２０】
システム・バス１８には、さらにＩ／Ｏバス・ブリッジ２６が接続されている。Ｉ／Ｏバス・ブリッジ２６の下流側には、ＰＣＩなどのＩ／Ｏバス２８を介して、ＩＤＥ、ＡＴＡ、ＡＴＡＰＩ、シリアルＡＴＡ、ＳＣＳＩ、ＵＳＢなどにより、ハードディスク３０が接続されている。ハードディスク３０は、本実施形態のデータベースのデータを記憶する記憶領域を提供している。また、Ｉ／Ｏバス２８には、ＵＳＢなどのバスを介して、キーボードおよびマウスなどのポインティング・デバイスなどの入力装置３２が接続されていて、この入力装置３２によりユーザ・インタフェースが提供される。オペレータは、入力装置３２を用いて、あるいはＮＩＣ２２を介したリモートアクセスにより、データベースのメンテナンス操作、後述するイベント通知トリガの定義付けなどの処理操作をコンピュータ装置３４に対し指令することができる。
【００２１】
コンピュータ装置３４のＣＰＵ１２としては、いかなるシングルコア・プロセッサまたはマルチコア・プロセッサを用いることができ、より具体的には、例えば、Ｘｅｏｎ（登録商標）、Ｉｔａｎｉｕｍ（登録商標）、ＰＯＷＥＲ５（登録商標）、ＰＯＷＥＲ６（登録商標）、ＰＯＷＥＲ  ＰＣ（登録商標）などＣＩＳＣまたはＲＩＳＣチップなどを挙げることができる。
【００２２】
サーバ１０は、ＷＩＮＤＯＷＳ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのオペレーティング・システム（以下、ＯＳとして参照する。）により制御され、リレーショナル・データベース、オブジェクト・リレーショナル・データベース、階層型データベース、ネットワーク型データベース、ＸＭＬ（eXtensible Markup Language）データベースなどのデータベースを管理するデータベース管理システム（ＤＢＭＳ；Database Management System）などを実装している。なお、クライアントも、図１に示したものと同様なハードウェア構成により実現することができる。
【００２３】
以下、本実施形態のＤＢシステムの機能構成について説明する。図２は、本実施形態のサーバ１０およびクライアント９０上に実現されるＤＢシステムの機能ブロック１００を示す。図２に示す機能ブロック１００は、サーバ１０およびクライアント９０の機能構成を含む。サーバ１０およびクライアント９０は、ローカル・エリア・ネットワーク（ＬＡＮ）などのネットワーク８０を介して、イーサネット（登録商標）およびＴＣＰ／ＩＰなどの通信プロトコルに従って、相互に通信を行っている。
【００２４】
サーバ１０は、データベース管理システム（以下、ＤＢＭＳとして参照する）５０と、データベース記憶部５２とを含んで構成される。なお、以下では、説明の便宜上、リレーショナル・データベースを用いた場合を例として説明する。データベース記憶部５２は、図１に示したハードディスク３０により構成され、コンピュータがアクセス可能なフォーマットとされたデータを記憶している。ＤＢＭＳ５０は、データベースを運用および管理するためのアプリケーションであり、ＳＱＬなどのデータベース言語を備え、クライアント９０とのＡＣＩＤ特性に従ったトランザクション処理を制御し、クライアント９０に対しデータベース記憶部５２内のデータへのアクセスを提供している。
【００２５】
本実施形態のＤＢＭＳ５０は、クライアント９０との通信を制御しデータベース接続を提供する通信サービス・コンポーネント５６と、本実施形態のイベント通知トリガ機能を実現するイベント通知トリガ・コンポーネント群５４とを含んで構成される。通信サービス・コンポーネント５６は、図１に示すＮＩＣ２２などのハードウェア資源とともに、本実施形態の通信部としてコンピュータ上に実現される。上記イベント通知トリガ機能とは、データベース上のテーブルなどに対しデータの追加（INSERT）、更新（UPDATE）または削除（DELETE）の操作が行われるなどデータベースの状態変更イベントを契機として、クライアント９０に対しイベント通知を行う機能である。本実施形態のＤＢシステムでは、契機となる状態変更イベントと、応答して呼び出されるアクションとを組として、複数のイベント通知トリガが登録可能とされている。
【００２６】
またサーバ１０は、登録されたイベント通知トリガを定義付けるデータを格納し、イベント通知トリガを登録するイベント通知トリガ定義登録部５８をさらに含んで構成される。イベント通知トリガ定義登録部５８は、ハードディスク３０などが提供する記憶領域により構成され、イベント通知トリガ・コンポーネント群５４の各コンポーネントがアクセス可能に上記定義付けデータを格納し、本実施形態の登録部としてコンピュータ上に実現される。
【００２７】
クライアント９０は、サーバ１０のＤＢＭＳ５０に遠隔的にアクセスするため、ＪＤＢＣおよびＯＤＢＣ（Open Database Connectivity）などの共通インタフェース（Application Programming Interface；ＡＰＩ）や、その他のＤＢＭＳ固有のＡＰＩとして構成されるデータベース接続ＡＰＩ（以下、ＤＢ接続ＡＰＩとして参照する。）９２を実装し、データベースにアクセスすることが可能とされている。クライアント９０上で実行され、該データベースのデータを利用するアプリケーション９４は、該ＡＰＩを介してデータベースにアクセスする。アプリケーション９４は、より具体的には、ビジネス・ロジックなどを受け持つファンクション機能部９６と、ユーザ・インタフェース機能部９８とを含んで構成される。本実施形態では、ファンクション機能部９６およびユーザ・インタフェース機能部９８が、データベースの状態変更の通知を要する処理を実行している。
【００２８】
アプリケーション９４は、ＤＢ接続ＡＰＩ９２を用いてサーバ１０へアクセスし、ＤＢＭＳ５０とのデータベース接続を確立させ、該データベース接続を介して、ＳＱＬなどのデータベース言語で記述されるステートメントを発行する。サーバ１０の説明に戻ると、ＤＢＭＳ５０は、アプリケーション９４から発行されたステートメントを解釈して、種々のコンポーネントを用いて要求された処理を実行し、処理結果をクライアント９０に応答する。
【００２９】
上記イベント通知トリガ・コンポーネント群５４は、より具体的には、イベント通知トリガを作成するためのトリガ作成コンポーネント６０と、作成されたイベント通知トリガをシステムから削除するためのトリガ削除コンポーネント６６とを含む。さらに、上記イベント通知トリガ・コンポーネント群５４は、作成されたイベント通知トリガの動作を開始させるためのトリガ開始コンポーネント６２と、開始されたイベント通知トリガの動作を停止するためのトリガ停止コンポーネント６８とを含む。
【００３０】
上記イベント通知トリガ・コンポーネント群５４は、さらに、トリガデータ取得コンポーネント６４と、イベント処理コンポーネント７０とを含む。上記トリガデータ取得コンポーネント６４は、動作中のイベント通知トリガに関して、データベース接続を介してクライアント９０から受信したイベント通知の取得要求を受け付ける。イベント処理コンポーネント７０は、データベースのすべてのテーブルに関するデータの追加・更新・削除が行われると、その通知を受け取り、開始されているイベント通知トリガの契機となる状態変更イベントであるか否かを判定する。トリガデータ取得コンポーネント６４は、上記イベント処理コンポーネント７０が契機とする状態変更イベントの発生を検知した後、クライアント９０に対してデータベース接続を介してイベント通知を行い、接続の制御をクライアント９０に戻す。
【００３１】
上記イベント通知トリガ・コンポーネント群５４は、トリガ中断コンポーネント７２をさらに含むことができる。トリガ中断コンポーネント７２は、既に取得要求が行われたイベント通知トリガに関して、上記イベント処理コンポーネント７０によって状態変更イベントの発生が検知される前であっても、クライアント９０からの中断要求に応答してイベント通知の取得処理を中断し、トリガデータ取得コンポーネント６４に対しエラー応答を実施させ、データベース接続の制御をクライアント９０に戻す。
【００３２】
クライアント９０がイベント通知の取得要求を発行した場合、用いたデータベース接続は、要求に対する応答を受け取るまで、応答待ちの状態となる。本実施形態では、詳細は後述するが、クライアント９０からの要求を受けて取得処理を中断する他、種々のタイミングでイベント通知の取得処理の実行を取り消して、データベース接続の制御をクライアントに戻すことができる。
【００３３】
例えば、上記イベント通知トリガ・コンポーネント群５４は、さらに、タイマコンポーネント（図２には示さない。）を含むことができる。タイマコンポーネントは、イベント通知の取得要求に応答して作動し、作動時からの時間を計測する。そして、タイマコンポーネントは、所与の期限の満了に応答して、イベント通知の取得処理を取り消して、トリガデータ取得コンポーネント６４に対しエラー応答を実施させて、接続の制御をクライアント９０に戻すことができる。
【００３４】
また、上記通信サービス・コンポーネント５６が、予めイベント通知トリガとの依存関係が指定されたデータベース接続の切断要求に応答して、切断要求のデータベース接続を切断するとともに、依存関係にあるイベント通知の取得処理の実行を取り消して、トリガデータ取得コンポーネント６４に対しエラー応答を実施させて、取得要求のデータベース接続の制御をクライアント９０に戻すことができる。
【００３５】
図２に示すサーバ１０の各機能部は、サーバ１０のシステム・メモリ１６上などにプログラムを展開して、ＣＰＵ１２がプログラムを実行し、各ハードウェア資源を動作制御することによって、サーバ１０上に実現される。上記トリガ作成コンポーネント６０、トリガ開始コンポーネント６２、トリガデータ取得コンポーネント６４、トリガ削除コンポーネント６６、トリガ停止コンポーネント６８、イベント処理コンポーネント７０、トリガ中断コンポーネント７２およびタイマコンポーネントは、それぞれ、作成部、開始部、通知部、削除部、停止部、変更検知部、中断部およびタイマ部としてコンピュータ上に実現される。同様にクライアント９０の各機能部も、クライアント９０のシステム・メモリ上などにプログラムを展開し、ＣＰＵがプログラムを実行し、各ハードウェア資源を動作制御することによってクライアント９０上に実現される。
【００３６】
なお、本実施形態では、２層クライアント・サーバ構成のＤＢシステムを一例として説明するが、エンドユーザが実際に利用する上記ユーザ・インタフェース機能部９８を、さらに別のパーソナル・コンピュータ（図示せず。）上に実現させる３層クライアント・サーバ構成など、多層クライアント・サーバの構成を採用することを妨げるものではない。また本実施形態では、サーバ機能を単一のサーバ・コンピュータ上に実現する構成を例として説明するが、ネットワーク接続された複数のサーバ・コンピュータからなるクラスタ上で個別のＤＢＭＳのプロセスを協同的に動作させて、仮想的に単一のＤＢＭＳの機能を実現する、分散データベースのアーキテクチャを採用することも妨げるものではない。
【００３７】
以下、本実施形態のイベント通知トリガ機能について、より詳細に説明する。
【００３８】
（Ａ）イベント通知トリガ機能の概要
本実施形態のＤＢシステムにおいて、イベント通知トリガ機能は、以下のように実施される。（１）まず事前準備として、トリガ作成コンポーネント６０を用いて、イベント通知トリガを作成し、その定義データをイベント通知トリガ定義登録部５８に登録する。実際の運用時には、（２）イベント通知を要するアプリケーション９４は、トリガの開始要求コマンドを発行し、該コマンドに応答してトリガ開始コンポーネント６２が、定義を読み出し、イベント通知トリガの動作を開始させる。（３）引き続きアプリケーション９４は、データベース接続を介してイベント通知の取得要求コマンドを発行し、トリガデータ取得コンポーネント６４は、イベント発生の後、取得要求コマンドに対する応答としてイベント通知を行う。
【００３９】
（４）動作中のトリガのイベント通知が不要となった際には、アプリケーション９４は、トリガの停止要求コマンドを発行し、該コマンドに応答してトリガ停止コンポーネント６８がイベント通知トリガの動作を停止させる。定義したイベント通知トリガ自体が不要となった場合には、（５）トリガ削除コンポーネント６６を用いて、イベント通知トリガの定義をイベント通知トリガ定義登録部５８から消去し、システムから登録を削除する。以下、サーバ１０のイベント通知トリガ機能について、各コンポーネント毎に分けて、より詳細に説明する。
【００４０】
（Ｂ）トリガ作成コンポーネント
図３は、トリガ作成コンポーネント６０が実行する処理を概略的に示す図である。図３には、CREATE CLIENT TRIGGER 構文により、内容３００ｂで定義付けられる名称「ｃｔ１」３００ａのイベント通知トリガの作成を要求する擬似的なステートメント３００が示されている。クライアントなどからステートメント３００を受け取ったＤＢＭＳ５０は、ステートメント３００を解釈し、トリガ作成コンポーネント６０を呼び出して処理を渡す。トリガ作成コンポーネント６０は、内容３００ｂで定義付けられるイベント通知トリガをイベント通知トリガ定義登録部５８に登録する。ステートメント３００の内容３００ｂには、イベント通知の契機とする状態変更イベント、および該イベントの発生を契機として呼び出されるアクションの定義が含まれる。契機とする状態変更イベントは、指定のテーブルに対する追加（INSERT）、更新（UPDATE）または削除（DELETE）の操作として定義される。状態変更イベントの発生を契機として呼び出されるアクションとしては、SELECT構文によるステートメントを挙げることができ、この実行結果がイベント通知を要求しているアプリケーションに渡される。上記アクションによれば、クライアントに対し、追加（INSERT）の場合は、追加した値を返すことができ、削除（DELETE）の場合は、削除した値を返すことができ、更新（UPDATE）の場合は、更新前の値および更新後の値、またはこれらの少なくとも一方を返すことができる。また、イベントの発生日時などをセットするカラムを別途追加してもよい。その他、内容３００ｂには、前トリガまたは後トリガの指定、相関名の指定、トリガの細分性の指定などを含むことができる。
【００４１】
図３に示すイベント通知トリガ定義テーブル２００は、イベント通知トリガ定義登録部５８に格納され、トリガの名称が入力されるフィールド２００ａと、内容が入力されるフィールド２００ｂとを含んで構成され、イベント通知トリガを登録している。図３に示す例では、CREATE CLIENT TRIGGER構文により、上記名称３００ａおよび内容３００ｂに対応する定義が入力されたエントリ２００ｃが生成されることとなる。作成されたイベント通知トリガは、削除要求により削除されるまで、イベント通知トリガ定義テーブル２００中に永続的に登録され、イベント通知トリガの動作を開始させる際や、イベント通知のアクションを呼び出す際に参照されることとなる。
【００４２】
（Ｃ）トリガ開始コンポーネント
図４は、トリガ開始コンポーネント６２、トリガデータ取得コンポーネント６４およびイベント処理コンポーネント７０が実行する処理を概略的に示す図である。以下、まずトリガ開始コンポーネント６２の処理を説明する。図４には、START CLIENT TRIGGER 構文により、名称「ｃｔ１」のイベント通知トリガの動作の開始を指令する擬似的なステートメント３０２が示されている。クライアントからステートメント３０２を受け取ったＤＢＭＳ５０は、トリガ開始コンポーネント６２を呼び出して処理を渡す。トリガ開始コンポーネント６２は、イベント通知トリガ定義登録部５８のテーブル２００を参照して、対応する内容を読み出し、動作中のイベント通知トリガに関する情報を保持するテーブル（以下、動作トリガ登録テーブルとして参照する。）２１０にエントリを追加して、イベント通知の取得要求への応答処理のためのデータ領域を準備する。
【００４３】
図４に示す動作トリガ登録テーブル２１０は、開始要求を発行したクライアントを識別するクライアントＩＤが入力されるフィールド２１０ａと、開始されたトリガの名称が入力されるフィールド２１０ｂと、ロックキーの状態値が入力されるフィールド２１０ｃと、アクションの結果出力データ２２０へのポインタが入力されるフィールド２１０ｄとを含んで構成される。上記結果出力データ２２０は、メモリまたはデータベース上に一時テーブルとして構成され、契機となるイベント発生に応答して呼び出されるアクションによる結果出力を格納するために確保される。上記ロックキーは、ロック状態またはロック解除状態に対応する値を保持し、イベント発生の待機時にはロック状態にセットされ、対応する状態変更イベントの発生に応答してロック解除状態にセットされる。
【００４４】
図４に示す例では、START CLIENT TRIGGER 構文により、クライアントＩＤ「１」とトリガ名称「ｃｔ１」とが入力されたエントリ２１０ｅが追加されることとなる。新しく追加されたエントリ２１０ｅのフィールド２１０ｃおよびフィールド２１０ｄには、初期値として「ロック状態」がセットされたロックキーと、トリガ処理結果を保持する空の一時テーブルへのポインタが入力される。作成されたイベント通知トリガのエントリ２１０ｅは、停止要求により停止されるか、要求したクライアントとの接続がDISCONNECT要求などにより切れるか、プロセスが終了するまで、動作トリガ登録テーブル２１０に動作中のイベント通知トリガに関する情報を保持する。なお、本実施形態では、動作中のイベント通知トリガは、クライアントＩＤおよびトリガ名称に従って識別され、複数のクライアントに対して同一のイベント通知トリガを動作させることが可能に構成されている。
【００４５】
（Ｄ）トリガデータ取得コンポーネント
以下、トリガデータ取得コンポーネント６４の処理を説明する。図４には、GET CLIENT TRIGGER 構文により、トリガ名称「ｃｔ１」のイベント通知トリガのイベント通知の取得を指令する擬似的なステートメント３０４ａが示されている。ＤＢＭＳ５０は、クライアント９０からデータベース接続を介してステートメント３０４ａを受け取り、トリガデータ取得コンポーネント６４を呼び出して処理を渡す。
【００４６】
トリガデータ取得コンポーネント６４は、動作トリガ登録テーブル２１０中の対応するエントリのロックキー・フィールド２１０ｃをモニタし、ロック解除を待ち受ける。トリガデータ取得コンポーネント６４は、後述するイベント処理コンポーネント７０によりロックキー・フィールド２１０ｃがロック解除状態に書き換えられたことを検知すると、フィールド２１０ｄのポインタにより結果出力データ２２０を取得して、クライアント９０に対し上記ステートメント３０４ａへの応答として、結果出力データ２２０を含むイベント通知を返す。図４には、ステートメント３０４ａに対する応答３０４ｂが示されている。また、トリガデータ取得コンポーネント６４は、イベント通知の後、次の処理に備えて、対応するエントリのロックキー・フィールド２１０ｃを再びロック状態に書き換え、対応する結果出力データ２２０の内容を消去する。
【００４７】
（Ｅ）イベント処理コンポーネント
以下、イベント処理コンポーネント７０の処理を説明する。データベースのすべてのテーブルに関してデータの追加・更新・削除が行われると、イベント処理コンポーネント７０が通知を受ける。イベント処理コンポーネント７０は、操作対象のテーブルがトリガのアクションで使用されているか否かをイベント通知トリガ定義テーブル２００をチェックし、また、該当するトリガが１つまたは複数のクライアントから開始されているか否かを動作トリガ登録テーブル２１０をチェックする。該当するトリガの定義が存在し、かつ、そのトリガが開始されていれば、そのアクションを実行し、そのトリガを開始しているすべてのクライアントに対応する、フィールド２１０ｄで管理されている結果出力データ２２０に実行の結果として得られたデータを追加し、ロックキー２１０ｃのロックを解除する。なお、イベント処理コンポーネント７０の状態変更イベントの発生を検知処理自体は、従来からのＤＢＭＳのトリガ（TRIGGER）機能と同様のメカニズムを用いることができる。
【００４８】
（Ｆ）イベント通知処理
以下、トリガ開始コンポーネント６２、トリガデータ取得コンポーネント６４およびイベント処理コンポーネント７０が連携して実現するイベント通知処理について説明する。トリガ開始コンポーネント６２は、図４に示すステートメント３０２のようなクライアント９０からのイベント通知トリガの動作の開始要求に応答して、動作トリガ登録テーブル２１０にエントリを追加する。これにより、当該トリガに対応する状態変更イベントの発生がイベント処理コンポーネント７０に検知されるようになる。一方、トリガデータ取得コンポーネント６４は、図４に示すステートメント３０４ａのようなクライアント９０からのイベント通知の取得要求に応答して、動作トリガ登録テーブル２１０の対応するエントリのロックキー・フィールド２１０ｃのモニタを開始し、ロック解除待ちとなる。
【００４９】
図４に示すステートメント３０５のようなテーブルに対する操作の要求があると、イベント処理コンポーネント７０は、（１）イベント通知トリガ定義テーブル２００を参照して、発生した状態変更イベントに対応するトリガの定義を確認し、（２）さらに、動作トリガ登録テーブル２１０を参照して、状態変更イベントに対応するトリガが開始されていることを確認して、当該トリガに対応する状態変更イベントが発生したとして、（３）内容２００ｂ中に定義された対応するアクションを呼び出して、結果出力を取得し、出力として１レコード以上のデータがある場合に結果出力を結果出力データ２２０に挿入する。このとき、イベント処理コンポーネント７０は、複数のクライアントにより同一のトリガが開始されていても、各イベントにつき一度のアクションの実行で、要求しているすべてのクライアントの結果出力データ２２０に挿入する。データ挿入の後、（４）イベント処理コンポーネント７０は、動作トリガ登録テーブル２１０の対応するエントリのフィールド２１０ｃを、ロック状態からロック解除状態に書き換える。
【００５０】
ロック解除を待ち受けていたトリガデータ取得コンポーネント６４は、（５）フィールド２１０ｃがロック解除状態に書き換えられたことを検知して、（６）対応する結果出力データ２２０を取得して、（７）取得要求のクライアント９０に対して、結果出力データ２２０を含むイベント通知を実施する。なお、イベント処理コンポーネント７０は、イベント通知トリガの動作開始から、当該イベント通知トリガに関する状態変更イベントの発生を検知するため、イベント通知の取得要求前に、既に結果出力データ２２０が挿入され、ロック解除状態に書き換えられていることがある。この場合、イベント通知の取得要求に応答して、直ちに結果出力データ２２０を含むイベント通知が実施されることとなる。
【００５１】
図６は、イベント通知トリガ機能の動作のシーケンスを示す。図６に示したステップＳ１０１〜ステップＳ１０３の処理は、イベント通知トリガの開始処理に対応し、ステップＳ２０１〜ステップＳ２１０の処理は、イベント通知処理に対応する。
【００５２】
図６に示す例では、ステップＳ１０１では、予め確立されたデータベース接続を介して、クライアント９０からSTART CLIENT TRIGGER ステートメントによるトリガの開始要求が発行される。ステップＳ１０２では、トリガの開始要求に応答して、トリガ開始コンポーネント６２は、指定されたイベント通知トリガの定義データをテーブル２００から読み出し、動作トリガ登録テーブル２１０にエントリを追加し、ステップＳ１０３で、同データベース接続を介して、開始要求に対する応答をクライアント９０に返す。ステップＳ１０１〜ステップＳ１０３の処理により、指定のイベント通知トリガの動作が開始され、開始されたトリガに対応する状態変更イベントが、イベント処理コンポーネント７０による検知の対象となり、イベント通知の取得要求を受付可能な状態となる。
【００５３】
以下、イベント通知の取得要求に対するイベント通知処理について説明する。図６に示す例では、ステップＳ２０１では、予め確立されたデータベース接続を介して、クライアント９０からGET CLIENT TRIGGER 構文のステートメントによるイベント通知の取得要求が発行される。ステップＳ２０２では、トリガデータ取得コンポーネント６４は、取得要求に応答して、対応エントリのロックキーのモニタを開始し、ロック解除を待ち受ける。ステップＳ２０３では、イベント処理コンポーネント７０は、イベント発生を検知し、ステップＳ２０４で、アクションを呼び出して、実行結果を結果出力データ２２０に挿入し、ステップＳ２０５で、動作トリガ登録テーブル２１０の対応エントリのフィールド２１０ｃを、ロック状態からロック解除状態に書き換える。
【００５４】
イベント発生後のタイミングであるステップＳ２０６では、トリガデータ取得コンポーネント６４は、ロックキーをモニタして、ステップＳ２０７で、ロック解除を検知する。ステップＳ２０８では、トリガデータ取得コンポーネント６４は、結果出力データ２２０を取得し、ステップＳ２０９で、取得した結果出力データ２２０を含むイベント通知を、同データベース接続を介して取得要求に対する応答としてクライアントに返す。ステップＳ２１０では、トリガデータ取得コンポーネント６４は、次のイベント通知の取得要求に対応するために、結果出力データ２２０の内容をクリアして、動作トリガ登録テーブル２１０の対応エントリのロックキー・フィールド２１０ｃを再びロック状態に書き換える。
【００５５】
（Ｇ）トリガ停止コンポーネント
図５は、トリガ削除コンポーネント６６およびトリガ停止コンポーネント６８が実行する処理を概略的に示す図である。以下、まずトリガ停止コンポーネント６８の処理を説明する。図５には、STOP CLIENT TRIGGER 構文により、名称「ｃｔ１」のイベント通知トリガの動作の停止を指令する擬似的なステートメント３０８が示されている。また図５には、ステートメント３０８が、クライアントＩＤ「１」のクライアントから発行されたものであることも示されている。
【００５６】
クライアント９０からステートメント３０８を受け取ったＤＢＭＳ５０は、トリガ停止コンポーネント６８を呼び出して処理を渡す。トリガ停止コンポーネント６８は、クライアントＩＤおよびトリガ名称から、動作トリガ登録テーブル２１０中の対応するエントリ２１０ｅを検索し、該エントリおよび対応する結果出力データ２２０を削除して、指定されたイベント通知トリガの動作を停止させる。
【００５７】
図６に示したステップＳ３０１〜ステップＳ３０３の処理は、イベント通知トリガの停止処理に対応する。図６に示す例では、ステップＳ３０１では、予め確立されたデータベース接続を介して、クライアント９０からSTOP CLIENT TRIGGER ステートメントによるトリガの停止要求が発行される。ステップＳ３０２では、トリガ停止コンポーネント６８は、トリガの停止要求に応答して、指定されたイベント通知トリガのエントリを動作トリガ登録テーブル２１０から削除し、ステップＳ３０３で、同データベース接続を介して、停止要求に対する応答をクライアント９０に返す。ステップＳ３０１〜ステップＳ３０３の処理により、動作中のイベント通知トリガにより確保されていたリソースが解放される。再びイベント通知が必要となった際には、クライアント９０は、再びトリガの開始要求を発行することとなる。
【００５８】
（Ｈ）トリガ削除コンポーネント
以下、トリガ削除コンポーネント６６の処理を説明する。図５には、DROP CLIENT TRIGGER 構文により、名称「ｃｔ１」のイベント通知トリガの動作の削除を指令する擬似的なステートメント３０６が示されている。クライアント９０からステートメント３０６を受け取ったＤＢＭＳ５０は、ステートメント３０６を解釈し、トリガ削除コンポーネント６６を呼び出して処理を渡す。トリガ削除コンポーネント６６は、イベント通知トリガ定義登録部５８のテーブル２００から、対応するエントリ２００ｃを削除する。トリガ削除コンポーネント６６による削除処理により、永続化されたイベント通知トリガが削除され、確保されていたリソースが解放される。
【００５９】
（Ｉ）中断要求によるイベント通知処理の取り消し
上述したように、クライアント９０がイベント通知の取得要求を発行した場合、用いたデータベース接続は、応答待ちとなる。本実施形態では、イベント発生に応答してイベント通知を行って接続の制御を戻す以外にも、種々のタイミングで取得処理の実行を取り消して、接続の制御をクライアント９０に戻すことができる。図７は、トリガデータ取得コンポーネント６４、トリガ中断コンポーネント７２およびタイマコンポーネント７４が実行する処理を概略的に示す図である。以下、まずトリガ中断コンポーネント７２によるイベント通知処理の中断動作について説明する。
【００６０】
図７には、GET CLIENT TRIGGER 構文により、名称「ｃｔ１」のイベント通知トリガのイベント通知の取得を指令する擬似的なステートメント３１２ａが示されている。また図７には、さらに、拡張された動作トリガ登録テーブル２１２が示されている。拡張された動作トリガ登録テーブル２１２は、クライアントＩＤが入力されるフィールド２１２ａと、開始されたトリガの名称が入力されるフィールド２１２ｂと、ロックキーの状態値が入力されるフィールド２１２ｃと、イベント通知の状態が入力されるフィールド２１２ｄと、該状態がエラーである場合にエラーの理由が入力されるフィールド２１２ｅと、アクションの結果出力データ２２０へのポインタが入力されるフィールド２１２ｆとを含んで構成される。上記拡張された動作トリガ登録テーブル２１２は、トリガ中断コンポーネント７２およびタイマコンポーネント７４をサポートする場合に、トリガ開始コンポーネント６２により動作トリガ登録テーブル２１０の代わりに準備される。
【００６１】
ＤＢＭＳ５０は、データベース接続を介してクライアントからステートメント３１２ａを受け取り、トリガデータ取得コンポーネント６４を呼び出して処理を渡す。トリガデータ取得コンポーネント６４は、図７に示すステートメント３１２ａのようなイベント通知の取得要求に応答して、上述したようにロック解除待ちとなる。
【００６２】
イベント通知の取得要求に用いたデータベース接続が応答待ちとなっている間、クライアント９０は、さらに別のデータベース接続を介して、図７に示すステートメント３１０を発行することができる。ステートメント３１０を受け取ったＤＢＭＳ５０は、トリガ中断コンポーネント７２を呼び出して処理を渡す。なお、図７に示すステートメント３１０は、BREAK CLIENT TRIGGER 構文により記述された、指定クライアント（クライアントＩＤ１）からのイベント通知取得の中断を指令する擬似的なステートメントである。
【００６３】
処理を渡されて、トリガ中断コンポーネント７２は、（１−１）当該中断指令を受領し、（１−２）状態フィールド２１２ｄに「エラー」を、理由フィールド２１２ｅに理由（例：「他クライアント（ＩＤ＝ｘｘ）からの中断」）をセットする。これらのセットが完了した後、（１−３）トリガ中断コンポーネント７２は、動作トリガ登録テーブル２１２の対応するエントリのフィールド２１２ｃを、ロック状態からロック解除状態に書き換える。
【００６４】
ロック解除を待ち受けていたトリガデータ取得コンポーネント６４は、（４）フィールド２１２ｃがロック解除状態に書き換えられたことを検知して、（５）状態フィールド２１２ｄおよび理由フィールド２１２ｅの値を取得し、（６）状態フィールド２１２ｄが「エラー」である場合、理由フィールド２１２ｅに入力された理由を含めて、取得要求のクライアントに対しエラー通知を実施する。
【００６５】
図８は、イベント通知トリガの中断動作のシーケンスを示す。図８に示したステップＳ１０１〜ステップＳ１０３の処理は、イベント通知トリガの開始処理に対応し、図６と同一であるため、説明は省略する。図８に示したステップＳ４０１〜ステップＳ４１２の処理は、イベント通知処理の中断動作に対応する。
【００６６】
図８に示す例では、ステップＳ４０１では、予め確立された第１のデータベース接続を介して、クライアント９０からGET CLIENT TRIGGER 構文のステートメントによるイベント通知の取得要求が発行される。ステップＳ４０２では、トリガデータ取得コンポーネント６４は、取得要求に応答して、対応エントリのロックキーのモニタを開始し、ロック解除を待ち受ける。
【００６７】
図８に示す例では、ステップＳ４０３では、追加で確立された第２のデータベース接続を介して、クライアント９０からBREAK CLIENT TRIGGER 構文のステートメントによるイベント通知の中断要求が発行される。ステップＳ４０４では、トリガ中断コンポーネント７２は、中断指令を受領して、ステップＳ４０５で、状態フィールド２１２ｄおよび理由フィールド２１２ｅに所定の値をセットしてエラー処理を行い、ステップＳ４０６で、拡張された動作トリガ登録テーブル２１２の対応エントリのフィールド２１２ｃをロック解除状態に書き換え、ステップＳ４０７で、BREAK CLIENT TRIGGER 構文のステートメントに対する応答を返す。
【００６８】
ステップＳ４０８では、トリガデータ取得コンポーネント６４は、ロックキーをモニタして、ステップＳ４０９で、ロック解除を検知する。ステップＳ４１０では、トリガデータ取得コンポーネント６４は、対応エントリの状態フィールド２１２ｄを参照し、値が「エラー」であることを検知して、フィールド２１２ｅのエラー情報を取得する。ステップＳ４１１では、トリガデータ取得コンポーネント６４は、取得要求で用いた第１のデータベース接続を介して、取得要求に対する応答としてエラー通知をクライアントに返す。
【００６９】
ステップＳ４１２では、トリガデータ取得コンポーネント６４は、次のイベント通知の取得要求に対応するために、状態フィールド２１２ｄおよび理由フィールド２１２ｅをクリアして、動作トリガ登録テーブル２１２の対応エントリのロックキー・フィールド２１２ｃを再びロック状態に書き換える。
【００７０】
（Ｊ）タイマによるイベント通知処理の取り消し
以下、図７を再び参照して、タイマコンポーネント７４によるイベント通知処理の中断動作について説明する。図７には、SET CLIENT TRIGGER TIMEOUT構文により、イベント通知トリガのイベント通知の取得処理のタイムアウト時間を設定する擬似的なステートメント３１４が示されている。また図７には、タイマコンポーネント７４がタイマを作動させる際に参照するタイマ設定テーブル２３０が示されている。タイマ設定テーブル２３０は、クライアントＩＤが入力されるフィールド２３０ａと、そのクライアントに対するイベント通知のタイマ値が入力されるフィールド２３０ｂとを含んで構成される。ＤＢＭＳ５０は、クライアント９０からステートメント３１４を受け取ると、イベント通知トリガのタイマ設定テーブル２３０中、要求あったクライアントに対応するエントリの値を書き換える。なお、フィールド２３０ｂには、デフォルト値がセットされており、クライアントからのSET CLIENT TRIGGER TIMEOUT構文による明示的な指定があった場合に変更される制御とすることができる。
【００７１】
また、ＤＢＭＳ５０は、クライアント９０からデータベース接続を介してステートメント３１２ａを受け取ると、トリガデータ取得コンポーネント６４を呼び出して処理を渡す。トリガデータ取得コンポーネント６４は、クライアント９０からのイベント通知の取得要求に応答してロック解除待ちとなる。さらに、タイマコンポーネント７４は、クライアント９０からのイベント通知の取得要求に応答して、タイマ設定テーブル２３０を参照して、要求あったクライアント９０に対応するエントリのタイマ値を取得し、取得したタイマ値を満了期限とするタイマを作動させる。
【００７２】
イベント通知の取得要求に用いたデータベース接続が応答待ちとなっている間、タイマコンポーネント７４は、タイマ満了、中断またはイベント発生まで計時する。イベント処理コンポーネント７０が状態変更イベントの発生を検知する前で、かつトリガ中断コンポーネント７２が上記中断要求を受領する前にタイマが満了した場合、タイマコンポーネント７４は、（２−１）当該タイマの満了を検知し、（２−２）動作トリガ登録テーブル２１２の状態フィールド２１２ｄに「エラー」を、理由フィールド２１２ｅに理由（例：「タイマ（１０秒）満了」）をセットする。これらのセットが完了した後、（２−３）タイマコンポーネント７４は、動作トリガ登録テーブル２１２の対応するエントリのフィールド２１２ｃを、ロック状態からロック解除状態に書き換える。
【００７３】
ロック解除を待ち受けていたトリガデータ取得コンポーネント６４は、（４）ロック解除状態に書き換えられたことを検知して、（５）状態フィールド２１２ｄおよび理由フィールド２１２ｅの値を取得し、（６）状態フィールド２１２ｄが「エラー」である場合、理由フィールド２１２ｅに入力された理由を含めて、取得要求のクライアント９０に対しエラー通知を応答３１２ｂとして実施し、タイマコンポーネント７４は、停止する。イベント処理コンポーネント７０が状態変更イベントの発生を検知したり、トリガ中断コンポーネント７２が中断要求を受領したりした場合、上述した対応する処理が実施され、タイマコンポーネント７４は、停止させられることとなる。
【００７４】
図９は、イベント通知トリガのタイマ満了動作のシーケンスを示す。図９に示したステップＳ１０１〜ステップＳ１０３の処理は、イベント通知トリガの開始処理に対応し、図６と同一であるため説明を省略する。図９に示したステップＳ５０１〜ステップＳ５１１の処理は、イベント通知処理のタイマ満了動作に対応する。
【００７５】
図９に示す例では、ステップＳ５０１では、クライアント９０からGET CLIENT TRIGGER 構文のステートメントによるイベント通知の取得要求が発行される。ステップＳ５０２では、タイマコンポーネント７４は、取得要求に応答してタイマを作動させる。ステップＳ５０３では、トリガデータ取得コンポーネント６４は、取得要求に応答してロックキーのモニタを開始し、ロック解除を待ち受ける。
【００７６】
図９に示す例では、ステップＳ５０４では、タイマコンポーネント７４は、タイマ満了を検知して、ステップＳ５０５で、動作トリガ登録テーブル２１２の状態フィールド２１２ｄおよび理由フィールド２１２ｅに所定の値をセットしてエラー処理を行い、ステップＳ５０６で、対応エントリのフィールド２１２ｃをロック解除状態に書き換る。ステップＳ５０７では、トリガデータ取得コンポーネント６４は、ロックキー・フィールド２１２ｃをモニタして、ステップＳ５０８で、ロック解除を検知する。ステップＳ５０９では、トリガデータ取得コンポーネント６４は、対応エントリの状態フィールド２１２ｅが「エラー」であることを検知して、フィールド２１２ｅのエラー情報を取得する。ステップＳ５１０では、トリガデータ取得コンポーネント６４は、取得要求で用いたデータベース接続を介して取得要求に対する応答として、エラー通知をクライアント９０に返す。
【００７７】
ステップＳ５１１では、トリガデータ取得コンポーネント６４は、次のイベント通知の取得要求に対応するために、状態フィールド２１２ｄおよび理由フィールド２１２ｅをクリアして、動作トリガ登録テーブル２１２の対応エントリのロックキー・フィールド２１２ｃを、再びロック状態に書き換える。
【００７８】
（Ｋ）データベース接続の切断に依存したイベント通知処理の取り消し
以下、図１０を参照して、通信サービス・コンポーネント５６によるイベント通知処理の中断動作について説明する。図１０は、通信サービス・コンポーネント５６およびトリガデータ取得コンポーネント６４が実行する処理を概略的に示す図である。図１０には、START CLIENT TRIGGER 構文により、指定のデータベース接続に依存させて、名称「ｃｔ１」のイベント通知トリガのイベント通知の動作の開始を指令する擬似的なステートメント３１６が示されている。
【００７９】
ＤＢＭＳ５０は、クライアント９０からデータベース接続を介してステートメント３１６を受け取ると、トリガ開始コンポーネント６２を呼び出して処理を渡す。トリガ開始コンポーネント６２は、イベント通知トリガ定義テーブル２００の対応する内容を読み出し、拡張された動作トリガ登録テーブル２１４にエントリを追加して、イベント通知の取得要求への応答処理のためのデータ領域を準備する。
【００８０】
図１０には、さらに、拡張された動作トリガ登録テーブル２１４が示されている。拡張された動作トリガ登録テーブル２１４は、図８に示したものと同様に、クライアントＩＤ、開始トリガの名称、ロックキーの状態値、イベント通知の状態、エラーの理由、およびポインタがそれぞれ入力されるフィールド２１４ａ、フィールド２１４ｃ、フィールド２１４ｄ、フィールド２１４ｅ、フィールド２１４ｆ、およびフィールド２１４ｇを含んで構成される。動作トリガ登録テーブル２１４は、さらに、依存関係にあるデータベース接続のクライアントＩＤが入力されるフィールド２１４ｂを含んで構成され、依存するクライアントＩＤのデータベース切断に応じた中断をサポートする場合に、トリガ開始コンポーネント６２により準備される。図１０に示す例では、START CLIENT TRIGGER 構文により、クライアントＩＤ「２」と、依存するクライアントＩＤ「１」と、開始トリガ名称「ｃｔ１」とが入力されたエントリ２１４ｈが追加されることとなる。つまり、START CLIENT TRIGGERを発行した時点では、依存するクライアントＩＤがデータベースに接続している必要があり、接続していなければエラーとなる。また、この目的のために、それぞれ接続しているクライアントＩＤの番号を、接続時の戻り値、または、新たに導入したステートメントなどで取得できる機能も提供する。
【００８１】
図１０には、さらに、GET CLIENT TRIGGER 構文により、名称「ｃｔ１」のイベント通知トリガのイベント通知の取得を指令する擬似的なステートメント３１８ａが示されている。図１０において、クライアントＩＤ１が発行する擬似的なステートメントには「ｃｉｄ１：」、クライアントＩＤ２が発行する擬似的なステートメントには「ｃｉｄ２：」と記載する。ＤＢＭＳ５０は、クライアント９０からデータベース接続（クライアントＩＤ：２）を介してステートメント３１８ａを受け取ると、トリガデータ取得コンポーネント６４を呼び出して処理を渡す。トリガデータ取得コンポーネント６４は、図１０に示すステートメント３１８ａのようなクライアント９０からのイベント通知の取得要求に応答して、ロック解除待ちとなる。
【００８２】
イベント通知の取得要求に用いたデータベース接続が応答待ちとなっている間、クライアント９０は、さらに別のデータベース接続（クライアントＩＤ：１）を介して、図１０に示すDISCONNECT 構文によるデータベース接続の切断を指令するステートメント３２０を発行することができる。ステートメント３２０を受け取ったＤＢＭＳ５０は、通信サービス・コンポーネント５６を呼び出して処理を渡す。
【００８３】
処理を渡されて、通信サービス・コンポーネント５６は、動作トリガ登録テーブル２１４を参照して、切断要求のあったデータベース接続と依存関係にあるイベント通知トリガを検索し、（１）依存接続の切断を検知する。通信サービス・コンポーネント５６は、さらに（２）状態フィールド２１４ｅに「エラー」を、理由フィールド２１４ｆに理由（例：「依存クライアント（ＩＤ＝１）の切断」）をセットする。これらのセットが完了した後、（３）通信サービス・コンポーネント５６は、動作トリガ登録テーブル２１４の対応するエントリのフィールド２１４ｄを、ロック状態からロック解除状態に書き換える。
【００８４】
ロック解除を待ち受けていたトリガデータ取得コンポーネント６４は、（４）ロック解除状態に書き換えられたことを検知して、（５）状態フィールド２１４ｅおよび理由フィールド２１４ｆの値を取得し、（６）状態フィールド２１４ｅが「エラー」である場合、理由フィールド２１４ｆに入力された理由を含めて、取得要求のクライアント９０に対しエラー通知３１８ｂを実施する。
【００８５】
図１１は、データベース接続に依存したイベント通知トリガの中断動作のシーケンスを示す。図１１に示したステップＳ６０１〜ステップＳ６０３の処理は、イベント通知トリガの開始処理に対応し、ステップＳ７０１〜ステップＳ７１２の処理は、イベント通知処理の中断動作に対応する。
【００８６】
図１０に示す例では、ステップＳ６０１では、予め確立されたデータベース接続（クライアントＩＤ：２）を介して、クライアント９０からSTART CLIENT TRIGGER ステートメントにより、データベース接続（クライアントＩＤ：１）に依存したトリガの開始要求が発行される。ステップＳ６０２では、トリガの開始要求に応答して、トリガ開始コンポーネント６２は、定義データをテーブル２００から読み出し、依存接続のＩＤを含めて動作トリガ登録テーブル２１４にエントリを追加し、ステップＳ６０３で、データベース接続（クライアントＩＤ：２）を介して、開始要求に対する応答をクライアント９０に返す。そして、開始されたトリガに対応する状態変更イベントが、イベント処理コンポーネント７０による検知の対象となる。
【００８７】
ステップＳ７０１では、データベース接続（クライアントＩＤ：２）を介して、クライアント９０からGET CLIENT TRIGGER 構文のステートメントによるイベント通知の取得要求が発行される。ステップＳ７０２では、トリガデータ取得コンポーネント６４は、取得要求に応答して、対応エントリのロックキーのモニタを開始し、ロック解除を待ち受ける。
【００８８】
ステップＳ７０３では、データベース接続（クライアントＩＤ：１）を介して、クライアント９０からDISCONNECT 構文のステートメントによるデータベース接続の切断要求が発行される。ステップＳ７０４では、通信サービス・コンポーネント５６は、依存接続の切断を検知し、ステップＳ７０５で、状態フィールド２１４ｅおよび理由フィールド２１４ｆに所定の値をセットしてエラー処理を行い、ステップＳ７０６で、動作トリガ登録テーブル２１４の対応エントリのフィールド２１４ｄをロック解除状態に書き換え、ステップＳ７０７で、DISCONNECT 構文のステートメントに対する応答を返すとともに、切断処理を実施する。
【００８９】
ステップＳ７０８〜Ｓ７１２は、図８に示したステップＳ４０８〜Ｓ４１２の処理と同様であるため、詳細な説明を省略する。トリガデータ取得コンポーネント６４は、ステップＳ７０９で、ロック解除を検知し、ステップＳ７１０では、エラー情報を取得し、ステップＳ７１１では、取得要求で用いたデータベース接続を介して取得要求に対する応答として、エラー通知をクライアントに返す。トリガデータ取得コンポーネント６４は、ステップＳ７１２では、動作トリガ登録テーブル２１４のエラー情報をクリアして、ロックキー・フィールド２１２ｄを、再びロック状態に書き換える。
【００９０】
以上説明したように、本実施形態では、クライアント９０は、データベースの状態変更のイベント通知が必要となった場合、イベント通知トリガの動作の開始要求を発行してイベント通知トリガの動作を開始し、続いて、イベント通知の取得要求を発行する。これにより、クライアント９０は、取得要求で用いたデータベース接続を用いて、要求の状態変更イベントが発生したことに応答して、イベント通知を受け取ることができる。その際には、サーバ１０は、別途イベント通知のためのポートを開く必要なく、また、クライアント９０からのポーリングを処理する必要なく、またクライアント９０側のアプリケーション間で密に連携させる必要もない。したがって、低負荷、高セキュリティ、かつ高いアプリケーションの独立性を維持しつつ、必要とするクライアントに対してデータベースの状態変更イベントを通知するメカニズムが実現される。
【００９１】
また本実施形態のサーバ１０では、トリガ中断コンポーネント７２、タイマコンポーネント７４、通信サービス・コンポーネント５６が、それぞれ中断要求の受信、タイマ満了、依存接続の切断など、状態変更イベント通知の取得処理の実行を取り消す契機となるイベントの発生に応答して、イベント通知の取得処理の取り消しを結果として与える。これにより、取得要求の条件に合致する状態変更を検知する前であっても、イベント通知が不要となった場合に、クライアント９０は、中断要求により明示的に指定したタイミング、予め定めたタイムアウト期限に達したタイミング、予め依存関係を指定したデータベース接続が切断されたタイミングなど、種々のタイミングで自由度高く取得要求を撤回することができ、データベース接続の制御をクライアント９０に戻すことができる。
【００９２】
以上説明したように、本発明によれば、データの追加・更新・削除といったデータベースの状態変更に応答して、クライアントに対して該状態変更を通知するイベント通知メカニズムを、低負荷、高セキュリティ、かつ高いアプリケーションの独立性を維持しつつ実現する情報管理サーバ、該情報管理サーバを含む情報処理システム、該情報管理サーバが実行する通信方法およびプログラムを提供することができる。
【００９３】
なお、本発明につき、発明の理解を容易にするために各機能部および各機能部の処理を記述したが、本発明は、上述した特定の機能部が特定の処理を実行する外、処理効率や実装上のプログラミングなどの効率を考慮して、いかなる機能部に、上述した処理を実行するための機能を割当てることができる。
【００９４】
本発明の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向プログラミング言語、ＳＱＬなどのデータベース言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布または伝送して頒布することができる。
【００９５】
これまで本発明を、特定の実施形態をもって説明してきたが、本発明は、実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【図面の簡単な説明】
【００９６】
【図１】データベース・サーバのハードウェア構成の実施形態を示す図。
【図２】本実施形態のデータベース・サーバおよびデータベース・クライアント上に実現されるデータベース・システムの機能ブロック図。
【図３】トリガ作成コンポーネントが実行する処理を概略的に示す図。
【図４】トリガ開始コンポーネント、トリガデータ取得コンポーネントおよびイベント処理コンポーネントが実行する処理を概略的に示す図。
【図５】トリガ削除コンポーネントおよびトリガ停止コンポーネントが実行する処理を概略的に示す図。
【図６】イベント通知トリガ機能の動作のシーケンス図。
【図７】トリガデータ取得コンポーネント、トリガ中断コンポーネントおよびタイマコンポーネントが実行する処理を概略的に示す図。
【図８】イベント通知トリガの中断動作のシーケンス図。
【図９】イベント通知トリガのタイマ満了動作のシーケンス図。
【図１０】通信サービス・コンポーネントおよびトリガデータ取得コンポーネントが実行する処理を概略的に示す図。
【図１１】データベース接続に依存したイベント通知トリガの中断動作のシーケンス図。
【図１２】トリガ機能を用いるステートメントの例文。
【符号の説明】
【００９７】
１０…サーバ、１２…ＣＰＵ、１４…キャッシュ・メモリ、１６…システム・メモリ、１８…システム・バス、２０…グラフィックス・ドライバ、２２…ＮＩＣ、２４…ディスプレイ、２６…Ｉ／Ｏバス・ブリッジ、２８…バス、３０…ハードディスク、３２…入力装置、３４…コンピュータ装置、５０…ＤＢＭＳ、５２…データベース記憶部、５４…イベント通知トリガ・コンポーネント群、５６…通信サービス・コンポーネント、５８…イベント通知トリガ定義登録部、６０…トリガ作成コンポーネント、６２…トリガ開始コンポーネント、６４…トリガデータ取得コンポーネント、６６…トリガ削除コンポーネント、６８…トリガ停止コンポーネント、７０…イベント処理コンポーネント、７２…トリガ中断コンポーネント、７４…タイマコンポーネント、８０…ネットワーク、９０…クライアント、９２…ＤＢ接続ＡＰＩ、９４…アプリケーション、９６…ファンクション機能部、９８…ユーザ・インタフェース機能部、１００…機能ブロック、２００…イベント通知トリガ定義テーブル、２１０，２１２，２１４…動作トリガ登録テーブル、２２０…結果出力データ、２３０…タイマ設定テーブル、３００，３０２，３０４ａ，３０５，３０６，３０８，３１０，３１２ａ，３１４，３１６，３１８ａ，３２０…ステートメント、３０４ｂ，３１２ｂ，３１８ｂ…応答
【図１】
2010026744.tif 000003
【図２】
2010026744.tif 000004
【図３】
2010026744.tif 000005
【図４】
2010026744.tif 000006
【図５】
2010026744.tif 000007
【図６】
2010026744.tif 000008
【図７】
2010026744.tif 000009
【図８】
2010026744.tif 000010
【図９】
2010026744.tif 000011
【図１０】
2010026744.tif 000012
【図１１】
2010026744.tif 000013
【図１２】
2010026744.tif 000014