(57)【要約】【課題】応答待ち時間を大きく短縮し、かつその後でデータベースが正常な状態に戻った場合に参照更新要求を再開させることのできるデータベース管理装置を提供する。【解決手段】本発明に係るデータベース管理装置２０は、スレッドに対してセッションを発行するセッションプール手段２４と、セッションプール手段が正常であるか否かを記憶する変数であるプールステータスを記憶するプールステータス保持手段２４−１と、プールステータスが正常であればセッションプール手段から発行された第１のセッションによってデータベースに対して第１のアクセスを行い、第１のアクセスが異常を起こせばプールステータスを異常に変更してクライアントにエラーを通知する業務処理手段２２と、異常を起こした第１のアクセスを中断して第１のセッションを返却する廃棄処理手段２６とを有する。【選択図】図１
2009157662.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの要求に基づいて、データベースとの間でセッションを確立してデータの参照および更新のうち少なくとも一方を行うデータベース管理装置であって、
前記データベース管理装置で動作するスレッドに対して前記セッションを発行するセッションプール手段と、
前記セッションプール手段が正常であるか否かを記憶する変数であるプールステータスを記憶するプールステータス保持手段と、
前記クライアントからの要求に基づいて起動され、前記プールステータスが前記セッションプール手段が正常である状態を示していれば前記セッションプール手段から発行された第１のセッションによって前記データベースに対して第１のアクセスを行い、前記第１のアクセスが異常終了もしくはタイムアウトを起こせば前記プールステータスを前記セッションプール手段が正常でない状態を示す値に変更して前記クライアントにエラーを通知する業務処理手段と、
異常終了もしくはタイムアウトを起こした前記第１のアクセスを中断して前記第１のセッションを前記セッションプール手段に返却する廃棄処理手段と
を有することを特徴とするデータベース管理装置。
【請求項２】
前記業務処理手段が、前記プールステータスが前記セッションプール手段が正常でない状態を示していれば前記クライアントにエラーを通知することを特徴とする、請求項１に記載のデータベース管理装置。
【請求項３】
定期的に起動され、前記セッションプール手段から発行された第２のセッションによって前記データベースに対して第２のアクセスを行い、前記第２のアクセスが異常終了もしくはタイムアウトを起こせば前記プールステータスを前記セッションプール手段が正常でない状態を示す値に変更し、前記第２のアクセスが正常終了すれば前記プールステータスを前記セッションプール手段が正常である状態を示す値に変更する死活監視手段を有することを特徴とする、請求項２に記載のデータベース管理装置。
【請求項４】
タイムアウト時間をあらかじめ定義して保持するタイムアウト定義手段を有し、
前記業務処理手段は、連続して前記データベースからの応答がない時間が前記タイムアウト時間を超えれば前記タイムアウトが発生したと判断することを特徴とする、請求項１ないし請求項３のうちいずれか１項に記載のデータベース管理装置。
【請求項５】
クライアントからの要求に基づいて、データベースとの間であらかじめ確立されたセッションの発行をセッションプールから受けてデータの参照および更新のうち少なくとも一方を行うデータベース管理方法であって、
前記クライアントからの要求に基づいて業務処理スレッドを起動する業務処理スレッド起動工程と、
前記業務処理スレッドが前記セッションプールが正常であるか否かを記憶する変数であるプールステータスを参照するプールステータス参照工程と、
前記プールステータスが前記セッションプールが正常である状態を示していれば前記業務処理スレッドが前記セッションプールから第１のセッションの発行を受けて前記データベースに対して第１のアクセスを行う第１アクセス工程と、
前記第１アクセス工程で前記第１のアクセスが異常終了もしくはタイムアウトを起こせば前記業務処理スレッドが前記プールステータスを前記セッションプールが正常でない状態を示す値に変更して前記クライアントにエラーを通知して廃棄処理スレッドを起動するエラー処理工程と、
前記廃棄処理スレッドが異常終了もしくはタイムアウトを起こした前記第１のアクセスを中断して前記第１のセッションを前記セッションプールに返却する廃棄処理工程と
を有することを特徴とするデータベース管理方法。
【請求項６】
前記プールステータス参照工程で前記プールステータスが前記セッションプールが正常でない状態を示していれば、前記業務処理スレッドが前記クライアントにエラーを通知するエラー通知工程を有することを特徴とする、請求項５に記載のデータベース管理方法。
【請求項７】
定期的に死活監視スレッドを起動する死活監視スレッド起動工程と、
前記死活監視スレッドが前記セッションプールから第２のセッションの発行を受けて前記データベースに対して第２のアクセスを行う第２アクセス工程と、
前記第２アクセス工程で第２のアクセスが異常終了もしくはタイムアウトを起こせば前記死活監視スレッドが前記プールステータスを前記セッションプールが正常でない状態を示す値に変更し、前記第２のアクセスが正常終了すれば前記死活監視スレッドが前記プールステータスを前記セッションプールが正常である状態を示す値に変更するプールステータス変更工程とを有することを特徴とする、請求項６に記載のデータベース管理方法。
【請求項８】
クライアントからの要求に基づいて、データベースとの間であらかじめ確立されたセッションの発行をセッションプールから受けてデータの参照および更新のうち少なくとも一方を行うデータベース管理装置を構成するコンピュータに、
前記クライアントからの要求に基づいて業務処理スレッドを起動する業務処理スレッド起動処理と、
前記業務処理スレッドが前記セッションプールが正常であるか否かを記憶する変数であるプールステータスを参照するプールステータス参照処理と、
前記プールステータスが前記セッションプールが正常である状態を示していれば前記業務処理スレッドが前記セッションプールから第１のセッションの発行を受けて前記データベースに対して第１のアクセスを行う第１アクセス処理と、
前記第１アクセス処理で前記第１のアクセスが異常終了もしくはタイムアウトを起こせば前記業務処理スレッドが前記プールステータスを前記セッションプールが正常でない状態を示す値に変更して前記クライアントにエラーを通知して廃棄処理スレッドを起動するエラー処理と、
前記廃棄処理スレッドが異常終了もしくはタイムアウトを起こした前記第１のアクセスを中断して前記第１のセッションを前記セッションプールに返却する廃棄処理と
を実行させることを特徴とするデータベース管理プログラム。
【請求項９】
前記プールステータス参照処理で前記プールステータスが前記セッションプールが正常でない状態を示していれば、前記業務処理スレッドが前記クライアントにエラーを通知するエラー通知処理を実行させることを特徴とする、請求項８に記載のデータベース管理プログラム。
【請求項１０】
定期的に死活監視スレッドを起動する死活監視スレッド起動処理と、
前記死活監視スレッドが前記セッションプールから第２のセッションの発行を受けて前記データベースに対して第２のアクセスを行う第２アクセス処理と、
前記第２アクセス工程で第２のアクセスが異常終了もしくはタイムアウトを起こせば前記死活監視スレッドが前記プールステータスを前記セッションプールが正常でない状態を示す値に変更し、前記第２のアクセスが正常終了すれば前記死活監視スレッドが前記プールステータスを前記セッションプールが正常である状態を示す値に変更するプールステータス変更処理とを実行させることを特徴とする、請求項９に記載のデータベース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はクライアント−サーバ方式のデータベースの管理に関し、特に該データベースにおいてプロセスがタイムアウトしたときの処理に関する。
【背景技術】
【０００２】
図４は、従来技術に係るデータベースシステム３０１の構成を示すブロック図である。データベースシステム３０１は、ｎ台（ｎは任意の自然数）のクライアントコンピュータ３１０（以後クライアント３１０）と、業務ノード３２０と、ＤＢノード３３０とが、ネットワークを介して相互に接続されて構成される。業務ノード３２０およびＤＢノード３３０はそれぞれ、クライアント３１０とは物理的に別のコンピュータのＣＰＵ、ＲＡＭ、ＯＳなどによって構成される、ソフトウェアの実行単位である。
【０００３】
業務ノード３２０は業務処理プロセス３２１を含む。業務処理プロセス３２１はｍスレッド（ｍは任意の自然数、ｎとは同数であってもなくてもよい）の業務処理スレッド３２２、ＤＢセッションプール３２４を含む。ＤＢノード３３０はデータベース３３１を含む。個々の業務処理スレッド３２２は各々に利用者アプリケーション３２３を含む。利用者アプリケーション３２３は、クライアント３１０を利用する各々の利用者がそれぞれに行おうとする業務処理に応じて作成される。  
業務処理プロセス３２１は複数の業務処理スレッド３２２を持つ。データベースシステム３０１では、業務処理プロセス３２１の起動時に、あらかじめ所定の数のデータベース３１とのセッション（以後ＤＢセッションという）３２５を接続しておくセッションプール方式を採用する。ＤＢセッションプール３２４は、ｋセッション（ｋは任意の自然数、ｎおよびｍとは同数であってもなくてもよい）のＤＢセッション３２５を含む。
【０００４】
クライアント３１０が業務処理プロセス３２１へ処理要求を行うと、クライアントの処理要求は業務処理スレッド３２２に届き、業務処理スレッド３２２は利用者アプリケーション３２３で用意された業務処理を開始する。利用者アプリケーション３２３がＤＢセッションプール３２４にＤＢセッション３２５の払い出し要求を行うと、ＤＢセッション３２５が１セッション払いだされ、払い出されたＤＢセッション３２５によってデータベース３３１の参照／更新処理が行われる。
【０００５】
なお、サーバ−クライアントシステムにおいてタイムアウト処理に関連する技術として、以下の文献がある。特許文献１には、サーバからクライアントに通知するタイムアウト処理を、専用の子スレッドで行うという技術が開示されている。特許文献２には、サーバのタイムアウト情報を記憶し、その情報をクライアントのタイムアウト判断に利用するという技術が開示されている。
【０００６】
特許文献３には、タイムアウトしたデータを専用のスレッドで破棄するというデータ転送方式が開示されている。特許文献４には、通信相手の状態を所定の周期で監視するという技術が開示されている。特許文献５には、サーバ−クライアントシステムにおけるデータベースのセッションで、タイムアウトの検出および該タイムアウトをユーザに告知を通知する技術が開示されている。
【０００７】
【特許文献１】特開２０００−２６７８９４号公報
【特許文献２】特開２００５−３２７１３７号公報
【特許文献３】特開昭６２−０６７９４６号公報
【特許文献４】特開平０５−３３６１２４号公報
【特許文献５】特表２００７−５０３６２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
データベース３３１での障害の中には、ネットワーク通信的な障害のために応答が数十秒ないし数分かかるような障害が存在する。このような障害が発生すると、業務ノード３２０においてデータベース３３１に対して処理を依頼した業務処理スレッド３２２が、障害を検知するためには数十秒から数分の応答を待つ必要があるので、業務処理の結果をクライアント３１０に通知するのが大きく遅延することになる。さらに、別のクライアント３１０から依頼された別の業務処理スレッド３２２がその後に続く場合、その処理も大きく遅延することになる。
【０００９】
そのような問題点を解決するため、ＤＢセッションプール３２４の状態を記録する変数であるプールステータス３２４−１を備えるという技術がある。データベースへの参照更新要求が正常に完了しない場合、プールステータス３２４−１を異常ステータスとする。プールステータス３２４−１が異常ステータスである場合には、利用者アプリケーション３２３からＤＢセッションプール３２４にＤＢセッション３２５の払い出し要求が発生しても、ＤＢセッション３２５は払い出されない。
【００１０】
しかしながら、この方法は後続の利用者アプリケーション３２３の応答の遅延を回避することはできるが、現在実行中の利用者アプリケーション３２３及びＤＢセッション３２５の払い出しを止める前に実行された利用者アプリケーション３２３の遅延を防ぐことはできない。
【００１１】
またデータベース３３１への参照更新要求を非同期で実行し、一定時間以上応答が無かった場合にデータベース３３１への参照更新要求を中断させるという方法もある。しかしながら、ＤＢノード３３０自体が停止しているような障害の場合には、この方法を使用した場合でもその中断処理自体で応答の遅延が発生してしまうため、この問題点を解決できない。
【００１２】
これに特許文献１〜５を組み合わせたとすると、業務ノードにおいてタイムアウトを検出し、そのことをクライアントに通知することはできる。しかしながら、タイムアウトを起こした利用者アプリケーションとそのユーザ以外の、他の利用者アプリケーションとそれらのユーザに対して影響が及ぶことを避けることはできない。また、その後でデータベースが正常な状態に戻った場合に、中断していたデータベースへの参照更新要求を再開させる手段もない。
【００１３】
本発明の目的は、データベースの異常に起因するクライアントの応答待ち時間を大きく短縮し、かつその後でデータベースが正常な状態に戻った場合に参照更新要求を再開させることのできるデータベース管理装置、データベース管理方法、およびデータベース管理プログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するため、本発明に係るデータベース管理装置は、クライアントからの要求に基づいて、データベースとの間でセッションを確立してデータの参照および更新のうち少なくとも一方を行うデータベース管理装置であって、データベース管理装置で動作するスレッドに対してセッションを発行するセッションプール手段と、セッションプール手段が正常であるか否かを記憶する変数であるプールステータスを記憶するプールステータス保持手段と、クライアントからの要求に基づいて起動され、プールステータスがセッションプール手段が正常である状態を示していればセッションプール手段から発行された第１のセッションによってデータベースに対して第１のアクセスを行い、第１のアクセスが異常終了もしくはタイムアウトを起こせばプールステータスをセッションプール手段が正常でない状態を示す値に変更してクライアントにエラーを通知する業務処理手段と、異常終了もしくはタイムアウトを起こした第１のアクセスを中断して第１のセッションをセッションプール手段に返却する廃棄処理手段とを有することを特徴とする。
【００１５】
上記目的を達成するため、本発明に係るデータベース管理方法は、クライアントからの要求に基づいて、データベースとの間であらかじめ確立されたセッションの発行をセッションプールから受けてデータの参照および更新のうち少なくとも一方を行うデータベース管理方法であって、クライアントからの要求に基づいて業務処理スレッドを起動する業務処理スレッド起動工程と、業務処理スレッドがセッションプールが正常であるか否かを記憶する変数であるプールステータスを参照するプールステータス参照工程と、プールステータスがセッションプールが正常である状態を示していれば業務処理スレッドがセッションプールから第１のセッションの発行を受けてデータベースに対して第１のアクセスを行う第１アクセス工程と、第１アクセス工程で第１のアクセスが異常終了もしくはタイムアウトを起こせば業務処理スレッドがプールステータスをセッションプールが正常でない状態を示す値に変更してクライアントにエラーを通知して廃棄処理スレッドを起動するエラー処理工程と、廃棄処理スレッドが異常終了もしくはタイムアウトを起こした第１のアクセスを中断して第１のセッションをセッションプールに返却する廃棄処理工程とを有することを特徴とする。
【００１６】
上記目的を達成するため、本発明に係るデータベース管理プログラムは、クライアントからの要求に基づいて、データベースとの間であらかじめ確立されたセッションの発行をセッションプールから受けてデータの参照および更新のうち少なくとも一方を行うデータベース管理装置を構成するコンピュータに、クライアントからの要求に基づいて業務処理スレッドを起動する業務処理スレッド起動処理と、業務処理スレッドがセッションプールが正常であるか否かを記憶する変数であるプールステータスを参照するプールステータス参照処理と、プールステータスがセッションプールが正常である状態を示していれば業務処理スレッドがセッションプールから第１のセッションの発行を受けてデータベースに対して第１のアクセスを行う第１アクセス処理と、第１アクセス処理で第１のアクセスが異常終了もしくはタイムアウトを起こせば業務処理スレッドがプールステータスをセッションプールが正常でない状態を示す値に変更してクライアントにエラーを通知して廃棄処理スレッドを起動するエラー処理と、廃棄処理スレッドが異常終了もしくはタイムアウトを起こした第１のアクセスを中断して第１のセッションをセッションプールに返却する廃棄処理とを実行させることを特徴とする。
【発明の効果】
【００１７】
本発明は、アクセスが異常終了もしくはタイムアウトを起こせばプールステータスをセッションプールの異常を示す値にして、廃棄処理スレッドが該アクセスに対するその後の処理を引き継ぐように構成したので、クライアントにすぐにエラーを通知することができる。これによって、データベースの異常に起因するクライアントの応答待ち時間を大きく短縮し、かつその後でデータベースが正常な状態に戻った場合に参照更新要求を再開させることができるという、従来にない優れたデータベース管理装置、データベース管理方法、およびデータベース管理プログラムを提供することができる。
【発明を実施するための最良の形態】
【００１８】
図１は、本発明の実施の形態に係るデータベースシステム１の構成を示すブロック図である。データベースシステム１は、ｎ台（ｎは任意の自然数）のクライアントコンピュータ１０（以後クライアント１０）と、業務ノード２０と、ＤＢノード３０とが、ネットワークを介して相互に接続されて構成される。
【００１９】
なお、「クライアント１０」と記述した場合は、データベースシステム１に含まれるクライアントを総称していう。「クライアント１０−１」「クライアント１０−２」などと表記した場合はクライアント１０の中の特定の１台を指し、「クライアント１０−ｎ」と表記した場合はクライアント１０の中の任意の１台を指す。
【００２０】
業務ノード２０およびＤＢノード３０はそれぞれ、クライアント１０とは物理的に別のコンピュータのＣＰＵ、ＲＡＭ、ＯＳなどによって構成される、ソフトウェアの実行単位である。なお、業務ノード２０とＤＢノード３０とが物理的に同一のコンピュータであっても、別々のコンピュータであってもよい。
【００２１】
業務ノード２０は業務処理プロセス２１を含む。業務処理プロセス２１はｍスレッド（ｍは任意の自然数、ｎとは同数であってもなくてもよい）の業務処理スレッド２２、死活監視スレッド２８、ＤＢセッションプール２４、破棄処理スレッド２６、タイムアウト定義２７を含む。ＤＢノード３０はデータベース３１を含む。
【００２２】
なお、「業務処理スレッド２２」と記述した場合は、業務処理プロセス２１に含まれる業務処理スレッドを総称していう。「業務処理スレッド２２−１」「業務処理スレッド２２−２」などと表記した場合は業務処理プロセス２１の中の特定の１スレッドを指し、「業務処理スレッド２２−ｍ」と表記した場合は業務処理プロセス２１の中の任意の１スレッドを指す。
【００２３】
個々の業務処理スレッド２２は各々に利用者アプリケーション２３を含む。業務処理スレッド２２−１には利用者アプリケーション２３−１が含まれ、以後同様に業務処理スレッド２２−ｍには利用者アプリケーション２３−ｍが含まれる。利用者アプリケーション２３は、クライアント１０を利用する各々の利用者がそれぞれに行おうとする業務処理に応じて作成される。  
業務処理プロセス２１は複数の業務処理スレッド２２を持つので、１つの業務スレッド２２−ｍ内の利用者アプリケーション２３−ｍがデータベース３１へ参照もしくは更新を行う場合には、データベース３１とのセッション（以後ＤＢセッションという）が１つ必要となる。複数の業務処理スレッド２２から同時にデータベース３１の参照もしくは更新を行う要求が発生した場合には、同時に処理を行う業務処理スレッド２２と同数のＤＢセッション２５が必要となる。
【００２４】
データベースシステム１では、必要となる数のＤＢセッション２５を用意する方法として、業務処理プロセス２１の起動時にあらかじめ所定の数のＤＢセッション２５を接続しておくセッションプール方式を採用する。ＤＢセッションプール２４は、該セッションプールが正常であるか否かを示すプールステータス２４−１と、ｋセッション（ｋは任意の自然数、ｎおよびｍとは同数であってもなくてもよい）のＤＢセッション２５を含む。
【００２５】
プールステータス２４−１はブーリアン変数であり、値がＴＲＵＥであればＤＢセッションプール２４が正常ステータスであることを示し、値がＦＡＬＳＥであればＤＢセッションプール２４が異常ステータスであることを示す。
【００２６】
なお、「ＤＢセッション２５」と記述した場合は、ＤＢセッションプール２４に含まれるＤＢセッションを総称していう。「ＤＢセッション２５−１」「ＤＢセッション２５−２」などと表記した場合はＤＢセッションプール２４の中の特定の１セッションを指し、「ＤＢセッション２５−ｋ」と表記した場合はＤＢセッションプール２４の中の任意の１セッションを指す。
【００２７】
クライアント１０−ｎが業務処理プロセス２１へ処理要求を行うと、クライアントの処理要求は業務処理スレッド２２−ｍに届き、業務処理スレッド２２−ｍは利用者アプリケーション２３−ｍで用意された業務処理を開始する。利用者アプリケーション２３−ｍがＤＢセッションプール２４にＤＢセッション２５−ｋの払い出しを要求を行うと、ＤＢセッション２５−ｋが払いだされ、払い出されたＤＢセッション２５−ｋによってデータベース３１の参照／更新処理が行われる。データベース３１の参照／更新処理は非同期で実行される。
【００２８】
タイムアウト定義２７は、これ以上の時間にわたって連続してデータベース３１からの応答がなければタイムアウトと見なす基準となるタイムアウト時間をあらかじめ定義して保持する。  ここでタイムアウト定義２７で定義されたタイムアウト時間以上の時間にわたってデータベース３１から応答がなかった場合、ＤＢセッション２５−ｋはプールステータス２４−１を異常ステータスに変更し、使用していたＤＢセッションを廃棄処理スレッド２６へ渡して、処理要求を行っていたクライアント１０−ｎに要求のあった処理が失敗したことを通知する。
【００２９】
廃棄処理スレッド２６は渡されたＤＢセッション２５−ｋで行っていたデータベース３１への参照／更新処理の中断処理を実行する。
【００３０】
死活監視スレッド２８は定期的にＤＢセッションプール２４にＤＢセッション２５−ｋの払い出し要求を行い、払いだされたＤＢセッションに基づいてデータベース３１を参照する。参照処理は非同期で実行される。タイムアウト時間以上の時間にわたって応答がなかった場合、死活監視スレッド２８はプールステータス２４−１を異常ステータスに変更する。タイムアウト時間以内に応答があった場合、死活監視スレッド２８はプールステータス２４−１を正常ステータスに変更する。
【００３１】
図２は、図１で開示した利用者アプリケーション２３−ｍおよび廃棄処理スレッド２６の処理を表すフローチャートである。クライアント１０−ｎは業務処理プロセス２１へ処理要求を行うと（ステップＳ１０１）、業務処理プロセス２１は業務処理スレッド２２−ｍを実行開始する。業務処理スレッド２２−ｍは、あらかじめプログラムされた利用者アプリケーション２３−ｍに従って業務処理を行う。
【００３２】
利用者アプリケーション２３−ｍは、データベース３１の参照／更新を行うために必要なＤＢセッション２５をＤＢセッションプール２４へ要求し（ステップＳ１０２）、プールステータス２４−１が正常ステータスであるか否かを判断する（ステップＳ１０３）。
【００３３】
プールステータス２４−１が正常ステータスであれば、利用者アプリケーション２３−ｍはＤＢセッション２５の中で空いているＤＢセッション２５−ｋの払い出しを受けてステップＳ１０５に進む。プールステータス２４−１が異常ステータスであった場合は、ＤＢセッションの払い出しを受けることができないため、業務処理スレッドは処理要求を行ったクライアント１０−ｎに要求のあった業務処理は失敗したことを通知する（ステップＳ１０４）。
【００３４】
ＤＢセッションの払い出しを受けた利用者アプリケーションはデータベース３１に対して業務処理で必要なデータの参照／更新要求を行い（ステップＳ１０５）、該データの参照／更新要求の結果を確認する（ステップＳ１０６）。これらの処理は非同期で実行される。
【００３５】
ステップＳ１０５で、タイムアウト時間以内に要求したデータの更新が正常に完了していることが確認されたら、利用者アプリケーション２３−ｍはＤＢセッション２５−ｋをＤＢセッションプール２４に返却し（ステップＳ１０７）、業務処理スレッド２２−ｍは処理要求を行ったクライアント１０−ｎに対して、正常に業務が終了したことを通知する（ステップＳ１０８）。
【００３６】
タイムアウト時間以上の時間にわたってデータベース３１からステップＳ１０６に対する応答がない、もしくはデータベース３１の処理が異常終了した場合、業務処理スレッド２２−ｍはプールステータス２４−１を異常ステータスに変更し（ステップＳ１０９）、払い出されていたＤＢセッション２５−ｋを廃棄処理スレッド２６に渡し（ステップＳ１１０）、業務処理スレッドは処理要求を行ったクライアント１０−ｎに要求のあった業務処理が失敗したことを通知する（ステップＳ１１１）。
【００３７】
廃棄処理スレッド２６は業務スレッドから渡されたＤＢセッション２５−ｋからデータベース３１に対して要求されていた処理の中断を指示し（ステップＳ１２１）、ＤＢセッション２５−ｋをＤＢセッションプール２４に返却する（ステップＳ１２２）。
【００３８】
図３は、図１で開示した死活監視スレッド２８の処理を表すフローチャートである。死活監視スレッド２８は定期的に起動される。起動されるとまず、死活監視スレッド２８はＤＢセッションプール２４にＤＢセッション２５−ｋの払い出し要求を行い（ステップＳ２０１）、プールステータス２４−１が正常ステータスであるか否かを判断する（ステップＳ２０２）。プールステータス２４−１が正常ステータスであれば、ＤＢセッション２５の中で空いているＤＢセッション２５−ｋの払い出しを受けてステップＳ２０３に進む。
【００３９】
ステップＳ２０２で、プールステータス２４−１が異常ステータスであれば、業務処理プロセス２１とデータベース３１の接続処理を行い（ステップＳ２０７）、接続処理に成功した場合はプールステータスを正常ステータスに変更して終了する（ステップＳ２０８）。接続処理に失敗した場合はそのまま終了する。
【００４０】
ＤＢセッション２５−ｋの払い出しを受けた死活監視スレッドは、データベース３１への参照処理を非同期で実行し（ステップＳ２０３）、該データの参照要求の結果を確認する（ステップＳ２０４）。タイムアウト時間以内に要求したデータの参照が正常に完了していることが確認されたら、死活監視スレッド２８はＤＢセッション２５−ｋをＤＢセッションプール２４に返却して（ステップＳ２０５）終了する。
【００４１】
タイムアウト時間以上の時間にわたってデータベース３１からステップＳ２０３に対する応答がない、もしくはデータベース３１の処理が異常終了した場合、死活監視スレッド２８はプールステータス２４−１を異常ステータスに変更して（ステップＳ２０６）終了する。
【００４２】
このようにして、定期的に起動される死活監視スレッド２８は、プールステータス２４−１が異常ステータスだった場合はデータベース３１との接続を回復させる処理を試行し、接続の回復に成功した場合はプールステータスを正常ステータスに変更し、業務処理スレッド２２へのＤＢセッション２５の払い出しを再開させる。
【００４３】
以上で説明した様に、本実施の形態では、データベース３１とのアクセスで一定時間以上応答がない場合に異常と判定し、異常と判定した直後にＤＢセッション２５−ｋの払い出しの停止を行い、処理に応答待ちの時間がかかる中断処理を業務処理スレッド２２とは別の廃棄処理スレッド２６で行っている。
【００４４】
それによって、廃棄処理スレッド２６はデータベース３１への参照更新要求の中断処理によって応答待ちの遅延が発生するが、業務処理スレッド２２−ｍで実行していた利用者アプリケーション２３−ｍは、定義されたタイムアウト時間以上の遅延が発生することなく、クライアントに応答を返すことができる。
【００４５】
また別の業務処理スレッド２２−ｍによる後続の処理は、ＤＢセッション２５−ｋを取得要求する前であれば、プールステータス２４−１が異常ステータスであるため、ＤＢセッション２５−ｋを取得できず、即時にクライアント１０−ｎにエラーの応答を返すことができる。
【００４６】
この時点で業務処理スレッド２２−ｍがＤＢセッション２５−ｋを取得した後である場合は、データベース３１に対して参照更新要求を実行してしまうが、その場合もデータベース３１からタイムアウト時間以上の応答が無かった場合は該ＤＢセッション２５−ｋを廃棄処理スレッド２６に渡すので、業務処理スレッド２２−ｍで実行していた利用者アプリケーション２３−ｍは応答を待つことなく処理を終了することができる。従って、業務処理スレッド２２で実行しているその他の利用者アプリケーション２３が応答待ちで遅延することはなくなる。
【００４７】
また、死活監視スレッド２８によって、データベース３１の状態を常に監視して、異常ステータスだったデータベース３１が正常な状態に戻ったら接続を回復させて業務処理スレッド２２へのＤＢセッション２５の払い出しを再開させることができる。
【００４８】
このことにより、データベース３１の異常によるクライアント１０の応答待ち時間を大きく短縮することが可能となる。
【００４９】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることは言うまでもないことである。
【産業上の利用可能性】
【００５０】
クライアント−サーバ方式でデータベースを扱うシステムにおいて幅広く適用できる。
【図面の簡単な説明】
【００５１】
【図１】本発明の実施の形態に係るデータベースシステムの構成を示すブロック図である。
【図２】図１で開示した利用者アプリケーションおよび廃棄処理スレッドの処理を表すフローチャートである。
【図３】図１で開示した死活監視スレッドの処理を表すフローチャートである。
【図４】従来技術に係るデータベースシステムの構成を示すブロック図である。
【符号の説明】
【００５２】
１  データベースシステム
１０、１０−１、１０−２、１０−ｎ  クライアント
２０  業務ノード
２１  業務処理プロセス
２２、２２−１、２２−２、２２−ｍ  業務処理スレッド
２３、２３−１、２３−２、２３−ｍ  利用者アプリケーション
２４  ＤＢセッションプール
２４−１  プールステータス
２５、２５−１、２５−２、２５−ｋ  ＤＢセッション
２６  破棄処理スレッド
２７  タイムアウト定義
２８  死活監視スレッド
３０  ＤＢノード
３１  データベース
【図１】
2009157662.tif 000003
【図２】
2009157662.tif 000004
【図３】
2009157662.tif 000005
【図４】
2009157662.tif 000006