(57)【要約】  情報処理装置は、アクセス要求手段、アクセス種別判定手段、通知先情報取得手段、および通知手段を有する。また、情報処理装置は、データベースサーバに記憶されている特定のデータのロケーション情報に対応して通知先の情報を記憶する通知先情報記憶手段にアクセス可能である。アクセス種別判定手段は、アクセス要求手段から発行されたアクセス要求が更新にかかるアクセス要求か否かを判定する。通知先情報取得手段は、発行されたアクセス要求が更新にかかるアクセス要求である場合に、そのアクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を通知先情報記憶手段から取得する。通知手段は、取得された通知先の情報で特定される通知先に通知を出す。
2012108175.tif 000002
【特許請求の範囲】
【請求項１】
データベースサーバへのアクセス要求を発行するアクセス要求手段と、アクセス種別判定手段と、通知先情報取得手段と、通知手段とを有する情報処理装置が実行するデータベース更新通知方法であって、
前記アクセス種別判定手段が、前記アクセス要求手段から発行されたアクセス要求が更新にかかるアクセス要求か否かを判定し、
前記通知先情報取得手段が、前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、前記データベースサーバに記憶されている特定のデータのロケーション情報に対応して前記特定のデータに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段から取得し、
前記通知手段が、前記取得された通知先の情報で特定される通知先に通知を出す
ことを特徴とするデータベース更新通知方法。
【請求項２】
前記情報処理装置が通知先情報付加判定手段と通知先情報登録手段とをさらに有し、
前記通知先情報付加判定手段が、前記アクセス要求手段から発行されたアクセス要求に通知先の情報が付加されているか否かを判定し、
前記通知先情報登録手段が、前記アクセス要求に付加されている通知先の情報を、前記アクセス要求に含まれるアクセス先データのロケーション情報に対応付けて前記通知先情報記憶手段に記憶する
ことを特徴とする請求項１に記載のデータベース更新通知方法。
【請求項３】
前記通知先の情報は、自情報処理装置で稼働するアプリケーションプログラムを特定する識別子を含む
ことを特徴とする請求項１または２に記載のデータベース更新通知方法。
【請求項４】
前記通知先の情報は、他の情報処理装置を特定する識別子と前記他の情報処理装置で稼働するアプリケーションプログラムを特定する識別子とを含む
ことを特徴とする請求項１または２に記載のデータベース更新通知方法。
【請求項５】
前記通知先の情報は、通知先に通知する情報として、コールバック関数を特定する情報を含む
ことを特徴とする請求項１乃至４の何れかに記載のデータベース更新通知方法。
【請求項６】
前記通知先情報記憶手段は、複数の情報処理装置で共用するために前記ネットワークに接続されている
ことを特徴とする請求項１乃至５の何れかに記載のデータベース更新通知方法。
【請求項７】
前記通知先情報記憶手段は、各々の前記情報処理装置に接続されている
ことを特徴とする請求項１乃至５の何れかに記載のデータベース更新通知方法。
【請求項８】
データベースサーバへのアクセス要求を発行するアクセス要求手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求か否かを判定するアクセス種別判定手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、前記データベースサーバに記憶されている特定のデータのロケーション情報に対応して前記特定のデータに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段から取得する通知先情報取得手段と、
前記取得された通知先の情報で特定される通知先に通知を出す通知手段と
を備えることを特徴とする情報処理装置。
【請求項９】
コンピュータを、
データベースサーバへのアクセス要求を発行するアクセス要求手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求か否かを判定するアクセス種別判定手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、前記データベースサーバに記憶されている特定のデータのロケーション情報に対応して前記特定のデータに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段から取得する通知先情報取得手段と、
前記取得された通知先の情報で特定される通知先に通知を出す通知手段と
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースをアクセスする情報処理装置におけるデータベース更新通知方法に関し、特にデータベース内の特定のデータに変更が行われた際に特定の通知先に通知を出すデータベース更新通知方法に関する。
【背景技術】
【０００２】
一般にこの種のデータベース更新通知方法は、特定のデータに変更が行われたことを検出する仕組みをデータベースのサーバ側に組み込むことで実現されている。【０００３】
例えば特許文献１には、データベースを有するサーバに、データベースを監視するルール、検知した結果を通知するルール、およびデータベースをアクセスした履歴とを保持するファイルを備え、データベースとは別のプロセスを使用して、サーバが定期的に監視ルールとアクセス履歴ファイルを参照して、監視データに変更がないかをチェックし、変更を検知すると、通知ルールに従い特定のユーザに通知を出す技術が記載されている。【０００４】
また特許文献２には、データベースを有するサーバで、適当な方法、例えば、ファイルのサイズおよびアクセス時刻を定期的にチェックする方法等を使用して、データファイルに変更があったか否かを検出し、変更があった場合に更新内容等を特定のクライアントに通知する方法が記載されている。【０００５】
また特許文献１の段落０００４には、データベース本体が、監視している表に対して更新（ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ）命令が発行されたとき、関連付けられたストアードプロシージャを実行してデータの変更を検知する方法が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平９−２８２２１０号公報
【特許文献２】特表２００２−５３３８３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
データベースのサーバ側に組み込んだ機能により、データベース中の特定のデータに変更が行われたか否かを検出することは至極当然の考え方である。このため、上述したように各種の方法が提案されている。しかし、データベースに変更が行われたか否かを監視し、通知を行う機能をサーバ側に実装すると、サーバのＣＰＵおよびＩ／Ｏの負荷が高まってしまい、データベースのスループットが低下する。【０００８】
本発明の目的は、上述したような課題、すなわち、データベース内の特定のデータに変更が行われた際に特定の通知先に通知を出すようにすると、データベースのスループットが低下する、という課題を解決するデータベース更新通知方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の一形態にかかるデータベース更新通知方法は、
データベースサーバへのアクセス要求を発行するアクセス要求手段と、アクセス種別判定手段と、通知先情報取得手段と、通知手段とを有する情報処理装置が実行するデータベース更新通知方法であって、
上記アクセス種別判定手段が、上記アクセス要求手段から発行されたアクセス要求が更新にかかるアクセス要求か否かを判定し、
上記通知先情報取得手段が、上記発行されたアクセス要求が更新にかかるアクセス要求である場合に、上記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、上記データベースサーバに記憶されている特定のデータのロケーション情報に対応して上記特定のデータに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段から取得し、
上記通知手段が、上記取得された通知先の情報で特定される通知先に通知を出す
といった構成を採る。【００１０】
また本発明の他の形態にかかる情報処理装置は、
データベースサーバへのアクセス要求を発行するアクセス要求手段と、
上記発行されたアクセス要求が更新にかかるアクセス要求か否かを判定するアクセス種別判定手段と、
上記発行されたアクセス要求が更新にかかるアクセス要求である場合に、上記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、上記データベースサーバに記憶されている特定のデータのロケーション情報に対応して上記特定のデータに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段から取得する通知先情報取得手段と、
上記取得された通知先の情報で特定される通知先に通知を出す通知手段と
を備えるといった構成を採る。
【発明の効果】
【００１１】
本発明は上述したような構成を有するため、データベースのスループットを低下させることなしに、データベースの特定のデータに変更が行われたことを検出して通知を出すことが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施形態のブロック図である。
【図２】本発明の第１の実施形態の動作を示すフローチャートである。
【図３】本発明の第２の実施形態のブロック図である。
【図４】本発明の第３の実施形態のブロック図である。
【図５】本発明の第３の実施形態におけるコールバック処理部のブロック図である。
【図６】本発明の第３の実施形態におけるアクセス要求発行時の動作を示すフローチャートである。
【図７】本発明の第３の実施形態におけるデータ更新通知受信時の動作を示すフローチャートである。
【図８】本発明の第４の実施形態のブロック図である。
【図９】本発明の第４の実施形態におけるコールバック処理部のブロック図である。
【図１０】本発明の第４の実施形態におけるアクセス要求発行時の動作を示すフローチャートである。
【図１１】本発明の第４の実施形態におけるデータ更新通知受信時の動作を示すフローチャートである。
【発明を実施するための形態】
【００１３】
次に本発明の実施の形態について図面を参照して詳細に説明する。
[第１の実施形態]
図１を参照すると、本発明の第１の実施形態は、１以上の情報処理装置１と、データベースサーバ２と、これらを相互に通信可能に接続するネットワーク３とから構成される。
【００１４】
データベースサーバ２は、ＫＶＳ（Ｋｅｙ  Ｖａｌｕｅ  Ｓｔｏｒｅ）サーバやＳＱＬサーバなどで構成される。データベースサーバ２は、１以上の情報処理装置１で共有するデータを蓄積している。
【００１５】
情報処理装置１は、データベースサーバ２に蓄積されているデータを参照、更新するクライアントである。情報処理装置１は、通知先情報記憶手段１１、アクセス要求手段１２、アクセス種別判定手段１３、通知先情報取得手段１４、および通知手段１５を有する。
【００１６】
通知先情報記憶手段１１は、データベースサーバ２に記憶されている特定のデータのロケーション情報に対応して、その特定のデータに変更があった際に通知を出す通知先の情報を記憶する機能を有する。
【００１７】
上記通知先の情報は、例えば、自情報処理装置１上で稼働する図示しないアプリケーションプログラムに対して通知を出すのであれば、そのアプリケーションプログラムを特定する情報（例えばプロセスＩＤ）である。また、上記通知先の情報は、例えば、他の情報処理装置１上で稼働する図示しないアプリケーションプログラムに対して通知を出すのであれば、他の情報処理装置１を特定する情報（例えば、その情報処理装置のＩＰアドレス）と、その情報処理装置上でそのアプリケーションプログラムを特定する情報（例えばプロセスＩＤ）である。また、上記通知先の情報は、さらに、通知先に対して通知する情報を含んでいてもよい。例えば上記通知先の情報は、通知先に対して通知する情報として、コールバック情報を一意に識別するための情報（例えば、コールバック関数の関数ポインタアドレス）を含んでいてもよい。
【００１８】
また、上記ロケーション情報は、データの位置を示す情報である。例えばデータベースサーバ２がＫＶＳサーバであれば、ＫＶＳにおけるキーがロケーション情報に相当する。
【００１９】
アクセス要求手段１２は、データベースサーバ２へのアクセス要求を発行する機能を有する。
【００２０】
アクセス種別判定手段１３は、アクセス要求手段１２から発行されたアクセス要求が更新にかかるアクセス要求か否かを判定する機能を有する。アクセス種別判定手段１３は、例えば、アクセス要求を解析してアクセスタイプを判定し、アクセスタイプがデータの更新を行うもの（例えばＳＥＴ命令など）であれば、更新にかかるアクセス要求であると判定する。
【００２１】
通知先情報取得手段１４は、アクセス要求が更新にかかるアクセス要求であるとアクセス種別判定手段１３により判定された場合に、そのアクセス要求によって更新するデータのロケーション情報に対応する通知先の情報が通知先情報記憶手段１１に記憶されているか否かを調べ、記憶されていればその通知先の情報を通知先情報記憶手段１１から取得する機能を有する。通知先情報取得手段１４は、例えば、ＫＶＳサーバへのアクセス要求であれば、アクセス要求に含まれるキーを使用して、そのキーに対応する通知先の情報が通知先情報記憶手段１１に記憶されているか否かを調べ、記憶されていればその情報を取得する。
【００２２】
通知手段１５は、通知先情報取得手段１４により取得された通知先の情報によって特定される通知先に対して、データに変更があった旨の通知を出す機能を有する。また、通知手段１５は、通知先の情報に、通知先に通知する情報が含まれていれば、通知先に通知する情報を添えて通知を行う。
【００２３】
次に本実施形態の動作を、図２のフローチャートを参照して説明する。
【００２４】
今、情報処理装置１の通知先情報記憶手段１１に、データのロケーション情報Ｌ１に対応して通知先情報Ｔ１が記憶されているものとする。
【００２５】
情報処理装置１のアクセス要求手段１２がデータベースサーバ２に対してアクセス要求を発行すると（ステップＳ１）、そのアクセス要求はネットワーク３を通じてデータベースサーバ２に対して送信されるとともに、アクセス種別判定手段１３で受信される。
【００２６】
アクセス種別判定手段１３は、受信したアクセス要求の種別を判定する（ステップＳ２）。若し、更新にかかるアクセス要求であれば、通知先情報取得手段１４は、そのアクセス要求に含まれるアクセス対象データのロケーション情報に対応する通知先の情報が通知先情報記憶手段１１に記憶されているか否かを調査する（ステップＳ３、Ｓ４）。ここで、アクセス要求に含まれるロケーション情報がＬ１であれば、通知先情報Ｔ１が存在するので、それを取得する。
【００２７】
通知手段１５は、通知先の情報Ｔ１を通知先情報取得手段１４から受け取り、通知先の情報Ｔ１で特定される通知先に対して通知を出す（ステップＳ５）。このとき、通知先に通知すべき情報があれば、それを添えて通知が行われる。通知先では、この通知を受信することにより、データベースサーバ２のロケーション情報Ｌ１で特定されるデータが変更されたことを認識することができる。また、通知先は、コールバック関数の関数ポインタアドレスが通知に添えられていれば、その関数ポインタアドレスのコールバック関数を呼び出す。これによって、特定のデータの変更に同期して、所定の処理を実行することができる。
【００２８】
以上のように、本実施形態によれば、データベースサーバ２の特定のデータに変更が行われたことを検出し通知を出す処理に関して、データベースサーバ２は一切関与していない。このため、データベースのスループットを低下させることなしに、データベースの特定のデータに変更が行われたことを検出して通知を出すことが可能となる。
【００２９】
また、データベースサーバ２の上記特定のデータに対してアクセスする可能性のある全ての情報処理装置１に、通知先情報記憶手段１１、アクセス要求手段１２、アクセス種別判定手段１３、通知先情報取得手段１４、および通知手段１５を組み込んでおくことにより、データベースサーバ２の特定のデータに変更が行われたことを漏れなく検出し、通知を出すことができる。
【００３０】
なお、上記の説明では、通知先情報記憶手段１１をそれぞれの情報処理装置１に個別に配置した。しかし、図１に示されるように、１または複数の通知先情報記憶手段４をネットワーク３に接続し、この通知先情報記憶手段４を複数の情報処理装置１で共用するようにしてもよい。また、上記の説明では、アクセス種別判定手段１３は、アクセス要求手段１３が発行したアクセス要求とは非同期に処理を行ったが、アクセス要求が正常終了したことを確認して処理を開始するようにしてもよい。
【００３１】
[第２の実施形態]
図３を参照すると、本発明の第２の実施形態は、情報処理装置１が、通知先情報付加判定手段１６と通知先情報登録手段１７とをさらに備えている点で、図１に示した第１の実施形態と相違する。
【００３２】
通知先情報付加判定手段１６は、アクセス要求手段１２から発行されたアクセス要求に通知先の情報が付加されているか否かを判定する機能を有する。
【００３３】
通知先情報登録手段１７は、アクセス要求に付加されている通知先の情報を、そのアクセス要求に含まれるアクセス先データのロケーション情報に対応付けて通知先情報記憶手段１１に記憶する機能を有する。
【００３４】
次に本実施形態の動作を説明する。本実施形態では、データベースサーバ２の或るデータに変更があった際に特定の通知先に通知が出るようにするために通知先情報記憶手段１１にデータのロケーション情報と通知先情報とを登録する第１の動作と、通知先情報記憶手段１１に記憶された情報に基づいてデータベースサーバ２へのアクセス要求を監視し特定のデータに変更があった場合に特定の通知先に通知を出す第２の動作とが行われる。第２の動作は第１の実施形態における動作と同様であるため、以下では、主に第１の動作について説明する。
【００３５】
情報処理装置１は、データベースサーバ２の或る位置に存在するデータに変更があった場合に、特定の通知先に通知が出るようにしたい場合、そのデータをアクセスする要求を出す。ただし、そのアクセス要求には、通知先の情報を付加しておく。アクセス要求の種別は、参照要求でも更新要求でもどちらでもよい。ここでは、アクセス要求に、通知先の情報Ｔ２が付加されているものとする。また、このアクセス要求に含まれる、アクセス先のデータを特定するロケーション情報をＬ２とする。
【００３６】
アクセス要求手段１２から、通知先の情報Ｔ２が付加されたアクセス要求が発行されると、そのアクセス要求はネットワーク３を通じてデータベースサーバ２に対して送信されるとともに、アクセス種別判定手段１３および通知先情報付加判定手段１６で受信される。
【００３７】
アクセス要求を受信したアクセス種別判定手段１３、それに引き続く通知先情報取得手段１４、通知手段１５の動作、すなわち第２の動作は、第１の実施形態における動作と同じである。
【００３８】
他方、アクセス要求を受信した通知先情報付加判定手段１６は、そのアクセス要求に通知先の情報が付加されているか否かを判定する。今の場合、通知先の情報Ｔ２が付加されている。このため、通知先情報登録手段１７は、アクセス要求に付加されている通知先の情報Ｔ２を、そのアクセス要求に含まれるアクセス先データのロケーション情報Ｌ２に対応付けて通知先情報記憶手段１１に記憶する。
【００３９】
このように本実施形態によれば、データベースサーバ２の或る位置に存在するデータに変更があった場合に特定の通知先に通知が出るようにしたい場合、通知先の情報を付加したアクセス要求を使用してそのデータをアクセスすればよい。
【００４０】
[第３の実施形態]
図４を参照すると、本実施形態は、クライアント１００とＫＶＳサーバ２００およびネットワーク３００とから構成されている。
【００４１】
ＫＶＳサーバ２００は、クライアント１００からＫｅｙ−Ｖａｌｕｅ形式のアクセス要求を受け付けて処理するサーバ（情報処理装置）である。ＫＶＳサーバ２００は、ＳＱＬサーバのストアードプロシージャのような、データ更新時にアプリケーションの指定した処理を実行する機能を備えておらず、データ更新通知を行うことができない。
【００４２】
クライアント１００は、ＫＶＳサーバ２００にアクセスするプログラム１１０、プログラム１２０およびコールバックＩＤ管理部１３０を備えたノード（情報処理装置）である。
【００４３】
コールバックＩＤ管理部１３０は、キーとコールバックＩＤとを関連づけて保存する。ここでコールバックＩＤとは、クライアント１００内でアプリケーションおよびコールバック情報を一意に識別する識別子であり、例えばＬｉｎｕｘのＰＩＤ（Ｐｒｏｃｅｓｓ  ＩＤ）とコールバック関数の関数ポインタアドレスとを連結した文字列などが相当する。以下の説明では、コールバックＩＤをＰＩＤと関数ポインタアドレスとを連結した文字列として説明する。
【００４４】
プログラム１１０は、ＫＶＳアプリケーション１１１、ＫＶＳライブラリ１１２およびコールバック処理部１１３から構成される。
【００４５】
ＫＶＳアプリケーション１１１は、ＫＶＳサーバ２００へアクセスを行う主体であり、ＫＶＳサーバ２００に対するアクセス要求を発行する。ここでアクセス要求とは、”ＳＥＴ”や”ＧＥＴ”などのアクセスタイプや、アクセス先のデータロケーション情報、データバッファ、コールバック情報を含む。このうち、データロケーション情報は、アクセス先のデータの位置を示す情報であり、ＫＶＳにおけるキーがこれに該当する。以下の説明では、キーをデータロケーション情報と見なして説明する。データバッファは、ロケーション情報と関連付けられたデータを示し、ＫＶＳにおけるバリュー（値）がこれに相当する。またコールバック情報は、アクセス要求内のデータロケーション情報によって特定されるデータが他のプログラムから更新された場合に呼び起こされるコールバックの情報であり、コールバック関数などがこれに相当する。以下の説明では、コールバック関数の関数ポインタアドレスをコールバック情報と見なして説明する。なお他のプログラムで更新されてもコールバックする必要がない場合は、コールバック情報を指定する必要はない。
【００４６】
ＫＶＳライブラリ１１２は、ＫＶＳサーバ２００とＫＶＳアプリケーション１１１との間のインタフェースを管理し、アクセス要求をＫＶＳサーバ２００のインタフェースに合った形式でＫＶＳサーバ２００へ送信する。またＫＶＳライブラリ１１２は、ＫＶＳサーバ２００から処理結果が戻ってくると、それを上位部に返す。
【００４７】
コールバック処理部１１３の詳細および他のコンポーネントとの関連図を図５に示す。図５を参照すると、コールバック処理部１１３は、コールバックＩＤ取得部１１４、コールバックＩＤ設定部１１５、コールバックＩＤ通信部１１６、コールバック実行部１１７から構成される。
【００４８】
コールバックＩＤ取得部１１４は、ＫＶＳアプリケーション１１１から通知されたアクセス要求に含まれているアクセスタイプを判定する。アクセスタイプがデータの更新を行う「更新系」アクセスの場合（例：”ＳＥＴ”命令）、アクセス要求に含まれるテーブル名をもとにコールバックＩＤ管理部１３０に問い合わせ、データロケーション情報に関連づけられているコールバックＩＤを取得する。またコールバックＩＤ取得部１１４は、取得したコールバックＩＤは関連づけを解除し、コールバックＩＤ管理部１３０から消去する。
【００４９】
コールバックＩＤ通信部１１６は、プログラム１２０や他のプログラムに対して、コールバックＩＤを送受信する。具体的には、コールバックＩＤ取得部１１４が取得したコールバックＩＤをもとに、該当するプログラムのコールバック処理部に対して、コールバックＩＤを通知する。この通知がデータ更新通知に相当する。また、他のプログラムからコールバックＩＤを受信すると、それをコールバック実行部１１７に通知する。
【００５０】
コールバック実行部１１７は、コールバックＩＤ通信部１１６から通知を受けたコールバックＩＤをもとに該当するコールバック関数を実行する。これにより、ＫＶＳアプリケーション１１１に対してデータ更新が通知されたことになる。
【００５１】
コールバックＩＤ設定部１１５は、アクセス要求にコールバック関数の関数ポインタが付加されている場合は、自プログラムのＰＩＤとコールバック関数の関数ポインタアドレスとを連結した文字列をコールバックＩＤとして生成する。そしてコールバックＩＤ設定部１１５は、そのコールバックＩＤをキーと関連づけて、コールバックＩＤ管理部１３０に保存する。なお、すでに登録されているコールバックＩＤがある場合は追記する。
【００５２】
またプログラム１２０は、ＫＶＳアプリケーション１２１、ＫＶＳライブラリ１２２、コールバック処理部１２３を備えているが、それぞれＫＶＳアプリケーション１１１、ＫＶＳライブラリ１１２、コールバック処理部１１３と同様であるため、説明は省略する。
【００５３】
[動作の説明]
本実施形態の全体の動作について詳細に説明する。まず図６のフローチャートを参照して、プログラム１１０がＫＶＳサーバ２００をアクセスする際の動作について説明する。
【００５４】
まずＫＶＳアプリケーション１１１がＫＶＳサーバ２００へのアクセス要求を発行する（図６のステップＡ１）。ＫＶＳライブラリ１１２は、ＫＶＳサーバ２００へアクセス要求を送信する（ステップＡ２）。ＫＶＳサーバ２００は、送信されてきたアクセス要求をもとにデータベース制御を行い、処理結果をＫＶＳライブラリ１１２に返す（ステップＡ３）。ＫＶＳライブラリ１１２は、ＫＶＳサーバ２００からの処理結果を判定し（ステップＡ４）、結果が異常の場合、異常処理を行い（ステップＡ５）終了する。結果が正常の場合、コールバックＩＤ取得部１１４が、アクセス要求のアクセスタイプを判定する（ステップＡ６）。ステップＡ６において、アクセスタイプが「更新系」アクセスの場合、コールバックＩＤ管理部１３０に問い合わせて、アクセス要求のキーに関連づけられているコールバックＩＤを取得し、取得したＩＤをコールバックＩＤ通信部１１６に通知する（ステップＡ７）。するとコールバックＩＤ通信部１１６は、通知されたコールバックＩＤからＰＩＤを解析し該当するプログラムに対して、データ更新通知としてコールバックＩＤを送信する（ステップＡ８）。
【００５５】
次にコールバックＩＤ設定部１１５は、アクセス要求にコールバック関数のポインタアドレスが付加されているか判定する（ステップＡ９）。ステップＡ９において、ポインタアドレスが付加されている場合、自プログラムのＰＩＤとコールバック関数のポインタアドレスとを連結した文字列を生成し（ステップＡ１０）、キーと関連づけて、コールバックＩＤ管理部１３０に保存し（ステップＡ１１）、終了する。ステップＡ９において、ポインタアドレスが付与されていない場合は、終了する。またステップＡ６において、アクセスタイプが「非更新系」アクセスの場合は、ステップＡ９に進む。
【００５６】
プログラム１２０がＫＶＳサーバ２００に対してアクセス要求を出した際の動作は、プログラム１１０がＫＶＳサーバ２００に対してアクセス要求を出した際の動作と同様であるため、説明は省略する。
【００５７】
次に図７のフローチャートを参照して、プログラム１１０がデータ更新通知を受信する場合の動作について説明する。
【００５８】
コールバックＩＤ通信部１１６が他プログラムからのデータ更新通知を受信する（図７のステップＢ１）。すると、コールバックＩＤ通信部１１６は、データ更新通知の中に含まれているコールバックＩＤをコールバック実行部１１７に通知する（ステップＢ２）。コールバック実行部１１７は、コールバックＩＤを解析し、該当するコールバック関数を実行する（ステップＢ３、Ｂ４）。
【００５９】
プログラム１２０がデータ更新通知を受信する場合の動作は、プログラム１１０がデータ更新通知を受信する場合の動作と同様であるため、説明は省略する。
【００６０】
[効果の説明]
本実施形態では、バイナリ形式で提供されることが多いデータベースサーバやデータベースクライアントライブラリに関係なくデータ更新通知を行うよう構成されているため、本来データ更新通知機能を備えていないデータベースサーバにもデータ更新通知機能を付与することができる。
【００６１】
また本実施形態では、同一クライアント内でのプログラム間のデータ更新通知を、ネットワークを介すことなく行うよう構成されているため、非常に高速なデータ更新通知を行うことができる。
【００６２】
[第４の実施形態]
図８を参照すると、本実施形態は、ＫＶＳのアプリケーションを実行するクライアント４００、ＳＱＬのアプリケーションを実行するクライアント５００、ＫＶＳサーバ６００、ＳＱＬサーバ７００、コールバックＩＤ管理サーバ８００およびネットワーク９００から構成されている。
【００６３】
コールバックＩＤ管理サーバ８００は、データベースサーバのロケーション情報、例えばアクセス先データベースのＩＰアドレス（以下の説明では、アクセス先データベースのＩＰアドレスをアクセス先データベースのロケーション情報と見なして説明する）とデータロケーション情報とを連結した文字列と、コールバックＩＤを関連づけて保存するものであり、複数のノードからアクセス可能である。ここでコールバックＩＤとは、システム内でコールバック情報を一意に識別する識別子であり、例えば各ノードのＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスとアプリケーションのＰＩＤとコールバック関数の関数ポインタアドレスとを連結した文字列などが相当する。以下の説明では、各ノードのＩＰアドレスとアプリケーションのＰＩＤ、コールバック関数の関数ポインタアドレスを連結した文字列を、コールバックＩＤと見なして説明する。なお、このコールバックＩＤ管理サーバ８００の実体は、ＫＶＳサーバ６００のような非常に高速にアクセスできるデータベースサーバである。
【００６４】
クライアント４００は、内部にＫＶＳアプリケーション４１０、ＫＶＳライブラリ４２０、コールバック処理部４３０を備えたノードである。このうち、ＫＶＳアプリケーション４１０およびＫＶＳライブラリ４２０は第３の実施形態のＫＶＳアプリケーション１１１およびＫＶＳライブラリ１１２と同様の構成であるため、説明は省略する。
【００６５】
コールバック処理部４３０の詳細および他のコンポーネントとの関連図を図９に示す。図９を参照すると、コールバック処理部４３０は、コールバックＩＤ取得部４３１、コールバックＩＤ設定部４３２、コールバックＩＤ通信部４３３、およびコールバック実行部４３４から構成される。
【００６６】
コールバックＩＤ取得部４３１は、ＫＶＳアプリケーション４１０から通知されたアクセス要求に含まれているアクセスタイプを判定する。アクセスタイプがデータの更新を行う「更新系」アクセスの場合、アクセス先データベースを一意に識別するための識別子、例えばアクセス先データベースのＩＰアドレス（以下の説明では、アクセス先データベースを一意に識別するための識別子としてアクセス先データベースのＩＰアドレスとして説明する）とアクセス要求に含まれるデータロケーション情報（ＫＶＳの場合はキー）とを連結した文字列をもとに、コールバックＩＤ管理サーバ８００に問い合わせ、データロケーション情報に関連づけられているコールバックＩＤを取得する。なお、コールバックＩＤ取得部４３１は、取得したコールバックＩＤは関連づけを解除し、コールバックＩＤ管理サーバ８００から消去する。
【００６７】
コールバックＩＤ通信部４３３は、コールバックＩＤを送受信する。具体的には、コールバックＩＤ取得部４３１が取得したコールバックＩＤをもとに、該当するプログラムのコールバック処理部に対して、コールバックＩＤを通知する。この通知がデータ更新通知に相当する。また、コールバックＩＤ通信部４３３は、他のプログラムからコールバックＩＤを受信すると、それをコールバック実行部４３４に通知する。
【００６８】
コールバック実行部４３４は、コールバックＩＤ通信部１１６から通知を受けたコールバックＩＤをもとに該当するコールバック関数を実行する。これにより、ＫＶＳアプリケーション１１１に対してデータ更新が通知されたことになる。
【００６９】
コールバックＩＤ設定部４３２は、アクセス要求にコールバック関数の関数ポインタが付加されている場合は、自ノードのＩＰアドレスと自プログラムのＰＩＤとコールバック関数の関数ポインタアドレスとを連結した文字列をコールバックＩＤとして生成する。このコールバックＩＤを、アクセス先データベースサーバのIPアドレスとキーとを連結した文字列に関連づけて、コールバックＩＤ管理サーバ８００に保存する。なお、コールバックＩＤ設定部４３２は、すでに登録されているコールバックＩＤがある場合、追記する。
【００７０】
ＳＱＬサーバ７００は、クライアントからＳＱＬ形式のアクセス要求を受け付けて処理するサーバである。なお、このＳＱＬサーバ７００は、ストアードプロシージャのような、データ更新時にアプリケーションが指定した処理を実行する機能がない。
【００７１】
クライアント５００は、内部にＳＱＬアプリケーション５１０、ＳＱＬライブラリ５２０、およびコールバック処理部５３０を備えたノードである。
【００７２】
ＳＱＬアプリケーション５１０は、ＳＱＬサーバ７００へアクセスを行う主体であり、ＳＱＬサーバ７００に対するアクセス要求を発行する。ここでアクセス要求とは、”ＩＮＳＥＲＴ”や”ＳＥＬＥＣＴ”などのアクセスタイプや、アクセス先のデータロケーション情報、データバッファ、コールバック情報を含む。このうち、データロケーション情報は、アクセス先のデータの位置を示す情報であり、ＳＱＬ文におけるテーブル名がこれに該当する。以下の説明では、テーブル名をデータロケーション情報と見なして説明する。データバッファは、ロケーション情報と関連付けられたデータを示し、ＳＱＬ文に含まれる値がこれに相当する。またコールバック情報は、アクセス要求内のデータロケーション情報が示すデータが、他のプログラムから更新された場合に呼び起こされるコールバックの情報であり、コールバック関数などがこれに相当する。以下の説明では、コールバック関数の関数ポインタアドレスをコールバック情報と見なして説明する。なお、他のプログラムで更新されてもコールバックする必要がない場合は、コールバック情報を指定する必要はない。
【００７３】
ＳＱＬライブラリ５２０は、ＳＱＬサーバ７００とＳＱＬアプリケーション５１０との間のインタフェースを管理し、アクセス要求をＳＱＬサーバ７００のインタフェースに合った形式でＳＱＬサーバ７００へ送信する。また、ＳＱＬライブラリ５２０は、ＳＱＬサーバ７００から処理結果が戻ってくると、それを上位部に返す。
【００７４】
コールバック処理部５３０は、コールバック処理部４３０と同一の構成になっている。ただしコールバック処理部５３０内部のコールバックＩＤ取得部が、「更新系」アクセスであると判断するアクセスタイプは異なる。ここでは、”ＩＮＳＥＲＴ”や”ＵＰＤＡＴＥ”といったＳＱＬサーバに更新が発生するアクセスタイプを「更新系」アクセスと見なす。
【００７５】
次に、本実施形態の全体の動作について詳細に説明する。まず図１０のフローチャートを参照して、クライアント４００がＫＶＳサーバ６００をアクセスする際の動作について説明する。
【００７６】
まずＫＶＳアプリケーション４１０がＫＶＳサーバへのアクセス要求を発行する（図１０のステップＣ１）。ＫＶＳライブラリ４２０は、ＫＶＳサーバ６００へアクセス要求を送信する（ステップＣ２）。ＫＶＳサーバ６００は送信されてきたアクセス要求をもとにデータベース制御を行い、処理結果をＫＶＳライブラリ４２０に返す（ステップＣ３）。ＫＶＳライブラリ４２０は、ＫＶＳサーバ６００からの処理結果を判定し（ステップＣ４）、結果が異常の場合、異常処理を行い（ステップＣ５）終了する。結果が正常の場合、コールバックＩＤ取得部４３１が、アクセス要求のアクセスタイプを判定する（ステップＣ６）。ステップＣ６において、アクセスタイプが「更新系」アクセスの場合、コールバックＩＤ管理サーバ８００に問い合わせて、アクセス要求のキーに関連づけられているコールバックＩＤを取得し、取得したＩＤをコールバックＩＤ通信部４３３に通知する（ステップＣ７）。するとコールバックＩＤ通信部４３３は、通知されたコールバックＩＤから一意に導き出されるプログラムに対して、データ更新通知としてコールバックＩＤを送信する（ステップＣ８）。
【００７７】
次にコールバックＩＤ設定部４３２は、アクセス要求にコールバック関数のポインタアドレスが付加されているか判定する（ステップＣ９）。ステップＣ９において、ポインタアドレスが付加されている場合、自ノードのＩＰアドレスと自プログラムのＰＩＤとコールバック関数のポインタアドレスとを連結した文字列を生成し、キーと関連づけて、コールバックＩＤ管理サーバ８００に保存し（ステップＣ１１）、終了する。ステップＣ９において、ポインタアドレスが付与されていない場合は、終了する。またステップＣ６において、アクセスタイプが「非更新系」アクセスの場合は、ステップＣ９に進む。
【００７８】
クライアント５００がＳＱＬサーバ７００をアクセスする時の動作は、クライアント４００がＫＶＳサーバ６００をアクセスする時の動作において、ＫＶＳアプリケーション４１０をＳＱＬアプリケーション５１０、ＫＶＳライブラリ４２０をＳＱＬライブラリ５２０、コールバック処理部４３０をコールバック処理部５３０、ＫＶＳサーバ６００をＳＱＬサーバ７００と置き換えた場合と同様であるため、説明は省略する。
【００７９】
次に図１１のフローチャートを参照して、クライアント４００がデータ更新通知を受信する時の動作について説明する。
【００８０】
コールバックＩＤ通信部４３３が他クライアントからのデータ更新通知を受信する（図１１のステップＤ１）。すると、コールバックＩＤ通信部４３３は、データ更新通知の中に含まれているコールバックＩＤをコールバック実行部４３４に通知する（ステップＤ２）。コールバック実行部４３４は、コールバックＩＤを解析し、該当するコールバック関数を実行する（ステップＤ３、Ｄ４）。
【００８１】
クライアント５００がデータ更新通知を受信する時の動作は、クライアント４００がデータ更新通知を受信する時の動作と同様であるため、説明は省略する。
【００８２】
本実施形態によれば、コールバックＩＤ取得部およびコールバックＩＤ設定部が、アクセス先データベースを一意に識別するための識別子をデータロケーション情報に付与して、コールバックＩＤ管理サーバにアクセスするよう構成されているので、複数のデータベースサーバのデータ更新通知を行うことができる。
【００８３】
以上本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されず、その他各種の付加変更が可能である。また、本発明は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体、あるいはフレキシブルディスク、光ディスク、光磁気ディスク、半導体メモリ等の可搬性を有する媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態におけるアクセス要求手段、アクセス種別判定手段、通知先情報取得手段、通知手段、通知先情報負荷判定手段、通知先情報登録手段等の手段として機能させる。
【００８４】
なお、本発明は、日本国にて２０１１年２月１０日に特許出願された特願２０１１−０２６７３５の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。
【符号の説明】
【００８５】
１…情報処理装置
２…データベースサーバ
３…ネットワーク
４…通知先情報記憶手段
１１…通知先情報記憶手段
１２…アクセス要求手段
１３…アクセス種別判定手段
１４…通知先情報取得手段
１５…通知手段
【図１】
2012108175.tif 000003
【図２】
2012108175.tif 000004
【図３】
2012108175.tif 000005
【図４】
2012108175.tif 000006
【図５】
2012108175.tif 000007
【図６】
2012108175.tif 000008
【図７】
2012108175.tif 000009
【図８】
2012108175.tif 000010
【図９】
2012108175.tif 000011
【図１０】
2012108175.tif 000012
【図１１】
2012108175.tif 000013
【手続補正書】
【提出日】平成26年4月21日(2014.4.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データベースサーバへのアクセス要求を発行するアクセス要求手段と、アクセス種別判定手段と、通知先情報取得手段と、通知手段と、通知先情報付加判定手段と、通知先情報登録手段とを有し、前記データベースサーバに記憶されているデータのロケーション情報に対応して前記データに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段に接続する情報処理装置が実行するデータベース更新通知方法であって、
前記アクセス種別判定手段が、前記アクセス要求手段から発行されたアクセス要求が更新にかかるアクセス要求か否かを判定すると共に、前記通知先情報付加判定手段が、前記アクセス要求手段から発行されたアクセス要求に通知先の情報が付加されているか否かを判定し、
前記通知先情報取得手段が、前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を前記通知先情報記憶手段から取得し、
前記通知手段が、前記取得された通知先の情報で特定される通知先に通知を出し、
前記通知先情報登録手段が、前記アクセス要求に付加されている通知先の情報を、前記アクセス要求に含まれるアクセス先データのロケーション情報に対応付けて前記通知先情報記憶手段に記憶する
データベース更新通知方法。
【請求項２】
前記通知先情報取得手段は、前記通知先の情報を取得すると、前記取得した通知先の情報と前記データのロケーション情報との対応付けを前記通知先情報記憶手段から消去する
請求項１に記載するデータベース更新通知方法。
【請求項３】
データベースサーバと前記データベースサーバに記憶されているデータのロケーション情報に対応して前記データに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段とに接続する情報処理装置であって、
データベースサーバへのアクセス要求を発行するアクセス要求手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求か否かを判定するアクセス種別判定手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、前記通知先情報記憶手段から取得する通知先情報取得手段と、
前記取得された通知先の情報で特定される通知先に通知を出す通知手段と、
前記アクセス要求手段から発行されたアクセス要求に通知先の情報が付加されているか否かを判定する通知先情報付加判定手段と、
前記アクセス要求に付加されている通知先の情報を、前記アクセス要求に含まれるアクセス先データのロケーション情報に対応付けて前記通知先情報記憶手段に記憶する通知先情報登録手段と
を備える情報処理装置。
【請求項４】
前記通知先情報取得手段は、前記通知先の情報を取得すると、前記取得した通知先の情報と前記データのロケーション情報との対応付けを前記通知先情報記憶手段から消去する
請求項３に記載する情報処理装置。
【請求項５】
前記通知先の情報は、自情報処理装置で稼働するアプリケーションプログラムを特定する識別子を含む
請求項３または４に記載の情報処理装置。
【請求項６】
前記通知先の情報は、他の情報処理装置を特定する識別子と前記他の情報処理装置で稼働するアプリケーションプログラムを特定する識別子とを含む
請求項３または４に記載の情報処理装置。
【請求項７】
前記通知先の情報は、通知先に通知する情報として、コールバック関数を特定する情報を含む
請求項３乃至６の何れかに記載の情報処理装置。
【請求項８】
データベースサーバと前記データベースサーバに記憶されているデータのロケーション情報に対応して前記データに変更があった際に通知を出す通知先の情報を記憶する通知先情報記憶手段とに接続するコンピュータを、
データベースサーバへのアクセス要求を発行するアクセス要求手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求か否かを判定するアクセス種別判定手段と、
前記発行されたアクセス要求が更新にかかるアクセス要求である場合に、前記アクセス要求によって更新するデータのロケーション情報に対応する通知先の情報を、前記通知先情報記憶手段から取得する通知先情報取得手段と、
前記取得された通知先の情報で特定される通知先に通知を出す通知手段と、
前記アクセス要求手段から発行されたアクセス要求に通知先の情報が付加されているか否かを判定する通知先情報付加判定手段と、
前記アクセス要求に付加されている通知先の情報を、前記アクセス要求に含まれるアクセス先データのロケーション情報に対応付けて前記通知先情報記憶手段に記憶する通知先情報登録手段と
して機能させるためのプログラム。
【請求項９】
前記通知先情報取得手段は、前記通知先の情報を取得すると、前記取得した通知先の情報と前記データのロケーション情報との対応付けを前記通知先情報記憶手段から消去する
請求項８に記載するプログラム。
【国際調査報告】
2012108175.tif 000014
2012108175.tif 000015
2012108175.tif 000016
2012108175.tif 000017