(57)【要約】【課題】本発明はデータベースアクセス方法及び装置に関し、ＡＰＬサーバが故障しても、同一要求の同一アプリケーションに対しては、正常なアプリケーション結果を返すことができるデータベースアクセス方法及び装置を提供することを目的としている。【解決手段】アプリケーションサーバ３内に、アプリケーション部３ａからの入力情報と共にアプリケーションサーバＩＤをパラメータに付与して後述するデータベースアクセス制御部４ｃに通知するデータベースアクセスメソッド部３ｂを設け、データベースサーバ４内に、前記データベースアクセスメソッド部３ｂからの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをＲＤＢＭＳアクセスし、そのアクセス情報をメモリ４ａに保存した後、アクセス元のアプリケーションサーバ３に結果を戻すデータベースアクセス制御部４ｃを設けて構成される。【選択図】図２
2007264770.tif 000002
【特許請求の範囲】
【請求項１】
ＲＤＢＭＳを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、ＲＤＢＭＳにアクセスし、その結果をＲＤＢＭＳ内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とするデータベースアクセス方法。
【請求項２】
前記ＲＤＢＭＳへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をＲＤＢＭＳを制御するデータベースサーバに配備するようにしたことを特徴とする請求項１記載のデータベースアクセス方法。
【請求項３】
コミット／ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット／ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求ＩＤに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする請求項１又は２記載のデータベースアクセス方法。
【請求項４】
ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする請求項１又は２記載のデータベースアクセス方法。
【請求項５】
ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、
該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、
該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、
前記アプリケーションサーバ内にＲＤＢＭＳへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバＩＤをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、
前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをＲＤＢＭＳアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設け、
たことを特徴とするデータベースアクセス装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータベースアクセス方法及び装置に関する。
【背景技術】
【０００２】
ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａ  Ｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ：ＲＤＢを構築運用するために用いられる管理ソフトウェア）にてデータ管理するデータベースサーバと、ユーザ要求を実行するアプリケーション（以下ＡＰＬと略す）サーバの構成において、高信頼なＡＰＬサーバの構成としてＨＡ構成、分散構成等が一般的な構成である。
【０００３】
ＨＡ構成は、サーバ故障発生時に即座にスタンバイ（以下ＳＢＹと略す）系に切り替えてサービスを継続する。また、分散構成は、同一サービスが提供可能な正常なＡＰＬサーバにサービスを分散することでサービスを継続する。上記の構成で、サービス無中断とするＡＰＬサーバ構成が構築されている。
【０００４】
これらの構成は、ユーザからの１つの要求を１つのＡＰＬサーバが処理する仕組みであり、サーバ故障が発生すると、実行途中の要求があれば、サーバ構成の分岐点に戻って正常な他のサーバに対してリトライする（分散構成）。
【０００５】
また、実行途中の経過データを正常なサーバに引き継ぐ方式として、実行した時点のＲＤＢＭＳ上のコミット（確定）済み更新データ、若しくはＡＰＬサーバのメモリ上の更新データを他の正常なサーバに引き継ぐことで、途中から実行しユーザの要求を継続する（ＨＡ構成）。
【０００６】
図１１は従来の分散構成の説明図である。図において、１はユーザ、２はフロントサーバ、３はＡＰＬサーバ、４はデータベースサーバ（ＲＤＢＭＳ）である。ＡＰＬサーバ３はＡとＢの２種類存在する。
１）ユーザ１がコマンドを入力し、フロントサーバ２からＡＰＬサーバＡにユーザ要求を通知する。
２）ＡＰＬサーバＡはデータベースサーバ４にアクセスし、必要に応じてデータの書き込みと読み出しを行ない、アプリケーションを実行する（ロジックにより繰り返し行なう）。
３）ＡＰＬサーバＡが故障し、フロントサーバ２にエラーが戻る。
４）受付部又はユーザ自身にて、同一ユーザ要求をリトライする。そして、フロントサーバ２から正常なＡＰＬサーバＢにユーザ要求を通知する。
５）ＡＰＬサーバＢは、データベースサーバ４にアクセスし、データの書き込みと読み出しを行ない、アプリケーションを実行する。
６）ＡＰＬサーバＢにて要求が完了すると、ユーザ１に要求完了を応答する。
【０００７】
図１２は従来のＨＡ構成の説明図である。図１１と同一のものは、同一の符号を付して示す。
１）ユーザ１がコマンドを入力し、フロントサーバ２からＡＰＬサーバ３のＡＣＴ系に対してユーザ要求を通知する。
２）ＡＣＴ系ＡＰＬサーバ３はデータベースサーバ４にアクセスし、必要に応じてデータの書き込みと読み出しを行ない、アプリケーションを実行する（ロジックにより繰り返し行なう）。
３）ＡＣＴ系のＡＰＬサーバ３が故障し、ＳＢＹ系（新ＡＣＴ系）のアプリケーションに切り替わる。
４）新ＡＣＴ系のＡＰＬサーバ３が立上がり時に、ＡＣＴ系で実行途中であったユーザ要求を、データベース状態、ＡＣＴ系メモリ情報を元に途中から実行する。
５）新ＡＣＴ系ＡＰＬサーバ３は、データベースサーバ４にアクセスし、データの書き込みと読み出しを行ない、アプリケーションを実行する。
６）新ＡＣＴ系ＡＰＬサーバ３で要求が完了すると、ユーザ１に要求完了を応答する。
【０００８】
従来のこの種のシステムとしては、照合系では処理系からの通知情報の有無、周期性及び内容から照合対象とすべき処理系の選択と照合を定期的に行って、処理系相互間の同期、処理系の状態管理を必要としない照合出力方法の技術が知られている（例えば特許文献１参照）。また、個々の実プロセス及び擬似プロセスが実行される度に、プロセス数の差を算出し、この差が所定のしきい値を越えたか否かを判定し、越えない場合は後続の実プロセスを実行し、越えた場合には遅延時間解消処理を実行する技術が知られている（例えば、特許文献２参照）。
【０００９】
また、ネットワークインフラやＷｅｂサイトに故障が発生してもサービスが停止しない技術が知られている（例えば非特許文献１参照）。また、クラスタによる高信頼システムの構築技術に関する技術である「クラスタによるシステムダウンの未然防止」に関する技術が知られている（例えば、非特許文献２参照）。
【特許文献１】特開昭６０−２６３２５２号公報（第４頁右上欄第１行〜第５頁左下欄第２行、第１図〜第３図）
【特許文献２】特開平８−２４９１９９号公報（段落００１０〜００１１、図１）
【非特許文献１】負荷分散入門、“アベイラビリティ（可用性）”、掲載日：２００４年７月２０日、富士通株式会社［２００５．１２．１７検索］、インターネット〈URL:http://primeserver.fujitsu.com/ipcom/catalog/data/1/1.html〉
【非特許文献２】クラスタによる高信頼システムの構築、“クラスタによるシステムダウンロードの未然防止”富士通株式会社［２００５．１２．１７検索］、インターネット〈URL:http://www.fmworld.net/biz/primergy/technical/cluster〉
【発明の開示】
【発明が解決しようとする課題】
【００１０】
前述した従来の技術によれば、故障時に実行していた要求は、最小で正常なサーバに引き継ぐ手続き時間、最大で１要求処理時間×２倍の応答時間がかかることになる。また、上記の遅延は、１つのＡＰＬサーバで実行していた時の、その要求に対するリカバリ（リトライ）時間である。このリカバリの時間をなくすため、ユーザの１要求に対して、単純に同時に複数のＡＰＬサーバにて冗長実行させ１台のサーバが正常に要求を完了すればよいとした場合、現存するＲＤＢＭＳを用いたデータ更新を伴うアプリケーションのロジック、及びデータベースアクセスでは、同一レコードの更新処理で、後からアクセス（更新）したＡＰＬサーバは、先にアクセス（更新）したＡＰＬサーバがコミット（確定）／ロールバック（元に戻す）するまでＲＤＢＭＳの排他にて待ち合わせが発生する。この場合、先にアクセスしていたサーバが故障すると、排他により待たされた時間分遅れてアクセスしたＡＰＬサーバが要求を実行することになり応答が遅延する。
【００１１】
また、データ更新が複数回のコミットによって実行するアプリケーションのロジックにおいては、処理矛盾が発生してしまう。以下、この点につき、説明する。いま、あるアプリケーションが、処理Ａ→処理Ｂ→処理Ｃの順番通りに処理しないと処理矛盾が発生するプログラムであるものとする。２つのＡＰＬサーバ＃１、ＡＰＬ＃２で同時に、このアプリケーションを要求ＩＤ：１で実行した場合、ＡＰＬサーバ＃２が処理Ａ後のコミットまで完了した時点（処理番号は１）で、ＡＰＬサーバ＃１は先に進んでいて処理Ｂ後のコミットが実行されると、データベース上の処理番号は２となる。ＡＰＬサーバ＃２は前記コミットの次の処理であるデータベース上の処理番号を取得して、処理番号は２を取得してしまう。この結果、ＡＰＬサーバ＃２の処理は、処理Ａを処理Ｂをスキップして完了後に処理Ｃを実行することになってしまうので、処理矛盾が発生することになる。
【００１２】
このように、現存するＲＤＢＭＳを用いたシステムにおいて、アプリケーションを同時実行すると、データ更新時のデータを保証しようとするＲＤＢＭＳ機能（排他）と、サーバ故障を危惧して複数台のＡＰＬサーバにて同時実行しユーザ応答時間を保証しようとする仕組みとでは、相反する課題が発生してしまう。また、ＡＰＬサーバ故障時に実行していた要求をその処理時点から保証するためには、アプリケーションのメモリ上の更新データを引き継ぐ仕組みが必要となる。
【００１３】
本発明はこのような課題に鑑みてなされたものであって、ＡＰＬサーバが故障しても、他のＡＰＬサーバが要求を実行してその結果をＲＤＢＭＳのメモリに記憶させておくことにより、後続の同一のアプリケーション要求に対しては前記メモリに記憶されている処理結果を返すことにより、同一要求の同一アプリケーションに対しては、正常なアプリケーション結果を返すことができるデータベースアクセス方法及び装置を提供することを目的としている。
【課題を解決するための手段】
【００１４】
前述した課題の解決手段は、ＲＤＢＭＳを用いたシステムにおいて、ユーザから１つの要求を複数のＡＰＬサーバ（同じアプリケーション、同じロジック）にて同時実行が可能なデータベースアクセスにある。本発明の課題の解決手段として、ユーザの１つの要求に同時実行する複数サーバからのデータベースアクセスに対して、最初のＡＰＬサーバからのアクセスをＲＤＢＭＳにアクセス・応答し、２つ目以降の同一アクセスは、最初のデータベースアクセス結果で応答することで解決する。
【００１５】
また、前述したＡＰＬサーバのアクセス（更新後）、後からアクセス（更新）したＡＰＬサーバがＲＤＢＭＳの排他により待たされる排他については、後からアクセス（更新）したＡＰＬサーバは、ＲＤＢＭＳにアクセスしないようにすることで解決できる。
【００１６】
また、データベースアクセスにて全てのデータ（入出力情報）を管理するアプリケーションにおいて、前述した解決手段で、複数ＡＰＬサーバで走行するアプリケーションは全てホットスタンバイであり、各ＡＰＬサーバのメモリ上の更新データも自アプリケーションにて更新されており、ＡＰＬサーバ故障時に更新データを引き継ぐ仕組みを必要としない。
【００１７】
（１）請求項１記載の発明は、ＲＤＢＭＳを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、ＲＤＢＭＳにアクセスし、その結果をＲＤＢＭＳ内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とする。
【００１８】
ここで、データベースアクセスとは、ＡＰＬサーバにて動作するアプリケーションからのデータベースへのアクセスをいう。ユーザからの要求毎に、アプリケーションのロジックが異なる。要求毎に、データベースへのアクセスについてもアクセス内容とそのアクセス順番はさまざまである。
【００１９】
次に、ＲＤＢＭＳアクセスとは、現存するＲＤＢＭＳへのアクセスをいう。
アクセス内容は、ＲＤＢＭＳアクセス（ＤＢトランザクション取得，レコード生成，削除，更新，参照，コミット／ロールバック，ＤＢトランザクション開放）の内容である。各要求に対する各アプリケーションの動作によって、パラメータとアクセス順番はさまざまである。
【００２０】
アクセス結果は、アクセス内容によってＲＤＢＭＳへアクセスした結果をいう。
アクセス情報は、要求毎のアクセス内容とそのアクセス順番とアクセス結果、及び各ＡＰＬサーバの実行状況をいう。
【００２１】
（２）請求項２記載の発明は、前記ＲＤＢＭＳへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をＲＤＢＭＳを制御するデータベースサーバに配備するようにしたことを特徴とする。
【００２２】
（３）請求項３記載の発明は、コミット／ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット／ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求ＩＤに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする。
【００２３】
（４）請求項４記載の発明は、ユーザからの一要求を識別するシステム一意の識別子（要求ＩＤ）と、各アプリケーションサーバを識別するシステム一意の識別情報（ＡＰＬサーバＩＤ）と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報（ＣＰＵ使用率、リソース使用量等）を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする。
【００２４】
（５）請求項５記載の発明は、ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、前記アプリケーションサーバ内にＲＤＢＭＳへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバＩＤをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをＲＤＢＭＳアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設けたことを特徴とする。
【発明の効果】
【００２５】
（１）請求項１記載の発明によれば、ＲＤＢＭＳを用いたシステムにおいて、ユーザからの１つの要求を複数のＡＰＬサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のＡＰＬサーバが故障しても、１台でも正常に要求実行したＡＰＬサーバが存在すれば、サービス無中断（サーバ切替不要）にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のＡＰＬサーバに発生しても、負荷の低い他ＡＰＬサーバが先行してデータベースアクセスを行なうため、ＡＰＬサーバ負荷によるユーザへの応答遅れを軽減することができる。
【００２６】
（２）請求項２記載の発明によれば、ＲＤＢＭＳを用いたシステムにおいて、ユーザからの１つの要求を複数のＡＰＬサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のＡＰＬサーバが故障しても、１台でも正常に要求実行したＡＰＬサーバが存在すれば、サービス無中断（サーバ切替不要）にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のＡＰＬサーバに発生しても、負荷の低い他ＡＰＬサーバが先行してデータベースアクセスを行なうため、ＡＰＬサーバ負荷によるユーザへの応答遅れを軽減することができる。
【００２７】
（３）請求項３記載の発明によれば、ユーザ要求を複数ＡＰＬサーバで同時実行中に１つのＡＰＬサーバがユーザ要求を完了した以降は、実行中の他のＡＰＬサーバのデータベースアクセス時に、結果としてそのユーザ要求が完了していることを知らせることで、その要求に対する実行を中止することができ、ＡＰＬサーバの負荷を軽減させることができる。
【００２８】
（４）請求項４記載の発明によれば、ユーザ要求を複数ＡＰＬサーバで同時実行中に、データベースアクセス時に、ＡＰＬサーバ負荷情報（ＣＰＵ使用率，リソース使用量等）を付加することで、同時実行（冗長実行）を制御し、負荷が重くなったＡＰＬサーバの要求実行を中止することができ、ＡＰＬサーバの負荷を軽減することができる。
【００２９】
（５）ＲＤＢＭＳを用いたシステムにおいて、ユーザからの１つの要求を複数のＡＰＬサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のＡＰＬサーバが故障しても、１台でも正常に要求実行したＡＰＬサーバが存在すれば、サービス無中断（サーバ切替不要）にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のＡＰＬサーバに発生しても、負荷の低い他ＡＰＬサーバが先行してデータベースアクセスを行なうため、ＡＰＬサーバ負荷によるユーザへの応答遅れを軽減することができる。
【００３０】
この場合において、ユーザ要求を複数ＡＰＬサーバで同時実行中に、各ＡＰＬサーバのデータベースアクセス実行状況（アクセス済み実行順番の差異）をチェックすることで、同時実行（冗長実行）を制御し、負荷が重くなったＡＰＬサーバの要求実行を中止することができ、ＡＰＬサーバの負荷を軽減することができる。
【００３１】
また、この場合において、アプリケーションのロジックに合わせたアクセス情報管理を行なうことで、さまざまなデータベースアクセスに対応することができる。
・ユーザの１つの要求に対して、１つのアクセス情報の管理とせず、管理単位をロジックに合わせてサブ要求ＩＤとして管理することができる（ユーザの要求が複数のデータベーストランザクションで制御するロジックとなる場合）。
・データベーストランザクションの確定の単位であるコミット／ロールバックを、ユーザ要求の完了とせず、アプリケーションとのインタフェースに“業務開始／業務完了”を設けて管理することができる（ユーザの要求が複数のコミット／ロールバックを伴うロジックとなる場合）。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図１は本発明の構成説明図である。図１１と同一のものは、同一の符号を付して示す。
１），１）´フロントサーバ２からＡＰＬサーバＡ，Ｂに同一のユーザ要求を通知する。
２），２）´ＡＰＬサーバＡ，Ｂはデータベース（以後ＤＢと略す）サーバ４（ＲＤＢＭＳ）３にアクセスし、データの書き込みと読み出しを行ないアプリケーションを実行する。この場合において、アプリケーションのロジックによりＡＰＬサーバＡ，Ｂから複数のアクセスが発生する。ＤＢサーバ４は、ユーザ要求毎にアクセス順番、内容、結果を管理してメモリ４ａに格納しておく。そして、ＡＰＬサーバＡ，Ｂから同一のアクセスを、最初にアクセスした結果で応答する。即ち、ＡＰＬサーバＡが故障した場合、その故障の前にアプリケーション実行結果がメモリ４ａに格納されておれば、そのメモリ４ａの内容で応答することができる。
３）この発明によれば、ＡＰＬサーバＡが故障しても、ＡＰＬサーバＢは、ユーザ要求の処理を続け、要求完了後、ユーザ１に応答する。
【００３３】
本発明によれば、ＲＤＢＭＳを用いたシステムにおいて、ユーザからの１つの要求を複数のＡＰＬサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のＡＰＬサーバが故障しても、１台でも正常に要求実行したＡＰＬサーバが存在すれば、サービス無中断（サーバ切替不要）にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のＡＰＬサーバに発生しても、負荷の低い他ＡＰＬサーバが先行してデータベースアクセスを行なうため、ＡＰＬサーバ負荷によるユーザへの応答遅れを軽減することができる。
【００３４】
図２は本発明システムの構成例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。図において、２はフロントサーバ、２ａはフロントサーバ２から入力されるユーザ要求である。１０は本発明を具備するシステムである。本発明を具備するシステム１０は、以下のような構成をもつ。
【００３５】
１１はフロントサーバ２からのユーザ要求２ａを受けるＡＰＬサーバ同時実行制御部、３は該ＡＰＬサーバ同時実行制御部１１と接続されるＡＰＬサーバである。該ＡＰＬサーバ３は複数台配備される。ＡＰＬサーバ３において、３ａはアプリケーション部、３ｂはフロントサーバ２とＡＰＬサーバ３にデータベースアクセスインタフェースを提供するＤＢアクセスメソッド部である。４はＡＰＬサーバ３と接続されるＤＢサーバである。ＤＢサーバ４において、４ｂはアクセス情報、４ｃは複数サーバからの同一内容のアクセス、及びアクセス順番を管理し、同一結果を保証するＤＢアクセス制御部、４ｄはＲＤＢＭＳ部、４ａは各種情報を記憶するメモリとしてのデータベースである。
【００３６】
ＤＢアクセス制御部４ｃは、負荷等によるサーバ毎のアクセスのタイミング遅れは、先のアクセス結果を保存し、後のアクセス結果に反映させることでカバーする。また、先にユーザ要求を完了したＡＰＬサーバがいれば、以降の他サーバのアクセスは実行しない、先勝ち方式とする。以降の他サーバのアクセスは、要求実行完了として、アプリケーションで処理中の要求実行を止める指示をアクセス結果として通知する。
【００３７】
なお、図の下には、それぞれの信号線の種別と四角で囲った構成の説明がなされている。以下、各構成要素について詳細に説明する。
１．ＡＰＬサーバ同時実行制御部１１
ユーザからの１つの要求を入力情報とし、複数のＡＰＬサーバ３に対してユーザ要求２ａを通知する。入力情報に要求ＩＤが含まれる場合は、その要求ＩＤを含めた情報で、ＡＰＬサーバ３にユーザ要求を通知する。入力情報に要求ＩＤがない場合には、要求ＩＤを付与し、その要求ＩＤを含めた情報で、ＡＰＬサーバ３にユーザ要求を通知する。そして、ユーザ要求を通知したＡＰＬサーバ３からの要求結果を待ち受け、何れかのＡＰＬサーバ３から要求結果を受けた時点で、ユーザへ要求結果を応答する。ここで、要求ＩＤとは、ユーザからの要求を識別するシステム一意の識別子のことである。
【００３８】
２．アプリケーション部３ａ
ＡＰＬサーバ同時実行制御部１１からの入力情報（要求ＩＤを含む）を元に、ユーザ要求に対するアプリケーションのロジックを実行する。データベースアクセスを行なう場合は、要求ＩＤをパラメータに含めてＤＢアクセスメソッド部３ｂを実行する。アプリケーションのロジックにより、１要求で複数のＤＢトランザクションを使用する場合は、要求ＩＤに、ロジックに対応した複数のサブ要求ＩＤを付与して要求ＩＤ（入力の要求ＩＤ＋サブ要求ＩＤ）とする。
【００３９】
３．ＤＢアクセスメソッド部３ｂ
ＲＤＢＭＳ部４ｄへアクセス（ＤＢトランザクション取得，レコード生成，削除，更新，参照，コミット／ロールバック，ＤＢトランザクション開放）するためのインタフェースをアプリケーション部３ａに提供し、アプリケーション部３ａからの入力情報（要求ＩＤを含む）と共にＡＰＬサーバＩＤをパラメータに付与してＤＢアクセス制御部４ｃに通知する。また、ＡＰＬサーバ負荷情報（ＣＰＵ使用率又はリソース使用量）をパラメータとして設定することで、ＤＢアクセス制御部４ｃ側にて自ＡＰＬサーバの要求実行制御を行なう。ここで、ＡＰＬサーバＩＤは、ＡＰＬサーバ３を識別するシステム一意の識別情報である。
【００４０】
４．ＤＢアクセス制御部４ｃ
ＤＢアクセスメソッド部３ｂからの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをＲＤＢＭＳアクセスし、そのアクセス情報を保存した後、アクセス元のＡＰＬサーバ３に結果を戻す。以降、発生する同一アクセス内容、同一アクセス番号の他、ＡＰＬサーバ（最初にアクセスしたＡＰＬサーバ以外）からのデータベースアクセスは、保存した同一アクセス情報のアクセス結果を通知する。
【００４１】
また、１要求の全アクセスの完了（要求実行完了）を意味するアプリケーションとのインタフェースを明示的（コミット／ロールバック，ＤＢトランザクション開放，要求完了インタフェース等）に決めておき、要求実行の完了を管理する。先に、要求実行完了したＡＰＬサーバ３がいれば、以降の他ＡＰＬサーバ３のアクセスは実行しない。以降の他ＡＰＬサーバ３のアクセスは要求実行完了として、アプリケーションに処理中の要求実行を止める指示をアクセス結果として通知する。
【００４２】
また、アクセス情報にて管理するアクセス番号をもとに、先行するＡＰＬサーバ３のアクセス番号との差異が規定値を越える場合、アクセスしたＡＰＬサーバ３へアクセス結果として要求実行中止を通知する。また、入力情報にＡＰＬサーバ負荷情報（ＣＰＵ使用率又はリソース使用量等）を付加し、その値が規定値を越える場合、アクセスしたＡＰＬサーバ３へアクセス結果として要求実行中止を通知する。
【００４３】
このように、本発明によれば、ユーザ要求を複数ＡＰＬサーバ３で同時実行中に１つのＡＰＬサーバ３がユーザ要求を完了した以降は、実行中の他のＡＰＬサーバ３のデータベースアクセス時に、結果としてそのユーザ要求が完了していることを知らせることで、その要求に対する実行を中止することができ、ＡＰＬサーバ３の負荷を軽減させることができる。
【００４４】
また、ユーザ要求を複数ＡＰＬサーバ３で同時実行中に、データベースアクセス時に、ＡＰＬサーバ負荷情報（ＣＰＵ使用率，リソース使用量等）を付加することで、同時実行（冗長実行）を制御し、負荷が重くなったＡＰＬサーバ３の要求実行を中止することができ、ＡＰＬサーバ３の負荷を軽減することができる。
【００４５】
５．ＲＤＢＭＳ部４ｄ
既存のリレーショナルデータベースである。例えば、Ｏｒａｃｌｅ等がある。
図３はＡＰＬサーバ同時実行制御部１１の動作を示すフローチャートである。以降、フローチャートで示す記号等の意味は、図４に示す通りである。ユーザからの要求を受けると、システム一意となる要求ＩＤを取得する（Ｓ１）。次に、既存の分散サーバにて管理される振り分け先ＡＰＬサーバ情報から、分散可能な複数のＡＰＬサーバ３を抽出する（Ｓ２）。次に、ユーザからの要求情報に要求ＩＤを付加し、抽出した複数のＡＰＬサーバ３にユーザ要求を通知する（Ｓ３）。ＡＰＬサーバ３にてアプリケーションが実行され、その結果が出力されると、ユーザに対して出力情報を応答する（Ｓ４）。
【００４６】
図５はアプリケーション部３ａの動作を示すフローチャートである。ＡＰＬサーバ同時実行制御部１１から要求情報と要求ＩＤとからなるユーザ要求を受け付けると、本発明にて提供するＤＢアクセスメソッド部３ｂをアクセスする（Ｓ１）。ＤＢアクセスメソッド部３ｂは、既存のデータベースアクセスの入力情報に要求ＩＤを付加した入力情報でアクセスされる。そして、ＤＢアクセスメソッドを実行し、アクセス結果が要求実行完了又は要求実行中止かチェックする（Ｓ２）。
【００４７】
アクセス結果が要求実行完了又は要求実行中止である場合には、ユーザ要求の実行を中止する（Ｓ３）。アクセス結果が要求実行完了でない場合、又は要求実行中止でない場合には、応答し、ＡＰＬサーバ同時実行制御部１１に対して出力情報（応答結果）を出力する（Ｓ４）。なお、図中に破線で囲った部分２０は、アプリケーションロジックにより複数回のアクセスが発生する。
【００４８】
図６はＤＢアクセスメソッド部３ｂの動作を示すフローチャートである。ＤＢアクセスメソッド部３ｂは、アプリケーションのロジックにてデータベースアクセスするメソッド分のＤＢアクセスメソッドを提供する。そして、ＤＢアクセスメソッドを実装したＡＰＬサーバ３のＡＰＬサーバＩＤをシステムデータから読み込み（Ｓ１）、システムデータからＡＰＬサーバ負荷情報（ＣＰＵ使用率）を読み込む（Ｓ２）。そして、ＤＢサーバにＤＢアクセスし、入力情報（既存のデータベースアクセスの入力情報、及び要求ＩＤ）とＡＰＬサーバＩＤ、ＡＰＬサーバ負荷情報を付加してＤＢサーバ４にアクセスし、通知する（Ｓ３）。
【００４９】
ＤＢアクセス制御部４ｃは、これら情報を元に所定の処理を行なう。その間、ＤＢサーバ４からのアクセス結果を待ち合わせし（Ｓ４）、受け取ったらアプリケーション部３ａに応答する（Ｓ５）。アプリケーション部３ａには、アクセス結果が出力情報として与えられる。
【００５０】
図７はＤＢアクセス制御部４ｃの動作を示すフローチャートである。ＤＢアクセス制御部４ｃは、アクセス情報を管理し、ＲＤＢＭＳ部４ｄへのＲＤＢＭＳアクセスを制御する。アクセス情報は、要求ＩＤ、アクセス番号、ＤＢトランザクションＩＤ、アクセス内容、アクセス結果、ＡＰＬサーバ実行状況で構成する。ＡＰＬサーバ３からの入力情報は、要求ＩＤ、アクセス内容、ＡＰＬサーバＩＤ、ＣＰＵ使用率である。
【００５１】
ＡＰＬサーバ３からＤＢアクセスの通知があると、アクセス情報から入力情報（要求ＩＤ、ＡＰＬサーバＩＤ）が一致する最後のアクセス番号を取得し（Ｓ１）、アクセス情報から同一要求ＩＤのアクセス番号＋１の情報を取得する（Ｓ２）。次に、要求ＩＤの（アクセス番号＋１）情報の有無を判定する（Ｓ３）。
【００５２】
アクセス番号＋１の情報が存在しない場合は、ＲＤＢＭＳ部４ｄにＲＤＢＭＳアクセスし、ＲＤＢＭＳを実行する（Ｓ４）。ＲＤＢＭＳ部４ｄからの結果が戻ると、アクセス情報に要求ＩＤ，（アクセス番号＋１），ＤＢトランザクションＩＤ，アクセス内容，アクセス結果，ＡＰＬサーバ実行状態（ＡＰＬサーバＩＤ）を登録する（Ｓ５）。ここで、ＤＢトランザクションＩＤは、ＤＢトランザクション取得にて上記を実行した結果であり、要求ＩＤ単位に最初のＲＤＢＭＳアクセスで取得し、システム情報（ＤＢトランザクションＩＤ）に設定する。以降の同一要求ＩＤのＤＢアクセスは、上記アクセス情報を取得してＲＤＢＭＳアクセス時にパラメータとして使用する。そして、アセス結果を出力情報に設定し（Ｓ６）、アクセス結果をＡＰＬサーバ３に通知する（Ｓ７）。
【００５３】
要求ＩＤの（アクセス番号＋１）の情報が存在する場合は、先行するＡＰＬサーバ３の実行状況確認、負荷状況確認を行なう。即ち、先行するＡＰＬサーバ３の実行状況確認は、アクセス情報から入力情報（要求ＩＤ）で、最後のアクセス番号のアクセス情報（アクセス内容）を取得し（Ｓ８）、最後のアクセス内容を判定する（Ｓ９）。アクセス内容がＤＢトランザクション解放である場合は、出力情報のアクセス結果に“要求実行完了”を設定し、ＡＰＬサーバ３に応答する（Ｓ１０）。
【００５４】
アクセス内容がその他のアクセスである場合、要求ＩＤの最後のアクセス番号と入力ＡＰＬサーバ３の最後のアクセス番号との差異を算出する（Ｓ１１）。そして、アクセス番号との差異＞規定値であるかどうかチェックする（Ｓ１２）。ここで、ＡＰＬサーバ毎のアクセス番号の差異が規定値をオーバした場合は、アクセスしたＡＰＬサーバ３の負荷が高いと判断する。アクセス番号との差異＞規定値である場合には、出力情報のアクセス結果に“要求実行中止”を設定し、ＡＰＬサーバ３に応答する（Ｓ１４）。
【００５５】
アクセス番号との差異＞規定値でない場合には、入力情報（ＣＰＵ使用率）＞規定値であるかどうかチェックする（Ｓ１３）。ここで、入力情報（ＣＰＵ使用率）が規定値をオーバした場合は、アクセスしたＡＰＬサーバ３
の負荷が高いと判断する。そこで、（ＣＰＵ使用率）＞規定値である場合には、出力情報のアクセス結果に“要求実行中止”を設定し、ＡＰＬサーバ３に応答する（Ｓ１４）。
【００５６】
入力情報（ＣＰＵ使用率）＞規定値でない場合には、要求ＩＤ，（アクセス番号＋１）のアクセス情報にＡＰＬサーバ実行状態（ＡＰＬサーバＩＤ）を追加し（Ｓ１４）、要求ＩＤ，（アクセス番号＋１）のアクセス情報のアクセス結果を出力情報に設定し（Ｓ１５）、ＡＰＬサーバに応答する（Ｓ７）。
【００５７】
ＲＤＢＭＳ部４ｄは、現存するＲＤＢＭＳである。指定したアクセス内容に対してアクセス結果を戻す機能を有する。
図９はアクセス情報を示す図である。要求ＩＤと、アクセス番号と、ＤＢトランザクションＩＤと、アクセス内容と、アクセス結果と、ＡＰＬサーバの実行状態が登録されている。
【００５８】
図１０は本発明の動作概要を示す図である。図２と同一のものは、同一の符号を付して示す。３はＡＰＬサーバであり、ＡＰＬサーバＡとＢの２台を示している。２はフロントサーバである。該フロントサーバ２はＡＰＬサーバＡとＡＰＬサーバＢと接続されている。各ＡＰＬサーバ３において、３ａはアプリケーション部、３ｂはＤＢアクセスメソッド部である。４ｃはＤＢアクセス制御部、４ｄはＲＤＢＭＳ部である。図中の※印は、「ＡＰＬサーバＩＤ、及びサーバ負荷情報を付加してＤＢアクセス制御部に通知する」処理を示している。以下、通知処理と略する。
【００５９】
ユーザ（フロントサーバ）２からＡＰＬサーバＡとＢに業務実行要求がなされる。以下、ＡＰＬサーバＡ側の動作について説明する。ＡＰＬサーバＡでは、ＤＢアクセス制御部４ｃに対して通知処理を行ない、要求実行を開始する（Ｓ１）。そして、ＲＤＢＭＳ部４ｄからＤＢトランザクションを取得する。次にＤＢアクセス制御部４ｃに対して通知処理を行ない、ＤＢ情報（ＳＥＬＥＣＴ）を取得する（Ｓ２）。次に、ＤＢアクセス制御部４ｃに対して通知処理を行ない、ＤＢ情報更新（１）（ＵＰＤＡＴＥ）を行なう（Ｓ３）。
【００６０】
次に、ＤＢアクセス制御部４ｃに対して通知処理を行ない、ＤＢ情報更新（２）（ＵＰＤＡＴＥ）を行なう（Ｓ４）。次に、ＤＢアクセス制御部４ｃに対して通知処理を行ない、ＤＢ確定（ＤＢコミット）を行なう（Ｓ５）。次に、ＤＢアクセス制御部４ｃに対して通知処理を行ない、要求実行終了する（Ｓ６）。この時、ユーザ（フロントサーバ）２に対して要求実行結果を通知し、ＤＢトランザクションを開放する。
【００６１】
次に、ＡＰＬサーバＢ側の動作について説明する。ユーザ（フロントサーバ）２からの業務実行要求がなされると、ＡＰＬサーバＢは、ＤＢアクセス制御部４ｃに通知処理を行ない、ＤＢトランザクションを取得する（Ｓ７）。次に、ＤＢアクセス制御部４ｃに通知処理を行ない、ＤＢ情報（ＳＥＬＥＣＴ）を取得する（Ｓ８）。次に、ＤＢアクセス制御部４ｃに通知処理を行ない、ＤＢ情報更新（１）（ＵＰＤＡＴＥ）を行なう（Ｓ９）。次に、ＤＢアクセス制御部４ｃに通知処理を行ない、ＤＢ情報（２）（ＵＰＤＡＴＥ）を行なう（Ｓ１０）。この時、ＡＰＬサーバＡ側で既に実行処理が終了しているので、ＤＢアクセス制御部４ｃから要求実行完了通知を受け、要求実行を破棄する。
【００６２】
以上、詳細に説明したように、本発明によれば、ＲＤＢＭＳを用いたシステムにおいて、ユーザからの１つの要求を複数のＡＰＬサーバにて同一アプリケーション，同一ロジックで同時実行することで、要求実行中のＡＰＬサーバが故障しても、１台でも正常に要求実行したＡＰＬサーバが存在すれば、サービス無中断（サーバ切替不要）にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のＡＰＬサーバに発生しても、負荷の低い他ＡＰＬサーバが先行してデータベースアクセスを行なうため、ＡＰＬサーバ負荷によるユーザへの応答遅れが軽減できる。
【００６３】
（付記１）
ＲＤＢＭＳを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、ＲＤＢＭＳにアクセスし、その結果をＲＤＢＭＳ内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とするデータベースアクセス方法。
【００６４】
（付記２）
前記ＲＤＢＭＳへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をＲＤＢＭＳを制御するデータベースサーバに配備するようにしたことを特徴とする。
【００６５】
（付記３）
コミット／ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット／ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求ＩＤに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする付記１又は２記載のデータベースアクセス方法。
【００６６】
（付記４）
ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする付記１又は２記載のデータベースアクセス方法。
【００６７】
（付記５）
ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、
該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、
該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、
前記アプリケーションサーバ内にＲＤＢＭＳへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバＩＤをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、
前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをＲＤＢＭＳアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設け、
たことを特徴とするデータベースアクセス装置。
【００６８】
（付記６）
複数のアプリケーションサーバで実行中の同一要求に対する各アプリケーションサーバの実行状況を、各アプリケーションサーバからのデータベースアクセス時に判断して、一定の遅れが発生したアプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すことを特徴とする付記１又は２記載のデータベースアクセス方法。
【００６９】
（付記７）
ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報の要求に加えてサブ要求ＩＤをアプリケーションのロジックで規定し入力情報とすることによって、ユーザの一要求をサブ要求ＩＤとして複数のデータベーストランザクションのアクセス情報を管理し、一要求であっても複数のデータベーストランザクションを取得してユーザからの要求を実行することを特徴とする付記１又は２記載のデータベースアクセス方法。
【００７０】
（付記８）
前記データベースアクセス制御部のインタフェースに業務開始／業務完了を設け、ユーザからの一要求の開始／完了をアプリケーションのロジックによって通知することを特徴とする付記１又は２記載のデータベースアクセス方法。
【図面の簡単な説明】
【００７１】
【図１】本発明の構成説明図である。
【図２】本発明システムの構成例を示すブロック図である。
【図３】ＡＰＬサーバ同時実行制御部の動作を示すフローチャートである。
【図４】フローチャートの説明図である。
【図５】アプリケーション部の動作を示すフローチャートである。
【図６】ＤＢアクセスメソッド部の動作を示すフローチャートである。
【図７】ＤＢアクセス制御部の動作を示すフローチャートである。
【図８】ＤＢアクセス制御部の動作を示すフローチャートである。
【図９】アクセス情報を示す図である。
【図１０】本発明の動作概要を示す図である。
【図１１】従来の分散構成の説明図である。
【図１２】従来のＨＡ構成の説明図である。
【符号の説明】
【００７２】
２    フロントサーバ
２ａ  ユーザ要求
３    ＡＰＬサーバ
３ａ  アプリケーション部
３ｂ  ＤＢアクセスメソッド部
４    ＤＢサーバ
４ａ  データベース
４ｂ  アクセス情報
４ｃ  ＤＢアクセス制御部
４ｄ  ＲＤＢＭＳ部
１０  本発明を具備するシステム
１１  ＡＰＬサーバ同時実行制御部
【図１】
2007264770.tif 000003
【図２】
2007264770.tif 000004
【図３】
2007264770.tif 000005
【図４】
2007264770.tif 000006
【図５】
2007264770.tif 000007
【図６】
2007264770.tif 000008
【図７】
2007264770.tif 000009
【図８】
2007264770.tif 000010
【図９】
2007264770.tif 000011
【図１０】
2007264770.tif 000012
【図１１】
2007264770.tif 000013
【図１２】
2007264770.tif 000014