JP6784296B2 - データベース管理装置、データベース管理方法、及びプログラム - Google Patents

Description

本発明は、データベースシステムにおける排他制御を行なうための、データベース管理装置及びデータベース管理方法に関し、更に、これらを実現するためのプログラムに関する。

従来から、データベースにアクセスする複数のアプリケーションプログラム（以下「アプリケーション」と表記する。）が並列に動作する、データベースシステムにおいては、データの整合性を確保するため、排他制御が導入されている（特許文献１及び２参照）。この排他制御によれば、複数のアプリケーションが、同時にデータベースの特定のレコードを更新しようとした場合に、レコードを更新できるアプリケーションは１つに制限される。

また、データベースシステムでは、一般的に、データベースの原子性を保証するために、一連のレコードの更新は、１つのトランザクションとして制御（以下「トランザクション制御」と表記する。）されている。このトランザクション制御においては、１つのトランザクション内で行なわれたレコードの更新は、トランザクション終了時に実行される確定処理（コミット）によって、データベース上で確定される。一方、トランザクションの途中でトランザクションが破棄（ロールバック）された場合は、トランザクション内で行った全てのレコード更新も破棄される。

また、トランザクション制御を行うデータベースにおいて、上述の排他制御は、多くの場合、悲観的ロックによって実現されている。悲観的ロックでは、アプリケーションは、トランザクション内でこれから更新しようとするレコードに対して排他をかけてから（ロックしてから）、レコードを参照および更新する。また、アプリケーションが、特定のレコードに排他をかけようとした際に、既に、別のアプリケーションが、この特定のレコードに排他をかけていた場合は、このアプリケーションは、別のアプリケーションが更新を確定して排他を解除するまで、排他待ちをすることになる。トランザクション内で更新されたレコードデータは、コミットするまで確定されないため、排他はコミットによって解除されることになる。

特開２００３−３０８２１９号公報 特開２０１２−１６４１９０号公報

上述したように、従来のデータベースシステムにおいては、排他制御によって、データの整合性は確保されるが、排他待ちによってアプリケーションの処理性能に悪影響が及ぶという問題がある。即ち、特定のアプリケーションは、レコードを更新する際に、別のアプリケーションが既に排他をかけている場合は、別のアプリケーションのトランザクションがコミットまたはロールバックされるまで待たされることになる。この結果、排他中のトランザクションの完了に時間がかかると、排他待ちをしている特定のアプリケーションによるトランザクションの完了までの時間が長くなってしまい、特定のアプリケーションの処理性能が低下してしまう。

この問題について図１６を用いて説明する。図１６は、従来からのデータベースシステムにおける排他制御を説明するための図である。図１６において、縦軸は時間の経過を表すと共に、アプリケーション１及びアプリケーション２における処理の順序も表している。

図１６の例では、アプリケーション１及びアプリケーション２は、共に、テーブルＡについては、共有レコードを更新するが、テーブルＢについては、それぞれ独立して固有レコードを更新する。具体的には、アプリケーション１は、固有レコード１−１、１−２、１−３を更新し、アプリケーション２は、固有レコード２−１、２−２、２−３を更新する。従って、図１６の例では、アプリケーション１がコミット完了とするまで、アプリケーション２による共有レコード及び固有レコード２−１〜２−３の更新処理は待たされる。

このように、従来のデータベースシステムでは、アプリケーションは、１つのレコードの排他待ちのために、他の排他不要のレコードの更新処理を行うことができなくなるため、処理性能が低下し、処理時間に無駄が生じてしまう。

また、このようなアプリケーション処理の具体例として、並列動作するトランザクションに対して、受付番号のような通番を発行して、各トランザクションに一意の連番を付与し、以降のアプリケーション処理で連番を使用した制御を行うことが挙げられる。この場合、連番はトランザクションが成功した場合にのみ更新され、ロールバックした場合に抜け番を生成しないようにされている。

また、上述の具体例では、連番を管理するレコードを用意し、複数のアプリケーションでそのレコードを排他して更新することが必要となるため、並行動作するトランザクションが連番付与の処理においてシリアライズされてしまう。この問題は、ロールバック時に抜け番を許容するようにすることで対応できるとも考えられるが、以降のアプリケーションの実装においては、抜け番を考慮することが強いられるため、アプリケーションが複雑になるという別の問題が生じてしまう。

本発明の目的の一例は、上記問題を解消し、データベースシステムにおいて並列して処理を実行する複数のアプリケーションプログラムの処理性能の低下を抑制し得る、データベース管理装置、データベース管理方法、及びプログラムを提供することにある。

上記目的を達成するため、本発明の一側面におけるデータベース管理装置は、複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための装置であって、
前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、要求受付部と、
前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、アクセス処理制御部と、
を備え、
前記アクセス処理制御部は、使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、
ことを特徴とする。

また、上記目的を達成するため、本発明の一側面におけるデータベース管理方法は、複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための方法であって、
（ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
（ｂ）前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
（ｃ）使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
を有することを特徴とする。

更に、上記目的を達成するため、本発明の一側面におけるプログラムは、コンピュータによって、複数のアプリケーションプログラムによってアクセスされるデータベースを管理するためのプログラムであって、
前記コンピュータに、
（ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
（ｂ）前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
（ｃ）使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
を実行させる、ことを特徴とする。

以上のように本発明によれば、データベースシステムにおいて並列して処理を実行する複数のアプリケーションプログラムの処理性能の低下を抑制することができる。

図１は、本発明によるデータベースの管理下でのアプリケーションプログラムの動作を説明する図である。 図２は、本発明によるデータベースの管理下でのアプリケーションプログラムの動作を説明する図である。 図３は、本発明によるデータベースの管理下でのアプリケーションプログラムの動作を説明する図である。 図４は、本発明における各アプリケーションプログラムの処理順序と処理結果とを示す図である。 図５は、本発明の実施の形態におけるデータベース管理装置の概略構成を示す図である。 図６は、本発明の実施の形態におけるデータベース管理装置の具体的構成を示すブロック図である。 図７は、本発明の実施の形態で用いられるトランザクション更新管理表の一例を示す図である。 図８は、本発明の実施の形態で用いられるレコード排他管理表の一例を示す図である。 図９は、本発明の実施の形態で用いられるトランザクション依存管理表の一例を示す図である。 図１０は、アプリケーションによる要求が排他ありレコード読み込みである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。 図１１は、アプリケーションによる要求がレコード更新である場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。 図１２は、アプリケーションによる要求がレコードの更新完了である場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。 図１３は、アプリケーションによる要求がコミットである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。 図１４は、アプリケーションによる要求がロールバックである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。 図１５は、本発明の実施の形態におけるデータベース管理装置を実現するコンピュータの一例を示すブロック図である。 図１６は、従来からのデータベースシステムにおける排他制御を説明するための図である。

（発明の概要）
本発明は、同一のレコードを排他的に使用して更新する複数のアプリケーションプログラム（以下「アプリケーション」と表記する）において、レコード排他待ちによる性能低下の影響を抑制して、各アプリケーションの並列実行性能を向上させる。具体的には、本発明では、トランザクション中にレコードの更新完了を宣言するステップが導入される。よって、レコードの更新完了の宣言によって、トランザクション中にレコードの排他的使用が解除され、他のアプリケーションの排他待ちも解除される。この時、両方のアプリケーションのトランザクションの依存関係を管理することで、トランザクションの原子性を保証しつつ、排他待ち時間を短縮することができる。

ここで、図１〜図３を用いて、本発明における処理について説明する。図１〜図３は、それぞれ、本発明によるデータベースの管理下でのアプリケーションプログラムの動作を説明する図である。

図１に示すように、先に対象レコードに排他をかけたアプリケーション１のトランザクションが更新完了を宣言すると、アプリケーション１のトランザクションのコミットが完了していない状態であっても対象レコードの排他が解除される。これにより、排他待ちをしていた別のアプリケーション２のトランザクションは、対象レコードに対して排他をかけることができるようになり、アプリケーション２の排他待ちが解除される。この時、アプリケーション２のトランザクションは、アプリケーション１のトランザクションによって更新されたコミット未完了の対象レコードを参照できる。

