JP2012014502A

JP2012014502A - トランザクションを集約して処理する方法、システム、およびプログラム

Info

Publication number: JP2012014502A
Application number: JP2010150989A
Authority: JP
Inventors: Hiroshi Horii; 洋堀井
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-07-01
Filing date: 2010-07-01
Publication date: 2012-01-19
Anticipated expiration: 2030-07-01
Also published as: US8527501B2; US20120005196A1; JP5536568B2

Abstract

【課題】トランザクションを集約して処理する方法、システム、およびプログラムを提供することである。
【解決手段】上記課題を解決するために第１の態様として、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップを有する。
【選択図】図１

Description

本発明はトランザクションの処理方法に関し、特に複数の照会クエリを含む集約トランザクションの処理方法、システムに関する。

通常、データベースにおけるトランザクション処理は、一貫した状態のデータベースを維持するよう設計されている。相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証している。そのために、ロック、ロールバック、デッドロックの回避の仕組みがある。

ロックとは、特定のデータに対するアクセスや更新を制御することである。特にデータベースへの書き込み処理を行なう際に、データの整合性を保つためにアクセスやデータの読み書きを一時的に制限することである。より具体的には１つの処理がデータＸにアクセス中は他の処理がＸへアクセスできないように排他制御を行う。１つの処理が２つ以上のＳＱＬ文で表される場合にトランザクションを利用する。

トランザクションは一連の処理（複数のＳＱＬからなる照会クエリ）をまとめてコミット（確定）またはロールバック（取り消し）を行うことができる機能で、これを利用すれば１つのＳＱＬ文が失敗した場合、同じ処理の別のＳＱＬ文をすべて取り消すことができる。ロールバックはつまりトランザクションがコミット前に失敗した場合、データベースをトランザクション開始前の状態に戻す処理である。またデッドロックとは、２つのトランザクションの処理中にデータベース内の同じ部分に同時にアクセスすることで、互いの処理の進行を妨げる現象である。例えば、トランザクションＡがデータＸにアクセスし、トランザクションＢがデータＹにアクセスする場合、ＡがＹにアクセスしようとし、ＢがＸにアクセスしようとしたときデッドロックが発生する。この場合どちらのトランザクションも先に進めなくなる。このようなデッドロックを回避するには、両方のトランザクションをキャンセルし、ロールバックする。そして順序を変えて再実行し、デッドロックが再度発生しないようにする。

クライアント数の増加と処理するデータ量の増大に伴い、データベースへのアクセスをより効率化する技術が知られている。特許文献１には、複数のロック制御によって複数のトランザクションの並行的な実行を制御する場合に、連続してなされるロック要求を蓄積し、ロック要求でない要求が出されたとき、この要求を処理する前に、前述の蓄積されたロック要求を一括してデ−タベ−スサ−バヘ送信し、ロック処理することによって送信回数を減少させる技術が開示されている。すなわち複数のトランザクション内でのロック要求をまとめる技術である。

特許文献２には、入力された複数のトランザクションを別々に処理するのではなく、入力された複数のトランザクションが処理を行うデータ項目に対して、そのデータ項目を一度だけ検索し、検索したデータ項目に対して、複数のトランザクションの更新処理を順次メインメモリ内で行い、最後に更新した結果だけをデータベースに一度だけ書き込む手法を開示している。すなわち複数のトランザクションの更新をまとめる技術である。

上記従来の方法は複数のトランザクションを１つにまとめて集約してデータベースに問い合わせる方法を採っていない。その理由は、複数のトランザクション（照会クエリ）に存在するＳＱＬ文を集約する方法が難しいことと、またＳＱＬの集約が可能になったとしても、データベースに集約照会をした時に、照会したデータを更新するトランザクションが１つでも発生した場合、必然的にデッドロックが発生するからである。なお本発明ではトランザクションの分離レベルを「再読み込み可能読み取り」（ＲＥＰＥＡＴＡＢＬＥＲＥＡＤ）とする。この分離レベルではトランザクションにおいて対象となるすべてのテーブルの対象データがトランザクション実行中に変更されないことが保証される。

特開１９９３−０１０８４５２特開２００９−０２７１６６５

本発明が解決しようとする課題は、データベース・クライアントがトランザクション処理をデータベースに要求する際に、一部の照会クエリを、その他のトランザクションの照会クエリと共に、別トランザクション（集約トランザクション）としてデータベースに要求する、集約トランザクションの処理方法、システムを提供することである。

さらに別の課題は、集約トランザクションの処理において、照会クエリを要求した全データベース・クライアントからのコミット要求を受信した時に前記集約トランザクションをコミットする方法、システムを提供することである。

