JP2011232926A - 分散データベースシステム、デッドロック通知方法およびデッドロック通知プログラム - Google Patents

Abstract

【課題】デッドロックが発生した際の処理効率を向上させる。
【解決手段】分散データベースを構成する複数のデータベースＤＢをそれぞれ管理する複数のサーバ装置１０、２０、３０を有する分散データベースシステム１であって、サーバ装置１０、２０、３０は、デッドロックが発生したか否かを判定する判定部１２３と、判定部１２３によりデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通信部１２１と、を備える。
【選択図】図１

Description

本発明は、分散データベースシステム、デッドロック通知方法およびデッドロック通知プログラムに関する。

下記特許文献１には、分散データベースシステムで発生するデッドロックを検出する技術が開示されている。この従来技術では、ロックの衝突を検知したときに、例えばデータＡのロックの解除待ちをしている側のアプリケーションが既にロックしているデータＢを、データＡのロックを獲得した側のアプリケーションがロックの解除待ちをしている場合に、デッドロックが発生していると判定する。

特開平５−２３３４１４号公報

ところで、デッドロックが発生した場合に、デッドロックに関与する双方のアプリケーションにデッドロックが発生したことを通知すると、双方のアプリケーションがアボートされ、処理効率が低下するおそれがある。上記従来技術では、デッドロックを検出した場合に、デッドロックに関与するアプリケーションの中からアボートするアプリケーションを選択することについては記載されているものの、アボートするアプリケーションを、どのようにして選択するのかについてまでは開示されていない。

本発明は、上述した課題を解決するためになされたものであり、デッドロックが発生した際の処理効率を向上させることができる分散データベースシステム、デッドロック通知方法およびデッドロック通知プログラムを提供することを目的とする。

本発明の分散データベースシステムは、分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムであって、前記サーバ装置は、デッドロックが発生したか否かを判定する判定部と、前記判定部によりデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知部と、を備える。

本発明のデッドロック通知方法は、分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムで実行されるデッドロック通知方法であって、前記サーバ装置が、デッドロックが発生したか否かを判定する判定ステップと、前記判定ステップにおいてデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知ステップと、を含む。

本発明のデッドロック通知プログラムは、上記デッドロック通知方法に含まれる各ステップをコンピュータに実行させる。

本発明によれば、デッドロックが発生した際の処理効率を向上させることができる。

実施形態における分散データベースシステムの構成を例示するブロック図である。 アプリケーション情報テーブルのデータ構成を例示する図である。 レコード情報テーブルのデータ構成を示す図である。 アプリケーションを実行する際の動作の一例を示すシーケンスチャートである。 デッドロック判定処理の処理手順の一例を示すフローチャートである。 アプリケーションを実行する際の動作の一例を示すシーケンスチャートである。

以下、添付図面を参照して、本発明に係る分散データベースシステム、デッドロック通知方法およびデッドロック通知プログラムの好適な実施形態について説明する。

まず、図１を参照して、実施形態における分散データベースシステムの構成について説明する。分散データベースシステム１は、ネットワークで相互に接続される複数のサーバ装置１０、２０、３０を有する。サーバ装置１０、２０、３０は、分散データベースを構成する複数のデータベースＤＢをそれぞれ管理する。ここで、各サーバ装置１０、２０、３０は、それぞれ同一の機能構成を有するため、以下においては、説明の便宜のため、サーバ装置１０の機能構成について説明する。

図１に示すように、実施形態におけるサーバ装置１０は、機能的には、例えば、アプリケーション実行部１１と、サーバ制御部１２と、を有する。サーバ装置１０は、これら各部が用いるデータを記憶する記憶部として、例えば、データベースＤＢと、アプリケーション情報テーブルＴＢ１と、レコード情報テーブルＴＢ２と、を備える。データベースＤＢは、インメモリデータベースであってもよいし、ディスク型データベースであってもよい。アプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２は、後述するデッドロック判定処理で用いるロック情報を記憶する。

ここで、サーバ装置１０は、物理的には、例えば、ＣＰＵ（Central Processing Unit）と、記憶装置と、入出力インターフェースとを含んで構成される。記憶装置には、例えば、ＣＰＵで処理されるプログラムやデータを記憶するＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）、主として制御処理のための各種作業領域として使用されるＲＡＭ（Random Access Memory）等が含まれる。これらの要素は、互いにバスを介して接続されている。ＣＰＵが、ＲＯＭに記憶されたプログラムを実行し、入出力インターフェースを介して受信されたメッセージや、ＲＡＭに展開されたデータを処理することで、後述するサーバ装置１０の各部が有する機能を実現することができる。