従って、図１に示すように、アプリケーション２における排他待ち区間が短くなるため、アプリケーション２のトランザクションの処理時間の短縮効果が得られることになる。また、アプリケーション１のコミットの発行とアプリケーション２のコミットの発行とが同時に起こる可能性があるため、グループコミット機能を適用できる場合も発生する。

また、アプリケーション２のトランザクションは、アプリケーション１のトランザクションによってコミットされていない状態のレコードを参照しているため、本発明では、各トランザクションに依存関係を持たせることで、データベースの原子性を保証する。具体的には、本発明では、下記の（ａ）及び（ｂ）の制御が行なわれる。

（ａ）アプリケーション１のトランザクションより先に、アプリケーション２のトランザクションが終了した場合、アプリケーション１のトランザクションが終了するまで、アプリケーション２のトランザクションを待機させる（図２参照）。
（ｂ）アプリケーション１のトランザクションがロールバックした場合、アプリケーション２のトランザクションのコミットを拒絶し、アプリケーション２のトランザクションにロールバックさせる（図３参照）。

図２に示すように、（ａ）の制御が行なわれると、先にアプリケーション２のトランザクションがコミットを行っても、アプリケーション２のトランザクションは、アプリケーション１のコミット完了を待ち合わせることになる。

図３に示すように、（ｂ）の制御が行なわれると、アプリケーション１のトランザクションがレコードデータ不正などの異常を検知してロールバックしたことにより、アプリケーション２のトランザクションからのコミットが拒絶され、アプリケーション２のトランザクションがロールバックされる。

図４は、本発明における各アプリケーションプログラムの処理順序と処理結果とを示す図である。図４には、アプリケーション１とアプリケーション２とがコミット及びロールバックを実施する順番と、各アプリケーションによる実施の結果とがまとめられている。図４においては、順番１→順番２の順に処理が行われ、矢印の後に記載されている内容が、実施結果を表している。

（実施の形態）
以下、本発明の実施の形態における、データベース管理装置、データベース管理方法、及びプログラムについて、図５〜図１５を参照しながら説明する。

［装置構成］
最初に、図５を用いて、本実施の形態におけるデータベース管理装置の概略構成について説明する。図５は、本発明の実施の形態におけるデータベース管理装置の概略構成を示す図である。

図５に示す、本実施の形態におけるデータベース管理装置３００は、複数のアプリケーションプログラム（以下「アプリケーション」と表記する）１００によってアクセスされるデータベース２００を管理するための装置である。

アプリケーション１００はデータベース２００を利用する任意のアプリケーションであり、データベース２００に対して各種操作を要求する。操作としては、「排他ありレコード読み込み」、「レコード更新」、「更新完了」「コミット」、「ロールバック」、が挙げられる。なお、アプリケーション１００によって要求される操作は、上記に限定されるものではない。本実施の形態において、アプリケーション１００は、従来と同様に、一般的なデータベースに対して要求できる操作を要求することができる。

また、データベース２００は、記憶装置の記憶領域に構築されており、データとして各種テーブルを格納している。また、テーブルは、複数のレコードで構成されている。また、以降の説明において、単に“レコード”と表記したものは、特記しない限りデータベース２００に格納されているレコードを指している。

図５に示すように、データベース管理装置３００は、要求受付部３０１と、アクセス処理制御部３０２とを備えている。このうち、要求受付部３０１は、データベース２００に格納されているレコードに対するアプリケーション１００からの要求を受け付ける。

アクセス処理制御部３０２は、アプリケーション１００からの要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求しているアプリケーション１００に対して、排他的使用を許可する。

また、アクセス処理制御部３０２は、使用を許可されたアプリケーション１００が特定のレコードの更新を完了する旨を宣言した場合に、特定のレコードに対する排他的な使用を解除する。そして、アクセス処理制御部３０２は、使用を許可したアプリケーション１００以外のアプリケーション１００に、特定のレコードの使用を許可する。

このように、本実施の形態では、データベース管理装置３００は、アプリケーションがトランザクションの実行中にレコードの更新完了を宣言した場合は、コミットが完了していなくても、当該アプリケーションによるレコードの排他的使用を解除する。そして、データベース管理装置は、他のアプリケーションに、当該レコードの使用を許可する。このため、本実施の形態によれば、データベースシステムにおいて並列して処理を実行する複数のアプリケーション１００の処理性能の低下を抑制することができる。

ここで、図６〜図９を用いて、本実施の形態におけるデータベース管理装置の具体的構成について説明する。図６は、本発明の実施の形態におけるデータベース管理装置の具体的構成を示すブロック図である。図６において、各処理部間を結ぶ実線は、処理部間でのデータのやり取りを行う関係を表している。また、破線は、管理表とそれを操作する処理部との関係を表している。

図６に示すように、本実施の形態では、データベース管理装置３００は、要求受付部３０１及びアクセス処理制御部３０２に加えて、レコード排他制御部３０３と、依存関係制御部３０４と、ストレージ処理部３０５とを備えている。以下に、各処理部について具体的に説明する。

要求受付部３０１は、上述したように、アプリケーション１００それぞれからの要求を受け付け、受け付けた要求をアクセス処理制御部３０２に渡す。また、要求受付部３０１は、本実施の形態では、複数備えられており、各要求受付部３０１は、複数存在するアプリケーション１００のいずれかと一対一で対応している。

アクセス処理制御部３０２は、本実施の形態では、要求受付部３０１から受け取った要求に応じて、トランザクション更新管理表３０６の制御データを操作する。また、アクセス処理制御部３０２は、後述する各処理部を通して、アクセス処理を制御する。更に、アクセス処理制御部３０２は、要求の種類に応じた処理を行なうため、以下の処理部を有する。

具体的には、本実施の形態では、アクセス処理制御部３０２は、排他あり読み込み処理制御部３１１と、レコード更新処理制御部３１２と、更新完了処理制御部３１３と、コミット処理制御部３１４と、ロールバック処理制御部３１５とを備えている。

排他あり読み込み処理制御部３１１は、アプリケーション１００が排他的なレコードの読み込み（「排他ありレコード読み込み」とも表記する。）を要求した場合に、要求元のアプリケーション１００に対応するトランザクション更新管理表３０６が存在しているかどうかを判定する。また、排他あり読み込み処理制御部３１１は、この場合において、後述のレコード排他制御部３０３による処理結果に基づいて、排他あり読み込みが可能かどうかを判定する。

図７は、本発明の実施の形態で用いられるトランザクション更新管理表の一例を示す図である。図７に示すように、トランザクション更新管理表３０６は、アプリケーション１００のトランザクション内容の管理に用いられる。また、トランザクション更新管理表３０６は、アプリケーション１００毎に設けられている。

図７において、［アプリケーションＩＤ］は、対応するアプリケーション１００を個々に識別する識別子である。アプリケーションＩＤは、例えば、ＵＮＩＸ（登録商標）システムにおけるプロセスＩＤのような識別子である。

［トランザクション状態］は、対応するアプリケーション１００の現在のトランザクションの状態を示している。トランザクション状態には、“有効”と“無効”とがある。“有効”の場合は、アクセス処理制御部３０２は、該当するアプリケーション１００からの全ての要求を受け付ける。“無効”の場合は、アクセス処理制御部３０２は、該当するアプリケーション１００からの要求のうち、ロールバックのみを受け付け、それ以外の要求を拒否する。

［テーブル名］、［キー］、［値］、及び［更新］は、該当するトランザクションによる「排他あり読み込み」及び「更新」の対象となるレコードを識別する情報である。［テーブル名］はレコードのテーブル名を表し、［キー］はレコードの主キー値を表し、［値］はレコードのデータ部値を表している。

［更新］は、対象のレコードが更新されているかどうかを表している。“あり”の場合は更新が行なわれている状態を表し、“なし”の場合は「排他あり読み込み」のみが行なわれた状態を表している。