さらに別の課題は、集約トランザクションを処理するにあたり、デッドロックの生じないデータ更新方法、システムを提供することである。

本発明は上記課題を解決するために、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップと、を有する。

また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップと、である。

また、前記送信するステップが、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップである

さらに、前記方法が、前記データベースから前記集約トランザクションに対する結果を受信するステップとを有する。

さらに、前記方法が、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップを有する。

また、前記分割して送信するステップが、データベースから送信された結果からクライアントＩＤを判断するステップと、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、前記クライアントＩＤを有するクライアントに照会結果を送信するステップである。

そして、前記方法が、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップを有する。

別の態様として、本発明は、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、複数クライアントから複数トランザクションを受信する手段と、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段を有する。

また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段である。

また、前記送信する手段が、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段である。

さらに、前記システムが、前記データベースから前記集約トランザクションに対する結果を受信する手段を有する。

さらに、前記システムが、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段を有する。

また、前記分割して送信する手段が、データベースから送信された結果からクライアントＩＤを判断する手段と、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、前記クライアントＩＤを有するクライアントに照会結果を送信する手段である。

そして、前記システムが、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、更新するデータが、集約トランザクションとして照会したかを判断する手段と、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段を有する。

また別の態様として、上記何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラムを提供する。

本発明により、複数のトランザクションを１つにまとめて集約してデータベースに問い合わせることが可能となる。またデータベースに集約トランザクションを問い合わせた場合に、データを更新するトランザクションが発生てもデッドロックすることなく、パフォーマンスに優れたデータベースアクセスが可能となる。

本発明の全体のシステム構成を示す。トランザクションをまとめてデータベース１３０へ送信する場合の図である。集約トランザクションの問題点を示す図である。本発明における集約トランザクションの処理例である。クライアントとＤＢＰｒｏｘｙ１２０の記憶構成ブロックを示す。トランザクション開始時のクライアントの挙動を示す。照会ＳＱＬを要求時のクライアントの挙動のフローチャートである。更新ＳＱＬを要求時のクライアントの挙動のフローチャートである。コミット要求時のクライアントの挙動のフローチャートである。ロールバック要求時のクライアントの挙動のフローチャートである。照会ＳＱＬ要求受信時のＤＢＰｒｏｘｙの挙動のフローチャートである。照会ＳＱＬのバッチ要求時の、ＤＢＰｒｏｘｙの挙動のフローチャートである。トランザクションのコミット要求時のＤＢＰｒｏｘｙの挙動のフローチャートである。本発明における、クライアント、ＤＢＰｒｏｘｙ、データベースの例示的なハードウェア構成である。ＳＱＬ文例である。別のＳＱＬ文例である。ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。データベース１３０から受信した結果の例である。データベース１３０から受信した結果を各クライアント用に分割する例１である。データベース１３０から受信した結果を各クライアント用に分割する例２である。データベース１３０から受信した結果を各クライアント用に分割する例３である。

図１に本発明の全体のシステム構成を示す。ＤＢＰｒｏｘｙ１２０は複数のクライアント１１０からトランザクションを集約してデータベース１３０に送信する。ＤＢＰｒｏｘｙ１２０は複数のクライアントに対して１つ存在する。

データベース１３０は、クライアント１１０、もしくは、ＤＢＰｒｏｘｙ１２０から受信する、複数のＳＱＬを１つのトランザクションとして処理する。

ＤＢＰｒｏｘｙ１２０は、トランザクションの開始をデータベース１３０に通知し、要求するＳＱＬを送信し、その結果を受信し、コミット要求をデータベースに送信することで行う。なお一般的には、ＳＱＬの送信、結果の受信は、複数回行われる。

なお本明細書の実施例において、クライアント１１０がトランザクションを開始する際の処理、照会ＳＱＬを要求する際の処理、更新ＳＱＬを要求する際の処理、コミット・ロールバックを要求する際の処理を詳細に説明する。また、ＤＢＰｒｏｘｙ１２０が、上記のクライアント１１０の処理内で、クライアントから照会ＳＱＬを受信した際の処理、クライアントからコミット要求を受信した際の処理を詳細に説明する。

なお説明の簡素化のため、ＤＢＰｒｏｘｙ１２０、クライアント１１０は、同時に１つのトランザクションしか要求しないものと仮定する。また、クライアント１１０とＤＢＰｒｏｘｙ１２０は、Ｎ対１の関係がついているものとする。

