(57)【要約】【課題】プールしてあるコネクションを利用する場合において、接続確認のための処理負荷を削減する。【解決手段】本データベースアクセス制御方法は、クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなくコネクションを取得する取得ステップと、取得ステップにおいて取得されたコネクションを利用して、業務処理要求に応じた第１のＳＱＬ文をデータベースに対して発行するステップと、第１のＳＱＬ文に対する処理が正常に完了しなかった場合、取得ステップにおいて取得されたコネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップとを含む。【選択図】図３
2011181039.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなく前記コネクションを取得する取得ステップと、
前記取得ステップにおいて取得された前記コネクションを利用して、前記業務処理要求に応じた第１のＳＱＬ文を前記データベースに対して発行するステップと、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記取得ステップにおいて取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップと、
をコンピュータに実行させるためのプログラム。
【請求項２】
前記第２のＳＱＬ文に対する処理が正常に完了した場合、前記第１のＳＱＬ文に対する処理が正常に完了しなかったことを表すエラー情報を出力するステップ
をさらに実行させるための請求項１記載のプログラム。
【請求項３】
前記第２のＳＱＬ文に対する処理が正常に完了しなかった場合、コネクション確立機構に、前記データベースへの新たなコネクションを確立させるステップと、
前記新たなコネクションの確立に成功した場合、当該新たなコネクションを利用して前記第１のＳＱＬ文を前記データベースに対して再発行するステップと、
をさらに実行させるための請求項１又は２記載のプログラム。
【請求項４】
前記新たなコネクションを確立できなかった場合、前記取得ステップにおいて取得された前記コネクションに接続不可を表すデータを対応付け、当該コネクションを前記コネクションプールに返却するステップ
をさらに実行させるための請求項３記載のプログラム。
【請求項５】
クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなく前記コネクションを取得する取得ステップと、
前記取得ステップにおいて取得された前記コネクションを利用して、前記業務処理要求に応じた第１のＳＱＬ文を前記データベースに対して発行するステップと、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記取得ステップにおいて取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップと、
を含み、コンピュータにより実行されるデータベースアクセス制御方法。
【請求項６】
データベースへのコネクションをプールするためのコネクションプールと、
クライアント端末からの業務処理要求を受信した場合、前記コネクションプールから、接続状態を確認することなく前記コネクションを取得するコネクション取得部と、
前記コネクション取得部により取得された前記コネクションを利用して前記データベースに対してＳＱＬ文を発行するアクセス部と、
前記アクセス部に前記業務処理要求に応じた第１のＳＱＬ文を前記データベースへ発行させる業務処理部と、
を有し、
前記アクセス部は、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記コネクション取得部により取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行する
情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、データベースへのアクセスを制御する技術に関する。
【背景技術】
【０００２】
データベース（ＤＢ）にアクセスする際には、データベースとのコネクション（ＤＢコネクションとも呼ばれる）を確立する必要がある。しかし、アクセスを行う度に、コネクションを確立するとなると、データベースアクセスの負荷が大きくなってしまう。
【０００３】
このようなデータベースアクセスの負荷を削減するための技術として、例えばコネクションプーリングなどの技術が知られている。コネクションプーリングでは、予め一定数のコネクションを確立しておき、そのコネクションを使い回すようになっている。より具体的には、例えばミドルウェア等においてコネクションをプールしておき、必要に応じてコネクションを業務アプリケーションに貸し出し、データベースへのアクセスが終了すると、そのコネクションをミドルウェアに返却するようになっている。これにより、毎回コネクションを確立・切断する必要がなくなるので、データベースアクセスの負荷を削減できる。
【０００４】
なお、何らかの要因（例えば障害発生によるデータベースダウンなど）により、コネクションが切断されてしまう場合がある。切断されているコネクションを業務アプリケーションに貸し出すとなると、業務アプリケーション側で、業務とは無関係のエラーについてまで対処しなければならなくなるため、切断されているコネクションを貸し出すのは好ましくない。そのため、従来のコネクションプーリングでは、コネクションを貸し出す際には、接続確認を行ってからコネクションを貸し出すようになっている。より具体的には、例えば図１に示すように、ＤＢアクセス装置（例えばミドルウェアを実行）において、コネクション貸出依頼を受け取ると、コネクションプール部からコネクションを取得し、そのコネクションを用いて例えば単純なＳＱＬ（Structured Query Language）文をデータベースへ発行するなどして、接続確認を行うようになっている。そして、接続確認の結果が正常を示している場合には、コネクションプール部から取得したコネクションを貸し出し、接続確認の結果が異常を示している場合には、コネクションを確立し直して、確立したコネクションを貸し出すようになっている。なお、図１において、文字「Ｃ」が付された楕円は、コネクション・データを表している。
【０００５】
しかしながら、上で述べた手法では、コネクションを貸し出す度に、接続確認用のＳＱＬ文を発行する必要があり、接続確認のための処理負荷がかかってしまう。特に、大規模且つミリ秒レベルの性能が求められるミッションクリティカルなシステムにおいては、たとえ接続確認用のＳＱＬ文が単純なＳＱＬ文であったとしても、コネクションを貸し出す度に発行されるとなると、システムの性能に影響を及ぼすことになる。
【０００６】
例えばプロセスを分散させてミッションクリティカルなシステムを構築した場合の一例を図２に示す。図２の例では、受付プロセスと業務処理プロセスと出力プロセスとに分かれている。例えば各プロセスにおいてデータベースへアクセスする必要があったとすると、クライアントからの依頼を受けた後、クライアントへ応答を返すまでの間に、接続確認用のＳＱＬ文が３回発行されることになる。これは、システムの性能に大きな影響を及ぼすことになる。なお、図２において、実線矢印は、処理の流れを示しており、点線矢印は、接続確認用のＳＱＬ文の発行を示している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−２８７７００号公報
【特許文献２】特開平１０−４０１４２号公報
【特許文献３】特開平９−１３５２４３号公報
【特許文献４】特開２００８−２３４３７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従って、本技術の目的は、プールしてあるコネクションを利用する場合において、接続確認のための処理負荷を削減するための技術を提供することである。
【課題を解決するための手段】
【０００９】
本データベースアクセス制御方法は、クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなくコネクションを取得する取得ステップと、取得ステップにおいて取得されたコネクションを利用して、業務処理要求に応じた第１のＳＱＬ文をデータベースに対して発行するステップと、第１のＳＱＬ文に対する処理が正常に完了しなかった場合、取得ステップにおいて取得されたコネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップとを含む。
【発明の効果】
【００１０】
プールしてあるコネクションを利用する場合において、接続確認のための処理負荷を削減できる。
【図面の簡単な説明】
【００１１】
【図１】図１は、従来のコネクションプーリングの問題点を説明するための図である。
【図２】図２は、プロセスを分散させてミッションクリティカルなシステムを構築した場合の一例を示す図である。
【図３】図３は、本技術の実施の形態におけるシステムの構成図である。
【図４】図４は、コネクション管理オブジェクトのデータ構造の一例を示す図である。
【図５】図５は、第１の実施の形態における状態フラグの状態遷移を表す図である。
【図６】図６は、サーバ５の動作の概要を説明するための図である。
【図７】図７は、コネクション管理オブジェクトの貸出・返却の流れを説明するための図である。
【図８】図８は、第１の実施の形態におけるコネクション貸出時の処理フローを示す図である。
【図９】図９は、第１の実施の形態におけるデータベースアクセス時の処理フロー（第１の部分）を示す図である。
【図１０】図１０は、第１の実施の形態におけるデータベースアクセス時の処理フロー（第２の部分）を示す図である。
【図１１】図１１は、第２の実施の形態における状態フラグの状態遷移を表す図である。
【図１２】図１２は、第２の実施の形態におけるコネクション貸出時の処理フローを示す図である。
【図１３】図１３は、第２の実施の形態におけるデータベースアクセス時の処理フローを示す図である。
【図１４】図１４は、コンピュータの機能ブロック図である。
【図１５】図１５は、第１の態様に係るデータベースアクセス制御方法の処理フローを示す図である。
【図１６】図１６は、第２の態様に係る情報処理装置の機能ブロック図である。
【発明を実施するための形態】
【００１２】
［実施の形態１］
図３に、本技術の実施の形態に係るシステムの構成図を示す。例えばインターネットやＬＡＮ（Local Area Network）であるネットワーク１には、クライアント３と、本実施の形態における主要な処理を実施するサーバ５とが接続されている。サーバ５は、データベース７とのＤＢコネクション（以下、コネクションと呼ぶ）を確立するなどの処理を実施するミドルウェア５１を有し、所定のタイミング（例えばサーバ５の起動後）でプロセスを起動する。なお、起動されたプロセスには、ミドルウェア５１によって確立されたコネクションに関するデータ（例えばコネクションの識別情報等）を含むコネクション管理オブジェクトをプールしておくためのコネクションプール部５３が含まれる。また、クライアント３から業務処理の要求があった場合には、要求を受信したプロセスが、業務処理を実施するスレッド（図３ではスレッドＡ乃至Ｃ）を起動する。なお、スレッドＡ乃至Ｃは、メッセージを交換することにより連携して処理を実施し、必要に応じてデータベース７にアクセスし、要求に対する応答をクライアント３に返す。なお、要求を受信したプロセスがスレッドＡ乃至Ｃと同じ処理を実行する子プロセスＡ乃至Ｃをコールするような場合もある。この場合には、子プロセスＡ乃至Ｃは、メッセージを交換することにより連携して処理を実施し、必要に応じてデータベース７にアクセスし、要求に対する応答をクライアント３に返す。図３では、サーバは１つしか示していないが、サーバの数はこれに限定されない。また、図３では、プロセスは１つしか示していないが、サーバにおいて起動されるプロセスの数もこれに限定されない。さらに、図３では、３つのスレッドを示しているが、１プロセス内で起動されるスレッド数もこれに限定されない。
【００１３】
スレッドＡは、業務処理Ａを実施するために実行されているスレッドであり、制御部５５１と、業務処理部５５３と、ＤＢアクセス処理部５５５とを含む。ＤＢアクセス処理部５５５は、アクセス部５５５１と、コネクション管理部５５５３とを含む。同様に、スレッドＢは、業務処理Ｂを実施するために実行されているスレッドであり、図３では図示していないが、制御部５５１と、業務処理部５５３と、ＤＢアクセス処理部５５５とを含む。さらに、スレッドＣは、業務処理Ｃを実施するために実行されているスレッドであり、図３では図示していないが、制御部５５１と、業務処理部５５３と、ＤＢアクセス処理部５５５とを含む。
【００１４】
なお、制御部５５１は、コネクション貸出依頼・返却依頼をＤＢアクセス処理部５５５に出力したり、業務処理部５５３を呼び出したりする。業務処理部５５３は、業務処理を実施し、データベース７に対する参照及び更新が必要な場合には、業務処理に応じた業務ＳＱＬ文を発行するようＤＢアクセス処理部５５５のアクセス部５５５１に指示する。ＤＢアクセス処理部５５５のコネクション管理部５５５３は、制御部５５１からの依頼に応じて、コネクション管理オブジェクトをコネクションプール部５３に要求し、コネクションプール部５３からコネクション管理オブジェクトを取得したり、コネクション管理オブジェクトをコネクションプール部５３に返却したりする。ＤＢアクセス処理部５５５のアクセス部５５５１は、業務処理部５５３からの指示に応じて、コネクション管理部５５５３が取得したコネクション管理オブジェクト内で指定されているコネクションを利用してデータベース７に対して業務ＳＱＬ文を発行する。また、アクセス部５５５１は、新たなコネクションの確立が必要な場合には、新たなコネクションを確立するようミドルウェア５１に要求する。コネクションプール部５３は、コネクション貸出・返却機能を有し、コネクション管理部５５５３からの要求に応じて、プールしてあるコネクション管理オブジェクトを、コネクション管理部５５５３に貸し出す。なお、コネクション管理オブジェクトは、貸し出す際に、コネクションプール部５３から取り出され、返却されると、再びコネクションプール部５３においてプールされる。なお、コネクションプール部５３内にコネクション管理オブジェクトがない場合には、ミドルウェア５１に新たなコネクションを確立させ、新たなコネクションに関するデータを含むコネクション管理オブジェクトを生成してからコネクション管理部５５５３に貸し出す。ミドルウェア５１は、コネクション接続機能を有し、ＤＢアクセス処理部５５５又はコネクションプール部５３からの要求に応じて、データベース７への新たなコネクションを確立し、確立した新たなコネクションに関するデータを要求元に出力する。
【００１５】
図４に、コネクションプール部５３に格納されるコネクション管理オブジェクトのデータ構造を示す。図４に示すように、コネクション管理オブジェクトには、コネクションに関するデータ（例えばコネクションの識別情報等）と、そのコネクション上で業務ＳＱＬが既に実行されているか否かを表す状態フラグ（未使用／ＳＱＬ実行済）とが含まれる。本実施の形態では、図５に示すように、コネクション貸出時に、状態フラグは「未使用」に初期化される。そして、コネクション上で最初に発行された業務ＳＱＬ文の処理が終了したときに、状態フラグは「ＳＱＬ実行済」に更新される。
【００１６】
次に、図３に示したサーバ５の動作の概要を図６及び図７を用いて説明する。例えばサーバ５は、クライアント３からの電文を受信すると（図６：ステップ（１））、電文に応じた業務処理を実施するスレッドを起動する。そして、起動されたスレッドにおける制御部５５１は、スレッドの初期処理として、コネクション貸出依頼をＤＢアクセス処理部５５５のコネクション管理部５５５３に出力する（ステップ（２））。コネクション管理部５５５３は、制御部５５１からのコネクション貸出依頼に応じて、コネクション管理オブジェクトをコネクションプール部５３に要求して、コネクションプール部５３からコネクション管理オブジェクトを取得する（ステップ（３））。なお、この時点では、コネクション管理オブジェクト内のコネクションの接続確認は行わない。
【００１７】
例えば図７に示すように、コネクション貸出・返却機能５３１を有するコネクションプール部５３は、ＤＢアクセス処理部５５５のコネクション管理部５５５３からの要求に応じて、プールしてあるコネクション管理オブジェクトのうちの１つをコネクション管理部５５５３に貸し出す。なお、コネクションプール部５３内にコネクション管理オブジェクトがない場合には、コネクションプール部５３が、コネクション接続機能５１１を有するミドルウェア５１に新たなコネクションを確立させ、確立されたコネクションに関するデータを含むコネクション管理オブジェクトを生成してからコネクション管理部５５５３に貸し出す。そして、コネクション管理部５５５３は、コネクション管理オブジェクトを、業務処理を実施するスレッドに割り当てる。例えばそのスレッドが使用する領域にコネクション管理オブジェクトを設定する。また、この際、コネクション管理オブジェクト内の状態フラグを「未使用」に初期化する。なお、図７において、コネクション管理オブジェクト内の右側の楕円（すなわち、「Ｃ」が付された楕円）は、コネクションに関するデータを表している。
【００１８】
図６の説明に戻って、その後、制御部５５１は、業務処理部５５３を呼び出し（ステップ（４））、呼び出された業務処理部５５３は、業務処理を実施する。ここでは、業務処理として、ＤＢアクセス処理ＡとＤＢアクセス処理ＢとＤＢアクセス処理Ｃとが含まれるものとする。業務処理部５５３は、これらの処理に関する業務ＳＱＬ文の実行依頼をアクセス部５５５１に出力する。そして、アクセス部５５５１は、業務処理部５５３からの実行依頼に応じて、コネクション管理部５５５３がスレッドに割り当てたコネクション管理オブジェクト内で指定されているコネクションを利用して業務ＳＱＬ文をデータベース７に対して発行する（ステップ（５））。なお、処理の順番が、ＤＢアクセス処理Ａ、ＤＢアクセス処理Ｂ、ＤＢアクセス処理Ｃの順であった場合、アクセス部５５５１は、ＤＢアクセス処理Ａが終了した時点で、コネクション管理オブジェクト内の状態フラグを「ＳＱＬ実行済」に更新する。また、詳細は後で説明するが、業務ＳＱＬ文に対する処理が正常に完了しなかったときに初めて接続確認用のＳＱＬ文を発行する。すなわち、正常に動作している間は、接続確認用のＳＱＬ文が発行されることなく、業務処理が実施される。
【００１９】
そして、業務処理部５５３による業務処理が終了すると、制御部５５１は、スレッドの終了処理として、コネクション返却依頼をＤＢアクセス処理部５５５のコネクション管理部５５５３に出力する（ステップ（６））。コネクション管理部５５５３は、制御部５５１からのコネクション返却依頼に応じて、図７に示すように、コネクション管理オブジェクトをコネクションプール部５３に返却する（ステップ（７））。その後、制御部５５１は、電文の応答を送信元に返す（ステップ（８））。
【００２０】
このような処理を実施することにより、プールしてあるコネクションを利用する場合であっても、正常動作中は、接続確認用のＳＱＬ文が発行されることはない。従って、接続確認のための処理負荷が削減される。
【００２１】
次に、図８乃至図１０を用いて、サーバ５のより詳細な処理について説明する。まず、図８を用いて、図６に示したステップ（３）の処理の詳細について説明する。例えばＤＢアクセス処理部５５５のコネクション管理部５５５３は、制御部５５１からのコネクション貸出依頼を受信すると、コネクション管理オブジェクトをコネクションプール部５３に要求する。コネクションプール部５３内にコネクション管理オブジェクトがある場合（ステップＳ１：Ｙｅｓルート）、コネクション管理部５５５３は、コネクションプール部５３から既存のコネクション管理オブジェクトを取得する（ステップＳ３）。すなわち、コネクションプール部５３からコネクション管理オブジェクトが貸し出される。なお、コネクションプール部５３内に複数のコネクション管理オブジェクトがある場合には、いずれのコネクション管理オブジェクトを利用するかは、例えばラウンドロビンなどの手法により決定する。その後、処理はステップＳ１３に移行する。
【００２２】
一方、コネクションプール部５３にコネクション管理オブジェクトがない場合（ステップＳ１：Ｎｏルート）、コネクションプール部５３は、新たなコネクションを確立するようミドルウェア５１に要求する。そして、ミドルウェア５１は、コネクションプール部５３からの要求に応じて、コネクションを確立するための処理を実施し、処理結果をコネクションプール部５３に出力する（ステップＳ５）。なお、コネクションの確立に成功した場合には、確立したコネクションに関するデータを合わせて出力する。新たなコネクションの確立に成功した場合（ステップＳ７：Ｙｅｓルート）、コネクションプール部５３は、コネクション管理オブジェクトを生成し、ミドルウェア５１が確立したコネクションに関するデータをそのコネクション管理オブジェクトに設定する（ステップＳ９）。そして、コネクションプール部５３は、新たに生成したコネクション管理オブジェクトをコネクション管理部５５５３に貸し出す。その後、処理はステップＳ１３に移行する。
【００２３】
一方、新たなコネクションを確立できなかった場合（ステップＳ７：Ｎｏルート）、コネクションプール部５３は、貸し出し可能なコネクション管理オブジェクトがない旨をコネクション管理部５５５３に通知する。そして、コネクション管理部５５５３は、コネクションプール部５３から、貸し出し可能なコネクション管理オブジェクトがない旨の通知を受信すると、制御部５５１にコネクション取得エラーを出力する（ステップＳ１１）。その後、処理を終了する。
【００２４】
また、ステップＳ３又はステップＳ９の後、コネクション管理部５５５３は、コネクションプール部５３から貸し出されたコネクション管理オブジェクト内の状態フラグを「未使用」に設定する（ステップＳ１３）。そして、コネクション管理部５５５３は、コネクション管理オブジェクトを、業務処理を実施するスレッドに割り当てる（ステップＳ１５）。例えば業務処理を実施するスレッドの使用領域が予め定められており、その使用領域にコネクション管理オブジェクトを設定する。そして、処理を終了する。このように、本実施の形態では、コネクション取得時には、コネクションの接続確認は行わない。
【００２５】
次に、図９及び図１０を用いて、図６に示したステップ（５）の処理の詳細について説明する。例えばＤＢアクセス処理部５５５のアクセス部５５５１は、業務処理部５５３から業務ＳＱＬ文の実行依頼を受信すると、業務処理を実施するスレッドに対して割り当てられているコネクション管理オブジェクトを取得する（ステップＳ２１）。そして、アクセス部５５５１は、そのコネクション管理オブジェクト内で指定されているコネクションを利用して、実行依頼に応じた業務ＳＱＬ文をデータベース７へ発行する（ステップＳ２３）。なお、発行すべき業務ＳＱＬ文が複数ある場合には、最初の業務ＳＱＬ文を１つ発行する。そして、アクセス部５５５１は、発行した業務ＳＱＬ文に対する処理が正常に完了したか判断する（ステップＳ２５）。発行したＳＱＬ文に対する処理が正常に完了した場合（ステップＳ２５：Ｙｅｓルート）、アクセス部５５５１は、業務ＳＱＬ文の実行結果を業務処理部５５３に出力する（ステップＳ２７）。また、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグを「ＳＱＬ実行済」に設定する（ステップＳ２９）。なお、業務ＳＱＬ文の初回実行時であれば、状態フラグは「未処理」であるため、「ＳＱＬ実行済」に更新する必要があるが、２回目以降の処理の場合には、状態フラグは既に「ＳＱＬ実行済」に設定されているため、本ステップをスキップし、ステップＳ３１に移行する。
【００２６】
その後、アクセス部５５５１は、未処理の業務ＳＱＬ文があるか判断する（ステップＳ３１）。未処理の業務ＳＱＬ文がある場合（ステップＳ３１：Ｙｅｓルート）、アクセス部５５５１は、次の業務ＳＱＬ文を選択し（ステップＳ３３）、ステップＳ２３の処理に戻って、次の業務ＳＱＬ文を発行する。一方、未処理の業務ＳＱＬ文がなければ（ステップＳ３１：Ｎｏルート）、処理を終了する。このように、動作が正常であれば、全ての業務ＳＱＬ文を実行するまでステップＳ２３乃至ステップＳ３３の処理が繰り返される。
【００２７】
一方、ステップＳ２３で発行した業務ＳＱＬ文に対する処理が正常に完了しなかった場合には（ステップＳ２５：Ｎｏルート）、端子Ａを介してステップＳ３５（図１０）の処理に移行する。
【００２８】
図１０の説明に移行して、端子Ａの後、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」であるか判断する（ステップＳ３５）。すなわち、業務ＳＱＬ文の初回実行時であるか否か判断する。スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」でなければ（ステップＳ３５：Ｎｏルート）、すなわち状態フラグが「ＳＱＬ実行済」である場合、処理はステップＳ４９に移行する。この場合、以下で説明するようなコネクションの接続確認等の処理は行わない。
【００２９】
一方、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」である場合（ステップＳ３５：Ｙｅｓルート）、すなわち業務ＳＱＬ文の初回実行時であれば、アクセス部５５５１は、そのコネクション管理オブジェクト内の状態フラグを「ＳＱＬ実行済」に設定する（ステップＳ３７）。そして、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内で指定されているコネクションの接続確認を行う。具体的には、アクセス部５５５１は、接続確認用のＳＱＬ文をデータベース７に対して発行する（ステップＳ３９）。その後、アクセス部５５５１は、接続確認の結果が正常を示しているか判断する（ステップＳ４１）。接続確認の結果が正常を示している場合（ステップＳ４１：Ｙｅｓルート）、処理はステップＳ４９に移行する。なお、接続確認の結果が正常であるということは、コネクションは正常に繋がっているということになる。この場合、コネクションに問題があるのではなく、業務処理部５５３の業務処理の内容や業務ＳＱＬ文などに問題があったために、業務ＳＱＬ文の実行に失敗したと判断できる。
【００３０】
一方、接続確認の結果が異常を示している場合（ステップＳ４１：Ｎｏルート）、すなわち何らかの要因でコネクションが切れてしまっている場合には、アクセス部５５５１は、新たなコネクションを確立するようミドルウェア５１に要求する。そして、ミドルウェア５１は、アクセス部５５５１からの要求に応じて、コネクションを確立するための処理を実施し、処理結果をアクセス部５５５１に出力する（ステップＳ４３）。なお、コネクションの確立に成功した場合には、確立したコネクションに関するデータを合わせて出力する。新たなコネクションの確立に成功した場合（ステップＳ４５：Ｙｅｓルート）、アクセス部５５５１は、元のコネクションに関するデータに代えて、ステップＳ４３において確立された新たなコネクションに関するデータを、スレッドに割り当てられているコネクション管理オブジェクトに設定する（ステップＳ４７）。そして、端子Ｃを介して図９（ステップＳ２３）の処理に戻る。なお、この後、ステップＳ２３では、アクセス部５５５１が、ステップＳ４３において確立された新たなコネクションを利用して、データベース７に対して業務ＳＱＬ文を再発行する。
【００３１】
一方、新たなコネクションを確立できなかった場合（ステップＳ４５：Ｎｏルート）、処理はステップＳ４９に移行する。なお、新たなコネクションを確立できなかったということは、データベース７がダウンしていると判断できる。
【００３２】
そして、ステップＳ４９の処理に移行して、アクセス部５５５１は、業務ＳＱＬ文の実行結果（エラー情報）を業務処理部５５３に出力する（ステップＳ４９）。なお、コネクションは正常に繋がっていたにもかかわらずエラーとなったのか、コネクションが切れているためにエラーとなったのかの情報などを合わせて出力するようにしてもよい。その後、端子Ｂを介して図９の処理に戻り、処理を終了する。
【００３３】
このような処理を実施することによって、業務ＳＱＬ文に対する処理が正常に完了しなかった場合に初めて接続確認が行われることになる。すなわち、プールしてあるコネクションを利用してデータベース７へアクセスする場合であっても、正常に動作している間は、接続確認を行わずに済むので、接続確認のための処理負荷を削減できる。
【００３４】
なお、業務ＳＱＬの初回実行時のみ接続確認等の処理を行うようになっているのは、既に業務ＳＱＬを実行していた場合に、新たなコネクション上で業務ＳＱＬを再実行すると、実行済みの業務ＳＱＬとの整合性を保つことができなくなる場合があるためである。
【００３５】
また、図１０の処理フローにおいて、新たなコネクションを確立できなかった場合に（ステップＳ４５：Ｎｏルート）、スレッドに割り当てられているコネクション管理オブジェクトをコネクションプール部５３に返却することなく、破棄するようにしてもよい。利用不可となったコネクションに係るコネクション管理オブジェクトについては、コネクションプール部５３から排除した方が効率的である。
【００３６】
また、上で説明した処理では、接続確認の結果が異常を示している場合（ステップＳ４１：Ｎｏルート）には、ステップＳ４３において新たなコネクションを確立するようになっているが、コネクションプール部５３から他のコネクション管理オブジェクトを再取得し、他のコネクション管理オブジェクト内で指定されているコネクションを利用して業務ＳＱＬ文を再発行するような構成にすることも可能である。例えば今回取得したコネクション管理オブジェクト内で指定されているコネクションのみが切れているような状況であった場合には、新たなコネクションを確立しなくても、他のコネクション管理オブジェクトを再取得することで、業務ＳＱＬ文を再発行できる。例えば他のコネクション管理オブジェクトを再取得してみて、他のコネクション管理オブジェクトでも同じ結果であった場合（すなわち、業務ＳＱＬ文に対する処理が正常に完了せず、接続確認の結果が異常を示している場合）に、コネクションを確立し直すような構成にすることも可能である。
【００３７】
［実施の形態２］
上で説明した第１の実施の形態では、コネクションの接続状態にかかわらず、コネクションの接続確認を行う前に業務ＳＱＬ文を発行するようになっている。但し、例えばデータベース７がダウンしているような場合には、プールしてあるコネクションは切れてしまっているため、初回の業務ＳＱＬ文の発行は無駄になる。そこで、第２の実施の形態では、図１１に示すように、業務ＳＱＬ文の実行結果が異常（エラー）、且つ、新たなコネクションの確立に失敗した場合には、状態フラグを「ＳＱＬ実行済」から「接続不可」に更新する。そして、コネクション取得時に、状態フラグが「接続不可」であれば、新たなコネクションを確立し、確立に成功した場合には、状態フラグを「接続不可」から「未使用」に更新する。以下、第２の実施の形態の詳細を説明する。
【００３８】
第２の実施の形態におけるシステム構成及びサーバ５の構成は、第１の実施の形態のものと同じである。また、第２の実施の形態におけるサーバ５の処理フローは、基本的には第１の実施の形態と同じであるが、図８に示した処理の代わりに、図１２に示すような処理を実施し、図１０に示した処理の代わりに、図１３に示すような処理を実施する。以下、これらの処理について説明する。
【００３９】
まず、図１２の処理フローについて説明する。なお、図１２は、図６に示したステップ（３）の詳細な処理フローを示している。例えばＤＢアクセス処理部５５５のコネクション管理部５５５３は、制御部５５１からのコネクション貸出依頼を受信すると、コネクション管理オブジェクトをコネクションプール部５３に要求する。コネクションプール部５３にコネクション管理オブジェクトがない場合（ステップＳ１０１：Ｎｏルート）、コネクションプール部５３は、新たなコネクションを確立するようミドルウェア５１に要求する。なお、処理はステップＳ１０７に移行する。
【００４０】
一方、コネクションプール部５３内にコネクション管理オブジェクトがある場合（ステップＳ１０１：Ｙｅｓルート）、コネクション管理部５５５３は、コネクションプール部５３から既存のコネクション管理オブジェクトを取得する（ステップＳ１０３）。すなわち、コネクションプール部５３からコネクション管理オブジェクトが貸し出される。なお、コネクションプール部５３内に複数のコネクション管理オブジェクトがある場合には、いずれのコネクション管理オブジェクトを利用するかは、例えばラウンドロビンなどの手法により決定する。その後、コネクション管理部５５５３は、取得したコネクション管理オブジェクト内の状態フラグが「接続不可」であるか判断する（ステップＳ１０５）。取得したコネクション管理オブジェクト内の状態フラグが「接続不可」でなければ（ステップＳ１０５：Ｎｏルート）、処理はステップＳ１１５に移行する。
【００４１】
一方、取得したコネクション管理オブジェクト内の状態フラグが「接続不可」である場合（ステップＳ１０５：Ｙｅｓルート）、コネクション管理部５５５３は、新たなコネクションを確立するようミドルウェア５１に要求する。なお、処理はステップＳ１０７に移行する。
【００４２】
そして、ステップＳ１０７に移行して、ミドルウェア５１は、コネクションプール部５３又はコネクション管理部５５５３からの要求に応じて、コネクションを確立するための処理を実施し、処理結果を要求元に出力する（ステップＳ１０７）。なお、コネクションの確立に成功した場合には、確立したコネクションに関するデータを合わせて出力する。新たなコネクションの確立に成功した場合（ステップＳ１０９：Ｙｅｓルート）、ミドルウェア５１が確立したコネクションに関するデータをコネクション管理オブジェクトに設定する（ステップＳ１１１）。より具体的には、ステップＳ１０１において、コネクションプール部５３内にコネクション管理オブジェクトがないと判断された場合であれば、コネクションプール部５３が、コネクション管理オブジェクトを生成し、ミドルウェア５１が確立したコネクションに関するデータをそのコネクション管理オブジェクトに設定する。そして、新たに生成したコネクション管理オブジェクトをコネクション管理部５５５３に貸し出す。また、ステップＳ１０５において、コネクション管理オブジェクト内の状態フラグが「接続不可」であると判断された場合であれば、コネクション管理部５５５３が、元のコネクションに関するデータに代えて、ミドルウェア５１が確立した新たなコネクションに関するデータをコネクション管理オブジェクトに設定する。その後、処理はステップＳ１１５に移行する。
【００４３】
一方、新たなコネクションを確立できなかった場合（ステップＳ１０９：Ｎｏルート）、コネクション管理部５５５３は、制御部５５１にコネクション取得エラーを出力する（ステップＳ１１３）。なお、ステップＳ１０１において、コネクションプール部５３内にコネクション管理オブジェクトがないと判断された場合であれば、コネクションプール部５３からコネクション管理部５５５３へ貸し出し可能なコネクション管理オブジェクトがない旨が通知され、当該通知を受信したコネクション管理部５５５３が、制御部５５１にコネクション取得エラーを出力する。その後、処理を終了する。
【００４４】
また、ステップＳ１０５又はステップＳ１１１の後、コネクション管理部５５５３は、コネクションプール部５３から貸し出されたコネクション管理オブジェクト内の状態フラグを「未使用」に設定する（ステップＳ１１５）。そして、コネクション管理部５５５３は、コネクション管理オブジェクトを、業務処理を実施するスレッドに割り当てる（ステップＳ１１７）。例えば業務処理を実施するスレッドの使用領域が予め定められており、その使用領域にコネクション管理オブジェクトを設定する。そして、処理を終了する。
【００４５】
第１の実施の形態（図８）と比較すると、第２の実施の形態（図１２）では、状態フラグが「接続不可」であるか否かの判断処理（すなわち、ステップＳ１０５）が追加されており、状態フラグが「接続不可」である場合には、新たなコネクションを確立するようになっている。なお、第２の実施の形態においても、コネクション取得時に、接続確認用のＳＱＬ文が発行されることはない。
【００４６】
次に、図１３の処理について説明する。なお、図９に示した処理は、第２の実施の形態でも同じく実施され、ここでは、ステップＳ２５において、業務ＳＱＬ文に対する処理が正常に完了しなかったと判断され、端子Ａを介して図１３に移行してきたものとする。図１３において、端子Ａの後、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」であるか判断する（ステップＳ１２１）。すなわち、業務ＳＱＬ文の初回実行時であるか否か判断する。スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」でなければ（ステップＳ１２１：Ｎｏルート）、すなわち状態フラグが「ＳＱＬ実行済」である場合、処理はステップＳ１３７に移行する。この場合、以下で説明するようなコネクションの接続確認等の処理は行わない。
【００４７】
一方、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグが「未使用」である場合（ステップＳ１２１：Ｙｅｓルート）、すなわち業務ＳＱＬ文の初回実行時であれば、アクセス部５５５１は、そのコネクション管理オブジェクト内の状態フラグを「ＳＱＬ実行済」に設定する（ステップＳ１２３）。そして、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内で指定されているコネクションの接続確認を行う。具体的には、アクセス部５５５１は、接続確認用のＳＱＬ文をデータベース７に対して発行する（ステップＳ１２５）。その後、アクセス部５５５１は、接続確認の結果が正常を示しているか判断する（ステップＳ１２７）。接続確認の結果が正常を示している場合（ステップＳ１２７：Ｙｅｓルート）、処理はステップＳ１３７に移行する。なお、接続確認の結果が正常であるということは、コネクションは正常に繋がっているということになる。この場合、コネクションに問題があるのではなく、業務処理部５５３の業務処理の内容や業務ＳＱＬ文などに問題があったために、業務ＳＱＬ文の実行に失敗したと判断できる。
【００４８】
一方、接続確認の結果が異常を示している場合（ステップＳ１２７：Ｎｏルート）、すなわち何らかの要因でコネクションが切れてしまっている場合には、アクセス部５５５１は、新たなコネクションを確立するようミドルウェア５１に要求する。そして、ミドルウェア５１は、アクセス部５５５１からの要求に応じて、コネクションを確立するための処理を実施し、処理結果をアクセス部５５５１に出力する（ステップＳ１２９）。なお、コネクションの確立に成功した場合には、確立したコネクションに関するデータを合わせて出力する。新たなコネクションの確立に成功した場合（ステップＳ１３１：Ｙｅｓルート）、アクセス部５５５１は、元のコネクションに関するデータに代えて、ステップＳ１２９において確立された新たなコネクションに関するデータを、スレッドに割り当てられているコネクション管理オブジェクトに設定する（ステップＳ１３３）。そして、端子Ｃを介して図９（ステップＳ２３）の処理に戻る。なお、この後、ステップＳ２３では、アクセス部５５５１が、ステップＳ１２９において確立された新たなコネクションを利用して、データベース７に対して業務ＳＱＬ文を再発行する。
【００４９】
一方、新たなコネクションを確立できなかった場合（ステップＳ１３１：Ｎｏルート）、アクセス部５５５１は、スレッドに割り当てられているコネクション管理オブジェクト内の状態フラグを「接続不可」に設定する（ステップＳ１３５）。なお、新たなコネクションを確立できなかったということは、データベース７がダウンしていると判断できる。その後、処理はステップＳ１３７に移行する。
【００５０】
そして、ステップＳ１３７の処理に移行して、アクセス部５５５１は、業務ＳＱＬ文の実行結果（エラー情報）を業務処理部５５３に出力する（ステップＳ１３７）。なお、コネクションは正常に繋がっていたにもかかわらずエラーとなったのか、コネクションが切れているためにエラーとなったのかの情報などを合わせて出力するようにしてもよい。その後、端子Ｂを介して図９の処理に戻り、処理を終了する。
【００５１】
このような処理を実施することによって、コネクション取得時に、状態フラグを用いてコネクションの状態を判断し、コネクションが切れている場合には、業務ＳＱＬ文を発行する前に新たなコネクションを確立することができる。なお、本実施の形態においても、コネクション取得時に接続確認用のＳＱＬ文は発行されることはないため、接続確認用のＳＱＬ文の発行による処理負荷を削減できる。
【００５２】
以上本技術の実施の形態について説明したが、本技術はこれに限定されるものではない。例えば上で説明したサーバ５の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致しない場合もある。また、本技術の実施の形態では、上で述べたような機能をサーバ上で動作する機能として説明してきたが、上で述べたような機能を同様の構成でクライアント側に実装することも可能である。
【００５３】
また、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
【００５４】
なお、上で説明したクライアント３やサーバ５は、コンピュータ装置であって、図１４に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００５５】
以上述べた本技術の実施の形態をまとめると以下のようになる。
【００５６】
本技術の第１の態様に係るデータベースアクセス制御方法は、クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなくコネクションを取得する取得ステップ（図１５：Ｓ１００１）と、取得ステップにおいて取得されたコネクションを利用して、業務処理要求に応じた第１のＳＱＬ文をデータベースに対して発行するステップ（図１５：Ｓ１００３）と、第１のＳＱＬ文に対する処理が正常に完了しなかった場合、取得ステップにおいて取得されたコネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップ（図１５：Ｓ１００５）とを含む。
【００５７】
このようにすれば、プールしてあるコネクションを利用してデータベースにアクセスする場合において、第１のＳＱＬ（例えば業務ＳＱＬ）文に対する処理が正常に完了しなかったときに初めて第２のＳＱＬ文（すなわち、接続確認用のＳＱＬ文）が発行されることになる。すなわち、正常に動作している間は、第２のＳＱＬ文が発行されることはないので、接続確認のための処理負荷を削減できるようになる。
【００５８】
また、本データベースアクセス制御方法が、第２のＳＱＬ文に対する処理が正常に完了した場合、第１のＳＱＬ文に対する処理が正常に完了しなかったことを表すエラー情報を出力するステップをさらに含むようにしてもよい。なお、第２のＳＱＬ文に対する処理が正常に完了したということは、コネクションは正常に繋がっているということになる。第２のＳＱＬ文は、第１のＳＱＬ（例えば業務ＳＱＬ）文に対する処理が正常に完了しなかった場合に初めて発行されるが、コネクションが正常に繋がっているにもかかわらず、第１のＳＱＬ文に対する処理が正常に完了しなかったということは、第１のＳＱＬ文に問題があると判断できる。
【００５９】
さらに、本データベースアクセス制御方法が、第２のＳＱＬ文に対する処理が正常に完了しなかった場合、コネクション確立機構に、データベースへの新たなコネクションを確立させるステップと、新たなコネクションの確立に成功した場合、当該新たなコネクションを利用して第１のＳＱＬ文をデータベースに対して再発行するステップとをさらに含むようにしてもよい。なお、第２のＳＱＬ文に対する処理が正常に完了しなかったということは、コネクションが切断されているということになる。従って、この場合には、新たなコネクションを確立して、新たなコネクションを用いて第１のＳＱＬ文を再発行する。これにより、コネクションプールから取得したコネクションが切断されていたとしても、新たなコネクションが確立できれば、データベースへアクセスできるようになる。
【００６０】
なお、本データベースアクセス制御方法が、第２のＳＱＬ文に対する処理が正常に完了しなかった場合、コネクションプールから他のコネクションを取得するステップと、取得した他のコネクションを利用して第１のＳＱＬ文をデータベースに対して再発行するステップとをさらに含むようにしてもよい。このようにすれば、例えば何らかの要因で最初に取得したコネクションだけが切断されているような場合には、新たなコネクションを確立しなくとも、他のコネクションを用いてデータベースへアクセスできるようになる。
【００６１】
さらに、本データベースアクセス制御方法が、新たなコネクションを確立できなかった場合、上記取得ステップにおいて取得されたコネクションをコネクションプールに返却せずに破棄するステップをさらに含むようにしてもよい。切断されたコネクションは使い回すことができないためである。これにより、利用不可となったコネクションをコネクションプール内から排除できる。
【００６２】
また、本データベースアクセス制御方法が、新たなコネクションを確立できなかった場合、上記取得ステップにおいて取得されたコネクションに接続不可を表すデータを対応付け、当該コネクションをコネクションプールに返却するステップをさらに含むようにしてもよい。このようにすれば、切断されているコネクションを把握できるようになる。
【００６３】
さらに、上で述べた取得ステップが、取得したコネクションに接続不可を表すデータが対応付けられているか判断し、接続不可を表すデータが対応付けられている場合には、コネクション確立機構に、取得したコネクションの代わりとなるコネクションを新たに確立させるステップを含むようにしてもよい。このようにすれば、コネクションプールからコネクションを取得した時点で、そのコネクションが切断されていることが分かるので、第１のＳＱＬ文及び第２のＳＱＬ文を発行する前に、新たなコネクションを確立することができるようになる。
【００６４】
本技術の第２の態様に係る情報処理装置は、データベースへのコネクションをプールするためのコネクションプール（図１６：１５０１）と、クライアント端末からの業務処理要求を受信した場合、コネクションプールから、接続状態を確認することなくコネクションを取得するコネクション取得部（図１６：１５０３）と、コネクション取得部により取得されたコネクションを利用してデータベースに対してＳＱＬ文を発行するアクセス部（図１６：１５０５）と、アクセス部に業務処理要求に応じた第１のＳＱＬ文をデータベースへ発行させる業務処理部（図１６：１５０７）とを有する。そして、上で述べたアクセス部は、第１のＳＱＬ文に対する処理が正常に完了しなかった場合、コネクション取得部により取得されたコネクションの接続状態を確認するための第２のＳＱＬ文を発行する。
【００６５】
また、上で述べたような処理をハードウエアに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【００６６】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【００６７】
（付記１）
クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなく前記コネクションを取得する取得ステップと、
前記取得ステップにおいて取得された前記コネクションを利用して、前記業務処理要求に応じた第１のＳＱＬ文を前記データベースに対して発行するステップと、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記取得ステップにおいて取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップと、
をコンピュータに実行させるためのプログラム。
【００６８】
（付記２）
前記第２のＳＱＬ文に対する処理が正常に完了した場合、前記第１のＳＱＬ文に対する処理が正常に完了しなかったことを表すエラー情報を出力するステップ
をさらに実行させるための付記１記載のプログラム。
【００６９】
（付記３）
前記第２のＳＱＬ文に対する処理が正常に完了しなかった場合、コネクション確立機構に、前記データベースへの新たなコネクションを確立させるステップと、
前記新たなコネクションの確立に成功した場合、当該新たなコネクションを利用して前記第１のＳＱＬ文を前記データベースに対して再発行するステップと、
をさらに実行させるための付記１又は２記載のプログラム。
【００７０】
（付記４）
前記第２のＳＱＬ文に対する処理が正常に完了しなかった場合、前記コネクションプールから他のコネクションを取得するステップと、
取得した前記他のコネクションを利用して前記第１のＳＱＬ文を前記データベースに対して再発行するステップと、
をさらに実行させるための付記１又は２記載のプログラム。
【００７１】
（付記５）
前記新たなコネクションを確立できなかった場合、前記取得ステップにおいて取得された前記コネクションを前記コネクションプールに返却せずに破棄するステップ
をさらに実行させるための付記３記載のプログラム。
【００７２】
（付記６）
前記新たなコネクションを確立できなかった場合、前記取得ステップにおいて取得された前記コネクションに接続不可を表すデータを対応付け、当該コネクションを前記コネクションプールに返却するステップ
をさらに実行させるための付記３記載のプログラム。
【００７３】
（付記７）
前記取得ステップが、
取得した前記コネクションに前記接続不可を表すデータが対応付けられているか判断し、前記接続不可を表すデータが対応付けられている場合には、前記コネクション確立機構に、取得した前記コネクションの代わりとなるコネクションを新たに確立させるステップ
を含む、付記６記載のプログラム。
【００７４】
（付記８）
クライアント端末からの業務処理要求を受信した場合、データベースへのコネクションをプールしているコネクションプールから、接続状態を確認することなく前記コネクションを取得する取得ステップと、
前記取得ステップにおいて取得された前記コネクションを利用して、前記業務処理要求に応じた第１のＳＱＬ文を前記データベースに対して発行するステップと、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記取得ステップにおいて取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行するステップと、
を含み、コンピュータにより実行されるデータベースアクセス制御方法。
【００７５】
（付記９）
データベースへのコネクションをプールするためのコネクションプールと、
クライアント端末からの業務処理要求を受信した場合、前記コネクションプールから、接続状態を確認することなく前記コネクションを取得するコネクション取得部と、
前記コネクション取得部により取得された前記コネクションを利用して前記データベースに対してＳＱＬ文を発行するアクセス部と、
前記アクセス部に前記業務処理要求に応じた第１のＳＱＬ文を前記データベースへ発行させる業務処理部と、
を有し、
前記アクセス部は、
前記第１のＳＱＬ文に対する処理が正常に完了しなかった場合、前記コネクション取得部により取得された前記コネクションの接続状態を確認するための第２のＳＱＬ文を発行する
情報処理装置。
【符号の説明】
【００７６】
１  ネットワーク    ３  クライアント
５  サーバ    ７  データベース
５１  ミドルウェア    ５３  コネクションプール部
５５１  制御部    ５５３  業務処理部    ５５５  ＤＢアクセス処理部
５５５１  アクセス部    ５５５３  コネクション管理部
【図１】
2011181039.tif 000003
【図２】
2011181039.tif 000004
【図３】
2011181039.tif 000005
【図４】
2011181039.tif 000006
【図５】
2011181039.tif 000007
【図６】
2011181039.tif 000008
【図７】
2011181039.tif 000009
【図８】
2011181039.tif 000010
【図９】
2011181039.tif 000011
【図１０】
2011181039.tif 000012
【図１１】
2011181039.tif 000013
【図１２】
2011181039.tif 000014
【図１３】
2011181039.tif 000015
【図１４】
2011181039.tif 000016
【図１５】
2011181039.tif 000017
【図１６】
2011181039.tif 000018