レコード更新処理制御部３１２は、アプリケーション１００がレコード更新を要求した場合に、要求元アプリケーション１００におけるトランザクション更新管理表３０６を確認する。そして、レコード更新処理制御部３１２は、トランザクション状態が“有効”である場合は、レコード更新要求に応じて、トランザクション更新管理表３０６の該当テーブルの該当レコードの値を更新する。

更新完了処理制御部３１３は、アプリケーション１００がレコード更新完了を要求した場合に、要求元アプリケーション１００におけるトランザクション更新管理表３０６を確認する。そして、更新完了処理制御部３１３は、トランザクション状態が“有効”である場合は、レコード排他制御部３０３に、後述するレコード排他管理表３０７（図８参照）を更新させる。

コミット処理制御部３１４は、アプリケーション１００がトランザクションのコミットを要求した場合に、要求元アプリケーション１００のトランザクション更新管理表３０６を確認する。そして、コミット処理制御部３１４は、トランザクション状態が“有効”である場合は、レコード排他制御部３０３に、後述するレコード排他管理表３０７（図８参照）を更新させる。

ロールバック処理制御部３１５は、アプリケーション１００がロールバックを要求した場合に、依存関係制御部３０４にロールバック処理を要求する。

レコード排他制御部３０３は、図８に示すレコード排他管理表３０７の制御データを操作し、データベース２００のレコードの排他制御を実行する。図８は、本発明の実施の形態で用いられるレコード排他管理表の一例を示す図である。図８に示すように、レコード排他管理表３０７は、データベース２００に格納されているテーブル内の各レコードに対する、アプリケーション１００による排他取得要求の管理と排他状態の管理とに用いられる。また、レコード排他管理表３０７は、複数行の“制御レコード”で構成されている。

以降の説明において、“制御レコード”は、特記しない限り、レコード排他管理表３０７に格納されているレコードを示している。レコード排他管理表３０７は、データベースに格納されているテーブル毎に設けられている。

また、レコード排他管理表３０７において、［テーブル名］は、対象のテーブル名を表している。［キー］は、レコードの主キー値を表している。［要求元］は、該当レコードの排他を要求したアプリケーション１００のアプリケーションＩＤを表している。

［直前要求元］は、該当レコードに対して、要求元アプリケーション１００の直前に排他取得を要求していたアプリケーション１００を表している。［直前要求元］が“なし”となっている場合は、直前に排他要求をしていたアプリケーション１００が存在していないか、既に、直前のアプリケーション１００のトランザクションが完了していることを表している。

また、［キー］が同一となっている制御レコード同士では、一方の［要求元］と他方の［直前要求元］とが一致しており、両者によって、リスト構造が構成され、要求順が管理されている。

［排他状態］は、データベース２００に格納されているレコードに対する要求元アプリケーション１００の排他状態を表している。“排他待ち”は、排他取得待ち状態を表している。“取得中”の場合は排他を取得した状態を表している。“更新完了”は、排他取得後に更新完了を宣言された状態であることを表している。［キー］が同一となっている制御レコードにおいては、“取得中”である制御レコードは必ず１つである。

依存関係制御部３０４は、アプリケーション１００それぞれのトランザクションの依存関係を管理し、アクセス処理制御部３０２による処理の結果に応じて、依存関係を更新する。本実施の形態では、依存関係制御部３０４は、図９に示すトランザクション依存管理表３０８の制御データを操作し、アプリケーション１００間のトランザクション依存関係を制御する。本実施の形態では、依存関係制御部３０４によって、トランザクションの原子性を保証しつつ、排他待ち時間を短縮している。

図９は、本発明の実施の形態で用いられるトランザクション依存管理表の一例を示す図である。図９に示すように、トランザクション依存管理表３０８は、トランザクションの依存関係をグラフ構造で表示しており、現在有効なトランザクション間の依存関係の管理に用いられる。

また、トランザクション依存管理表３０８に示された各ノードには、トランザクションを識別するために、アプリケーションＩＤが表示されている。トランザクション依存管理表３０８は、「アプリケーションＩＤ」を管理しているともいえる。また、トランザクション依存管理表３０８において、矢印は、ノード間の依存関係を表しており、矢印の向きは、親ノードから子ノードの方向に設定されている。

あるアプリケーション１００によって更新完了とされたレコードが、他のアプリケーション１００によって排他取得されたとする。この場合、トランザクション依存管理表３０８においては、更新を完了したアプリケーション１００は親ノードとして表示され、排他取得したアプリケーション１００は子ノードとして表示される。

従って、トランザクション依存管理表３０８によれば、トランザクションがコミット可能かどうかを親ノードの存在によって判断することができる。また、トランザクション依存管理表３０８において、親ノードが存在しなければ、コミットを即時実行できると判断できる。一方、親ノードが存在すれば、親ノードのトランザクションがコミットされるまでコミットの実行を待つべきと判断できる。

更に、トランザクション依存管理表３０８において、コミットが実行されれば、該当ノードは削除され、ロールバックが実行されれば、該当ノードとその子孫ノードとは削除される。また、トランザクション依存管理表３０８では、子孫ノードとは、子ノードとその先の子ノードとの全てを含むノードを意味する。

ストレージ処理部３０５は、データベース２００を構成する記憶装置（ストレージ）に対して、レコードのデータ取得及びデータ更新を実行する。

［動作説明］
次に、本発明の実施の形態におけるデータベース管理装置３００の動作について図１０〜図１４を用いて説明する。また、本実施の形態では、データベース管理装置３００を動作させることによって、データベース管理方法が実施される。よって、本実施の形態におけるデータベース管理方法の説明は、以下のデータベース管理装置３００の動作説明に代える。

また、以下においては、アプリケーション１００による要求が、「排他ありレコード読み込み」、「レコード更新」、「更新完了」、「コミット」、及び「ロールバック」である場合、それぞれについて説明する。

［排他ありレコード読み込み］
最初に、図１０を用いて、アプリケーション１００が排他ありレコード読み込みを要求した場合のデータベース管理装置３００の動作について説明する。図１０は、アプリケーションによる要求が排他ありレコード読み込みである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。以降においては、要求元であるアプリケーション１００のアプリケーションＩＤを“AP001”として説明する。

図１０に示すように、最初に、要求受付部３０１は、アプリケーション１００から、排他ありレコード読み込みの要求を受付ける（ステップＡ１）。具体的には、要求受付部３０１は、アプリケーション１００から、読み込み対象となるテーブルのテーブル名と、読み込み対象レコードのキー値とを、情報として受け取り、受け取った情報を、アクセス処理制御部３０２の排他あり読み込み処理制御部３１１に渡す。

次に、排他あり読み込み処理制御部３１１は、アプリケーションＩＤが要求のあったアプリケーションに該当するトランザクション更新管理表３０６が存在しているかどうかを判定する（ステップＡ２）。具体的には、例えば、要求のあったアプリケーションＩＤが“AP001”であるとすると、排他あり読み込み処理制御部３１１は、アプリケーションＩＤが“AP001”に設定されたトランザクション更新管理表３０６が存在しているどうかを判定する。

ステップＡ２の判定の結果、該当するトランザクション更新管理表３０６が存在しない場合は、排他あり読み込み処理制御部３１１は、アプリケーションＩＤを“AP001”に設定したトランザクション更新管理表３０６を新たに作成する（ステップＡ３）。また、排他あり読み込み処理制御部３１１は、作成したトランザクション更新管理表３０６におけるトランザクション状態を“有効”にする。

一方、ステップＡ２の判定の結果、該当するトランザクション更新管理表３０６が存在する場合、及びステップＡ３の実行後は、排他あり読み込み処理制御部３１１は、トランザクション更新管理表３０６のトランザクション状態が“有効”かどうかを判定する（ステップＡ４）。

ステップＡ４の判定の結果、トランザクション状態が“無効”の場合は、排他あり読み込み処理制御部３１１は、要求受付部３０１を通して、要求のあったアプリケーション１００にエラーを返却する（ステップＡ５）。この場合、データベース管理装置３００における処理は一旦終了する。