図２に、トランザクションをまとめてデータベース１３０へ送信する場合を図示する。図２ではＤＢＰｒｏｘｙ１２０がクライアント１とクライアント２のトランザクション中の照会クエリをまとめてデータベースに要求することにより、データベースのスループットを向上させる。なお図中においてｒは読み取り（Ｒｅａｄ）、ｗは書き込み（Ｗｒｉｔｅ）を表し、その添え字の最初はクライアント番号、次の添え字は時系列順序を表している。

図２において、クライアント１およびクライアント２は、トランザクション中の照会クエリを、ＤＢＰｒｏｘｙ１２０に転送する。ＤＢＰｒｏｘｙ１２０は、複数のクライアントから受信した照会クエリを１つのクエリにまとめ、照会トランザクションとしてデータベース１３０に処理要求する。照会クエリは通常ＳＱＬ文であるので、同時系列順序で出されたクライアント１のレコードＡを参照するＳＱＬと、クライアント２のレコードＢを照会するＳＱＬ２つのＳＱＬは、ＤＢＰｒｏｘｙ１２０で１つのＳＱＬに集約されてデータベース１３０に送信されることになる。

図１７に、ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。本発明ではＳＥＬＥＣＴ文の集約に集合演算子であるＵＮＩＯＮＡＬＬを使用する。ＵＮＩＯＮ集合演算子とは複数のＳＥＬＥＣＴ文を１つに組み合わせる演算子である。しかし、複数の問い合わせを１つに結合することから、それぞれの問い合わせの抽出項目のリストは同数、かつ、同じグループのデータ型でなければ結合することができない。この方法により任意のＳＱＬをまとめることが可能になる。

まず１７１０で連結対象となるＳＥＬＥＣＴ文と、クライアントＩＤ（ＩＮＴ型）を対応付ける。例として以下の２つのＳＥＬＣＥＣＴ文を結合対象として説明する。
S1: SELECT C11, C12, C13 FROM T1 WHEREK1=? →クライアントIDを1とする
> C11: INT, C12: DOUBLE, C13: STRING
S2: SELECT C21, C22, C23 FROM T0 WHERE K2=? →クライアントIDを2とする
> C21: DOUBLE, C22:INT, C23: DATE

ステップ１７２０で、全てのＳＥＬＥＣＴ文が返すデータ（カラム）の型を含む、データの型の集合を生成する。この時、同一グループのデータ型について型を増加させす１つにして異なるグループのデータ型は新しく付加する。すなわち型の集合を作成する時は異なる型のみを追加する。
例では、{INT, DOUBLE,STRING, DATE}となる。

ステップ１７３０で、ステップ１７２０で生成した型の集合に順序をつけ、先頭にＩＮＴ型を追加する。
例では、INT, INT, DOUBLE,STRING, DATEの順となる。

ステップ１７４０で、各ＳＥＬＥＣＴ文に対し、ステップ１７３０でつけた順序で結果を返すように書き換える。もし、返す型が存在しない場合は、固定値を返すようにする。また、最初のＩＮＴ型には、クライアントＩＤを固定値として返すようにする。
S1': SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=?
S2': SELECT 2, C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?

ステップ１７５０で、元のＳＥＬＥＣＴ文のデータ型（カラム）順序と、書き換えたＳＥＬＥＣＴ文のデータ型（カラム）順序の対応を記憶する。記憶した内容は後ほど結果を分割するために使用する。

S1とS1'の対応:{1→2, 2→3, 3→4} (1→2は、S1の1番目の項目がS1'の2番目の項目に対応することを意味する)
S2とS2'の対応:{1→3, 2→2, 3→5} (1→3は、S2の1番目の項目がS2'の3番目の項目に対応することを意味する)

ステップ１７６０で、書き換えたＳＥＬＥＣＴ文をＵＮＩＯＮＡＬＬで連結する。そしてデータベース１３０に照会する。
SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=? UNION ALL SELECT 2,C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?

図１８に、データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。

図１９に、データベース１３０から受信した結果の例を示す。表は左から、INT, INT, DOUBLE, STRING, DATEの順で構成されたデータが５行存在している。左端のＩＮＴ型データはクライアントＩＤを示している。

図１８のフローチャートに従い、ステップ１８１０で、データベース１３０から受信した結果から一行読み込む。すなわち１行目である、1, 1, 0.001, "AAAA"が読み込まれる。ステップ１８２０で、ステップ１８１０で読み込んだ行の、始めのＩＮＴ型のデータからクライアントＩＤを取得する。この場合は１であるのでクライアント１であることがわかる。

ステップ１８３０で、ステップ１８２０で読み込んだ行を、ステップ１７５０で記憶したデータ型順序の対応から、各クライアントが要求したデータ型の値のみを、要求順に並び替え、そのクライアントＩＤのＳＥＬＥＣＴ文に対する結果とする。

