(57)【要約】【課題】ネットワークの異常あるいはクライアント側の異常が起こっても、サーバ側のデータベースに対する影響が出ることを防止する。【解決手段】データベース１０の各レコードにあらかじめ排他制御用キーを格納させておき、参照側アプリケーション２００がデータベース１０のレコードを参照した場合に（Ｓ１）、参照側アプリケーション２００内にデータベース１０の対象レコードから参照した排他制御用キーを格納する（Ｓ２，Ｓ３）。実更新処理の際には、排他制御用キーの比較を行い（Ｓ６）、一致したときに実更新処理を行う（Ｓ７）。実更新処理が終了したら、排他制御用キーを変更して（Ｓ８）、対象レコードのデータの不要な上書きを防止する。【選択図】図２
2006113883.tif 000002
【特許請求の範囲】
【請求項１】
各レコードにデータを格納しているデータベースと、前記データベースの各レコードのデータを参照する参照側アプリケーションと、前記参照側アプリケーションからの更新命令を受けて、前記データベースのレコード内のデータの更新を行う更新側アプリケーションとを備えた排他制御システムであって、
前記データベースの各前記レコードにあらかじめ排他制御用キーを格納させておき、前記参照側アプリケーションが前記データベースのレコードを参照した場合には、前記参照側アプリケーション内に前記データベースの対象レコードから参照した排他制御用キーを格納することを特徴とする排他制御システム。
【請求項２】
前記更新側アプリケーションに設けられ、前記参照側アプリケーションから更新命令が出された場合に、前記参照側アプリケーション内に格納された排他制御用キーと、前記データベースの対象レコードの排他制御用キーとを比較することにより、更新可否を判断するキー比較手段を
さらに備えていることを特徴とする請求項１に記載の排他制御システム。
【請求項３】
前記キー比較手段は、前記更新可否の結果を前記参照側アプリケーションに通知することを特徴とする請求項２に記載の排他制御システム。
【請求項４】
前記更新側アプリケーションに設けられ、前記キー比較手段によって更新可と判断された場合に、前記データベースの対象レコードのデータの更新処理を行うデータ更新手段を
さらに備えていることを特徴とする請求項２または３に記載の排他制御システム。
【請求項５】
前記更新側アプリケーションに設けられ、前記データ更新手段によりデータの更新処理が行われた場合に、前記データベースの対象レコードの排他制御用キーを変更するキー変更手段を
さらに備えていることを特徴とする請求項４に記載の排他制御システム。
【請求項６】
各レコードにデータを格納しているデータベースと、前記データベースの各レコードのデータを参照する参照側アプリケーションと、前記参照側アプリケーションからの更新命令を受けて、前記データベースのレコード内のデータの更新を行う更新側アプリケーションとを備えた排他制御システムで用いられる排他制御プログラムを記憶した計算機に読み取り可能な記憶媒体であって、
前記排他制御プログラムは、
前記データベースの各前記レコードにあらかじめ排他制御用キーを格納させるステップを計算機に実行させるプログラムである
ことを特徴とする排他制御プログラムを記憶した記憶媒体。
【請求項７】
各レコードにデータを格納しているデータベースと、前記データベースの各レコードのデータを参照する参照側アプリケーションと、前記参照側アプリケーションからの更新命令を受けて、前記データベースのレコード内のデータの更新を行う更新側アプリケーションとを備えた排他制御システムで用いられる排他制御プログラムを記憶した計算機に読み取り可能な記憶媒体であって、
前記データベースの各前記レコードはあらかじめ排他制御用キーを格納しており、
前記排他制御プログラムは、
前記参照側アプリケーションが前記データベースのレコードを参照した場合に、前記参照側アプリケーション内に、前記データベースの対象レコードから参照する前記排他制御用キーを格納するステップ
を計算機に実行させるプログラムである
ことを特徴とする排他制御プログラムを記憶した記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は排他制御システムおよび排他制御プログラムを記憶した記憶媒体に関し、特に、参照側アプリケーションからの更新命令を受けてデータベース内のデータの更新を行う更新側アプリケーションを備えた排他制御システムおよび排他制御プログラムを記憶した記憶媒体に関する。
【背景技術】
【０００２】
従来のデータベース排他制御システムとして、データベースマネージメントシステム（以下ＤＢＭＳとする。）内のデータベース内に排他情報を保持することにより、排他制御を実現するシステムがあった。また、このシステムでは更新命令送信時にデータベース内の排他情報をクリアにすることによりレコードロックを解除していた。
【０００３】
しかしながら、このシステムでは、データベースとクライアント側アプリケーションとの間のネットワークの不具合や断線、クライアント側アプリケーションの異常終了やフリーズ、参照しつづけて放置している状態等の予測しえない原因によってデータベース内に不当なロックがかかる恐れがあった。
【０００４】
これに対する方法として、異常終了したデータに対して次回削除対象とすることにより、データベースの整合性を確保する方法が提案されている（例えば、特許文献１参照。）。
【０００５】
また、他の方法として、排他制御情報をサーバ側に格納し、クライアントの動向を監視する方法が提案されている（例えば、特許文献２参照。）。
【０００６】
【特許文献１】特開２００２−１３２５６５号公報
【特許文献２】特開２０００−０２０３７６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献１に記載された方法においては、データ更新作業の不具合によるデータロックは次回削除時まで保持される結果となり、データをリアルタイムに変更する作業には適していないという問題点があった。
【０００８】
また、上記特許文献２に記載された方法においては、クライアントの動向を監視する際にネットワークの異常が発生した場合においては不当なロックがかかる恐れがあるという問題点があった。
【０００９】
この発明はかかる問題点を解決するためになされたものであり、ネットワークの異常あるいはクライアント側の異常が起こっても、サーバ側のデータベースに対する影響が出ることを防止することが可能な排他制御システムおよび排他制御プログラムを記憶した記憶媒体を得ることを目的としている。
【課題を解決するための手段】
【００１０】
この発明は、各レコードにデータを格納しているデータベースと、前記データベースの各レコードのデータを参照する参照側アプリケーションと、前記参照側アプリケーションからの更新命令を受けて、前記データベースのレコード内のデータの更新を行う更新側アプリケーションとを備えた排他制御システムであって、前記データベースの各前記レコードにあらかじめ排他制御用キーを格納させておき、前記参照側アプリケーションが前記データベースのレコードを参照した場合には、前記参照側アプリケーション内に前記データベースの対象レコードから参照した排他制御用キーを格納することを特徴とする排他制御システムである。
【発明の効果】
【００１１】
この発明は、各レコードにデータを格納しているデータベースと、前記データベースの各レコードのデータを参照する参照側アプリケーションと、前記参照側アプリケーションからの更新命令を受けて、前記データベースのレコード内のデータの更新を行う更新側アプリケーションとを備えた排他制御システムであって、前記データベースの各前記レコードにあらかじめ排他制御用キーを格納させておき、前記参照側アプリケーションが前記データベースのレコードを参照した場合には、前記参照側アプリケーション内に前記データベースの対象レコードから参照した排他制御用キーを格納することを特徴とする排他制御システムであるので、ネットワークの異常あるいはクライアント側の異常が起こっても、前記参照側アプリケーションに格納された排他制御用キーを用いて確認するようにすれば、サーバ側のデータベースに対する影響が出ることを防止することが可能となる。
【発明を実施するための最良の形態】
【００１２】
実施の形態１．
この発明の実施の形態１に係る排他制御システムについて図を参照して詳細に説明する。図１に示すように、本実施の形態１に係る排他制御システムにおいては、データベース１０を利用するコンピュータシステム内において、クライアント側には、データベース１０を更新目的で参照する参照側アプリケーション２００が設けられており、サーバ側には、各レコードにデータを格納しているデータベース１０と、参照側アプリケーション２００からの更新命令を受けて、データベース１０の各レコードのデータの更新処理を行う更新側アプリケーション１００とが設けられている。データベース１０の各レコードには、あらかじめ排他制御用キーが格納されている。参照側アプリケーション２００がデータベース１０のレコードを参照した場合には、参照側アプリケーション２００内にデータベース１０の対象レコードから参照した排他制御用キーが格納される構成となっている。
【００１３】
サーバ側の更新側アプリケーション１００内には、項目格納手段１０１と、キー比較手段１０２と、データ更新手段１０３と、キー変更手段１０４とが設けられている。項目格納手段１０１は、クライアント側の参照側アプリケーション２００からデータベース１０内のデータを更新するための更新命令を受けたときに、参照側アプリケーション２００から送信されてきた全項目を一時的に格納する。キー比較手段１０２は、実際に更新処理を行う前に、参照側アプリケーション２００から送信されてきた排他制御用キーと、データベース１０内の排他制御用キーとを比較して、等しいときに、更新可能の判断を下す。データ更新手段１０３は、キー比較手段１０２が更新可能と判断した場合に、項目格納手段１０１に一時的に格納したデータを用いて、データベース１０内のデータの更新処理を行う。キー変更手段１０４は、データ更新手段１０３によるデータ更新処理が行われた後に、データベース１０内に格納されている排他制御用キーを変更する。
【００１４】
クライアント側の参照側アプリケーション２００は、データベース１０内のデータを操作（検索・参照・更新用データ作成）するためのデータベース操作命令と、データベース１０内のデータを更新するための更新命令とを出力する。当該データベース操作命令には、検索操作命令、参照操作命令および更新用データ作成操作命令がある。また、当該更新命令には、データベース内の対象レコードのデータと変更後のデータ及び排他制御用キーを各々含む。
【００１５】
図２は、本実施の形態１に係る排他制御システムの処理の流れを示した流れ図である。まずはじめに、参照側アプリケーション２００が、データベース１０上の任意のレコードを更新目的で参照するためのデータベース操作命令を出力した場合、参照側アプリケーション２００は、データベース１０内のデータ（項目値）を読み取り、参照側アプリケーション２００内の各々の入力可能なボックスに格納する（ステップＳ１）。同時に、参照側アプリケーション２００は、更新側アプリケーション１００から送信されてくるデータベース１０内の対象レコードの排他制御用キーを、隠し項目として、参照側アプリケーション２００の画面情報として、参照側アプリケーション２００内に格納する（ステップＳ２，Ｓ３）。
【００１６】
参照側アプリケーション２００が、ステップＳ１においてデータベース１０から読み取ったデータの更新作業を行って、更新命令を出力した場合（ステップＳ４）、更新側アプリケーション１００は、参照側アプリケーション２００から送信されてきた全項目（更新用データ）と排他制御用キーとを、項目格納手段１０１をに一時的格納する（ステップＳ５）。
【００１７】
次に、更新側アプリケーション１００は、キー比較手段１０２を使用して、ステップＳ３で格納してステップＳ５で送信してきた参照側アプリケーション２００内の排他制御用キーとデータベース１０に格納されている当該レコードの排他制御用キーとを比較し、等しいならば、更新可能の判断をくだし、データ更新手段１０３に処理を引き継ぐ（ステップＳ６）。また、参照側アプリケーション２００から送信されてきた排他制御用キーとデータベース１０に格納されている当該レコードの排他制御用キーとが等しくないならば、更新不可の判断をくだし、対象レコードの再参照を促すメッセージを参照側アプリケーション２００に対して出力し（ステップＳ１０）、それにより、参照側アプリケーション２００の画面に更新不可の通知が表示されて（ステップＳ１１）、ステップＳ１に戻る。
【００１８】
更新側アプリケーション１００は、ステップＳ６の比較処理において参照側アプリケーション２００の排他制御用キーとデータベース１０に格納されている当該レコードの排他制御用キーが等しいと判断されて更新可能な場合は、データ更新手段１０３を用いてデータベース１０内のデータを更新する（ステップＳ７）。
【００１９】
次に、更新側アプリケーション１００は、前記データ更新手段１０３による更新処理が行われた後、キー変更手段１０４を使用して、データベース１０に格納されている当該レコードの排他制御用キーを変更する（ステップＳ８）。次に、更新側アプリケーション１００は、当該レコードのデータ更新処理の終了の通知を参照側アプリケーション２００に送信する（ステップＳ９）。
【００２０】
このように、本実施の形態は、クライアント側の参照側アプリケーション２００内にデータベース１０の対象レコードから参照した排他制御用キーを格納し、実更新の際に更新側アプリケーション２００から送信されてきたクライアント側の参照側アプリケーション２００内の排他制御用キーとデータベース１０内の対象レコードの排他制御用キーとを比較し、等しいときに更新可能の判断をくだし、等しくない場合は更新不可の判断をくだすことにより排他制御を実現するものである。これにより、更新側アプリケーション２００から送信されてくる排他制御用キーを保管していない参照側アプリケーション２００から不当に更新命令が送信されてきた場合には、更新不可の判断をくだして、更新処理を行わないようにすることができる。また、正当な更新命令を受けて、更新可能の場合は、実更新の際にデータベース１０の対象レコードの更新を行い、同時に排他制御用キーを変更する。このことにより、他の参照側アプリケーションが同時に更新目的で参照していた場合でもデータベース１０の実更新が先着順で処理され、後に更新しようとした参照側アプリケーション２００には更新不可の判断が通知される。なお、本実施の形態の排他制御システムでは、クライアント側の参照側アプリケーション２００内に排他制御用キーを格納するので、ネットワークの不具合や断線、クライアント側の異常終了、あるいは、データを参照しつづけて放置している状態等が起こっても、サーバ側のデータベース１０には影響がない。
【００２１】
以上のように、本実施の形態によれば、クライアント側に排他制御用キーを保持することにより、ネットワークの不具合や断線、クライアントの参照側アプリケーションの異常終了、あるいは、データを参照しつづけて放置している状態等が起こってもクライアント内の問題で済み、サーバ側のデータベース１０内に不当なロックがかかる等のデータベース１０に対する影響がない。また、クライアントとサーバの処理を完全に分断しているので、不具合発生時の問題点の早期発見にもつながる。
【００２２】
実施の形態２．
図３は、参照側アプリケーションが複数個展開している状態を示した図である。本実施の形態２においては、図３に示すように、クライアント側に複数の参照側アプリケーション２０１および２０２があり、サーバ側に、データベース１０と更新側アプリケーション１００とが設けられている。サーバ側の更新側アプリケーション１００内には、上述の図１と同様に、項目格納手段１０１と、キー比較手段１０２と、データ更新手段１０３と、キー変更手段１０４とを備えている。なお、各手段の動作は、図１で説明したものと同じであるので、ここではその説明を省略する。
【００２３】
図４を用いて、本実施の形態に係る排他制御システムの処理の流れについて説明する。参照側アプリケーション２０１と２０２がデータベース１０上の同じレコードをほぼ同時刻に更新目的で参照した場合、参照側アプリケーション２０１と２０２はデータベース１０内のデータ（項目値）を読み取り、各々の入力可能なボックスに格納する（ステップＳ１）。同時に、参照側アプリケーション２０１と２０２は、データベース１０内の当該レコードの同一排他制御用キーを隠し項目として参照側アプリケーション２０１と２０２の画面情報として各々格納する（ステップＳ２，Ｓ３）。
【００２４】
更新側アプリケーション１００は、たとえば、参照側アプリケーション２０１が先に更新作業を行って更新データ反映命令を出力した場合（ステップＳ４）、更新側アプリケーション１００は参照側アプリケーション２０１の全項目を、項目格納手段１０１に格納する（ステップＳ５）。
【００２５】
次に更新側アプリケーション１００は、キー比較手段１０２を使用して、参照側アプリケーション２０１内の排他制御用キーとデータベース１０に格納されている当該レコードの排他制御用キーとを比較し（ステップＳ６）、等しい排他制御キーであった場合に更新可能の判断をくだし、データ更新手段１０３を使用してデータを更新する（ステップＳ７）。
【００２６】
更新側アプリケーション１００は前記データ更新手段１０３によるデータ更新処理が行われた後、キー変更手段１０４を使用して、データベース１０に格納されている当該レコードの排他制御用キーを変更する（ステップＳ８）。次に、更新側アプリケーション１００は、当該レコードのデータ更新処理の終了の通知を参照側アプリケーション２０１に送信する（ステップＳ９）。
【００２７】
一方、参照側アプリケーション２０２が更新作業を終え、参照側アプリケーション２０１の更新後に、更新データ反映命令を出力した場合（ステップＳ４Ａ）、更新側アプリケーション１００は、参照側アプリケーション２０２の全項目を、項目格納手段１０１に格納する（ステップＳ５Ａ）。
【００２８】
次に更新側アプリケーション１００は、キー比較手段１０２を使用して参照側アプリケーション２０２内の排他制御用キーとデータベース１０に格納されている当該レコードの排他制御用キーとを比較する（ステップＳ６Ａ）。データベース１０内の排他制御キーは参照側アプリケーション２０１の更新作業後にすでに変更されている（ステップＳ８）ので、排他制御キーは等しくない。したがって、更新不可の判断をくだし、参照側アプリケーション２０２に更新不可の通知を送信する（ステップＳ１０Ａ，１１Ａ）。
【００２９】
このように、本実施の形態は、クライアント側の参照側アプリケーション２０１および２０２がデータベース１０の同一レコードを更新目的でほぼ同時刻に参照した場合に、クライアント側の参照側アプリケーション２０１および２０２内にデータベース１０の対象レコードから参照した排他制御用キーを格納する。次に、先に更新命令を送信してきた参照側アプリケーション２０１内の排他制御用キーとデータベース１０内の対象レコードの排他制御用キーとを比較し、等しいときに更新可能の判断をくだし、等しくない場合は更新不可の判断をくだす。これにより、更新可能の場合は実更新の際にデータベース１０の対象レコードの更新を行い、同時に排他制御用キーを変更する。このことにより、他方の参照側アプリケーション２０２が同時に更新目的で参照していた場合でもデータベース１０の実更新が先着順で処理され、後に更新しようとした参照側アプリケーション２０２には更新不可の判断が通知される。なお、本実施の形態の排他制御システムでは、クライアント側の参照側アプリケーション２０１および２０２内に排他制御用キーを格納するので、ネットワークの不具合や断線、クライアント側の異常終了、あるいは、データを参照しつづけて放置している状態等が起こっても、サーバ側のデータベース１０には影響がない。
【００３０】
以上のように、本実施の形態によれば、上述の実施の形態１と同様に、クライアント側に排他制御用キーを保持することにより、ネットワークの不具合や断線、クライアントの参照側アプリケーションの異常終了、あるいは、データを参照しつづけて放置している状態等が起こってもクライアント内の問題で済み、サーバ側のデータベース１０内に不当なロックがかかる等のデータベース１０に対する影響がない。また、クライアントとサーバの処理を完全に分断しているので、不具合発生時の問題点の早期発見にもつながる。
【００３１】
また、上述の実施の形態１および２としてあげた方法は、ＷＥＢ−ＤＢ型（ウェブ−データベース型）のシステムでも、クライアント−サーバ型のシステムでも利用することができる。
【図面の簡単な説明】
【００３２】
【図１】この発明の実施の形態１に係る排他制御システムの構成を示した構成図である。
【図２】この発明の実施の形態１に係る排他制御システムの処理の流れを示した流れ図である。
【図３】この発明の実施の形態２に係る排他制御システムの構成を示した構成図である。
【図４】この発明の実施の形態２に係る排他制御システムの処理の流れを示した流れ図である。
【符号の説明】
【００３３】
１０  データベース、１００  更新側アプリケーション、１０１  項目格納手段、１０２  キー比較手段、１０３  データ更新手段、１０４  キー変更手段、２００  参照側アプリケーション、２０１  参照側アプリケーション、２０２  参照側アプリケーション。
【図１】
2006113883.tif 000003
【図２】
2006113883.tif 000004
【図３】
2006113883.tif 000005
【図４】
2006113883.tif 000006