一方、ステップＡ４の判定の結果、トランザクション状態が“有効”の場合は、排他あり読み込み処理制御部３１１は、レコード排他制御部３０３に、要求元アプリケーションが求めているレコードの排他状態を確認させる（ステップＡ６）。

具体的には、排他あり読み込み処理制御部３１１は、要求元アプリケーション１００のＩＤ(“AP001”)と、排他対象レコードのテーブル名及びキーの値とを、レコード排他制御部３０３に渡す。これにより、レコード排他制御部３０３は、該当テーブル用のレコード排他管理表３０７から制御レコードを読み込み、排他対象レコードの排他状態を確認する。

次に、レコード排他制御部３０３は、要求元アプリケーション１００以外の別のアプリケーション１００によって、排他対象レコードについて更新完了が宣言されているかどうかを判定する（ステップＡ７）。

ステップＡ７の判定の結果、排他対象レコードについて更新完了が宣言されていない場合は、レコード排他制御部３０３は、排他状態の状況に応じて、排他制御を実行する（ステップＡ８）。一方、ステップＡ７の判定の結果、排他対象レコードについて更新完了が宣言されている場合は、レコード排他制御部３０３は、依存関係制御部３０４に、依存関係の状況に応じて処理を実行させる（ステップＡ９）。

ここで、ステップＡ７〜Ａ９までについて具体的に説明する。まず、ステップＡ７においては、レコード排他制御部３０３は、該当テーブル用のレコード排他管理表３０７から制御レコードを読み込み、排他対象レコードの排他状態を確認する。続いて、レコード排他制御部３０３は、排他状態が、下記のパターン１〜５のいずれに該当するかを判定する。

パターン１：制御レコードがレコード排他管理表３０７に存在しない。
パターン２：［排他状態］が“取得中”の制御レコードが存在し、［要求元］が要求元アプリケーション１００(“AP001”)である。
パターン３：［排他状態］が“取得中”の制御レコードが存在し、［要求元］が要求元アプリケーション１００(“AP001”)とは別のアプリケーション１００である。
パターン４：［排他状態］が“更新完了”の制御レコードのみが存在し、排他取得者が要求元アプリケーション１００(“AP001”)である。
パターン５：［排他状態］が“更新完了”の制御レコードのみが存在し、排他取得者が要求元アプリケーション１００(“AP001”)とは別のアプリケーション１００である。

そして、パターン１〜４に該当する場合は、ステップＡ７においてＮｏとなり、レコード排他制御部３０３は、ステップＡ８を実行する。ステップＡ８の具体的な内容は以下の通りである。

パターン１に該当する場合は、他のアプリケーション１００が該当レコードを排他していないので、要求元のアプリケーション１００は排他取得可能である。また、データベース２００にあるレコードのデータが、そのレコードの最新データである。従って、レコード排他制御部３０３は、該当テーブルのレコード排他管理表３０７に該当レコードの制御レコードを新規に追加し、［要求元］を要求元アプリケーション１００のID(“AP001”)に設定し、［排他状態］を“取得中”に設定する。また、レコード排他制御部３０３は、［直前要求元］を“なし”に設定する。

その後、レコード排他制御部３０３は、排他あり読み込み処理制御部３１１に“排他取得者なし”を返却する。これにより、排他あり読み込み処理制御部３１１は、ストレージ処理部３０５に該当レコードの読み込みを要求し、取得したデータを要求元アプリケーション１００のトランザクション更新管理表３０６に登録する。このとき、［更新］は“なし”とする。その後、排他あり読み込み処理制御部３１１は、要求受付部３０１を通して、要求元アプリケーション１００にレコードデータを渡す。

パターン２に該当する場合は、要求元アプリケーション１００が該当レコードに対して再度排他あり読み込みを行った場合である。この時は、レコード排他制御部３０３は、排他あり読み込み処理制御部３１１に対して、要求元アプリケーション１００のトランザクション更新管理表３０６から該当レコードのデータを取得させる。この後、排他あり読み込み処理制御部３１１は、要求受付部３０１を通して、要求元アプリケーション１００にレコードデータを渡す。

パターン３に該当する場合は、他のアプリケーション１００が排他を取得しているため、排他取得待ちとなる。レコード排他制御部３０３は、該当レコードに対する要求元アプリケーション１００の制御レコードが存在しなければ、レコード排他管理表３０７に制御レコードを新規に追加する。そして、レコード排他制御部３０３は、［要求元］を要求元アプリケーション１００のID(“AP001”)に設定し、［排他状態］を“取得待ち”に設定する。また、レコード排他制御部３０３は、［直前要求元］には、［キー］が同一で、最後に追加された制御レコードの［要求元］を設定する。

一方、レコード排他制御部３０３は、該当レコードに対する要求元アプリケーション１００の制御レコードが既に存在する場合は、制御レコードを追加せず、排他あり読み込み処理制御部３１１に排他中であることを返却する。これにより、排他あり読み込み処理制御部３１１は、要求受付部３０１に、待機後に要求をリトライするように指示する。

パターン４に該当する場合は、要求元アプリケーション１００が一度更新完了を宣言したレコードに対して、再度排他を取得した場合である。一度更新完了を宣言したレコードに対して排他取得は禁止されている。従って、レコード排他制御部３０３は、排他取得不可を、排他あり読み込み処理制御部３１１に返却し、要求受付部３０１を通して、要求元アプリケーション１００に排他取得不可を通知する。

パターン５に該当する場合は、ステップＡ７においてＹｅｓとなり、レコード排他制御部３０３は、ステップＡ９を実行する。具体的には、パターン５に該当する場合は、要求元のアプリケーション１００が、他のアプリケーション１００によって更新完了が宣言されたレコードに対して、排他を取得しようとした場合である。

ここで、更新完了を宣言したアプリケーション１００のIDを“AP002”として、以下に具体例を説明する。この場合、レコード排他制御部３０３は、レコード排他管理表３０７において、該当レコードに対する要求元アプリケーション１００(“AP001”)の制御レコードが存在していた場合は、［排他状態］を“取得待ち”から“取得中”に更新する。一方、該当レコードに対する要求元アプリケーション１００(“AP001”)の制御レコードが存在していない場合は、レコード排他制御部３０３は、同様の制御レコードを新規に追加する。

その後、レコード排他制御部３０３は、アクセス処理制御部３０２の排他あり読み込み処理制御部３１１に対して、排他取得可能を返却し、更に、更新完了を宣言していたアプリケーション１００のID(“AP002”)も返却する。

続いて、アクセス処理制御部３０２において、排他あり読み込み処理制御部３１１は、親ノードが“AP002”となり、子ノードが“AP001”となる場合の依存関係の登録を、依存関係制御部３０４に要求する。依存関係制御部３０４はトランザクション依存管理表３０８を参照して、排他あり読み込み処理制御部３１１からの登録要求に対して登録可能かどうかを確認する。

具体的には、依存関係制御部３０４は、以下のパターン６〜９のいずれかに該当するかを判定し、判定結果に応じた処理を実行する。

パターン６：既に該当する依存関係が登録されている。
パターン７：新規子ノード(“AP001”)に相当するノードが存在しない。
パターン８：新規子ノード(“AP001”)に相当するノードが存在するが、該当する依存関係は登録されていない。また、新規子ノードの子孫ノードとしても、新規親ノード(“AP002”)は存在していない。
パターン９：新規子ノード(“AP001”)に相当するノードが存在するが、該当する依存関係は登録されていない。但し、新規子ノードの子孫ノードとして、新規親ノード(“AP002”)が存在する。

パターン６に該当する場合は、既に別のレコードにおいて、アプリケーション１００“AP002”が更新完了したレコードに対してアプリケーション１００“AP001”が排他を取得していた状態である。従って、既に該当する依存関係が存在するため、依存関係制御部３０４による登録処理は不要である。