ここでクライアント１において、S1とS1'の対応関係は{1→2, 2→3, 3→4} であるので、１行目のデータは図２０に示すように変換される。この処理を繰り返すことで、クライアント１のデータは図２１に示すように、元の結果から分離され、変換されることになる。

３行目からはクライアント２の結果であるので、S2とS2'の対応関係{1→3, 2→2, 3→5} を参照しながら、図２２に示すように、元の結果から分離され、変換される。

図１８のフローチャートに従い、ステップ１８４０で、受信した結果が存在しない場合は処理を終了する。それ以外は、ステップ１８１０に戻る。

本発明の集約と分割の特徴はまとめると次のようになる。
・ＳＥＬＥＣＴ対象となるデータの型情報のみを利用して、ＵＮＩＯＮＡＬＬのデータ型を決定すること
・ＵＮＩＯＮＡＬＬのデータ（カラム）名とクライアントの要求したＳＥＬＥＣＴ文のデータ（カラム）名の対応関係から、各クライアント用の結果を分割して生成すること。
・ＳＥＬＥＣＴ文のＩＤが結果に含まれない場合は、空の結果（ＲｅｓｕｌｔＳｅｔ）を生成すること
これにより本発明は、ＤＢＰｒｏｘｙ１２０で、複数の照会ＳＱＬを集約してデータベースに処理要求し、その結果をそれぞれのクライアントに分割して返すことができる。

図２の集約クエリ送信後の問題点を図３で説明する。
１．クライアント１は、トランザクション中の照会クエリ（レコードＡを照会ｒ_１１）を、ＤＢＰｒｏｘｙ１２０に転送する。
２．クライアント２は、トランザクション中の照会クエリ（レコードＢを照会ｒ_２１）を、ＤＢＰｒｏｘｙ１２０に転送する。
３．ＤＢＰｒｏｘｙ１２０は、クライアント１とクライアント２から受信した照会クエリを１つのクエリにまとめ、集約トランザクション（レコードＡとレコードＢを同時照会ｒ_{１１＋２１}）としてデータベース１３０に処理要求する。
４．ここでクライアント１が、同じトランザクション中の更新クエリを更新トランザクション（レコードＡを更新ｗ_１２）として、ＤＢＰｒｏｘｙ１２０経由で照会中の集約トランザクション（照会クエリ）とは別に、データベース１３０に要求する。

しかし、この更新トランザクションは集約トランザクションによりレコードＡがロックされているため、レコードＡのロックが開放されるまで待たねばならないが開放されることがない。

なぜなら、クライアント１の更新トランザクションは、ＤＢＰｒｏｘｙ１２０の照会トランザクションがコミットされないと、コミットできないからである。逆に、クライアント１の更新トランザクションよりコミットの通知を受けなくては、ＤＢＰｒｏｘｙ１２０の照会トランザクションがコミットすることはないからである。すなわち、ＤＢＰｒｏｘｙ１２０に要求した照会クエリで照会したレコードＡを、同じトランザクションで更新する場合、必ずデッドロックが発生することになる。

そこで本発明では図４の方法を採る。以下の手順により、集約トランザクションで照会したレコードを更新する場合でも、デッドロックが発生しない。クライアント１が集約トランザクション経由で照会したデータを更新する際に、
４．まずクライアント１は、更新するレコードＡが、集約トランザクションとして照会したかをＤＢＰｒｏｘｙ１２０に問い合わせる。集約トランザクションとして照会している場合、クライアント１は、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベース１３０に処理要求する。
５．クライアント１は、ＤＢＰｒｏｘｙ１２０にコミット要求を出す。
６．クライアント１はレコードＡの更新クエリを直接トランザクションとして、データベース１３０に処理要求する

図５に、クライアントとＤＢＰｒｏｘｙ１２０の記憶構成ブロックを示す。ここでＤＢＰｒｏｘｙ１２０は説明のため１つのトランザクションのみを実行することを仮定する。

クライアントは、照会済ＳＱＬ記憶部、更新済ＳＱＬ記憶部、モード、トランザクション状態を管理する。照会済ＳＱＬ記憶部は、現在実行中のトランザクション内で照会したＳＱＬの履歴を保持する。更新済ＳＱＬ記憶部は、現在実行中のトランザクション内で更新したＳＱＬの履歴を保持する。

モードは、照会ＳＱＬの送信モードを意味し、Ｐｒｏｘｙ時はＤＢＰｒｏｘｙを優先的に利用する、Ｄｉｒｅｃｔ時は直接利用することを意味する。なお、Ｎｕｌｌ時はモードが決定されていないことを意味する。トランザクション状態は、クライアントが直接要求するトランザクションの状態を意味し、Ａｃｔｉｖｅ時はトランザクションを要求中、Ｉｎａｃｔｉｖｅはトランザクションを要求していないことを意味する。