図２を参照して、アプリケーション情報テーブルＴＢ１のデータ構成について説明する。アプリケーション情報テーブルＴＢ１は、サーバ装置１０のアプリケーション実行部１１が実行しているアプリケーションごとに、アプリケーションがアクセスするデータベースＤＢのレコードのロック状況に関する情報を管理するテーブルである。アプリケーション情報テーブルＴＢ１は、データ項目として、例えば、アプリケーション識別子項目、ロック中レコード識別子項目、待機中レコード識別子項目および待機開始時刻項目を有する。アプリケーション識別子項目は、アプリケーションを一意に特定する識別情報を格納する。ロック中レコード識別子項目は、アプリケーションがロックしているデータベースＤＢのレコードを一意に特定する識別情報を格納する。待機中レコード識別子項目は、アプリケーションがロックの解除待ちをしているデータベースＤＢのレコードを一意に特定する識別情報を格納する。待機開始時刻項目は、アプリケーションがロックの解除待ちを開始したときの時刻情報を格納する。

アプリケーション情報テーブルＴＢ１は、アプリケーションがデータベースＤＢのレコードをロックしたときや、ロックの解除待ちになったときに更新される。具体的には、アプリケーションがレコードをロックしたときには、そのアプリケーションの識別子に対応するロック中レコード識別子項目に、ロックしたレコードの識別子が格納される。その後、ロックが解除されたときには、解除されたレコードの識別子がロック中レコード識別子項目から削除される。また、アプリケーションがロックの解除待ちになったときには、そのアプリケーションの識別子に対応する待機中レコード識別子項目に、ロックの解除待ちになったレコードの識別子が格納され、そのアプリケーションの識別子に対応する待機開始時刻項目に、ロックの解除待ちを開始したときの時刻情報が格納される。その後、ロックの解除待ちが解消したときには、解除待ちが解消したレコードの識別子が待機中レコード識別子項目から削除され、解除待ちが解消したレコードに対応する時刻情報が待機開始時刻項目から削除される。

図３を参照して、レコード情報テーブルＴＢ２のデータ構成について説明する。レコード情報テーブルＴＢ２は、データベースＤＢのレコードごとに、ロックを要求してきたアプリケーションに関する情報を管理するテーブルである。レコード情報テーブルＴＢ２は、データ項目として、例えば、レコード識別子項目、ロック中ＡＰ識別子項目および待機中ＡＰ識別子項目を有する。レコード識別子項目は、データベースＤＢのレコードを一意に特定する識別情報を格納する。ロック中ＡＰ識別子項目は、レコードをロックしているアプリケーションを一意に特定する識別情報を格納する。待機中ＡＰ識別子項目は、レコードに対してロックの解除待ちをしているアプリケーションを一意に特定する識別情報を格納する。

レコード情報テーブルＴＢ２は、アプリケーションがデータベースＤＢのレコードをロックしたときや、ロックの解除待ちになったときに更新される。具体的には、アプリケーションがレコードをロックしたときには、そのレコードの識別子に対応するロック中ＡＰ識別子項目に、ロックしたアプリケーションの識別子が格納される。その後、ロックが解除されたときには、解除されたアプリケーションの識別子がロック中ＡＰ識別子項目から削除される。また、アプリケーションがロックの解除待ちになったときには、解除待ちのレコードの識別子に対応する待機中ＡＰ識別子項目に、ロックの解除待ちになったアプリケーションの識別子が格納される。その後、ロックの解除待ちが解消したときには、解除待ちが解消したアプリケーションの識別子が待機中ＡＰ識別子項目から削除される。

図１に示すアプリケーション実行部１１は、データベースＤＢのデータ更新を伴う各種のアプリケーションを実行する。サーバ制御部１２は、通信部１２１と、データベース制御部１２２と、判定部１２３と、を有する。

通信部１２１は、アプリケーション実行部１１や他のサーバ装置２０、３０と、サーバ制御部１２との間でやり取りされる各種メッセージやデータの送受信を制御する。各種メッセージとしては、例えば、データベースＤＢのレコードをロックするように要求するロック要求や、ロック要求に応じてロックが正常に行われることを知らせるロック応答、デッドロックが発生したことを知らせるデッドロック通知等が該当する。