パターン７及び８に該当する場合は、排他あり読み込み処理制御部３１１は、要求した依存関係が登録可能な状態であるため、新規に依存関係を登録する。排他あり読み込み処理制御部３１１は、いずれかのノードが存在しなければノードを追加する。

また、パターン６〜８においては、登録が完了すると、依存関係制御部３０４は、排他あり読み込み処理制御部３１１に対して、登録完了を返却する。該当レコードの最新のレコードデータは、更新完了を宣言していたアプリケーション１００(“AP002”)の更新したデータである。

このため、排他あり読み込み処理制御部３１１はアプリケーションIDが“AP002”のトランザクション更新管理表３０６から該当レコードのデータを取得し、取得したデータを、要求受付部３０１を通して、要求元アプリケーション１００(“AP001”)に渡す。これにより、他アプリケーション１００(“AP002”)のトランザクションで更新されたレコードを排他待ちせずに、排他あり読み込みすることが可能になる。

更に、パターン９に該当する場合は、登録要求を受けた依存関係と逆の依存関係が既に登録されている場合である。例えば、既にアプリケーション１００(“AP001”)が更新完了したレコードをアプリケーション１００(“AP002”)が排他取得していた場合が該当する。この場合、依存関係が循環してしまうため、後述するコミット時の親ノードのトランザクション完了待ちにおいて、デッドロックが発生してしまう。そのため、デッドロックにならないように、次に示す処理によって新規親ノードのトランザクションを無効にすることで、デッドロックを解消する。

具体的には、依存関係制御部３０４は、新規親ノード(“AP002”)とその子孫ノードとをトランザクション依存管理表３０８から削除する。その後、排他あり読み込み処理制御部３１１に対して、“再判定”を返却し、削除したノードにあたるアプリケーション１００のID一覧を返却する。

排他あり読み込み処理制御部３１１は、削除したアプリケーション１００全てのトランザクションを無効にするために、該当アプリケーション１００のトランザクション更新管理表３０６のトランザクション状態を“無効”に更新する。

次に、排他あり読み込み処理制御部３１１は、無効にしたアプリケーション１００のＩＤ一覧をレコード排他制御部３０３に渡し、再度排他取得の判定を要求する。レコード排他制御部３０３は、レコード排他管理表３０７を確認し、無効になったアプリケーション１００のＩＤが［要求元］に設定されている制御レコードを削除する。

また、レコード排他制御部３０３は、無効になったアプリケーション１００のＩＤが［直前要求元］に設定されている制御レコードに対して、［直前要求元］の設定値を、削除した制御レコードに設定されていた［直前要求元］の設定値に変更する。つまり、レコード排他制御部３０３は、排他順を管理している制御レコードのリスト構造から、無効になった要求元アプリケーション１００の制御レコードを切り離して、残りの有効な制御レコード同士をつなぎ直す。その後、レコード排他制御部３０３は、該当レコードの制御レコードで、［要求元］が要求元アプリケーション１００であるID(“AP001”)のおける［直前要求元］を確認する。この時、パターンとしては以下の二つがある。

パターン１０：［直前要求元］が“なし”である。
パターン１１：［直前要求元］に他のアプリケーション１００のIDが設定されている。

パターン１０の場合は、トランザクションが有効であり、且つ、該当レコードを更新している他のアプリケーション１００が存在しないため、データベース２００に格納されたレコードデータが最新データになる。これは、上述したパターン１と同じであるため、パターン１の通りの動作を行うことで、要求元アプリケーション１００(“AP001”)に対してレコードデータを返却し、排他取得が成立する。

パターン１１の場合は、トランザクションが有効であり、且つ、該当レコードを更新している他のアプリケーション１００が存在する。このため、要求元アプリケーション１００(“AP001”)は、そのアプリケーション１００の子ノードとしてトランザクション依存関係を登録する必要がある。これは、上述したパターン５と同じであるので、トランザクション依存関係の登録が再実行される。また、この再登録が繰り返し実行されると、最終的にはパターン６、７、８、１０のいずれかのパターンとなって排他取得が完了する。

［レコード更新］
次に、図１１を用いて、アプリケーション１００が排他あり読み込み中のレコードに対してレコード更新を要求した場合のデータベース管理装置３００の動作について説明する。図１１は、アプリケーションによる要求がレコード更新である場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。

図１１に示すように、最初に、要求受付部３０１は、アプリケーション１００から、レコード更新の要求を受け付ける（ステップＢ１）。また、要求受付部３０１は、受付けた要求をアクセス処理制御部３０２のレコード更新処理制御部３１２に渡す。

次に、レコード更新処理制御部３１２は、要求元アプリケーション１００のトランザクション更新管理表３０６を確認し、トランザクション状態が“有効”であるかどうかを判定する（ステップＢ２）。

ステップＢ２の判定の結果、トランザクション状態が“無効”である場合は、レコード更新処理制御部３１２は、要求受付部３０１を通して、要求元アプリケーション１００に更新失敗を通知する（ステップＢ３）。

一方、ステップＢ２の判定の結果、トランザクション状態が“有効”である場合は、レコード更新処理制御部３１２は、トランザクション更新管理表３０６に格納している該当テーブルにおける該当レコードの値を更新し、［更新］を“あり”に更新する（ステップＢ４）。

次に、ステップＢ４の実行後、レコード更新処理制御部３１２は、要求受付部３０１を通して、要求元アプリケーション１００に更新成功を通知する（ステップＢ５）。

［更新完了］
次に、図１２を用いて、アプリケーション１００が排他あり読み込み中のレコードに対してレコードの更新完了を要求した場合のデータベース管理装置３００の動作について説明する。図１２は、アプリケーションによる要求がレコードの更新完了である場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。

図１２に示すように、最初に、要求受付部３０１は、アプリケーション１００から、レコードの更新完了の要求を受け付ける（ステップＣ１）。また、要求受付部３０１は、受付けた要求をアクセス処理制御部３０２の更新完了処理制御部３１３に渡す。

次に、更新完了処理制御部３１３は、要求元アプリケーション１００のトランザクション更新管理表３０６を確認し、トランザクション状態が“有効”であるかどうかを判定する（ステップＣ２）。

ステップＣ２の判定の結果、トランザクション状態が“無効”である場合は、更新完了処理制御部３１３は、要求受付部３０１を通して、要求元アプリケーション１００に失敗を通知する（ステップＣ３）。

一方、ステップＣ２の判定の結果、トランザクション状態が“有効”である場合は、更新完了制御部３１３は、レコード排他制御部３０３に、更新完了を要求する。これにより、レコード排他制御部３０３は、レコード排他管理表３０７を確認し、該当する制御レコードの状態を“取得中”から“更新完了”に更新し、処理完了を返却する（ステップＣ４）。

次に、ステップＣ４の実行後、更新完了処理制御部３１３は、要求受付部３０１を通して、要求元アプリケーション１００に処理完了を通知する（ステップＣ５）。

［コミット］
次に、図１３を用いて、アプリケーション１００がトランザクションのコミットを要求した場合のデータベース管理装置３００の動作について説明する。図１３は、アプリケーションによる要求がコミットである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。

図１３に示すように、最初に、要求受付部３０１は、アプリケーション１００から、トランザクションのコミットの要求を受け付ける（ステップＤ１）。

次に、要求受付部３０１は、受付けた要求をアクセス処理制御部３０２のコミット処理制御部３１４に渡す。これにより、コミット処理制御部３１４は、要求元アプリケーション１００のトランザクション更新管理表３０６を確認し、トランザクション状態が“有効”であるかどうかを判定する（ステップＤ２）。

ステップＤ２の判定の結果、トランザクション状態が“無効”である場合は、コミット処理制御部３１４は、要求受付部３０１を通して、要求元アプリケーション１００にコミット失敗を通知する（ステップＤ３）。

一方、ステップＤ２の判定の結果、トランザクション状態が“有効”である場合は、コミット処理制御部３１４は、依存関係制御部３０４に、要求元アプリケーション１００がコミット可能かどうかの確認を要求する。これにより、依存関係制御部３０４は、要求元アプリケーション１００がコミット可能かどうかを判定する（ステップＤ４）。