ＤＢＰｒｏｘｙは、開始待ちクライアント記憶部、開始済クライアント記憶部、コミット済クライアント記憶部、バッチ待ち照会ＳＱＬ記憶部を管理する。

開始待ちクライアント記憶部は、ＤＢＰｒｏｘｙが次のトランザクションでバッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。開始済みクライアント記憶部は、ＤＢＰｒｏｘｙが現在バッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。

コミット済みクライアント記憶部は、開始済みクライアント記憶部のうち、コミット要求を受信したクライアントの識別子のリストを保持する。バッチ待ち照会ＳＱＬ記憶部は、開始済みクライアント記憶部のクライアントがＤＢＰｒｏｘｙに要求し、ＤＢＰｒｏｘｙがまだデータベースに要求していないＳＱＬを保持する。

図６に、トランザクション開始時のクライアントの挙動を示す。

ステップ６０２で、照会ＳＱＬを要求する。ステップ６０４でモードをＮｕｌｌに遷移する。次にステップ６０６で照会済ＳＱＬ記憶部をクリアする。そしてステップ６０８で更新済ＳＱＬ記憶部をクリアし、最後にステップ６１０でトランザクション状態をＩｎａｃｔｉｖｅにする。

図７に、照会ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。

クライアントが照会ＳＱＬを要求する際は、ステップ７０４で、モードがＤｉｒｅｃｔモードか否かを判断する。Ｎｕｌｌモード、もしくは、Ｐｒｏｘｙモードの場合は、Ｐｒｏｘｙ経由でＳＱＬが処理可能かを判断するためにステップ７０６へ移る。

Ｐｒｏｘｙ経由でＳＱＬが処理可能かチェックするには、ステップ７０６でこれまでクライアントが同じトランザクション内で要求した更新データを、照会ＳＱＬが照会する可能性があるかを判断することで行う。

例えば、図１５のＳＱＬＡ（ＵＰＤＡＴＥ）をすでに実行済みで、ＳＱＬＢ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新したデータを照会することはないので、Ｐｒｏｘｙ経由で照会可能となる。

一方、ＳＱＬＣ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新データを照会する可能性があるため、Ｐｒｏｘｙ経由で照会できない。また、ＳＱＬＤ（ＳＥＬＥＣＴ）のように、クエリからでは更新したデータを判定できない場合も、同様にＰｒｏｘｙ、経由で照会できないと判断する。

ステップ７０８で、Ｐｒｏｘｙ経由で照会する場合は、ＤＢＰｒｏｘｙに照会ＳＱＬを送信し、ステップ７１０で、ＤＢＰｒｏｘｙから照会ＳＱＬ結果を受信するまで待機する。ステップ７１２で、照会ＳＱＬ結果を受信後は、照会ＳＱＬを照会済ＳＱＬ記憶部に追加し、ステップ７１４でモードをＰｒｏｘｙモードに遷移させる。

一方、Ｐｒｏｘｙ経由で照会しない場合は、直接データベースに照会ＳＱＬを要求し、照会ＳＱＬ結果を受信する。ステップ７１６で、もしトランザクションが開始されていない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ７１８でトランザクション開始をデータベースに要求し、ステップ７２２でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ７２４で照会ＳＱＬを要求する。そしてステップ７２６でデータベース１３０から照会ＳＱＬの結果を受信する。

図８に、更新ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。

ステップ８０２でクライアントが照会ＳＱＬを要求する際は、まず、ステップ８０４でモードがＰｒｏｘｙモードか否かを判断する。
Ｐｒｏｘｙモードの場合は、ステップ７０６で照会ＳＱＬで照会したデータを、更新ＳＱＬが更新する可能性があるかを判断する。

更新ＳＱＬが更新する可能性があるかのチェックは、照会済ＳＱＬ記憶部内の照会ＳＱＬと、その照会結果をチェックすることで判定する。
例えば、照会済ＳＱＬ記憶部内に、図１６のＳＱＬＤ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合、ＳＱＬＥ（ＵＰＤＡＴＥ）という更新の際は更新する可能性がなく、ＳＱＬＦ（ＵＰＤＡＴＥ）の際は更新する可能性があると判断する。

ステップ８０６で、もし更新があると判断した場合は、これまでにＰｒｏｘｙ経由で照会したＳＱＬを、再度直接データベースに要求し、照会結果を受信する。

ステップ８０８で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８１０でデータベースにトランザクションの開始要求を行ってから、ステップ８１２で照会ＳＱＬを送信する。