データベース制御部１２２は、データベースＤＢ、アプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２へのアクセスやデータ更新を制御する。

判定部１２３は、各サーバ装置１０、２０、３０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２に記憶されたアプリケーション情報およびレコード情報（以下、「ロック情報」という。）に基づいて、デッドロックが発生したか否かを判定する。判定部１２３による判定方法を、以下に、具体的に説明する。

最初に、判定部１２３は、自サーバ装置１０のデータベースＤＢの特定のレコード（例えば「レコードＡ」とする。）でロックの解除待ちが発生した場合、他サーバ装置２０、３０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２に記憶されているロック情報を、他サーバ装置２０、３０からそれぞれ取得する。

続いて、判定部１２３は、上記データＡをロックしているアプリケーション（例えば「アプリケーションＡＰ１」とする。）が、データＡ以外の他のデータでロックの解除待ちをしているか否かを判定する。

判定部１２３は、上記アプリケーションＡＰ１が他のデータでロックの解除待ちをしていると判定した場合、このアプリケーションＡＰ１がロックの解除待ちをしているデータ（例えば「データＢ」とする。）をロックしているアプリケーションが、上記データＡでロックの解除待ちをしているアプリケーション（例えば「アプリケーションＡＰ２」とする。）と同一であるか否かを判定する。

判定部１２３は、上記データＢをロックしているアプリケーションがアプリケーションＡＰ２と同一であると判定した場合に、デッドロックが発生したと判定する。

次に、図４を参照して、本実施形態における分散データベースシステム１でアプリケーションを実行する際の動作について説明する。この動作では、サーバ装置１０のアプリケーション実行部１１がアプリケーションＡＰ１を実行し、サーバ装置２０のアプリケーション実行部１１がアプリケーションＡＰ２を実行している場合について説明する。

最初に、サーバ装置１０のアプリケーション実行部１１は、サーバ装置１０のデータベースＤＢのレコードＡをロックするように要求するロック要求をサーバ装置１０のサーバ制御部１２に送信する（ステップＳ１０１）。

続いて、サーバ装置１０のデータベース制御部１２２は、この時点でサーバ装置１０のデータベースＤＢのレコードＡがいずれのアプリケーションにもロックされていないため、レコードＡをロックし（ステップＳ１０２）、サーバ装置１０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２を更新する。

続いて、サーバ装置１０の通信部１２１は、ロック要求に応じてレコードＡのロックが正常に行われたことを知らせるロック応答をサーバ装置１０のアプリケーション実行部１１に送信する（ステップＳ１０３）。

続いて、サーバ装置２０のアプリケーション実行部１１は、サーバ装置２０のデータベースＤＢのレコードＢをロックするように要求するロック要求をサーバ装置２０のサーバ制御部１２に送信する（ステップＳ１０４）。

続いて、サーバ装置２０のデータベース制御部１２２は、この時点でサーバ装置２０のデータベースＤＢのレコードＢがいずれのアプリケーションにもロックされていないため、レコードＢをロックし（ステップＳ１０５）、サーバ装置２０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２を更新する。

続いて、サーバ装置２０の通信部１２１は、ロック要求に応じてレコードＢのロックが正常に行われたことを知らせるロック応答をサーバ装置２０のアプリケーション実行部１１に送信する（ステップＳ１０６）。

続いて、サーバ装置１０のアプリケーション実行部１１は、サーバ装置２０のデータベースＤＢのレコードＢをロックするように要求するロック要求をサーバ装置１０のサーバ制御部１２に送信する（ステップＳ１０７）。そして、サーバ装置１０の通信部１２１は、同ロック要求をサーバ装置２０に送信する（ステップＳ１０８）。

続いて、サーバ装置２０のデータベース制御部１２２は、この時点でサーバ装置２０のデータベースＤＢのレコードＢがアプリケーションＡＰ２によって既にロックされているため、アプリケーションＡＰ１によるレコードＢへのロック要求を待機させ（ステップＳ１０９）、サーバ装置２０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２を更新する。

続いて、サーバ装置２０の通信部１２１は、ロック情報を送信するように要求するロック情報取得要求を、サーバ装置１０、３０にそれぞれ送信する（ステップＳ１１０、Ｓ１１１）。