具体的には、ステップＤ４では、依存関係制御部３０４は、トランザクション依存管理表３０８を参照し、要求元アプリケーション１００のノードに親ノードが存在しているかどうかを判定する。これは、要求元アプリケーション１００のノードに親ノードが存在する場合は、要求元アプリケーション１００が他のアプリケーション１００の更新完了レコードを排他していて、他のアプリケーション１００がコミット完了していないことを表しているからである。また、要求元アプリケーション１００のノードに親ノードが存在していない場合は、要求元トランザクションは既に他のトランザクションに依存していないため、コミット可能な状態であるからである。

ステップＤ２の判定の結果、コミット可能ではない場合、即ち、親ノードが存在している場合は、依存関係制御部３０４は、親ノードのアプリケーション１００のコミット待ちが必要と判断し、コミット処理制御部３１４に“コミット待ち”を返却する。これにより、コミット処理制御部３１４は、要求受付部３０１に、待機した後で再度ステップＤ２を実行するよう要求する（ステップＤ５）。これにより、要求受付部３０１は、、待機状態となり、設定時間の経過後に、コミット処理制御部３１４に、再度ステップＤ２の判定を実行させる。

一方、ステップＤ２の判定の結果、コミット可能である場合、即ち、親ノードが存在していない場合は、依存関係制御部３０４は、トランザクション依存管理表３０８から、要求元アプリケーション１００のノードを削除し、コミット処理制御部３１４に“コミット可能”を返却する。

これにより、コミット処理制御部３１４は、要求元アプリケーション１００のトランザクション更新管理表３０６を参照し、［更新］が“あり”となっている全てのレコードデータを取り出し、ストレージ処理部３０５に書き込みを要求する。これにより、データベース２００のレコードが更新される（ステップＤ６）。

次に、ステップＤ６による書き込みが完了すると、コミット処理制御部３１４は、要求元アプリケーション１００の排他レコードを解除するために、レコード排他制御部３０３に排他解除を要求する。これにより、レコード排他制御部３０３は、全てのレコード排他管理表３０７から、［要求元］が要求元アプリケーション１００のアプリケーションＩＤである制御レコードを全て削除する（ステップＤ７）。

また、ステップＤ７では、レコード排他制御部［直前要求元］が要求元アプリケーション１００のアプリケーションＩＤである制御レコードに対して、［直前要求元］を“なし”に設定する。レコード排他制御部３０３はコミット処理制御部３１４に完了を通知する。

次に、コミット処理制御部３１４は、依存関係制御部３０４に、要求元アプリケーション１００のトランザクション依存関係の解除を要求する。依存関係制御部３０４はトランザクション依存管理表３０８から、要求元アプリケーション１００のノードを削除する（ステップＤ８）。

次に、ステップＤ７のレコード排他とステップＤ８のトランザクション依存関係の削除とが完了すると、コミット処理制御部３１４は、要求元アプリケーション１００のトランザクション更新管理表３０６を削除する（ステップＤ９）。

そして、コミット処理制御部３１４は、要求受付部３０１を通して、要求元アプリケーション１００にコミット完了を通知する（ステップＤ１０）。

［ロールバック］
最後に、図１４を用いて、ロールバック時におけるデータベース管理装置３００の動作について、説明する。図１４は、アプリケーションによる要求がロールバックである場合の本発明の実施の形態におけるデータベース管理装置の動作を示すフロー図である。

図１４に示すように、最初に、要求受付部３０１は、アプリケーション１００からロールバック要求を受け付ける（ステップＥ１）。また、要求受付部３０１は、受付けた要求をアクセス処理制御部３０２のロールバック処理制御部３１５に渡す。

次に、ロールバック処理制御部３１５は、依存関係制御部３０４にロールバック処理を要求する。依存関係制御部３０４は、ロールバック要求を受け取ると、トランザクション依存管理表３０８を確認し、要求元アプリケーション１００のノードとその子孫のノード全てを削除する（ステップＥ２）。また、ステップＥ２では、依存関係制御部３０４は、削除した子孫のノードにあたるアプリケーション１００のＩＤ一覧をトランザクション無効一覧として、ロールバック処理制御部３１５に返却する。

次に、ロールバック処理制御部３１５は、要求元アプリケーション１００のＩＤと、依存関係制御部３０４から返却されたトランザクションが無効になったアプリケーション１００のＩＤ一覧とを、レコード排他制御部３０３に渡す。そして、ロールバック処理制御部３１５は、レコード排他制御部３０３に、これらのアプリケーション１００のレコード排他の解除を要求する。

これにより、レコード排他制御部３０３は、レコード排他管理表３０７から、渡されたアプリケーションＩＤが［要求元］に設定されている制御レコードを全て削除する（ステップＥ３）。また、渡されたアプリケーションＩＤが［直前要求元］に設定されている制御レコードが存在すれば、レコード排他制御部３０３は、［直前要求元］の値を更新し、レコード排他要求順番のリストをつなぎ直す。

最後に、ロールバック処理制御部３１５は、要求元アプリケーション１００のトランザクション更新管理表３０６を削除する（ステップＥ４）。また、ロールバック処理制御部３１５は、依存関係制御部３０４から受け取ったトランザクション無効一覧にあるアプリケーション１００全てに対して、トランザクション更新管理表３０６の［状態］を“無効”に更新する。これにより、要求元アプリケーション１００が更新完了したレコードに対して排他を取得した別のアプリケーション１００のトランザクションが無効になる。

［実施の形態による効果］
以上のように、本実施の形態では、排他ありレコード読み込み時に、パターン５、及びパターン６〜８の条件が満たされた場合、同一のレコードを排他する複数のアプリケーション１００において、排他取得中のアプリケーション１００のトランザクションがコミットされる前に、別のアプリケーション１００が排他を取得できるようになる。このため、本実施の形態によれば、排他待ち時間が短縮され、データベースシステムにおいて並列して処理を実行する複数のアプリケーション１００の処理性能の低下が抑制される。

［変形例］
続いて、本実施の形態における変形例について説明する。本変形例によれば、同一レコードを排他する２つのトランザクションに対して、グループコミット機能を適用することが可能となる。

ここで、グループコミット機能について説明する。一般に、Oracle（登録商標）又はMySQL（登録商標）などに代表される従来からのデータベースシステムは、複数の完了済みトランザクションをまとめてストレージにコミットするといったグループコミット機能を有している。コミットはストレージへの書き込み等を必要とするコストのかかる処理であるが、グループコミット機能によれば、複数トランザクションのコミット処理を一度に行うことができるので、コミット処理のオーバーヘッドを抑えることが可能となる。よって、グループコミット機能により、トランザクションのスループットの向上が期待できる。

但し、同一レコードを排他するトランザクション同士は、コミット処理がシリアライズされてしまうため、グループコミット機能を用いて、これらのトランザクションを同時に完了させることは不可能である。上述の図１６を用いて説明すると、アプリケーション１のコミットとアプリケーション２のコミットとの間に、共有レコードの排他解除があるため、２つのコミットが同時に起きることはない。

なお、コミットでのストレージ書き込みをバッファリングすれば、同一レコードを排他する２つのトランザクションに対して、グループコミット機能を適用できるようにも考えられる。しかし、この場合は、コミットに対して、ストレージへのデータの永続化が保証されているわけではないため、耐障害性が低下してしまう。

このため、本変形例では、決められた個数のコミット要求が集まった場合に、コミットが行なわれるように、コミット時の制御を行なうことで、グループコミット機能への対応が図られている。以下に具体的に説明する。

本変形例では、コミット処理制御部３１４は、要求受付部３０１からコミット要求を受け取ると、トランザクション状態が“有効”であることを確認した後で、決められた個数のコミット要求が届いているかを確認する。届いていなければ、コミット処理制御部３１４は、他の要求受付部３０１からのコミット要求を受け付けるまで、コミット処理を保留する。既にコミット要求の個数が達している場合は、コミット処理制御部３１４は、コミット処理を進める。