ステップ８１４で照会結果を受信後は、ステップ８１６でＤｉｒｅｃｔモードに遷移し、ステップ８１８でＤＢＰｒｏｘｙにコミット要求を送信する。そして処理はステップ８２０へ移る。

Ｐｒｏｘｙモードではない場合、もしくは、照会結果を受信した後は、データベースに更新ＳＱＬを要求し、更新結果を受信する。

ステップ８２０で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８２２でデータベースにトランザクションの開始要求を行い、ステップ８２４でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ８２６で更新ＳＱＬを送信する。ステップ８２８で更新結果を受信した後は、ステップ８３０で更新ＳＱＬを更新済みＳＱＬ記憶部に追加する。

図９に、コミット要求時のクライアントの挙動のフローチャートを示す。

ステップ９０２でコミット要求を出す際に、ステップ９０４でトランザクション状態がＩｎａｃｔｉｖｅか判断する。Ｉｎａｃｔｉｖｅの場合はステップ９０６でデータベース１３０にコミット要求を出しステップ９０８へ移る。

ステップ９０４でトランザクション状態がＡｃｉｖｅの場合はステップ９０８でＤＢＰｒｏｘｙモードか判断する。ＤＢＰｒｏｘｙモードの場合はステップ９１０でＤＢＰｒｏｘｙ１２０にコミット要求を出しステップ９１２に進む。ステップ９０８でＤＢＰｒｏｘｙモードでない場合にはステップ９１２でトランザクション処理終了となる。

図１０に、ロールバック要求時のクライアントの挙動のフローチャートを示す。

ステップ１００２で、ロールバックを要求する際、ステップ１００４でトランザクション状態がＩｎａｃｔｉｖｅかどうか判断する。Ｉｎａｃｔｉｖｅの場合はステップ１００６でデータベースにロールバック要求し、ステップ１００８に進む。Ａｃｔｉｖｅの場合は、ステップ１００８でＤＢＰｒｏｘｙモードかどうかを判断する。ＤＢＰｒｏｘｙモードの場合は、ステップ１０１０でＤＢＰｒｏｘｙにコミット要求し、ステップ１０１２に進む、ＤＢＰｒｏｘｙモードでない場合にはステップ１０１２でトランザクション処理を終了する。

図１１に、照会ＳＱＬ要求受信時のＤＢＰｒｏｘｙの挙動のフローチャートを示す。

ステップ１１０２で、クライアントから照会ＳＱＬを受信する際、ステップ１１０４で、開始済クライアント記憶部にクライアントが含まれるか判断する。含まれる場合には処理はステップ１１１０に進む。含まれない場合にはステップ１１０６で、クライアントを開始待ちクライアント記憶部に追加する。そしてステップ１１０８で、クライアントが開始済みクライアント記憶部に追加されるまで待機する。そしてステップ１１１０で、バッチ待ち照会ＳＱＬ記憶部に照会ＳＱＬを追加する。

図１２に、照会ＳＱＬのバッチ要求時の、ＤＢＰｒｏｘｙの挙動のフローチャートを示す。

ステップ１２０２で、バッチ待ち照会ＳＱＬ記憶部内に照会ＳＱＬが存在するようになる待機する。ステップ１２０４で、バッチ待ち照会ＳＱＬ記憶部内の照会ＳＱＬの１つを選択する。

ステップ１２０６で、開始済クライアント記憶部内の他クライアントが、選択した照会ＳＱＬとバッチ可能なＳＱＬを要求する可能性がないか判断する。可能性がある場合には処理はステップ１２０２に戻る。可能性がない場合にはステップ１２０８でバッチ待ち照会ＳＱＬ記憶部から、照会ＳＱＬとバッチ可能な他クライアントの照会ＳＱＬを消去し、バッチ照会ＳＱＬとしてデータベースに要求する。次にステップ１２１０でデータベースから照会結果を受信し、バッチ照会ＳＱＬに含まれる照会ＳＱＬごとに、照会結果を分割し、要求したクライアントに送信する。

図１３に、トランザクションのコミット要求時のＤＢＰｒｏｘｙの挙動のフローチャートを示す。

ステップ１３０２でクライアントからのコミット要求を待機する。ステップ１３０４で、コミット済クライアント記憶部にクライアントを追加する。

ステップ１３０６でコミット済クライアント記憶部と開始済クライアント記憶部が同じかどうか判断する、同じでない場合、処理はステップ１３１６へ進む。同じ場合はステップ１３０８でデータベースにコミット要求し、ステップ１３１０で、開始済クライアント記憶部の全クライアントに、コミット完了を通知する。