続いて、サーバ装置１０、３０の通信部１２１は、サーバ装置１０、３０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２に記憶されているロック情報を、サーバ装置２０にそれぞれ送信する（ステップＳ１１２、Ｓ１１３）。

続いて、サーバ装置２０の判定部１２３は、デッドロック判定処理を実行する（ステップＳ１１４）。デッドロック判定処理の詳細については、後述する。

続いて、サーバ装置２０の通信部１２１は、後述するデッドロック判定処理でデッドロックが発生していないと判定されるため、ロック要求に応じてレコードＢのロックが正常に行われることを知らせるロック応答をサーバ装置１０に送信する（ステップＳ１１５）。そして、サーバ装置１０の通信部１２１は、同ロック応答をアプリケーション実行部１１に送信する（ステップＳ１１６）。

続いて、サーバ装置２０のアプリケーション実行部１１は、サーバ装置１０のデータベースＤＢのレコードＡをロックするように要求するロック要求をサーバ装置２０のサーバ制御部１２に送信する（ステップＳ１１７）。そして、サーバ装置２０の通信部１２１は、同ロック要求をサーバ装置１０に送信する（ステップＳ１１８）。

続いて、サーバ装置１０のデータベース制御部１２２は、この時点でサーバ装置１０のデータベースＤＢのレコードＡがアプリケーションＡＰ１によって既にロックされているため、アプリケーションＡＰ２によるレコードＡへのロック要求を待機させ（ステップＳ１１９）、サーバ装置１０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２を更新する。

続いて、サーバ装置１０の通信部１２１は、ロック情報を送信するように要求するロック情報取得要求を、サーバ装置２０、３０にそれぞれ送信する（ステップＳ１２０、Ｓ１２１）。

続いて、サーバ装置２０、３０の通信部１２１は、サーバ装置２０、３０のアプリケーション情報テーブルＴＢ１およびレコード情報テーブルＴＢ２に記憶されているロック情報を、サーバ装置１０にそれぞれ送信する（ステップＳ１２２、Ｓ１２３）。

続いて、サーバ装置１０の判定部１２３は、デッドロック判定処理を実行する（ステップＳ１２４）。デッドロック判定処理の詳細については、後述する。

続いて、サーバ装置１０の通信部１２１は、後述するデッドロック判定処理においてデッドロックが発生し、デッドロック発生の通知対象としてサーバ装置２０が選択されるため、デッドロックが発生したことを知らせるデッドロック通知をサーバ装置２０に送信する（ステップＳ１２５）。

続いて、サーバ装置２０の通信部１２１は、デッドロックを発生させているアプリケーションＡＰ２をアボートするように要求するアボート要求を、サーバ装置２０のアプリケーション実行部１１に送信する（ステップＳ１２６）。これにより、アプリケーションＡＰ２がアボートされるため、上記ステップＳ１０９でレコードＢのロックの解除待ちをしていたアプリケーションＡＰ１が、レコードＢをロックすることができる。

次に、図５を参照して、上記デッドロック判定処理の処理手順について説明する。この処理手順では、サーバ装置１０がデッドロック判定処理を行う場合について説明する。このデッドロック判定処理は、サーバ装置１０の判定部１２３が、サーバ装置１０のデータベースＤＢの一のレコードにロックの解除待ちが発生したと判定した場合に開始される。

最初に、サーバ装置１０の判定部１２３は、ロックの解除待ちを発生させた一のレコードをロックしているアプリケーションが、他のレコードでロックの解除待ちをしているか否かを判定する（ステップＳ２０１）。この判定がＮＯである場合（ステップＳ２０１；ＮＯ）には、デッドロック判定処理を終了する。

一方、上記ステップＳ２０１の判定において、一のレコードをロックしているアプリケーションが他のレコードでロックの解除待ちをしていると判定された場合（ステップＳ２０１；ＹＥＳ）に、サーバ装置１０の判定部１２３は、当該他のレコードをロックしているアプリケーションが、一のレコードでロックの解除待ちをしているアプリケーションと同一であるか否かを判定する（ステップＳ２０２）。この判定がＮＯである場合（ステップＳ２０２；ＮＯ）には、デッドロック判定処理を終了する。