また、コミット処理を進める場合、コミット処理制御部３１４は、依存関係制御部３０４に、コミット要求中のアプリケーション１００のアプリケーションＩＤ一覧を渡し、それぞれについてコミット可能かどうかの判定を要求する。これにより、依存関係制御部３０４は、トランザクション依存管理表３０８を参照し、各アプリケーション１００のノードに親ノードが存在するかを確認する。

親ノードが存在した場合であっても、そのノードがコミット要求中のアプリケーション１００のノードである場合は、依存関係制御部３０４は、コミット可能と判定する。依存関係制御部３０４は、コミット可能なアプリケーション１００とコミット待ちのアプリケーション１００とを判別して、コミット処理制御部３１４に判定結果を返却する。

コミット処理制御部３１４は、コミット可能と判断されたアプリケーション１００について、該当するトランザクション更新管理表３０６に格納された全ての更新データを取得する。そして、取得された更新データの中に、テーブル名とレコードのキー値とが一致する複数の更新データが存在するとする。この場合、コミット処理制御部３１４は、依存関係制御部３０４に対して、その更新レコードを更新していた複数のアプリケーション１００のうち、トランザクション依存関係において最も下層の子ノードとなるものがいずれであるかを確認するよう要求する。

最も下層の子ノードに該当するアプリケーション１００を確認できると、コミット処理制御部３１４は、該当するアプリケーション１００のレコードデータのみを残し、親ノードのアプリケーション１００が更新していた同一レコードデータについては破棄する。これは、データベース２００において、同一レコードを更新する場合は、最も新しいレコードのみを更新する必要があるためである。また、最も下層の子ノードであるアプリケーション１００のトランザクション更新管理表３０６が、最も新しいレコードデータを保持している。

そして、コミット処理制御部３１４は、全ての更新後のレコードデータが揃うと、ストレージ処理部３０５にデータベース２００への書き込みを要求する。また、コミット処理制御部３１４は、データベース２００への書き込みが完了すると、レコード排他制御部３０３にコミットを実行したアプリケーション１００の排他解除を要求し、更に、依存関係制御部３０４に依存関係削除を要求する。

また、コミット処理制御部３１４は、それぞれの制御レコードが削除できたら、要求受付部３０１を通して、コミット完了した全てのアプリケーション１００に対し、コミット完了を通知する。

これにより、同一レコードを排他する複数のアプリケーション１００がグループコミットによってまとめてコミットすることが可能になる。

［デッドロックとその回避策］
ここで、本実施の形態で発生する可能生のあるデッドロックとその回避策とについて説明する。上述した排他ありレコード読み込みにおけるパターン９は、トランザクション依存関係によるデッドロックが発生している状態である。

一般的にデッドロックは、２つのトランザクションが２つのレコード（例えば、レコードＡとレコードＢとする）を排他する際に、一方のトランザクションがレコードＡ→レコードＢの順に排他取得し、もう一方のトランザクションがレコードＢ→レコードＡの順に排他取得するような場合に発生する。

そして、このような場合においては、全てのトランザクションにおいて、レコードの排他取得順を統一することで、デッドロックが発生しないようにできる。しかしながら、本実施の形態では、レコードの排他取得順を統一したとしてもデッドロックが発生する可能性がある。例えば、２つのトランザクション（例えば、トランザクション１とトランザクション２とする）が、レコードＡ→レコードＢという順番で排他を取得する場合を考える。

トランザクション１が、レコードＡを排他して更新した直後に更新完了を宣言する。別のトランザクション２が、トランザクション１の更新完了後にレコードＡを排他して更新し、更新完了を宣言する。その後、トランザクション２がトランザクション１よりも先にレコードＢの排他を取得して更新し、更新完了を宣言する。その後、トランザクション１がレコードＢの排他を取得する。この時、トランザクション１とトランザクション２との依存関係が循環するため、本実施の形態では、片方または両方のトランザクションが無効となる。

このようなトランザクションの異常が発生しないようにするには、レコードＡの排他を取得して更新した後すぐには、レコードＡを更新完了をせず、レコードＢの排他を取得した後でレコードＡの更新完了を宣言すればいい。つまり、トランザクション１がレコードＢを排他した後でレコードＡの更新完了をすることで、トランザクション２は、トランザクション１よりも先にレコードＢを排他することを防ぐことができる。このため、本実施の形態では、上述の処理が行なわれる。

［プログラム］
本実施の形態におけるプログラムは、コンピュータに、図１０に示すステップＡ１〜Ａ９、図１１に示すステップＢ１〜Ｂ５、図１２に示すステップＣ１〜Ｃ５、図１３に示すステップＤ１〜Ｄ１０、図１４に示すステップＥ１〜Ｅ４を実行させるプログラムであれば良い。このプログラムをコンピュータにインストールし、実行することによって、本実施の形態におけるデータベース管理装置３００とデータベース管理方法とを実現することができる。この場合、コンピュータのＣＰＵ（Central Processing Unit）は、要求受付部３０１、アクセス処理制御部３０２、レコード排他制御部３０３、依存関係制御部３０４、及びストレージ処理部３０５として機能し、処理を行なう。

また、本実施の形態におけるプログラムは、複数のコンピュータによって構築されたコンピュータシステムによって実行されても良い。この場合は、例えば、各コンピュータが、それぞれ、要求受付部３０１、アクセス処理制御部３０２、レコード排他制御部３０３、依存関係制御部３０４、及びストレージ処理部３０５のいずれかとして機能しても良い。また、記憶部５０は、本実施の形態におけるプログラムを実行するコンピュータとは別のコンピュータ上に構築されていても良い。

［物理構成］
ここで、本実施の形態におけるプログラムを実行することによって、データベース管理装置３００を実現するコンピュータについて図１５を用いて説明する。図１５は、本発明の実施の形態におけるデータベース管理装置を実現するコンピュータの一例を示すブロック図である。

図１５に示すように、コンピュータ１１０は、ＣＰＵ１１１と、メインメモリ１１２と、記憶装置１１３と、入力インターフェイス１１４と、表示コントローラ１１５と、データリーダ／ライタ１１６と、通信インターフェイス１１７とを備える。これらの各部は、バス１２１を介して、互いにデータ通信可能に接続される。

ＣＰＵ１１１は、記憶装置１１３に格納された、本実施の形態におけるプログラム（コード）をメインメモリ１１２に展開し、これらを所定順序で実行することにより、各種の演算を実施する。メインメモリ１１２は、典型的には、ＤＲＡＭ（Dynamic Random Access Memory）等の揮発性の記憶装置である。また、本実施の形態におけるプログラムは、コンピュータ読み取り可能な記録媒体１２０に格納された状態で提供される。なお、本実施の形態におけるプログラムは、通信インターフェイス１１７を介して接続されたインターネット上で流通するものであっても良い。

また、記憶装置１１３の具体例としては、ハードディスクドライブの他、フラッシュメモリ等の半導体記憶装置が挙げられる。入力インターフェイス１１４は、ＣＰＵ１１１と、キーボード及びマウスといった入力機器１１８との間のデータ伝送を仲介する。表示コントローラ１１５は、ディスプレイ装置１１９と接続され、ディスプレイ装置１１９での表示を制御する。

データリーダ／ライタ１１６は、ＣＰＵ１１１と記録媒体１２０との間のデータ伝送を仲介し、記録媒体１２０からのプログラムの読み出し、及びコンピュータ１１０における処理結果の記録媒体１２０への書き込みを実行する。通信インターフェイス１１７は、ＣＰＵ１１１と、他のコンピュータとの間のデータ伝送を仲介する。

また、記録媒体１２０の具体例としては、ＣＦ（CompactFlash（登録商標））及びＳＤ（Secure Digital）等の汎用的な半導体記憶デバイス、フレキシブルディスク（Flexible Disk）等の磁気記録媒体、又はＣＤ−ＲＯＭ（Compact DiskRead Only Memory）などの光学記録媒体が挙げられる。