次にステップ１３１２で開始済みクライアント記憶部を消去する。そしてステップ１３１４で開始待ちクライアント記憶部にクライアントが存在するか判断する。存在しない場合には処理は１３０２に戻る。存在する場合にはステップ１３１６で、開始待ちクライアント記憶部の全クライアントを開始済クライアント記憶部に追加する。

以下、図面を参照して、本発明の実施例のシステム構成例を説明する。ここで説明する構成要素は必須の構成要件ではなく、一実施例として説明するものであり、本発明の技術的範囲をこの一実施例に限定して解釈されるものではないことに留意されたい。

図１４を参照すると、本発明の一実施例に係る、クライアント、ＤＢＰｒｏｘｙ、もしくはデータベースのシステム構成を実現するためのコンピュータ・ハードウェアのブロック図が示されている。

図１４において、システム・バス１４０９には、ＣＰＵ１４１０と、主記憶（ＲＡＭ）１４２０と、ハードディスク・ドライブ（ＨＤＤ）１４３０と、ネットワークコントローラ１４４０と、キーボード１４５０と、マウス１４６０と、ディスプレイ１４７０と、オーディオコントローラ１４８０が接続されている。

ＣＰＵ１４１０は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標）４、インテル社のＣｏｒｅ（商標）２ＤＵＯ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１４２０は、好適には、１ＧＢ以上の容量、より好ましくは、２ＧＢ以上の容量をもつものである。

ハードディスク・ドライブ１４３０には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ７、ＷｉｎｄｏｗｓＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃＯＳ（商標）などの、ＣＰＵ１４１０に適合するオペレーティング・システムとして任意のものでよい。

ハードディスク・ドライブ１４３０には、好適にはＯＲＡＣＬＥ（商標）、ＤＢ２（商標）、ＳＱＬＳＥＲＶＥＲ（商標）、ＡＣＣＥＳＳ（商標）などのリレーショナルデータベース・アプリケーションが格納される。これらのアプリケーション、ソフトウェアに限らずＳＱＬを解釈できるものであれば任意に選択できる。そしてこれらのプログラムはオペレータのキーボードやマウス操作に応答して、メイン・メモリ１４２０にロードされて実行される。

キーボード１４５０及びマウス１４６０は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、データベースアプリケーションを開始したり、照会クエリの入力、パラメータの指定を提供するために使用される。

ディスプレイ１４７０は、照会クエリの表示、照会結果の表示等、適宜表示するために使用される。また音声認識ソフトウェアを用いてオーディオコントローラ１４８０通じ、音声により照会クエリを入力するようにしてもよい。

ネットワークコントローラ１４４０はネットワークを通じて、クライアント、ＤＢＰｒｏｘｙ、データベース間で通信を行う。本発明はクライアント、ＤＢＰｒｏｘｙ、が夫々別のハードウェアに存在する必要はない。例えば、ＤＢＰｒｏｘｙとデータベースを１つのコンピュータ・ハードウェア内に構成しても良い。さらにクライアント、ＤＢＰｒｏｘｙ、データベースを１つのデータベースサーバ内に置く態様も可能である。

１１０クライアント
１２０ＤＢＰｒｏｘｙ
１３０データベース
１４０９システム・バス
１４１０ＣＰＵ
１４２０メイン・メモリ
１４２０主記憶
１４３０ハードディスク・ドライブ
１４４０ネットワークコントローラ
１４５０キーボード
１４６０マウス
１４７０ディスプレイ
１４８０オーディオコントローラ

トランザクションは一連の処理（複数のＳＱＬからなる更新・照会クエリ）をまとめてコミット（確定）またはロールバック（取り消し）を行うことができる機能で、これを利用すれば１つのＳＱＬ文が失敗した場合、同じ処理の別のＳＱＬ文をすべて取り消すことができる。ロールバックはつまりトランザクションがコミット前に失敗した場合、更新されたデータを、データベースをトランザクション開始前の状態に戻す処理である。またデッドロックとは、２つ以上のトランザクションの処理中にデータベース内の同じ部分に同時にアクセスすることで、互いの処理の進行を妨げる現象である。例えば、トランザクションＡがデータＸにアクセスし、トランザクションＢがデータＹにアクセスする場合、ＡがＹにアクセスしようとし、ＢがＸにアクセスしようとしたときデッドロックが発生する。この場合どちらのトランザクションも先に進めなくなる。このようなデッドロックを回避するには、両方のトランザクションをキャンセルし、ロールバックする。そして順序を変えて再実行し、デッドロックが再度発生しないようにする。