上記ステップＳ２０２の判定において、他のレコードをロックしているアプリケーションが一のレコードでロックの解除待ちをしているアプリケーションと同一であると判定された場合（ステップＳ２０２；ＹＥＳ）に、サーバ装置１０の判定部１２３は、デッドロックが発生したと判定し、デッドロックを発生させたアプリケーションのうち、アプリケーション情報の待機開始時刻が遅い方のアプリケーションをデッドロック発生の通知対象として選択する（ステップＳ２０３）。

以下に、デッドロック判定処理の具体例について説明する。まず、図４のステップＳ１１４で実行されるデッドロック判定処理について、図５を参照して説明する。

最初に、サーバ装置２０の判定部１２３は、アプリケーションＡＰ１にロックの解除待ちを発生させたレコードＢをロックしているアプリケーションＡＰ２が、他のレコードでロックの解除待ちをしているか否かを判定する（ステップＳ２０１）。この場合、アプリケーションＡＰ２は、レコードＢをロックしているだけであるため、この判定はＮＯとなり（ステップＳ２０１；ＮＯ）、デッドロック判定処理を終了する。つまり、デッドロックは発生していないと判定されることになる。

次に、図４のステップＳ１２４で実行されるデッドロック判定処理について、図５を参照して説明する。

最初に、サーバ装置１０の判定部１２３は、アプリケーションＡＰ２にロックの解除待ちをさせているレコードＡをロックしているアプリケーションＡＰ１が、他のレコードでロックの解除待ちをしているか否かを判定する（ステップＳ２０１）。この場合、アプリケーションＡＰ１は、レコードＡをロックし、レコードＢでロックの解除待ちをしているため、この判定はＹＥＳとなる（ステップＳ２０１；ＹＥＳ）。

続いて、サーバ装置１０の判定部１２３は、他のレコードＢをロックしているアプリケーションが、レコードＡでロックの解除待ちをしているアプリケーションと同一であるか否かを判定する（ステップＳ２０２）。この場合、他のレコードＢをロックしているアプリケーションと、レコードＡでロックの解除待ちをしているアプリケーションは、共にアプリケーションＡＰ２となるため、この判定はＹＥＳとなる（ステップＳ２０２；ＹＥＳ）。

続いて、サーバ装置１０の判定部１２３は、デッドロックが発生したと判定し、デッドロックを発生させたアプリケーションＡＰ１、ＡＰ２のうち、アプリケーション情報の待機開始時刻が遅い方のアプリケーションをデッドロック発生の通知対象として選択する（ステップＳ２０３）。この場合、アプリケーションＡＰ１は、図４のステップＳ１０９で待機を開始し、アプリケーションＡＰ２は、図４のステップＳ１１９で待機を開始しているため、デッドロック発生の通知対象は、アプリケーションＡＰ２が選択されることになる。

ここで、図５のステップＳ２０３において、判定部１２３は、自サーバ装置のアプリケーションに対応する待機開始時刻が、他サーバ装置のアプリケーションに対応する待機開始時刻よりも前の時刻（早い時刻）である場合に、デッドロックが発生したと判定し、他サーバ装置のアプリケーションをデッドロック発生の通知対象として選択することもできる。図４のステップＳ１２４で実行されるデッドロック判定処理を例にして具体的に説明する。

この例の場合、サーバ装置１０の判定部１２３は、自サーバ装置１０のアプリケーションＡＰ１のレコードＢへの待機開始時刻が、他サーバ装置２０のアプリケーションＡＰ２のレコードＡへの待機開始時刻よりも前の時刻となるため、デッドロックが発生したと判定し、他サーバ装置２０のアプリケーションＡＰ２をデッドロック発生の通知対象として選択することになる。

このように処理することで、デッドロックに関与するアプリケーションＡＰ１、ＡＰ２のうち、後からロック要求をしてきた他サーバ装置２０のアプリケーションＡＰ２のみをアボートさせることが可能となる。しかしながら、この処理には、以下の問題がある。

アプリケーションＡＰ１を実行する自サーバ装置１０で計測している時刻が、アプリケーションＡＰ２を実行する他サーバ装置２０で計測している時刻よりも進んでいる場合には、アプリケーションＡＰ１の方がアプリケーションＡＰ２よりも先にロックの解除待ちになったにもかかわらず、アプリケーションＡＰ１に対応する待機開始時刻が、アプリケーションＡＰ２に対応する待機開始時刻よりも後の時刻（遅い時刻）になることがある。この場合には、図４のステップＳ１２４で実行されるデッドロック判定処理において、他サーバ装置２０のアプリケーションＡＰ２の方が自サーバ装置１０のアプリケーションＡＰ１よりも先にロックの解除待ちになったと判定され、デッドロックが発生していないと誤判定されることになる。つまり、デッドロックを見逃してしまうことになる。

これに対して、本実施形態の判定部１２３は、上述した図５のステップＳ２０２でデッドロックの有無を判定し、上述したステップＳ２０３で待機開始時刻が遅い方のアプリケーションをデッドロック発生の通知対象に選択している。これにより、アプリケーションＡＰ１を実行するサーバ装置１０で計測している時刻が、アプリケーションＡＰ２を実行するサーバ装置２０で計測している時刻よりも進んでいる場合であっても、確実にデッドロックの発生を検出し、デッドロックに関与するいずれか一方のアプリケーションにのみデッドロック通知を送信することが可能となる。

図６を参照して、本実施形態における分散データベースシステム１において、アプリケーションＡＰ１を実行するサーバ装置１０で計測している時刻が、アプリケーションＡＰ２を実行するサーバ装置２０で計測している時刻よりも進んでいる場合の動作について説明する。なお、図６に示すステップＳ１０１〜ステップＳ１２３までの各処理は、図４に示すステップＳ１０１〜ステップＳ１２３までの各処理と同様であるため、これら各処理の説明については省略する。

図６に示す処理手順では、アプリケーションＡＰ１が、ステップＳ１０９で待機を開始し、アプリケーションＡＰ２が、ステップＳ１１９で待機を開始しているが、ここでは、サーバ装置１０の時刻がサーバ装置２０の時刻よりも進んでおり、アプリケーションＡＰ１の待機開始時刻が、アプリケーションＡＰ２の待機開始時刻よりも後の時刻（遅い時刻）になっていることとする。

この処理手順では、ステップＳ１２４ａのデッドロック判定処理において、判定部１２３は、デッドロックが発生したと判定し、デッドロックを発生させたアプリケーションＡＰ１、ＡＰ２のうち、アプリケーション情報の待機開始時刻が遅い方のアプリケーションＡＰ１をデッドロック発生の通知対象として選択する（ステップＳ１２４ａ）。

続いて、サーバ装置１０の通信部１２１は、デッドロックが発生したことを知らせるデッドロック通知、およびデッドロックを発生させているアプリケーションＡＰ１をアボートするように要求するアボート要求を、サーバ装置１０のアプリケーション実行部１１に送信する（ステップＳ１２５ａ）。

続いて、サーバ装置１０の通信部１２１は、上記ステップＳ１１８におけるロック要求に応じてレコードＡのロックが正常に行われることを知らせるロック応答をサーバ装置２０に送信する（ステップＳ１２６ａ）。

上述したように、実施形態における分散データベースシステム１によれば、デッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションに対してデッドロックの発生を通知することができる。これにより、デッドロックに関与するいずれか一方のアプリケーションのみをアボートさせることができる。それゆえに、デッドロックが発生した際の処理効率を向上させることができる。

[変形例]
なお、上述した各実施形態は、単なる例示に過ぎず、各実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。

例えば、上述した各実施形態では、データベースＤＢのレコード単位にロックをかけているが、ロックの対象はレコード単位に限定されない。例えば、データベースＤＢのデータ単位であってもよいし、複数のデータ群であるレコード単位やファイル単位であってもよい。

最後に、上記の各実施形態の一部または全部は、以下の付記のようにも記載され得るが、本発明を以下に限定するものではない。

（付記１）分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムであって、前記サーバ装置は、デッドロックが発生したか否かを判定する判定部と、前記判定部によりデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知部と、を備えることを特徴とする分散データベースシステム。

（付記２）前記判定部は、自装置で管理するデータベースの第一のデータでロックの解除待ちが発生した場合に、当該第一のデータをロックしている第一のアプリケーションが、前記第一のデータとは異なる第二のデータでロックの解除待ちをしているか否かを判定する第一の判定部と、前記第一の判定部により前記第一のアプリケーションが前記第二のデータでロックの解除待ちをしていると判定された場合に、当該第一のアプリケーションがロックの解除待ちをしている前記第二のデータをロックしているアプリケーションが、前記第一のデータでロックの解除待ちをしている第二のアプリケーションと同一であるか否かを判定する第二の判定部と、を含み、前記第二の判定部により前記第二のデータをロックしているアプリケーションが、前記第二のアプリケーションと同一であると判定された場合に、デッドロックが発生したと判定する、ことを特徴とする付記１記載の分散データベースシステム。

（付記３）前記サーバ装置は、少なくとも、アプリケーションを特定するためのアプリケーション識別子ごとに、当該アプリケーションがロックしているデータを特定するためのロックデータ識別子、当該アプリケーションがロックの解除待ちをしているデータを特定するための待機データ識別子、および当該アプリケーションがロックの解除待ちを開始した時刻を示す待機開始時刻を対応付けた情報を含むロック情報を記憶する記憶部と、自装置で管理するデータベースの第一のデータでロックの解除待ちが発生した場合に、他装置の前記記憶部により記憶された前記ロック情報を、前記他装置からそれぞれ取得する取得部と、をさらに備え、前記判定部は、前記記憶部により記憶された前記ロック情報および前記取得部により取得された前記ロック情報に基づいて、デッドロックが発生したか否かを判定する、ことを特徴とする付記１または２記載の分散データベースシステム。

（付記４）分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムで実行されるデッドロック通知方法であって、前記サーバ装置が、デッドロックが発生したか否かを判定する判定ステップと、前記判定ステップにおいてデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知ステップと、を含むことを特徴とするデッドロック通知方法。

（付記５）付記４に記載の各ステップをコンピュータに実行させるためのデッドロック通知プログラム。

１…分散データベースシステム、１０、２０、３０…サーバ装置、１１…アプリケーション実行部、１２…サーバ制御部、１２１…通信部、１２２…データベース制御部、１２３…判定部、ＤＢ…データベース、ＴＢ１…アプリケーション情報テーブル、ＴＢ２…レコード情報テーブル。

Claims (5)

1. 分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムであって、
   前記サーバ装置は、
   デッドロックが発生したか否かを判定する判定部と、
   前記判定部によりデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知部と、
   を備えることを特徴とする分散データベースシステム。
2. 前記判定部は、
   自装置で管理するデータベースの第一のデータでロックの解除待ちが発生した場合に、当該第一のデータをロックしている第一のアプリケーションが、前記第一のデータとは異なる第二のデータでロックの解除待ちをしているか否かを判定する第一の判定部と、
   前記第一の判定部により前記第一のアプリケーションが前記第二のデータでロックの解除待ちをしていると判定された場合に、当該第一のアプリケーションがロックの解除待ちをしている前記第二のデータをロックしているアプリケーションが、前記第一のデータでロックの解除待ちをしている第二のアプリケーションと同一であるか否かを判定する第二の判定部と、を含み、
   前記第二の判定部により前記第二のデータをロックしているアプリケーションが、前記第二のアプリケーションと同一であると判定された場合に、デッドロックが発生したと判定する、
   ことを特徴とする請求項１記載の分散データベースシステム。
3. 前記サーバ装置は、
   少なくとも、アプリケーションを特定するためのアプリケーション識別子ごとに、当該アプリケーションがロックしているデータを特定するためのロックデータ識別子、当該アプリケーションがロックの解除待ちをしているデータを特定するための待機データ識別子、および当該アプリケーションがロックの解除待ちを開始した時刻を示す待機開始時刻を対応付けた情報を含むロック情報を記憶する記憶部と、
   自装置で管理するデータベースの第一のデータでロックの解除待ちが発生した場合に、他装置の前記記憶部により記憶された前記ロック情報を、前記他装置からそれぞれ取得する取得部と、
   をさらに備え、
   前記判定部は、前記記憶部により記憶された前記ロック情報および前記取得部により取得された前記ロック情報に基づいて、デッドロックが発生したか否かを判定する、
   ことを特徴とする請求項１または２記載の分散データベースシステム。
4. 分散データベースを構成する複数のデータベースをそれぞれ管理する複数のサーバ装置を有する分散データベースシステムで実行されるデッドロック通知方法であって、
   前記サーバ装置が、
   デッドロックが発生したか否かを判定する判定ステップと、
   前記判定ステップにおいてデッドロックが発生したと判定された場合に、デッドロックを発生させているアプリケーションのうち、ロックの解除待ちを開始した時刻が遅い方のアプリケーションにデッドロックの発生を通知する通知ステップと、
   を含むことを特徴とするデッドロック通知方法。
5. 請求項４に記載の各ステップをコンピュータに実行させるためのデッドロック通知プログラム。

Images