なお、本実施の形態におけるデータベース管理装置３００は、プログラムがインストールされたコンピュータではなく、各部に対応したハードウェアを用いることによっても実現可能である。更に、データベース管理装置３００は、一部がプログラムで実現され、残りの部分がハードウェアで実現されていてもよい。

上述した実施の形態の一部又は全部は、以下に記載する（付記１）〜（付記１２）によって表現することができるが、以下の記載に限定されるものではない。

（付記１）
複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための装置であって、
前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、要求受付部と、
前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、アクセス処理制御部と、
を備え、
前記アクセス処理制御部は、使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、
ことを特徴とするデータベース管理装置。

（付記２）
前記アクセス処理制御部は、使用を許可された前記アプリケーションプログラムが、トランザクションの途中で、前記特定のレコードの更新を完了する旨を宣言した場合でも、前記特定のレコードに対する排他的な使用を解除する、
付記１に記載のデータベース管理装置。

（付記３）
前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、依存関係制御部を更に備え、
前記依存関係制御部は、前記アクセス処理制御部による処理の結果に応じて、前記依存関係を更新する、
付記２に記載のデータベース管理装置。

（付記４）
前記アクセス処理制御部が、前記要求がトランザクションのコミットである場合に、要求されたコミットの数が設定数以上であることを条件に、要求している前記アプリケーション全てのトランザクションをコミットする、
付記１〜３のいずれかに記載のデータベース管理装置。

（付記５）
複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための方法であって、
（ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
（ｂ）前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
（ｃ）使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
を有することを特徴とするデータベース管理方法。

（付記６）
前記（ｃ）のステップにおいて、使用を許可された前記アプリケーションプログラムが、トランザクションの途中で、前記特定のレコードの更新を完了する旨を宣言した場合でも、前記特定のレコードに対する排他的な使用を解除する、
付記５に記載のデータベース管理方法。

（付記７）
（ｄ）前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、ステップを更に有し、
前記（ｄ）のステップにおいて、前記（ｂ）及び（ｃ）のステップによる処理の結果に応じて、前記依存関係を更新する、
付記６に記載のデータベース管理方法。

（付記８）
（ｅ）前記要求がトランザクションのコミットである場合に、要求されたコミットの数が設定数以上であることを条件に、要求している前記アプリケーション全てのトランザクションをコミットする、ステップを更に有する、
付記５〜７のいずれかに記載のデータベース管理方法。

（付記９）
コンピュータによって、複数のアプリケーションプログラムによってアクセスされるデータベースを管理するためのプログラムであって、
前記コンピュータに、
（ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
（ｂ）前記要求が特定のレコードに対する排他的使用である場合に、一定条件を満たすことを条件に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
（ｃ）使用を許可された前記アプリケーションプログラムが前記特定のレコードの更新を完了する旨を宣言した場合に、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
を実行させる、プログラム。

（付記１０）
前記（ｃ）のステップにおいて、使用を許可された前記アプリケーションプログラムが、トランザクションの途中で、前記特定のレコードの更新を完了する旨を宣言した場合でも、前記特定のレコードに対する排他的な使用を解除する、
付記９に記載のプログラム。

（付記１１）
前記コンピュータに、
（ｄ）前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、ステップを更に実行させ、
前記（ｄ）のステップにおいて、前記（ｂ）及び（ｃ）のステップによる処理の結果に応じて、前記依存関係を更新する、
付記１０に記載のプログラム。

（付記１２）
前記コンピュータに、
（ｅ）前記要求がトランザクションのコミットである場合に、要求されたコミットの数が設定数以上であることを条件に、要求している前記アプリケーション全てのトランザクションをコミットする、ステップを更に実行させる、
付記９〜１１のいずれかに記載のプログラム。

以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は、２０１６年９月２０日に出願された日本出願特願２０１６−１８３４９２を基礎とする優先権を主張し、その開示の全てをここに取り込む。

以上のように本発明によれば、データベースシステムにおいて並列して処理を実行する複数のアプリケーションプログラムの処理性能の低下を抑制することができる。本発明は、大量のトランザクションを高速に処理するシステム、例えば、航空管制システムに代表される追跡システム、勘定系システム等に有用である。

１００ アプリケーションプログラム
１１０ コンピュータ
１１１ ＣＰＵ
１１２ メインメモリ
１１３ 記憶装置
１１４ 入力インターフェイス
１１５ 表示コントローラ
１１６ データリーダ／ライタ
１１７ 通信インターフェイス
１１８ 入力機器
１１９ ディスプレイ装置
１２０ 記録媒体
１２１ バス
２００ データベース
３００ データベース管理装置
３０１ 要求受付部
３０２ アクセス処理制御部
３０３ レコード排他制御部
３０４ 依存関係制御部
３０５ ストレージ処理部
３０６ トランザクション更新管理表
３０７ レコード排他管理表
３０８ トランザクション依存管理表
３１１ 排他あり読み込み処理制御部
３１２ レコード更新処理制御部
３１３ 更新完了処理制御部
３１４ コミット処理制御部
３１５ ロールバック処理制御部

Claims (4)

1. 複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための装置であって、
   前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、要求受付部と、
   前記要求が特定のレコードに対する排他的使用である場合であって、排他的使用を許可するための前提条件を満たす場合に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、アクセス処理制御部と、
   前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、依存関係制御部と、
   を備え、
   前記アクセス処理制御部は、使用を許可された前記アプリケーションプログラムが排他的使用によるトランザクションの続行中に、前記特定のレコードの更新を完了する旨を宣言した場合に、使用を許可された前記アプリケーションプログラムと、使用を許可された前記アプリケーションプログラム以外のアプリケーションプログラムとの関係を、新規の依存関係として、前記依存関係制御部に登録させ、そして、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、
   ことを特徴とするデータベース管理装置。
2. 前記アクセス処理制御部が、前記要求がトランザクションのコミットである場合に、要求されたコミットの数が設定数以上であることを条件に、要求している前記アプリケーション全てのトランザクションをコミットする、
   請求項１に記載のデータベース管理装置。
3. 複数のアプリケーションプログラムによってアクセスされるデータベースを管理するための方法であって、
   （ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
   （ｂ）前記要求が特定のレコードに対する排他的使用である場合に、排他的使用を許可するための前提条件を満たす場合に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
   （ｃ）前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、ステップと、
   （ｄ）使用を許可された前記アプリケーションプログラムが排他的使用によるトランザクションの続行中に、前記特定のレコードの更新を完了する旨を宣言した場合に、使用を許可された前記アプリケーションプログラムと、使用を許可された前記アプリケーションプログラム以外のアプリケーションプログラムとの関係を、新規の依存関係として登録し、そして、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
   を有することを特徴とするデータベース管理方法。
4. コンピュータによって、複数のアプリケーションプログラムによってアクセスされるデータベースを管理するためのプログラムであって、
   前記コンピュータに、
   （ａ）前記データベースに格納されているレコードに対する前記アプリケーションプログラムからの要求を受け付ける、ステップと、
   （ｂ）前記要求が特定のレコードに対する排他的使用である場合に、排他的使用を許可するための前提条件を満たす場合に、排他的使用を要求している前記アプリケーションプログラムに対して、排他的使用を許可する、ステップと、
   （ｃ）前記複数のアプリケーションプログラムそれぞれのトランザクションの依存関係を管理する、ステップと、
   （ｄ）使用を許可された前記アプリケーションプログラムが排他的使用によるトランザクションの続行中に、前記特定のレコードの更新を完了する旨を宣言した場合に、使用を許可された前記アプリケーションプログラムと、使用を許可された前記アプリケーションプログラム以外のアプリケーションプログラムとの関係を、新規の依存関係として登録し、そして、前記特定のレコードに対する排他的な使用を解除して、使用を許可した前記アプリケーションプログラム以外のアプリケーションプログラムに、前記特定のレコードの使用を許可する、ステップと、
   を実行させる、プログラム。

Images