クライアント数の増加と処理するデータ量の増大に伴い、データベースへのアクセスをより効率化する技術が知られている。特許文献１には、複数のロック制御によって複数のトランザクションの並行的な実行を制御する場合に、連続してなされるロック要求を蓄積し、ロック要求でない要求が出されたとき、この要求を処理する前に、前述の蓄積されたロック要求を一括してデ−タベ−ス・サ−バヘ送信し、ロック処理することによって送信回数を減少させる技術が開示されている。すなわち複数のトランザクション内でのロック要求をまとめる技術である。

特許文献２には、入力された複数のトランザクションを別々に処理するのではなく、入力された複数のトランザクションが処理を行うデータ項目に対して、そのデータ項目を一度だけ検索し、検索したデータ項目に対して、複数のトランザクションの更新処理を順次メイン・メモリ内で行い、最後に更新した結果だけをデータベースに一度だけ書き込む手法を開示している。すなわち複数のトランザクションの更新をまとめる技術である。

さらに、前記方法が、前記データベースから前記集約トランザクションに対する変換したSQL文の結果を受信するステップとを有する。

ステップ１７２０で、全てのＳＥＬＥＣＴ文が返すデータ（カラム）の型を含む、データの型の集合を生成する。この時、同一グループのデータ型について型を増加させず、１つにして異なるグループのデータ型は新しく付加する。すなわち型の集合を作成する時は異なる型のみを追加する。
例では、{INT, DOUBLE,STRING, DATE}となる。

図２の集約クエリ送信後の問題点を図３で説明する。
１．クライアント１は、トランザクション中の照会クエリ（レコードＡを照会ｒ１１）を、ＤＢＰｒｏｘｙ１２０に転送する。
２．クライアント２は、トランザクション中の照会クエリ（レコードＢを照会ｒ２１）を、ＤＢＰｒｏｘｙ１２０に転送する。
３．ＤＢＰｒｏｘｙ１２０は、クライアント１とクライアント２から受信した照会クエリを１つのクエリにまとめ、集約トランザクション（レコードＡとレコードＢを同時照会ｒ１１＋２１）としてデータベース１３０に処理要求する。
４．ここでクライアント１が、同じトランザクション中の更新クエリを更新トランザクション（レコードＡを更新ｗ１２）として、ＤＢＰｒｏｘｙ１２０経由で照会中の集約トランザクション（照会クエリ）とは別に、データベース１３０に要求する。

一方、照会ＳＱＬを要求する場合は、更新データを照会する可能性があるため、Ｐｒｏｘｙ経由で照会できない。この場合のＳＱＬは以下の通りである。
SELECT * FROM TABLE1 WHERE ID=100
また、ＳＱＬ C（ＳＥＬＥＣＴ）のように、クエリからでは更新したデータを判定できない場合も、同様にＰｒｏｘｙ、経由で照会できないと判断する。

ステップ８０２でクライアントが更新ＳＱＬを要求する際は、まず、ステップ８０４でモードがＰｒｏｘｙモードか否かを判断する。
Ｐｒｏｘｙモードの場合は、ステップ７０６で照会ＳＱＬで照会したデータを、更新ＳＱＬが更新する可能性があるかを判断する。

Claims

コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、
複数クライアントから複数トランザクションを受信するステップと、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップ、
を有する、方法。
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、
前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップ、
である、請求項１記載の方法。
前記送信するステップが、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップ、
である、請求項２の方法。
前記方法が、さらに
前記データベースから前記集約トランザクションに対する結果を受信するステップと、
を有する、請求項３記載の方法。
前記方法が、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップと、
を有する、請求項４記載の方法。
前記分割して送信するステップが、
データベースから送信された結果からクライアントＩＤを判断するステップと、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、
前記クライアントＩＤを有するクライアントに照会結果を送信するステップ、
である、請求項５記載の方法。
前記方法が、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、
更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップ、
を有する、請求項１記載の方法。
データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、
複数クライアントから複数トランザクションを受信する手段と、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段、
を有する、システム。
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、
前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段、
である、請求項８記載のシステム。
前記送信する手段が、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段、
である、請求項９のシステム。
前記システムが、さらに
前記データベースから前記集約トランザクションに対する結果を受信する手段、
を有する、請求項１０記載のシステム。
前記システムが、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段、
を有する、請求項１１記載のシステム。
前記分割して送信する手段が、
データベースから送信された結果からクライアントＩＤを判断する手段と、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、
前記クライアントＩＤを有するクライアントに照会結果を送信する手段、
である、請求項１２記載のシステム。
前記システムが、さらに、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、
更新するデータが、集約トランザクションとして照会したかを判断する手段と、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段、
を有する、請求項８記載のシステム。
請求項１〜７記載の何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラム。