(57)【要約】【課題】リソースに制約がある装置においてもトランザクションを迅速に処理する。【解決手段】データを管理するデータベースを備えたデータベース管理装置において、データの更新を含むトランザクションを実行する場合に、トランザクションを実行するために割り当てられたリソースをトランザクションの完了後に解放する第１のトランザクション決着方式、又は割り当てられたリソースをトランザクションの完了後に保持する第２のトランザクション決着方式のいずれか一方を実行し、データの更新を含むトランザクションの実行要求を受け付けた場合には、データベースの実行状態に基づいて、第１のトランザクション決着方式又は第２のトランザクション決着方式を選択し、選択されたトランザクション決着方式に基づいて、トランザクションを実行する。【選択図】図１
2010198581.tif 000002
【特許請求の範囲】
【請求項１】
記憶部を備え、データを管理するデータベースを有するデータベース管理装置におけるデータベース管理方法であって、
前記データベース管理装置は
前記記憶部に前記データベースの実行状態を記録するデータベース実行情報を格納し、
前記データの更新を含むトランザクションを実行する場合は、前記トランザクションを実行するために割り当てられたリソースを前記トランザクションの完了後に解放する第１のトランザクション決着方式、又は前記割り当てられたリソースを前記トランザクションの完了後も保持する第２のトランザクション決着方式のいずれか一方を実行し、
前記データの更新を含むトランザクションの実行要求を受け付けた場合は、前記データベースの実行状態に基づいて、前記第１のトランザクション決着方式又は前記第２のトランザクション決着方式を選択し、
前記選択されたトランザクション決着方式に基づいて、前記トランザクションを実行することを特徴とするデータベース管理方法。
【請求項２】
前記データベースの実行状態には、前記データベース管理装置によって提供されるリソースの使用量が含まれ、
前記リソースの使用量が所定の閾値よりも大きい場合は、前記第１のトランザクション決着方式を選択することを特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記データベースの実行状態には、前記データベースに要求されたトランザクションに含まれるＳＱＬコマンドの実行状態が含まれ、
前記ＳＱＬコマンドの実行状態に基づいて、前記実行要求が受け付けられたトランザクションに含まれるＳＱＬコマンドが再実行される否かを判定し、
前記実行要求が受け付けられたトランザクションに含まれるＳＱＬコマンドが再実行される可能性が高いと判定された場合には、前記第２のトランザクション決着方式を選択することを特徴とする請求項１に記載のデータベース管理方法。
【請求項４】
前記ＳＱＬコマンドの実行状態には、前記ＳＱＬコマンドの実行回数が含まれ、
前記方法は、前記ＳＱＬコマンドの実行回数が所定の閾値よりも大きい場合は、前記ＳＱＬコマンドが再実行される可能性が高いと判定することを特徴とする請求項３に記載のデータベース管理方法。
【請求項５】
前記ＳＱＬコマンドの実行状態には、前記ＳＱＬコマンドが最後に実行された時刻が含まれ、
前記ＳＱＬコマンドが最後に実行されてから経過した時間が所定の時間よりも少ない場合は、前記ＳＱＬコマンドが再実行される可能性が高いと判定することを特徴とする請求項３に記載のデータベース管理方法。
【請求項６】
前記トランザクション決着方式の指定を受け付け、
前記指定されたトランザクション決着方式を選択してトランザクションを実行することを特徴とする請求項１に記載のデータベース管理方法。
【請求項７】
前記データベースの実行状態に基づいて、前記第１のトランザクション決着方式が選択される場合は、前記指定されたトランザクション決着方式によらず、前記第１のトランザクション決着方式を選択することを特徴とする請求項６に記載のデータベース管理方法。
【請求項８】
プロセッサ及び記憶部を備え、データを管理するデータベースを有するデータベース管理装置であって、
前記記憶部には、前記データベースの実行状態を記録するデータベース実行情報が格納され、
前記プロセッサは、
前記データの更新を含むトランザクションを実行する場合には、前記トランザクションを実行するために割り当てられたリソースを前記トランザクションの完了後に解放する第１のトランザクション決着方式、又は前記割り当てられたリソースを前記トランザクションの完了後も保持する第２のトランザクション決着方式のいずれか一方を実行し、
前記データの更新を含むトランザクションの実行要求を受け付けた場合には、前記データベースの実行状態に基づいて、前記第１のトランザクション決着方式又は前記第２のトランザクション決着方式を選択し、
前記選択されたトランザクション決着方式に基づいて、前記トランザクションを実行することを特徴とするデータベース管理装置。
【請求項９】
プロセッサ及び記憶部を備え、データを管理するデータベースを有するデータベース管理装置に実行させるデータベース管理プログラムであって、
前記記憶部には、前記データベースの実行状態を記録するデータベース実行情報が格納され、
前記プログラムは、
前記データの更新を含むトランザクションを実行する場合には、前記トランザクションを実行するために割り当てられたリソースを前記トランザクションの完了後に解放する第１のトランザクション決着方式、又は前記割り当てられたリソースを前記トランザクションの完了後も保持する第２のトランザクション決着方式のいずれか一方を実行する手順と、
前記データの更新を含むトランザクションの実行要求を受け付けた場合には、前記データベースの実行状態に基づいて、前記第１のトランザクション決着方式又は前記第２のトランザクション決着方式を選択する手順と、
前記選択されたトランザクション決着方式に基づいて、前記トランザクションを実行する手順と、を含むことを特徴とするデータベース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースにおいてトランザクションを決着させる技術に関する。
【背景技術】
【０００２】
ＳＱＬは、データベースによって管理されているデータを操作するために利用される言語である。また、データベースに格納されたデータを操作する際に、関連する複数の処理（ＳＱＬコマンド）を一つの処理単位としてまとめて実行する場合がある。関連する複数のＳＱＬがまとめられたものをトランザクションという。トランザクションの決着とは、トランザクションに含まれるすべての処理を確定させることである。
【０００３】
ＳＱＬは、トランザクションを決着させる機能として「ＣＯＭＭＩＴ」及び「ＲＯＬＬＢＡＣＫ」を有している。「ＣＯＭＭＩＴ」は、データベースの更新反映などを行うことによってトランザクションを決着させる機能である。また、「ＲＯＬＬＢＡＣＫ」は、データベースの更新反映を取り消し、データベースをトランザクション開始時点の状態に戻す機能である。
【０００４】
また、データベースの更新反映を頻繁に行う場合に、トランザクションを処理する時間を短縮するための技術が提案されている。例えば、カーソルを用いた検索の途中に「ＣＯＭＭＩＴ」が行われた場合にも、カーソルを保持するホールダブルカーソル機能である。さらに、同様の機能としてセーブポイント機能が提案されている。これは、トランザクション中にチェックポイントを取得する機能であり、各チェックポイントまでの間が擬似的なトランザクションになる機能である。
【０００５】
さらに、処理に必要なデータをメモリに一括して読み出すなどして、データベースの更新に必要な時間を短縮する技術が提案されていた（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平６−３３２７７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ホールダブルカーソル機能では、データベースへの更新反映が頻繁な処理を実行する場合には、トランザクション決着処理で割り当てられたリソースが解放されないように指定する。
【０００８】
ホールダブルカーソルは、ユーザが指定する機能であり、データベースの更新を必要とする他のＳＱＬが実行される可能性があれば、必要でない場合にも指定される場合がある。また、ホールダブルカーソルのセクションは、セッションが切断されるまで保存されるため、リソースの消費が大きくなる。したがって、ＣＰＵ又はメモリなどのリソースに制約がある装置ではホールダブルカーソルを利用しにくいという問題が生じる。
【０００９】
本発明は、このような問題を鑑みてなされたものであり、リソースの消費を抑えながら、トランザクションを処理する時間を短縮することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一形態によれば、プロセッサ及び記憶部を備え、データを管理するデータベースを有するデータベース管理装置におけるデータベース管理方法であって、前記記憶部には、前記データベースの実行状態を記録するデータベース実行情報が格納され、前記方法は、前記データの更新を含むトランザクションを実行する場合には、前記プロセッサが、前記トランザクションを実行するために割り当てられたリソースを前記トランザクションの完了後に解放する第１のトランザクション決着方式又は前記割り当てられたリソースを前記トランザクションの完了後も保持する第２のトランザクション決着方式のいずれか一方を実行し、前記データの更新を含むトランザクションの実行要求を受け付けた場合には、前記プロセッサが、前記データベースの実行状態に基づいて、前記第１のトランザクション決着方式又は前記第２のトランザクション決着方式を選択し、前記プロセッサが、前記選択されたトランザクション決着方式に基づいて、前記トランザクションを実行する。
【発明の効果】
【００１１】
本発明の代表的な一形態によれば、データベースの実行状態に基づいて、トランザクション決着方式を選択してトランザクションを決着させることによって、リソースの消費を抑えながらトランザクションを処理する時間を短縮することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施の形態のデータベース管理装置の構成を示すブロック図である。
【図２】本発明の第１の実施の形態のデータベース管理装置における処理の概要を説明するフローチャートである。
【図３】本発明の第１の実施の形態のＣＯＭＭＩＴ選択処理の手順を示すフローチャートである。
【図４】本発明の第１の実施の形態のリソースの使用状態を判定する処理の手順を示すフローチャートである。
【図５】本発明の第１の実施の形態のＳＱＬが再利用される可能性が高いか否かを判定する処理の手順を示すフローチャートである。
【図６】本発明の第１の実施の形態のアプリケーションからの要求をＤＢＭＳが処理する手順の一例を示す図である。
【図７】本発明の第１の実施の形態のリソースモニタテーブルの一例を示す図である。
【図８】本発明の第１の実施の形態のＳＱＬ予測管理テーブルの一例を示す図である。
【図９】本発明の第２の実施の形態のＣＯＭＭＩＴ選択処理の手順を示すフローチャートである。
【図１０】本発明の第２の実施の形態のアプリケーションから要求されたＳＱＬをＤＢＭＳによって処理する手順を説明する図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態を図面に基づいて詳細に説明する。
【００１４】
（第１の実施の形態）
図１は、本発明の第１の実施の形態のデータベース管理装置の構成を示すブロック図である。
【００１５】
本発明の第１の実施の形態のデータベース管理装置１１０は、ＣＰＵ１１１、メモリ１１２、外部記憶装置１０３〜１０５、表示装置１０２及び入出力装置１０１を備える。
【００１６】
ＣＰＵ１１１は、メモリ１１２に記憶されたプログラムを実行することによって、要求された処理を実行する。
【００１７】
メモリ１１２は、ＣＰＵ１１１によって実行されるプログラム及び当該プログラムの実行に必要なデータを記憶する。具体的には、メモリ１１２には、ＤＢＭＳ１２０、セクション１２４、リソース１２３及びプログラム実行環境部１２１が記憶される。
【００１８】
外部記憶装置１０３〜１０５は、例えば、磁気ディスク装置などである。外部記憶装置１０３〜１０５は、半導体記憶装置であってもよい。外部記憶装置１０３〜１０５には、ＤＢＭＳ１２０によって管理されるデータベースなどが格納される。具体的には、外部記憶装置１０４にはデータベースが格納される。また、外部記憶装置１０５にはディクショナリが格納される。さらに、外部記憶装置１０３には、ＤＢＭＳ１２０及びプログラム実行環境部１２１を実現するための処理プログラムが格納される。
【００１９】
ＤＢＭＳ１２０は、ＳＱＬ処理部１３０、ＣＯＭＭＩＴ処理部１３１、プログラム実行制御部１３４、リソース制御部１３２、ＳＱＬ予測処理部１３３、データベースアクセス部１３５、ディクショナリアクセス部１３６、リソースモニタテーブル１３８及びＳＱＬ予測管理テーブル１３９を含む。
【００２０】
プログラム実行制御部１３４は、入出力装置１０１を介して受信したコマンドを受け付ける。受信したコマンドにはデータの更新要求が含まれる。また、プログラム実行制御部１３４は、受信したコマンドに基づいて、プログラム実行環境部１２１を起動する。プログラム実行環境部１２１は、受信したコマンドに基づいて、実行するアプリケーション（ＡＰ）を決定し、決定されたＡＰ１２２を実行する。ＡＰ１２２は、ＳＱＬ処理部１３０に受信したコマンドを処理するためのＳＱＬの実行を要求する。なお、ＳＱＬの実行とは、ＳＱＬによって記述されたコマンドを実行することである。
【００２１】
ＳＱＬ処理部１３０は、要求されたＳＱＬを実行するために、まず、前処理を実行する。ＳＱＬの前処理では、要求されたＳＱＬを解析し、ディクショナリアクセス部１３６を介して外部記憶装置１０５に格納されたディクショナリから必要な情報を取得する。このとき、リソース制御部１３２によって必要に応じてリソース１２３を割り当て、リソースモニタテーブル１３８に記録する。さらに、ＳＱＬ予測処理部１３３によって実行されるＳＱＬに関する情報をＳＱＬ予測管理テーブル１３９に記録する。
【００２２】
ＳＱＬ処理部１３０は、さらに、セクション１２４を構成し、構成されたセクション１２４を利用して要求されたＳＱＬに基づく処理を実行する。このとき、データベースアクセス部１３５によって、外部記憶装置１０４に格納されたデータベースにアクセスし、データを取得したり、更新したりする。
【００２３】
リソース制御部１３２は、リソースを確保又は解放し、リソースに関する情報をリソースモニタテーブル１３８に登録する。リソースモニタテーブル１３８の詳細については、図７にて詳細を説明する。なお、リソース１２３は、図１ではメモリ１１２に含まれているが、符号を付さない「リソース」にはＣＰＵ１１１の利用率などメモリ１１２に関連するリソース以外も含むものとする。
【００２４】
ＳＱＬ予測処理部１３３は、ＳＱＬの実行に関する情報をＳＱＬ予測管理テーブル１３９に登録する。ＳＱＬ予測管理テーブル１３９の詳細については、図８にて詳細を説明する。
【００２５】
ＳＱＬ処理部１３０は、ＳＱＬの実行が完了すると、ＡＰ１２２に実行結果を送信する。ＡＰ１２２は、続いて、ＣＯＭＭＩＴ処理部１３１にトランザクションの決着を要求する。ＣＯＭＭＩＴ処理部１３１は、トランザクションの決着方式を決定し、決定した決着方式に基づいて、トランザクションを決着させる。
【００２６】
トランザクションとは、前述のように、関連する複数の処理（ＳＱＬ）を一つの処理単位としてまとめたものである。例えば、金融機関の入出金処理のように、入金処理と出金処理は必ず両方実行されなければならない。このような場合には、入金処理及び出金処理を含む一つのトランザクションとして処理される。したがって、トランザクションの結果は、トランザクションに含まれる処理がすべて成功するか失敗するかのいずれかであって、一部の処理のみが成功するということはない。
【００２７】
また、トランザクションの決着とは、トランザクションに含まれるすべての処理を確定させることである。具体的には、トランザクションの決着には、各処理の実行結果をデータベースに反映させる「ＣＯＭＭＩＴ」と、各処理の実行結果をキャンセルし、データベースに結果を一切反映しない「ＲＯＬＬＢＡＣＫ」とがある。
【００２８】
一般的に、トランザクションの決着方式が「ＣＯＭＭＩＴ」であっても「ＲＯＬＬＢＡＣＫ」であっても、トランザクションが決着した場合には、当該トランザクションに含まれる各処理（ＳＱＬ）を実行するために割り当てられたリソースが解放される。本発明の第１の実施の形態のＣＯＭＭＩＴ処理部１３１は、トランザクションに含まれるすべての処理の実行が成功し、トランザクション決着方式として「ＣＯＭＭＩＴ」が選択される場合に、リソースを解放せずに保持する「ＣＯＭＭＩＴ  ＨＯＬＤ」を新たに選択することができる。
【００２９】
本発明の第１の実施の形態では、リソースモニタテーブル１３８及びＳＱＬ予測管理テーブル１３９に記録された情報に基づいて、トランザクションの決着方式を選択することによって、トランザクションを決着させるまでに必要な時間を短縮させることができる。トランザクションの決着方式を選択するための具体的な処理などは、詳細を後述する。
【００３０】
トランザクションの決着は、ＣＯＭＭＩＴ処理部１３１などによって行われる。なお、本発明の第１の実施の形態では、トランザクションの決着方式として「ＲＯＬＬＢＡＣＫ」を選択する場合については、特に言及しない。「ＲＯＬＬＢＡＣＫ」を選択する場合は、トランザクションの実行がキャンセルされる場合であるため、従来の方法と同様に処理すればよい。
【００３１】
図２は、本発明の第１の実施の形態のデータベース管理装置１１０における処理の概要を説明するフローチャートである。
【００３２】
本処理は、ＡＰ１２２によってＳＱＬが発行された場合、及びＡＰ１２２によってトランザクションの決着が指示された場合の処理を示している。
【００３３】
ステップ２０１〜２０５の処理は、ＡＰ１２２による処理である。ステップ２１０〜２１４の処理は、ＳＱＬ処理部１３０による処理である。
【００３４】
ステップ２２０〜２２５の処理は、ＣＯＭＭＩＴ処理部１３１による処理である。なお、ステップ２２３の「ＣＯＭＭＩＴ」処理は、従来のトランザクション決着方式であって、データベースに更新を反映し、リソースの解放及びセクションの解放などを行う処理である。一方、ステップ２２４の「ＨＯＬＤ」処理は、データベースに更新を反映し、リソースの解放及びセクションの解放などを行わない処理である。
【００３５】
ステップ２３０の処理は、リソース制御部１３２による処理である。ステップ２３１及び２３２の処理は、リソース制御部１３２による処理である。ステップ２４０及び２４１の処理は、ＳＱＬ予測処理部１３３による処理である。
【００３６】
ＣＰＵ１１１は、入出力装置１０１を介してＡＰ１２２の実行要求を受け付ける。そして、ＡＰ１２２を実行し、ＳＱＬを発行するか否かを判定する（ステップ２０２）。ＳＱＬを発行する場合には（ステップ２０２の結果が「ＹＥＳ」）、ＳＱＬ処理部１３０を処理することによって、ＳＱＬ制御処理２１０を実行する。
【００３７】
ＣＰＵ１１１は、ＳＱＬ制御処理２１０が実行されると、まず、受け付けられたＳＱＬに対応するセクション１２４が登録されているか否かを判定する（ステップ２１１）。対応するセクション１２４が登録されている場合には（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を実行せずに、ＳＱＬを実行することができる（ステップ２１３）。
【００３８】
一方、ＣＰＵ１１１は、対応するセクションが登録されていない場合には（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理を実行する（ステップ２１２）。ＳＱＬ前処理は、リソース制御部１３２及びＳＱＬ予測処理部１３３と連携して実行される。
【００３９】
ＣＰＵ１１１は、リソース制御部１３２を実行することによって、リソースの確保及び解放を制御し、リソースに関する情報をリソースモニタに通知する。リソースモニタは、通知されたリソースに関する情報をリソースモニタテーブル１３８に登録する（ステップ２３１）。
【００４０】
さらに、ＣＰＵ１１１は、ＳＱＬ予測処理部１３３を処理することによって、ＳＱＬ予測管理処理２４０を実行する。ＳＱＬ予測管理処理２４０では、ＳＱＬ前処理（ステップ２１２）によって通知された情報をＳＱＬ予測管理テーブル１３９に登録する。
【００４１】
ＣＰＵ１１１は、ＳＱＬ前処理が完了すると、ＳＱＬを実行する（ステップ２１３）。さらに、リソース制御処理２３０及びＳＱＬ予測管理処理２４０を実行する。前述のように、リソース制御処理２３０では、リソースの確保及び解放を制御し、リソースに関する情報をリソースモニタに通知する。リソースモニタは、通知されたリソースに関する情報をリソースモニタテーブル１３８に登録する（ステップ２３１）。ＳＱＬ予測管理処理２４０では、ステップ２１３のＳＱＬ実行の処理によって通知されたＳＱＬの実行情報をＳＱＬ予測管理テーブル１３９に登録する。
【００４２】
ＣＰＵ１１１は、ＳＱＬの実行が完了すると、ＳＱＬ制御処理２１０を終了する（ステップ２１４）。ＳＱＬ制御処理２１０の終了時には、後処理を実行し、ＡＰ１２２に制御を戻す。
【００４３】
ＣＰＵ１１１は、ステップ２０２の処理で発行されたＳＱＬが処理され、ＡＰ１２２に制御が戻ると、ＣＯＭＭＩＴを発行するか否かを判定する（ステップ２０３）。ＣＯＭＭＩＴを発行する場合には（ステップ２０３の結果が「ＹＥＳ」）、ＣＯＭＭＩＴ制御処理２２０の実行を要求する。なお、前述したように、ＲＯＬＬＢＡＣＫする場合については、処理を省略している。
【００４４】
ＣＰＵ１１１は、ＣＯＭＭＩＴ処理部１３１が処理され、ＣＯＭＭＩＴ制御処理２２０が開始されると、トランザクションの決着方式を決定するためのＣＯＭＭＩＴ選択処理を実行する（ステップ２２１）。ＣＯＭＭＩＴ選択処理は、リソースモニタテーブル１３８及びＳＱＬ予測管理テーブル１３９に記録された情報に基づいて、トランザクションの決着方式を決定する。
【００４５】
次に、ＣＰＵ１１１は、決定したトランザクションの決着方式を判定する（ステップ２２２）。決定したトランザクションの決着方式が「ＣＯＭＭＩＴ」の場合には（ステップ２２２の結果が「ＣＯＭＭＩＴ」）、データベースに更新を反映し、リソースの解放及びセクションの解放などを実行する。トランザクションの決着方式に「ＣＯＭＭＩＴ」が選択された場合は、従来のトランザクションの決着と同じである。
【００４６】
一方、ＣＰＵ１１１は、決定したトランザクションの決着方式に「ＨＯＬＤ」が選択された場合には（ステップ２２２の結果が「ＨＯＬＤ」）、データベースに対する更新反映のみを行うことによって、トランザクションを決着させる。こうすることによって、構成されたセクション１２４が保持され、再利用されることによって、後に実行されるＳＱＬを処理するために必要な時間を短縮させることができる。
【００４７】
ＣＰＵ１１１は、トランザクションの決着が完了すると、後処理を実行し、ＣＯＭＭＩＴ制御処理２２０を終了する（ステップ２２５）。その後、ＡＰ１２２に制御を戻す。
【００４８】
ＣＰＵ１１１は、ステップ２０３の処理で発行されたコミット要求が処理され、ＡＰ１２２に制御が戻ると、ＡＰ１２２のプログラムの実行を終了するか否かを判定する（ステップ２０４）。プログラムを終了する場合には（ステップ２０４の結果が「ＹＥＳ」）、本処理を終了する（ステップ２０５）。プログラムを終了せずに処理を継続する場合には（ステップ２０４の結果が「ＮＯ」）、ステップ２０２の処理に戻る。
【００４９】
以上のように、ステップ２２１のＣＯＭＭＩＴ選択処理において、リソースモニタテーブル１３８及びＳＱＬ予測管理テーブル１３９に基づいて、トランザクション決着処理を決定することによって、データベースの実行状態に応じたトランザクション決着方式を選択し、トランザクション決着時間を短縮することができる。
【００５０】
図３は、本発明の第１の実施の形態のＣＯＭＭＩＴ選択処理の手順を示すフローチャートである。
【００５１】
ＣＰＵ１１１は、ＡＰ１２２からＣＯＭＭＩＴの要求を受け付けると、ＣＯＭＭＩＴ処理部１３１を実行し、ＣＯＭＭＩＴ選択処理を実行する（図２のステップ２２１）。
【００５２】
ＣＰＵ１１１は、まず、リソースモニタテーブル１３８からリソースに関する情報を取得する（ステップ３０２）。さらに、取得されたリソースに関する情報に基づいて、リソースの使用状態を判定する（ステップ３０３）。リソースの使用状態の判定では、データベース管理装置１１０のリソースを解放する必要があるか否かを判定する。なお、リソースを解放する必要があるか否かを判定する処理は、図４にて詳細を説明する。
【００５３】
ＣＰＵ１１１は、リソースを解放する必要があると判定した場合には（ステップ３０２の結果が「ＹＥＳ」）、トランクションの決着方式として「ＣＯＭＭＩＴ」を選択し（ステップ３０７）、割り当てられていたリソースを解放させる。
【００５４】
一方、ＣＰＵ１１１は、リソースの残量が十分であり、リソースを解放する必要がない場合には（ステップ３０３の結果が「ＮＯ」）、実行されるＳＱＬに対応する情報をＳＱＬ予測管理テーブル１３９から取得する（ステップ３０４）。さらに、取得されたＳＱＬに対応する情報に基づいて、実行対象のＳＱＬが後の処理で再利用される可能性が高いか否かを判定する（ステップ３０５）。なお、ＳＱＬが再利用される可能性が高いか否かを判定する処理は、図５にて詳細を説明する。
【００５５】
ＣＰＵ１１１は、ＳＱＬが再利用される可能性が高くないと判定した場合には（ステップ３０５の結果が「ＮＯ」）、トランクション決着方式として「ＣＯＭＭＩＴ」を選択し（ステップ３０７）、割り当てられていたリソースを解放する。再利用する可能性が高くないＳＱＬのためにリソースを保持し続けることによって、リソースが消費されることを防ぐためである。
【００５６】
一方、ＣＰＵ１１１は、ＳＱＬが再利用される可能性が高いと判定した場合には（ステップ３０５の結果が「ＹＥＳ」）、トランクション決着方式として「ＨＯＬＤ」を選択し（ステップ３０６）、要求されたＳＱＬを実行するために割り当てられたリソースを保持し続ける。
【００５７】
ＣＰＵ１１１は、トランザクション決着方式を決定すると、ＣＯＭＭＩＴ選択処理を終了する。以上のように、リソースモニタテーブル１３８及びＳＱＬ予測管理テーブル１３９に記録された情報に基づいて、リソースの使用状態とＳＱＬの使用状態に応じたトランザクション決着方式を選択することができる。すなわち、リソースの残量が十分であり、ＳＱＬを再利用する可能性が高い場合には、リソースを解放せずに保持し続けることによって、前処理の実行を省略し、トランザクション決着時間を短縮することができる。
【００５８】
図４は、本発明の第１の実施の形態のリソースの使用状態を判定する処理の手順を示すフローチャートである。本処理は、ＣＯＭＭＩＴ選択処理のステップ３０３の処理に対応する。
【００５９】
ＣＰＵ１１１は、まず、リソースモニタテーブル１３８の最初のレコードを取得し、対応するリソースを判定対象とする（ステップ４０２）。
【００６０】
次に、ＣＰＵ１１１は、判定対象のリソースの残量が不足しているか否かを判定する（ステップ４０３）。判定対象のリソースの残量が不足している場合（ステップ４０３の結果が「ＹＥＳ」）、例えば、判定対象のリソースの残量が所定の閾値よりも少ない場合には、リソースの解放が必要と判定する（ステップ４０７）。
【００６１】
一方、ＣＰＵ１１１は、判定対象のリソースの残量が不足していない場合には（ステップ４０３の結果が「ＮＯ」）、リソースモニタテーブル１３８に次のリソースが存在するか否かを判定する（ステップ４０４）。
【００６２】
ＣＰＵ１１１は、次のリソースが存在しない場合には（ステップ４０４の結果が「ＮＯ」）、すべてのリソースで設定された残量が不足していないと判定し、リソースの解放は不要であると判定する（ステップ４０６）。
【００６３】
ＣＰＵ１１１は、次のリソースが存在する場合には（ステップ４０４の結果が「ＹＥＳ」）、リソースモニタテーブル１３８から次のレコードに対応するリソースに関する情報を取得し（ステップ４０５）、当該リソースの残量が不足しているか否かを判定する（ステップ４０３）。このようにして、リソースモニタテーブル１３８に含まれるすべてのリソースについて残量を判定する。
【００６４】
なお、本発明の第１の実施の形態では、リソースの残量が不足しているか否かを判定する基準の値（所定の閾値）は、あらかじめ、図７にて後述するように、リソースモニタテーブル１３８に登録しておく。なお、閾値は、データベース管理装置１１０のリソース全体の量に基づいて決定される値としてもよい。このように、リソースの使用状態に応じてトランザクションの決着方式を選択することによって、リソースの制約のある装置において、リソースを不足させることなくトランザクションの決着時間を短縮することが可能となる。
【００６５】
図５は、本発明の第１の実施の形態のＳＱＬが再利用される可能性が高いか否かを判定する処理の手順を示すフローチャートである。本処理は、ＣＯＭＭＩＴ選択処理のステップ３０５の処理に対応する。
【００６６】
ＣＰＵ１１１は、まず、ＳＱＬ予測管理テーブル１３９の最初のレコードに対応するセクションを判定対象とする（ステップ５０２）。
【００６７】
次に、ＣＰＵ１１１は、判定対象のセクションの利用回数が多いか否かを判定する（ステップ５０３）。利用回数が多い場合には（ステップ５０３の結果が「ＹＥＳ」）、再利用の可能性が高いと判定する（ステップ５０８）。利用回数が多いか否かを判定するためには、例えば、あらかじめ設定された閾値と比較する。閾値は、管理者によって入力されたものであってもよいし、リソースの使用状態に応じて変化するものであってもよい。
【００６８】
ＣＰＵ１１１は、利用回数が少ない場合には（ステップ５０３の結果が「ＮＯ」）、さらに、当該セクションを最近利用したか否かを判定する（ステップ５０４）。セクションを最近利用したか否かは、最終利用時刻からの経過時間に基づいて判定される。セクションを最近利用したか否かの判定についても、例えば、あらかじめ設定された閾値と最終利用時刻からの経過時間とを比較する。この場合の閾値についても、利用回数と同様に、管理者によって入力されたものであってもよいし、リソースの残量が多い場合には閾値を大きくするなど、リソースの使用状態に応じて変化するものであってもよい。なお、ＳＱＬ予測管理テーブル１３９にＳＱＬの実行情報を記録するタイミングによっては、直前に実行されたＳＱＬについては、判定対象から除くようにしてもよい。
【００６９】
ＣＰＵ１１１は、当該セクションを最近利用したと判定した場合には（ステップ５０４の結果が「ＹＥＳ」）、再利用の可能性が高いと判定する（ステップ５０８）。
【００７０】
ＣＰＵ１１１は、当該セクションを最近利用していないと判定した場合には（ステップ５０４の結果が「ＮＯ」）、ＳＱＬ予測管理テーブル１３９に次のレコードが存在するか否かを判定する（ステップ５０５）。
【００７１】
ＣＰＵ１１１は、ＳＱＬ予測管理テーブル１３９に判定対象のレコードの次のレコードが存在しない場合には（ステップ５０５の結果が「ＮＯ」）、ここまでの処理で再利用の可能性が高いと判定されなかったため、再利用の可能性は低いと判定する（ステップ５０７）。
【００７２】
ＣＰＵ１１１は、判定対象のレコードの次のレコードがＳＱＬ予測管理テーブル１３９に存在する場合には（ステップ５０５の結果が「ＹＥＳ」）、ＳＱＬ予測管理テーブル１３９の次のレコードに対応するセクションを判定対象とし、ステップ５０３の処理を実行する。以降、ＳＱＬ予測管理テーブル１３９に登録されているすべてのセクションについて処理を繰り返す。
【００７３】
本発明の第１の実施の形態では、ＳＱＬが再利用される可能性について、当該ＳＱＬの実行回数及び最終実行時刻に基づいて判定していたが、その他の基準で判定してもよい。例えば、実行回数と最終実行時刻を組み合わせた基準であってもよいし、所定の期間内の実行回数であってもよい。
【００７４】
ＳＱＬ予測管理テーブル１３９には、図８にて後述するように、実行されたＳＱＬを処理するために利用された各セクションの利用回数及び最終利用時刻などの情報が登録されている。ＳＱＬの再利用可能性に基づいてトランザクション決着方式を選択することによって、リソースの解放及び保持を効率的に切り替えて、リソースの利用効率を向上させながらトランザクション決着時間を短縮させることができる。
【００７５】
以下、本発明の第１の実施の形態について、ＡＰ（アプリケーション）１２２及びＤＢＭＳ１２０における処理を具体例を示しながらさらに説明する。
【００７６】
図６は、本発明の第１の実施の形態のＡＰ１２２からの要求をＤＢＭＳ１２０が処理する手順の一例を示す図である。
【００７７】
図６左段には、ＡＰ１２２によって発行されたコマンド６０１〜６１７が時系列順に示されている。図６中段には、ＤＢＭＳ１２０によって処理されるコマンド６２１〜６３７が示されている。図６右段には、ＤＢＭＳで実際に実行される処理の説明６４１〜６５７が示されている。
【００７８】
ここで、図６に示した処理を図１〜図５を参照しながら説明する。なお、各処理の実行主体は、すべてＣＰＵ１１１となるが、ＣＰＵ１１１によって実行されるＡＰ１２２及びＤＢＭＳ１２０を各処理の主体として説明する。
【００７９】
ＡＰ１２２は、まず、ＤＢＭＳ１２０にＳＱＬ１（６０１）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ１（６０１）がＳＱＬ処理部１３０に通知されると（６２１）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ１（６０１）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。ＳＱＬ１（６０１）はＡＰ１２２が実行されてから最初に発行されたＳＱＬであるため、当該ＳＱＬに対応するセクション１２４が登録されておらず（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理が実行される（ステップ２１２、６４１）。ＳＱＬ処理部１３０は、ＳＱＬ前処理が完了すると、ＳＱＬ１（６０１）を実行する（ステップ２１３）。
【００８０】
ＳＱＬ前処理では、まず、要求されたＳＱＬを解析し、解析結果に基づいて外部記憶装置１０５に格納されたディクショナリから必要な情報を取得する。さらに、ディクショナリから取得された情報との整合性を確認する処理などが実行される。また、ＳＱＬ前処理では、必要に応じてリソース制御部１３２によってＳＱＬの実行に必要なリソースを割り当てる。
【００８１】
リソース制御処理２３０では、ＳＱＬの実行に必要なリソースを割り当てるとともに、割り当てたリソースに関する情報をリソースモニタに通知する（ステップ２３１）。リソースモニタでは、通知されたリソース１２３に関する情報をリソースモニタテーブル１３８に登録する。
【００８２】
ＳＱＬの実行処理では、ＳＱＬの前処理結果に基づいてＳＱＬを実行する。ＳＱＬの実行処理では、必要に応じてリソース制御部１３２によって、リソースを割り当てる。また、ＳＱＬを実行するために構成されたセクションに関する情報などをＳＱＬ予測処理部１３３に通知する。ＳＱＬ予測処理部１３３は、ＳＱＬ予測管理処理２４０を実行し、通知された情報をＳＱＬ予測管理テーブル１３９に登録する。
【００８３】
ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【００８４】
次に、ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ６０２を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ６０２がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、最初に、ＣＯＭＭＩＴ選択処理が実行される（ステップ２２１）。
【００８５】
ＣＯＭＭＩＴ選択処理では、まず、リソースモニタテーブル１３８から情報を取得する（ステップ３０２）。続いて、リソースモニタテーブル１３８から取得された情報に基づいて、リソースの使用状態を判定する処理を実行する（ステップ３０３）。リソースの使用状態を判定する処理では、図４にて説明したように、まず、リソースモニタテーブル１３８の最初のレコードに対応するリソースを判定対象とし、リソースの残量を判定する（ステップ４０３）。この時点では、ＳＱＬ１（６０１）のみが実行された状態であるため、リソースの残量が十分にあると判定される。
【００８６】
続いて、ＤＢＭＳ１２０は、判定対象となる次のリソースが存在するか否かを判定し（ステップ４０４）、次のリソースが存在する場合には、リソースモニタテーブル１３８から次のレコードに対応するリソースを判定対象とし、リソースの残量を判定する（ステップ４０４）。以降、リソースモニタテーブル１３８に登録されたレコードに対応するすべてのリソースに対して残量の判定を繰り返す。前述のように、この時点では、ＳＱＬ１（６０１）のみが実行された状態であるため、すべてのリソースで残量が十分であると判定され、リソース使用状態判定処理の結果を「解放不要」と判定する（ステップ４０６）。
【００８７】
続いて、ＣＯＭＭＩＴ選択処理では、実行されたＳＱＬの再利用可能性について判定する。具体的には、まず、ＳＱＬ予測管理テーブル１３９から実行されたＳＱＬに関する情報を取得する（ステップ３０４）。そして、取得されたＳＱＬの実行情報に基づいて、ＳＱＬ再利用可能性判定処理を実行する（ステップ３０５）。
【００８８】
ＳＱＬ再利用可能性判定処理では、まず、ＳＱＬ予測管理テーブル１３９の最初のレコードに対応するセクションを判定対象とする（ステップ５０２）。そして、ＳＱＬ予測管理テーブル１３９に含まれる各セクションの利用回数を判定する（ステップ５０３）。利用回数が多い場合には、再利用の可能性が大きいと判定する（ステップ５０８）。この時点では、利用回数は１であるため、利用回数が少ないと判定される。
【００８９】
ＤＢＭＳ１２０は、当該セクションの利用回数が少ない場合には、最終利用時刻に基づいてＳＱＬが最近利用されたか否かを判定する（ステップ５０４）。このとき、当該セクションを直前に利用しているため、最近利用していると判定し、ＳＱＬ再利用可能性判定処理の結果を「再利用の可能性が高い」とする（ステップ５０８）。
【００９０】
以上より、ＤＢＭＳ１２０は、当該ＳＱＬの再利用の可能性が高いと判定し（ステップ３０５の結果が「Ｙｅｓ」）、トランザクション決着方式として「ＨＯＬＤ」を選択する（ステップ３０６）。ＤＢＭＳ１２０は、トランザクション決着方式として「ＨＯＬＤ」が選択されたため（ステップ２２２の結果が「ＨＯＬＤ」）、ＣＯＭＭＩＴ  ＨＯＬＤを実行することによって（６２２）、データの更新のみを行ってリソースを解放せずにトランザクションを決着させる（ステップ２２４、６４２）。その後、ＣＯＭＭＩＴ制御処理を終了し、ＡＰ１２２に制御を戻す。
【００９１】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ２（６０３）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ２（６０３）がＳＱＬ処理部１３０に通知されると（６２３）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ１（６０１）の場合と同様に、ＳＱＬ２（６０３）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。ＳＱＬ２はＡＰ１２２の実行が開始されてから最初に発行されたため、当該ＳＱＬに対応するセクション１２４が登録されておらず（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理が実行される（ステップ２１２、６４２）。ＳＱＬ処理部１３０は、ＳＱＬ前処理が完了すると、ＳＱＬ２（６０３）を実行する（ステップ２１３）。
【００９２】
ＳＱＬの実行処理では、ＳＱＬ１（６０１）の場合と同様に、ＳＱＬの前処理結果に基づいてＳＱＬを実行する。ＳＱＬの実行処理では、必要に応じてリソース制御部１３２によって、リソースを割り当てる。また、ＳＱＬを実行するために構成されたセクションに関する情報などをＳＱＬ予測処理部１３３に通知する。ＳＱＬ予測処理部１３３は、ＳＱＬ予測管理処理２４０を実行し、通知された情報をＳＱＬ予測管理テーブル１３９に登録する。
【００９３】
ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【００９４】
次に、ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ６０４を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ６０４がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、前述のように、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、リソースモニタテーブル１３８から取得された情報に基づいて、リソースの使用状態を判定する（ステップ３０３）。この時点では、ＳＱＬ１（６０１）及びＳＱＬ２（６０３）のみが実行された状態であるため、リソース１２３の残量が十分にあると判定される。
【００９５】
続いて、ＤＢＭＳ１２０は、判定対象となる次のリソースが存在するか否かを判定する（ステップ４０４）。次のリソースが存在する場合には、当該リソースを判定対象とし、リソースの残量を判定する（ステップ４０４）。以降、リソースモニタテーブル１３８に登録されたレコードに対応するすべてのリソースに対して残量の判定を繰り返す。この時点では、前述のように、ＳＱＬ１（６０１）及びＳＱＬ２（６０３）のみが実行されている状態であるため、すべてのリソースについて残量が十分であると判定され、リソース使用状態判定処理の結果を「解放不要」と決定する（ステップ４０６）。
【００９６】
次に、ＤＢＭＳ１２０は、ＳＱＬ予測管理テーブル１３９から実行されたＳＱＬに関する情報を取得し（ステップ３０４）、取得されたＳＱＬの実行情報に基づいて、ＳＱＬ再利用可能性判定処理を実行する（ステップ３０５）。具体的には、ＳＱＬ予測管理テーブル１３９の各レコードに対応する各セクションを判定対象とし、ＳＱＬを再利用する可能性について判定する（ステップ５０２〜ステップ５０８）。
【００９７】
前述のように、ＳＱＬ再利用可能性判定処理では、まず、ＳＱＬ予測管理テーブル１３９に含まれる各セクションの利用回数を判定する（ステップ５０３）。利用回数が多い場合には、「再利用の可能性が大きい」と判定する（ステップ５０８）。
【００９８】
さらに、ＤＢＭＳ１２０は、当該セクションの利用回数が少ない場合には、最終利用時刻に基づいてＳＱＬが最近利用されたか否かを判定する（ステップ５０４）。このとき、当該セクションを直前に利用しているため、最近利用していると判定し、ＳＱＬ再利用可能性判定処理の結果を「再利用の可能性が高い」とする（ステップ５０８）。
【００９９】
以上より、ＤＢＭＳ１２０は、当該ＳＱＬの再利用の可能性が高いと判定し（ステップ３０５の結果が「Ｙｅｓ」）、トランザクション決着方式として「ＨＯＬＤ」を選択する（ステップ３０６）。ＤＢＭＳ１２０は、トランザクション決着方式として「ＨＯＬＤ」が選択されたため（ステップ２２２の結果が「ＨＯＬＤ」）、ＣＯＭＭＩＴ  ＨＯＬＤ（６２４）を実行することによってトランザクションを決着させる（ステップ２２４、６４４）。その後、ＣＯＭＭＩＴ制御処理を終了し、ＡＰ１２２に制御を戻す。
【０１００】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ２（６０５）を発行する（ステップ２０２）。ＳＱＬ２（６０３）と同様に、ＳＱＬ発行処理によって、ＳＱＬ２（６０５）がＳＱＬ処理部１３０に通知されると（６２５）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ２（６０５）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。この場合、ＳＱＬに対応するセクション１２４が登録済みであるため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を実行せずに、セクション１２４に登録されたＳＱＬ２の前処理結果に基づいてＳＱＬ２（６０５）を実行する（ステップ２１３、６４５）。このとき、当該ＳＱＬの実行に関する情報をＳＱＬ予測処理部１３３に通知し、ＳＱＬの実行に関する情報をＳＱＬ予測管理テーブル１３９に登録する。具体的には、利用したセクションの最終利用時刻を更新する。
【０１０１】
ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【０１０２】
次に、ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ６０６を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ６０６がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、リソースモニタテーブル１３８から取得された情報に基づいて、リソースの使用状態を判定する処理が実行される（ステップ３０３）。リソースの使用状態を判定する処理は、ＣＯＭＭＩＴ６０２の場合と同様である。この時点では、ＳＱＬ１（６０１）及びＳＱＬ２（６０３、６０５）のみが実行された状態であるため、リソース１２３の残量が十分にあると判定される。
【０１０３】
続いて、ＤＢＭＳ１２０は、判定対象となる次のリソースが存在するか否かを判定する（ステップ４０４）。次のリソースが存在する場合には、当該リソースを判定対象とし、リソースの残量を判定する（ステップ４０４）。以降、リソースモニタテーブル１３８に登録されたレコードに対応するすべてのリソースに対して残量の判定を繰り返す。この時点では、前述のように、ＳＱＬ１（６０１）及びＳＱＬ２（６０３、６０５）のみが実行されている状態であるため、すべてのリソースで残量が十分であると判定され、リソース使用状態判定処理の結果を「解放不要」と判定する（ステップ４０６）。
【０１０４】
次に、ＤＢＭＳ１２０は、ＳＱＬ予測管理テーブル１３９から実行されたＳＱＬに関する情報を取得し（ステップ３０４）、取得されたＳＱＬの実行情報に基づいて、ＳＱＬ再利用可能性判定処理を実行する（ステップ３０５）。具体的には、ＳＱＬ予測管理テーブル１３９の各レコードに対応する各セクションを判定対象とし、ＳＱＬを再利用する可能性について判定する（ステップ５０２〜ステップ５０８）。
【０１０５】
前述のように、ＳＱＬ再利用可能性判定処理では、まず、ＳＱＬ予測管理テーブル１３９に含まれる各セクションの利用回数を判定する（ステップ５０３）。この時点では、利用回数は１であり、利用回数が少ないと判定される。
【０１０６】
さらに、ＤＢＭＳ１２０は、当該セクションの利用回数が少ない場合には、最終利用時刻に基づいてＳＱＬが最近利用されたか否かを判定する（ステップ５０４）。このとき、当該セクションを直前に利用しているため、最近利用していると判定し、ＳＱＬ再利用可能性判定処理の結果を「再利用の可能性が高い」とする（ステップ５０８）。
【０１０７】
以上より、ＤＢＭＳ１２０は、当該ＳＱＬの再利用の可能性が高いと判定し（ステップ３０５の結果が「Ｙｅｓ」）、トランザクション決着方式として「ＨＯＬＤ」を選択する（ステップ３０６）。ＤＢＭＳ１２０は、トランザクション決着方式として「ＨＯＬＤ」が選択されたため（ステップ２２２の結果が「ＨＯＬＤ」）、ＣＯＭＭＩＴ  ＨＯＬＤ（６２６）を実行することによってトランザクションを決着させる（ステップ２２４、６４６）。その後、ＣＯＭＭＩＴ制御処理を終了し、ＡＰ１２２に制御を戻す。
【０１０８】
ＡＰ１２２は、同様に、ＳＱＬ２（６０７）〜ＳＱＬ５（６１３）をＤＢＭＳ１２０に発行する（ステップ２０２）。ＤＢＭＳ１２０は、前述した処理と同様に、ＳＱＬ２（６０７）〜ＳＱＬ５（６１３）を処理する（６２７〜６３３、６４７〜６５３）。以下、ＳＱＬ５（６１３）の次に発行されるＣＯＭＭＩＴ６１４について説明する。
【０１０９】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ６１４を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ６１４がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、前述のように、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、リソースモニタテーブル１３８から取得された情報に基づいて、リソースの使用状態を判定する（ステップ３０３）。
【０１１０】
ここで、この時点におけるリソースモニタテーブル１３８の状態を図７を参照しながら説明する。
【０１１１】
図７は、本発明の第１の実施の形態のリソースモニタテーブル１３８の一例を示す図である。
【０１１２】
リソースモニタテーブル１３８には、リソースＩＤ８０１、リソース容量８０２、リソース使用量８０３、リソース残量８０４及びリソース残量ＬＩＭＩＴ８０５を含む。
【０１１３】
リソースＩＤ８０１は、リソースの種類を識別する識別子である。リソース容量８０２は、利用可能なリソースの総量である。リソース使用量８０３は、リソースＩＤ８０１によって識別されるリソースの使用量である。
【０１１４】
リソース残量８０４は、利用可能なリソースの残量である。なお、リソース残量８０４については、リソース容量８０２及びリソース使用量８０３に基づいて算出するようにしてもよい。リソース残量ＬＩＭＩＴ８０５は、リソースが不足しているか否かを判定するための閾値である。
【０１１５】
前述したように、図７に示したリソースモニタテーブル１３８は、図６のＣＯＭＭＩＴ６１４が発行された後の状態である。このとき、まず、リソースＩＤ８０１が「Ａ００１」のレコードを取得し、リソース残量が不足しているか否かを判定する。このとき、リソース残量８０４の値が「２５，０００，０００」であり、リソース残量ＬＩＭＩＴ８０５の値が「８０，０００，０００」であるため、リソース残量８０４がリソース残量ＬＩＭＩＴ８０５を下回るため、リソースが不足していると判定される（ステップ４０３の結果が「ＹＥＳ」）。その結果、リソース状況判定の結果が「解放必要」に決定される（ステップ４０７）。
【０１１６】
したがって、ＤＢＭＳ１２０は、リソースの解放が必要であると判定し（ステップ３０３の結果が「ＹＥＳ」）、トランザクション決着方式として「ＣＯＭＭＩＴ」を選択する（ステップ３０７）。
【０１１７】
その後、ＤＢＭＳ１２０は、トランザクション決着方式として「ＣＯＭＭＩＴ」が選択されたため（ステップ２２２の結果が「ＣＯＭＭＩＴ」）、ＣＯＭＭＩＴを実行することによってトランザクションを決着させる（ステップ２２４、６３４、６５４）。このとき、保持されていたリソースは解放される。その後、ＣＯＭＭＩＴ制御処理を終了し、ＡＰ１２２に制御を戻す。
【０１１８】
ここで、リソースの解放が不要と判定された場合について説明すると、ＤＢＭＳ１２０は、前述のように、実行されたＳＱＬを再利用する可能性を判定する処理が実行される（ステップ３０５）。ＳＱＬを再利用する可能性を判定するための処理について、図８に示したＳＱＬ予測管理テーブル１３９を参照しながら説明する。
【０１１９】
図８は、本発明の第１の実施の形態のＳＱＬ予測管理テーブル１３９の一例を示す図である。
【０１２０】
ＳＱＬ予測管理テーブル１３９は、ユーザＩＤ９０１、ＡＰ管理ＩＤ９０２、セクションＩＤ９０３、セクション作成時刻９０４、セクション最終利用時刻９０５及びセクション利用回数９０６を含む。
【０１２１】
ユーザＩＤ９０１は、セクションを利用しているユーザの識別子である。ＡＰ管理ＩＤ９０２は、実行されているアプリケーションの識別子である。セクションＩＤ９０３は、利用されているセクションの識別子である。
【０１２２】
セクション作成時刻９０４は、セクションが作成された時刻である。セクション最終利用時刻９０５は、セクションが最後に利用された時刻である。セクション利用回数９０６は、セクションが利用された回数である。
【０１２３】
ＳＱＬを再利用する可能性を判定する場合には、まず、ＳＱＬ予測管理テーブル１３９の最初のレコードを取得し、当該取得されたレコードのセクション利用回数９０６を取得する。具体的に説明すると、最初の判定対象のセクションとして、セクションＩＤ９０３の値が「０００１」のレコードが取得される。このとき、対応するセクション利用回数９０６の値は１である。この場合、利用回数が少ないと判定され、さらに、当該セクションが最近利用されたか否かを判定する（ステップ５０４）。当該セクションは、最初に実行され、その後利用されていないため、最近利用していないと判定される（ステップ５０４の結果が「ＮＯ」）。
【０１２４】
さらに、ＤＢＭＳ１２０は、ＳＱＬ予測管理テーブル１３９に次のレコードが存在するため（ステップ５０５の結果が「ＹＥＳ」）、次のレコード（セクションＩＤ９０３が「０００２」のセクション）を判定対象とする（ステップ５０６）。
【０１２５】
続いて、対応するセクション利用回数９０６を取得し、利用回数を判定する（ステップ５０３）。ここでは、利用回数が３であるため、利用回数が少ないと判定する。さらに、当該セクションが最近利用されているか否かを判定する（ステップ５０４）。このとき、当該セクションは利用されてから、一定の時間が経過しているため、最近利用していないと判定される（ステップ５０４の結果が「ＮＯ」）。さらに、ＳＱＬ予測管理テーブル１３９に含まれるすべてのレコードについて以上の処理を実行し、すべてのレコードについて再利用の可能性が高いと判定されなかった場合には（ステップ５０５の結果が「ＮＯ」）、ＳＱＬ再利用可能性判定処理の結果を「再利用の可能性が低い」とする（ステップ５０７）。この場合、ステップ３０５の結果が「ＮＯ」となり、トランザクション決着方式として「ＣＯＭＭＩＴ」が選択され（ステップ３０７）、ステップ２２３の処理でＣＯＭＭＩＴ処理が実行される。その後、実行するＳＱＬがまだ残っている場合には、次のＳＱＬを実行する。
【０１２６】
ここで、図６の説明に戻る。
【０１２７】
ＤＢＭＳ１２０に発行したＣＯＭＭＩＴ６１４に対するＣＯＭＭＴ制御処理が完了し、ＤＢＭＳ１２０からＡＰ１２２に制御が戻されると、ＡＰ１２２はＳＱＬ６（６１５）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ６（６１５）がＳＱＬ処理部１３０に通知されると（６３５）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ６（６１５）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。ここでは、直前に実行されたＣＯＭＭＩＴ６１４によって、すべてのセクション１２４が解放されているため、利用可能なセクション１２４が登録されていないと判定され（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理を実行する（ステップ２１２、６５５）。さらに、ＳＱＬ処理部１３０は、ＳＱＬ前処理の実行後、ＳＱＬ６（６１５）を実行する。
【０１２８】
ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【０１２９】
次に、ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ６１６を発行する（ステップ２０３）。ＣＯＭＭＩＴ６１６がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、リソースモニタテーブル１３８から取得された情報に基づいて、リソースの使用状態を判定する処理が実行される（ステップ３０３）。リソースの使用状態を判定する処理は、ＣＯＭＭＩＴ６０２の場合と同様である。
【０１３０】
さらに、ＤＢＭＳ１２０は、リソースモニタテーブル１３８に登録されたレコードに対応するすべてのリソースの残量を判定する。この時点では、直前にＣＯＭＭＩＴ６１４が実行されたことで一旦すべてのリソースが解放されているため、ＳＱＬ６（６１５）のみが実行された状態であり、リソースの残量が十分にあると判定される（ステップ４０４）。したがって、「解放不要」と決定される（ステップ４０６）。
【０１３１】
次に、ＤＢＭＳ１２０は、ＳＱＬ予測管理テーブル１３９の各レコードに対応する各セクションを判定対象とし、ＳＱＬを再利用する可能性について判定する（ステップ５０２〜ステップ５０８）。
【０１３２】
前述のように、ＳＱＬ再利用可能性判定処理では、まず、ＳＱＬ予測管理テーブル１３９に含まれる各セクションの利用回数を判定する（ステップ５０３）。この時点では、直前に実行したＳＱＬ５（６１５）の情報のみが格納されているため、利用回数は１であり、利用回数が少ないと判定される（ステップ５０３の結果が「ＮＯ」）。
【０１３３】
さらに、ＤＢＭＳ１２０は、当該セクションの利用回数が少ない場合には、最終利用時刻に基づいてＳＱＬが最近利用されたか否かを判定する（ステップ５０４）。このとき、当該セクションを直前に利用しているため、最近利用していると判定し、ＳＱＬ再利用可能性判定処理の結果を「再利用の可能性が高い」とする（ステップ５０８）。
【０１３４】
ＣＯＭＭＩＴ処理部１３１は、ステップ３０５の処理でＳＱＬ再利用可能性判定処理の結果が「再利用の可能性が高い」と判定されたため、トランザクション決着方式として「ＨＯＬＤ」を選択する（ステップ３０６）。ＤＢＭＳ１２０は、トランザクション決着方式として「ＨＯＬＤ」が選択されたため（ステップ２２２の結果が「ＨＯＬＤ」）、ＣＯＭＭＩＴ  ＨＯＬＤを実行することによってトランザクションを決着させる（ステップ２２４、６３６、６５６）。その後、ＣＯＭＭＩＴ制御処理を終了し、ＡＰ１２２に制御を戻す。
【０１３５】
ＡＰ１２２は、制御が戻ると、プログラム終了判定を行う（ステップ２０４）。図６に示すように、まだ次のＳＱＬ６（６１７）が存在するため、当該ＳＱＬを実行する。
【０１３６】
ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ６（６１７）を発行する（ステップ２０２）。この場合、ＳＱＬ６（６１５）が実行され、直前のトランザクション決着方式に「ＨＯＬＤ」が選択されているため、ＳＱＬ前処理を実行せずにＳＱＬ６（６１７）が実行される。ＳＱＬが実行され（６３７、６５７）、ＡＰ１２２に制御が戻されると、要求されたＳＱＬがすべて実行されたため、ＡＰ１２２のプログラムを終了するか否かが判定される（ステップ２０４）。ＡＰ１２２は、プログラムを終了すると判定した場合には（ステップ２０４の結果が「ＹＥＳ」）、ＡＰ１２２の後処理を実行し、ＡＰ１２２の実行を終了する（ステップ２０５）。
【０１３７】
本発明の第１の実施の形態によれば、リソースの使用状態、及びＳＱＬを再利用する可能性の予測結果に基づいて、トランザクションの決着方式を選択することにより、トランザクションを決着させるために必要な時間を短縮することができる。具体的には、リソースの残量が多く、かつ、実行されたＳＱＬが再利用される可能性が高い場合には、リソースを解放せずにセクションを保持する。したがって、保持されたセクションを再利用することによってＳＱＬの前処理を省略することが可能となり、トランザクションを高速に処理することができる。また、リソースの残量が少なくなった場合、又は実行されたＳＱＬが再利用される可能性が少ない場合には、リソースを解放することによって、リソースが無駄に消費されることを防ぐことができる。
【０１３８】
なお、本発明の第１の実施の形態では、図５のステップ３０５のＳＱＬ再利用可能性判定処理で、一段階のみの判定に基づいてトランザクションの決着方式を決定しているが、例えば、セクションの利用状況をさらに詳細に解析することによって、再利用の可能性をより詳細に判定することが可能となる。
【０１３９】
（第２の実施の形態）
続いて、本発明の第２の実施の形態について、図面を参照しながら説明する。
【０１４０】
第１の実施の形態では、ＤＢＭＳ１２０においてリソースの使用状態及びＳＱＬの再利用予測の結果に基づいてトランザクションの決着方式を決定していたが、第２の実施の形態では、さらに、アプリケーションによってトランザクションの決着方式を指定することを可能とする。
【０１４１】
なお、第２の実施の形態では、第１の実施の形態と共通する構成については、適宜説明を省略し、相違する構成を中心に説明する。第２の実施の形態のシステム構成は、図１に示した第１の実施の形態のシステム構成と同様である。
【０１４２】
また、第２の実施の形態では、基本的な処理手順についても図２に示した第１の実施の形態における手順と同様である。さらに、図４に示したリソース使用状態判定処理及び図５に示したＳＱＬ再利用可能性判定処理についても第１の実施の形態と同様である。
【０１４３】
まず、第１の実施の形態と相違する第２の実施の形態のＣＯＭＭＩＴ選択処理について図９を参照しながら説明する。
【０１４４】
図９は、本発明の第２の実施の形態のＣＯＭＭＩＴ選択処理の手順を示すフローチャートである。
【０１４５】
第２の実施の形態のＣＯＭＭＩＴ選択処理は、図３に示した第１の実施の形態のＣＯＭＭＩＴ選択処理に、ＡＰ１２２で指定されたトランザクション決着方式を選択する機能を追加したものである。具体的には、ステップ１００２からステップ１００４までの処理は、ＡＰ１２２によって指定されたトランザクション決着方式を選択する処理である。また、ステップ１００５からステップ１０１０までの処理は、図３に示した第１の実施の形態のＣＯＭＭＩＴ選択処理のステップ３０３からステップ３０７までの処理に対応する。
【０１４６】
ＣＰＵ１１１は、ＡＰ１２２からＣＯＭＭＩＴの要求を受け付けると、要求に含まれるトランザクションの決着方式の指定値を取得する（ステップ１００２）。さらに、ステップ１００２の処理で指定値が取得されたか否か、すなわち、ＣＯＭＭＩＴ要求にトランザクションの決着方式が指定されていたか否かを判定する（ステップ１００３）。
【０１４７】
ＣＰＵ１１１は、トランザクションの決着方式が指定されていた場合には（ステップ１００３の結果が「ＹＥＳ」）、指定されていたトランザクション決着方式に基づいてトランザクションの決着方式を決定する（ステップ１００４）。「ＣＯＭＭＩＴ」が指定されていた場合には（ステップ１００４の結果が「ＣＯＭＭＩＴ」）、トランザクションの決着方式として「ＣＯＭＭＩＴ」を選択する（ステップ１０１０）。一方、「ＨＯＬＤ」が指定されていた場合には（ステップ１００４の結果が「ＨＯＬＤ」）、トランザクションの決着方式として「ＨＯＬＤ」を選択する（ステップ１００９）。
【０１４８】
ＣＰＵ１１１は、トランザクションの決着方式が指定されていなかった場合には（ステップ１００３の結果が「ＮＯ」）、第１の実施の形態と同様に、リソースの使用状態及びＳＱＬの再利用予測結果に基づいてトランザクションの決着方式を決定する（ステップ１００５〜ステップ１０１０）。
【０１４９】
以下、本発明の第２の実施の形態について、具体例を示しながら説明する。
【０１５０】
図１０は、本発明の第２の実施の形態のＡＰから要求されたＳＱＬをＤＢＭＳによって処理する手順を説明する図である。
【０１５１】
図１０左段には、ＡＰ１２２によって発行されたコマンド７０１〜７１７が時系列順に示されている。図１０中段には、ＤＢＭＳ１２０によって処理されるコマンド７２１〜７３７が示されている。図１０右段には、ＤＢＭＳで実際に実行される処理の説明７４１〜７５７が示されている。
【０１５２】
ここで、図１０に示した処理を図１、図２、図４、図５及び図９を参照しながら説明する。なお、各処理の実行主体は、第１の実施の形態と同様に、すべてＣＰＵ１１１となるが、ＣＰＵ１１１によって実行されるＡＰ１２２及びＤＢＭＳ１２０を各処理の主体として説明する。
【０１５３】
ＡＰ１２２は、まず、ＤＢＭＳ１２０にＳＱＬ１（７０１）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ１（７０１）がＳＱＬ処理部１３０に通知されると（７２１）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ１（７０１）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。ＳＱＬ１（７０１）はＡＰ１２２が実行されてから最初に発行されたＳＱＬであるため、当該ＳＱＬに対応するセクション１２４が登録されておらず（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理が実行される（ステップ２１２、７４１）。
【０１５４】
ＳＱＬ前処理は、第１の実施の形態と同様である。ＳＱＬ処理部１３０は、ＳＱＬ前処理が完了すると、ＳＱＬ１（７０１）を実行する（ステップ２１３、７４１）。ＳＱＬの実行処理では、ＳＱＬの前処理結果に基づいてＳＱＬを実行する。ＳＱＬの実行処理についても第１の実施の形態と同様である。ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【０１５５】
次に、ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７０２）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７０２）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。ＣＯＭＭＩＴ制御処理２２０では、最初に、ＣＯＭＭＩＴ選択処理が実行される（ステップ２２１）。
【０１５６】
ＣＯＭＭＩＴ選択処理では、まず、アプリケーションによって入力されたトランザクションの決着方式の指定値を取得する（ステップ１００２）。さらに、トランザクションの決着方式の指定値を取得されたか否かによってトランザクションの決着方式が指定されているか否かを判定する（ステップ１００３）。
【０１５７】
ＤＢＭＳ１２０は、トランザクションの決着方式が指定されている場合には（ステップ１００３の結果が「指定あり」）、さらに指定されているトランザクションの決着方式が「ＣＯＭＭＩＴ」であるか「ＨＯＬＤ」であるかを判定する（ステップ１００４）。指定されたトランザクションの決着方式が「ＣＯＭＭＩＴ」である場合には（ステップ１００４の結果が「ＣＯＭＭＩＴ」）、トランザクション決着方式として「ＣＯＭＭＩＴ」を選択する（ステップ１０１０）。一方、指定されたトランザクションの決着方式が「ＨＯＬＤ」である場合には（ステップ１００４の結果が「ＨＯＬＤ」）、トランザクション決着方式として「ＨＯＬＤ」を選択する（ステップ１００９）。
【０１５８】
図１０に示す例では、アプリケーションによってトランザクション決着方式として「ＣＯＭＭＩＴ  ＨＯＬＤ」が指定されているため、トランザクション決着方式として「ＨＯＬＤ」が選択され、ＤＢＭＳ１２０は、ＣＯＭＭＩＴ  ＨＯＬＤを実行する（ステップ２２４、７２２）。その結果、リソースを解放せずに、ＳＱＬ１（７０１）の実行結果がデータベースに反映されてトランザクションが決着する（７４２）。
【０１５９】
ＤＢＭＳ１２０は、その後、後処理を実行し、ＣＯＭＭＩＴ制御処理を終了する。さらに、ＡＰ１２２に制御を戻す。ＡＰ１２２は、制御が戻ると、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１６０】
なお、アプリケーションによってトランザクション決着方式が指定されている場合であっても、リソースの使用状態及びＳＱＬの実行状態に基づいて、トランザクション決着方式を判定してもよい。このとき、アプリケーションによって「ＣＯＭＭＩＴ  ＨＯＬＤ」が指定されている場合であっても、リソースが不足している場合、又は実行されるＳＱＬを再利用する可能性が低い場合には、トランザクション決着方式を「ＣＯＭＭＩＴ」としてリソースが解放されるようにしてもよい。特に、リソースが不足している場合には、安定して処理を継続できなくなる可能性があるため、アプリケーションによる指定にかかわらず「ＣＯＭＭＩＴ」を選択するようにしてもよい。
【０１６１】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ２（７０３）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ２（７０３）がＳＱＬ処理部１３０に通知されると（７２３）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ２（７０３）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１６２】
図１０に示す例では、ＳＱＬ１（７０１）の実行に利用されたセクションのみが登録されており、ＳＱＬ２を実行するために利用されるＳＱＬに対応するセクション１２４が登録されていないため（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理が実行される（ステップ２１２、７４３）。したがって、ＳＱＬ処理部１３０は、ＳＱＬ１（７０１）の場合と同様に、ＳＱＬ前処理が実行された後、ＳＱＬ２（７０３）を実行する（ステップ２１３、７４３）。ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【０１６３】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７０４）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７０４）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１６４】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＨＯＬＤ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴ  ＨＯＬＤを実行し（ステップ２２４、７２４、７４４）、その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１６５】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ１（７０５）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ１（７０５）がＳＱＬ処理部１３０に通知されると（７２５）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ１（７０５）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１６６】
図１０に示す例では、ＳＱＬ１を実行するために利用されるセクション１２４が登録されているため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を省略し、登録済みのセクションを利用してＳＱＬ１（７０５）を実行する（ステップ２１３、７４５）。その後、ＡＰ１２２に制御を戻す。
【０１６７】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７０６）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７０６）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１６８】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＨＯＬＤ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴ  ＨＯＬＤを実行し（ステップ２２４、７２６、７４６）、その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１６９】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ２（７０７）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ２（７０７）がＳＱＬ処理部１３０に通知されると（７２７）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ２（７０７）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１７０】
図１０に示す例では、ＳＱＬ２を実行するために利用されるセクション１２４が登録されているため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を省略し、登録済みのセクションを利用してＳＱＬ２（７０７）を実行する（ステップ２１３、７４７）。その後、ＡＰ１２２に制御を戻す。
【０１７１】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ７０８を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ７０８がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１７２】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＣＯＭＭＩＴ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴを実行し（ステップ２２４、７２８、７４８）、ＳＱＬ２（７０７）の実行結果をデータベースに反映するとともに、割り当てられていたリソースを解放する。その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１７３】
このとき、ＤＢＭＳ１２０にはリソースが十分残されており、ＳＱＬ１及びＳＱＬ２が交互に２回実行された後であるため、ＳＱＬ１又はＳＱＬ２が再実行される可能性が高いと判定される。しかし、ＡＰ１２２では、以降、ＳＱＬ１及びＳＱＬ２は実行されないことがあらかじめ把握されているため、トランザクション決着方式として「ＣＯＭＭＩＴ」が指定されている。そこで、ＤＢＭＳ１２０がトランザクション決着方式として「ＣＯＭＭＩＴ」を実行することによって、割り当てられたリソースを使用されなくなった時点で解放し、リソースの無用な消費を回避することができる。
【０１７４】
ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ３（７０９）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ３（７０９）がＳＱＬ処理部１３０に通知されると（７２９）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ３（７０９）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１７５】
図１０に示す例では、直前にトランザクション決着方式として「ＣＯＭＭＩＴ」が実行され、セクション１２４が登録されていないため（ステップ２１１の結果が「ＮＯ」）、ＳＱＬ前処理を実行する（ステップ２１２、７２９）。ＳＱＬ処理部１３０は、ＳＱＬ前処理が実行された後、ＳＱＬ３（７０９）を実行する（ステップ２１３、７４９）。ＤＢＭＳ１２０は、ＳＱＬの実行処理が終了すると、後処理を実行し、ＡＰ１２２に制御を戻す。
【０１７６】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７１０）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７０４）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１７７】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＨＯＬＤ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴ  ＨＯＬＤを実行し（ステップ２２４、７３０、７５０）、その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１７８】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ４（７１１）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ４（７１１）がＳＱＬ処理部１３０に通知されると（７３１）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ４（７１１）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１７９】
図１０に示す例では、ＳＱＬ１を実行するために利用されるセクション１２４が登録されていないため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を実行し、その後、ＳＱＬ４（７１１）を実行する（ステップ２１３、７５１）。その後、ＡＰ１２２に制御を戻す。
【０１８０】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７１２）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７１２）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１８１】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＨＯＬＤ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴ  ＨＯＬＤを実行し（ステップ２２４、７３２、７５２）、その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１８２】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ３（７１３）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ３（７１３）がＳＱＬ処理部１３０に通知されると（７３３）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ３（７１３）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１８３】
図１０に示す例では、ＳＱＬ３を実行するために利用されるセクション１２４が登録されているため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を省略し、登録済みのセクションを利用してＳＱＬ３（７１３）を実行する（ステップ２１３、７５３）。その後、ＡＰ１２２に制御を戻す。
【０１８４】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ  ＨＯＬＤ（７１４）を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ  ＨＯＬＤ（７１４）がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１８５】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＨＯＬＤ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴ  ＨＯＬＤを実行し（ステップ２２４、７３４、７５４）、その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬが残されているため、次のＳＱＬを実行する。
【０１８６】
続いて、ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ４（７１５）を発行する（ステップ２０２）。ＳＱＬ発行処理によって、ＳＱＬ４（７１５）がＳＱＬ処理部１３０に通知されると（７３５）、ＳＱＬ制御処理２１０が実行される。ＳＱＬ制御処理２１０では、ＳＱＬ４（７１５）を処理するために利用可能なセクションが登録済みか否かを判定する（ステップ２１１）。
【０１８７】
図１０に示す例では、ＳＱＬ４を実行するために利用されるセクション１２４が登録されているため（ステップ２１１の結果が「ＹＥＳ」）、ＳＱＬ前処理を省略し、登録済みのセクションを利用してＳＱＬ４（７１５）を実行する（ステップ２１３、７５５）。その後、ＡＰ１２２に制御を戻す。
【０１８８】
ＡＰ１２２は、ＤＢＭＳ１２０にＣＯＭＭＩＴ７１６を発行する（ステップ２０３）。ＣＯＭＭＩＴ発行処理によって、ＣＯＭＭＩＴ７１６がＣＯＭＭＩＴ処理部１３１に通知されると、ＣＯＭＭＩＴ制御処理２２０が実行される。
【０１８９】
ＣＯＭＭＩＴ制御処理２２０では、ＣＯＭＭＩＴ選択処理が実行され（ステップ２２１）、図１０に示す例では、指定されたトランザクション決着方式（「ＣＯＭＭＩＴ」）が選択される（ステップ１００９）。ＤＢＭＳ１２０は、トランザクション決着方式としてＣＯＭＭＩＴを実行し（ステップ２２４、７３６、７５６）、ＳＱＬ４（７１５）の実行結果をデータベースに反映するとともに、割り当てられていたリソースを解放する。その後、ＡＰ１２２に制御を戻す。ＡＰ１２２は、プログラム終了判定処理を実行する（ステップ２０４）。図１０に示すように、未実行のＳＱＬ５（７１７）が残されているため、当該ＳＱＬを実行する。
【０１９０】
ＡＰ１２２は、ＤＢＭＳ１２０にＳＱＬ５（７１７）を発行する（ステップ２０２）。このとき、直前のトランザクション決着方式として「ＣＯＭＭＩＴ」が実行されているため、ＳＱＬ前処理を実行する（ステップ２１２、７３７、７５７）。ＳＱＬが実行された後、ＡＰ１２２に制御が戻されると、要求されたＳＱＬがすべて実行されたため、プログラムを終了するか否かが判定される（ステップ２０４）。ＡＰ１２２は、プログラムを終了すると判定し（ステップ２０４の結果が「ＹＥＳ」）、ＡＰ１２２の後処理を実行した後、ＡＰ１２２の実行を終了する（ステップ２０５）。
【０１９１】
本発明の第２の実施の形態によれば、アプリケーション側からトランザクションの決着方式を指定することができるため、あらかじめ把握されている処理に基づいてリソースの解放及び保持を決定することができる。したがって、リソースを保持すべき又は解放すべきかを自動的に判断しにくい場合に対応することが可能となる。
【０１９２】
また、本発明の第２の実施の形態によれば、アプリケーションによるトランザクションの決着方式の指定に関わらず、リソースの使用状態に応じてリソースを解放することによって、アプリケーションを安定して稼働させることができる。
【符号の説明】
【０１９３】
１０１    入出力装置
１０２    表示装置
１０３〜１０５    外部記憶装置
１１０    データベース管理装置
１１１    ＣＰＵ
１１２    メモリ
１２０    ＤＢＭＳ
１２１    プログラム実行環境部
１２２    アプリケーション（ＡＰ）
１２３    リソース
１２４    セクション
１３０    ＳＱＬ処理部
１３１    ＣＯＭＭＩＴ処理部
１３２    リソース制御部
１３３    ＳＱＬ予測処理部
１３４    プログラム実行制御部
１３５    データベースアクセス部
１３６    ディクショナリアクセス部
１３８    リソースモニタテーブル
１３９    ＳＱＬ予測管理テーブル
【図１】
2010198581.tif 000003
【図２】
2010198581.tif 000004
【図３】
2010198581.tif 000005
【図４】
2010198581.tif 000006
【図５】
2010198581.tif 000007
【図６】
2010198581.tif 000008
【図７】
2010198581.tif 000009
【図８】
2010198581.tif 000010
【図９】
2010198581.tif 000011
【図１０】
2010198581.tif 000012