通信装置管理システムおよびデータベースアクセス処理方法
【課題】レコードの競合やデッドロックを回避しつつ処理負荷の軽減が可能な通信装置管理システムを得ること。
【解決手段】同一テーブルの同一レコードにアクセスするＣＭＤＢ処理要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合に、ＣＭＤＢ処理要求を受信し、ＣＭＤＢ処理要求に記載されているテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて受信したＣＭＤＢ処理要求の振り分け先を決定する振分処理部１０と、ハッシュ計算値ごとに同一のハッシュ計算値のＣＭＤＢ処理要求を格納するＤＢ処理要求キュー１１〜１３と、ＤＢ処理要求キュー１１〜１３ごとに格納されたＣＭＤＢ処理要求を取り出して構成管理データベース１７に対するアクセス処理を行うＤＢ処理部１４〜１６と、を備える。
【解決手段】同一テーブルの同一レコードにアクセスするＣＭＤＢ処理要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合に、ＣＭＤＢ処理要求を受信し、ＣＭＤＢ処理要求に記載されているテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて受信したＣＭＤＢ処理要求の振り分け先を決定する振分処理部１０と、ハッシュ計算値ごとに同一のハッシュ計算値のＣＭＤＢ処理要求を格納するＤＢ処理要求キュー１１〜１３と、ＤＢ処理要求キュー１１〜１３ごとに格納されたＣＭＤＢ処理要求を取り出して構成管理データベース１７に対するアクセス処理を行うＤＢ処理部１４〜１６と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構成管理データベースに対して並列処理を行う通信装置管理システムに関する。
【背景技術】
【０００２】
従来、通信装置管理システム（ＥＭＳ：Element Management System）に対して、非同期に発生する複数の構成管理データベース（ＣＭＤＢ：Configuration Management Database）の更新／参照処理要求（以下、ＣＭＤＢ処理要求とする）を効率的に負荷分散するため、一連の複数のレコードアクセスであるトランザクション単位で複数のキューにランダムに分散して振り分け、キュー毎に起動されたデータベースアクセス処理アプリケーションプロセス群が、各キューに登録された要求をひとつずつ順番に取り出してＣＭＤＢアクセス処理を行っている。
【０００３】
ＣＭＤＢ処理要求をトランザクション単位で各キューに割り振る場合、同一レコードに対する処理要求を含む複数のトランザクションが異なるキューに振り分けられるため、同一レコードに対する競合が発生する。また、各トランザクション内のレコードの更新／参照順序が異なると、実行順序によってデッドロックが発生する。そのため、定期的にデッドロック状態を監視し、デッドロック発生時は、デッドロックを発生させているトランザクションによるＣＭＤＢ処理要求をリセットし、再度ＣＭＤＢ処理要求を発行し直す必要がある。デッドロック状態を監視するプロセスを定期的に起動し、デッドロック発生時は処理負荷が高くなるため、応答性能が悪化する等の問題が生じていた。
【０００４】
このような問題の解決策として、ＣＭＤＢ処理キューを一元化する方式がある。ＥＭＳに対して非同期に発生する複数のＣＭＤＢ処理要求間の競合やデッドロックを回避するため、ＣＭＤＢ処理要求を単一のキュー（待ち行列）に一元的に集約し、先頭から登録された順序で処理する。しかしながら、単一キュー方式では、ＣＭＤＢ処理要求が大量に発生して負荷が増大した場合、並列処理して負荷分散する本来の目的の実現が困難であった。
【０００５】
そこで、同一レコードに対するＣＭＤＢ処理要求ごとにキューに割り振る方法が考えられる。例えば、ＣＭＤＢ処理要求が対象とするデータベース上のレコードキーにハッシュ関数を使用する方法である。具体的に、データベースへの更新／参照要求の処理においてハッシュ関数を適用する技術が、下記特許文献１〜４において開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平５−０４６４５４号公報
【特許文献２】特開平５−２９８３６６号公報
【特許文献３】特開２０００−１８７６６８号公報
【特許文献４】特開２０００−２５０９２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来の技術によれば、登録後のレコード状態の分散化や平均化、アクセス頻度の平滑化や検索の迅速性等の登録後の処理を目的としてハッシュ関数を使用するものである。そのため、レコード更新処理を目的とするＣＭＤＢ処理要求が大量に発生した場合には更新対象が競合するため、並列処理を実行しても処理負荷を軽減することができない、という問題があった。
【０００８】
本発明は、上記に鑑みてなされたものであって、レコードの競合やデッドロックを回避しつつ、処理負荷の軽減が可能な通信装置管理システムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明は、構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システムであって、同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、他装置からのアクセス要求を受信し、当該アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて、受信したアクセス要求の振り分け先を決定する振分処理手段と、複数のキューを備え、ハッシュ計算値ごとに、同一のハッシュ計算値のアクセス要求を同一キューに格納する格納手段と、前記キューごとに、格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理手段と、を備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、レコードの競合やデッドロックを回避しつつ、処理負荷を軽減できる、という効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】図１は、通信装置管理システムの構成例を示す図である。
【図２】図２は、構成管理ＤＢの更新処理を示すフローチャートである。
【図３】図３は、通信装置管理システムの構成例を示す図である。
【図４】図４は、通信装置管理システムの構成例を示す図である。
【図５】図５は、構成管理ＤＢの更新処理を示すフローチャートである。
【図６】図６は、通信装置管理システムの接続例を示す図である。
【発明を実施するための形態】
【００１２】
以下に、本発明にかかる通信装置管理システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１３】
実施の形態１．
図１は、通信装置管理システム（ＥＭＳ：Element Management System）の構成例を示す図である。通信装置管理システム１は、同時に発生する複数のＣＭＤＢ（Configuration Management Database）処理要求に対して、競合を防止しつつ並行して処理する。ＣＭＤＢ処理要求は、通信装置管理システム１が備える構成管理データベース（ＣＭＤＢ)に対する更新／参照処理を要求するメッセージである。ここでは、トランザクション単位が、１レコード単位の更新／参照とする簡易なシステムとする。なお、ＣＭＤＢ処理要求を送信する装置として、上位管理アプリケーション装置２と、ＥＭＳ利用者端末３と、管理対象通信装置４を想定する。
【００１４】
通信装置管理システム１は、振分処理部１０と、データベース（ＤＢ）処理要求キュー１１〜１３と、データベース（ＤＢ）処理部１４〜１６と、構成管理データベース（ＤＢ）１７と、を備える。振分処理部１０は、上位管理アプリケーション装置２等からのＣＭＤＢ処理要求に対してハッシュ関数の計算を行い、計算結果に基づいて振り分け処理を行う。ＤＢ処理要求キュー１１〜１３は、振り分けされたＣＭＤＢ処理要求を登録する。ＤＢ処理部１４〜１６は、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出してアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。構成管理ＤＢ１７は、システムに関する情報を管理するデータベースである。
【００１５】
構成管理ＤＢ１７は、テーブル１８、１９を備える。テーブル１８、１９は、データベース上に登録されているリレーショナルデータベーステーブルである。レコード１８１、１８２、１８３は、テーブル１８に登録されたレコードを示し、レコード１９１、１９２、１９３は、テーブル１９に登録されたレコードを示す。
【００１６】
つづいて、通信装置管理システム１の動作について説明する。図２は、通信装置管理システムにおける構成管理ＤＢ１７の更新処理を示すフローチャートである。まず、上位管理アプリケーション装置２、ＥＭＳ利用者端末３、および管理対象通信装置４においてＣＭＤＢ処理要求が非同期に複数発生する。ここでは、上位管理アプリケーション装置２、ＥＭＳ利用者端末３、管理対象通信装置４の順に各装置がＣＭＤＢ処理要求を送信する。なお、上位管理アプリケーション装置２およびＥＭＳ利用者端末３からのＣＭＤＢ処理要求はテーブル１８のレコード１８１に対するレコード更新要求、管理対象通信装置４からのＣＭＤＢ処理要求はテーブル１９のレコード１９２に対するレコード更新要求とする。
【００１７】
通信装置管理システム１では、振分処理部１０において、各装置から送信されたＣＭＤＢ処理要求を受け付ける（ステップＳ１）。振分処理部１０は、ＣＭＤＢ処理要求に付与されているＤＢ処理対象のテーブル識別子、レコード識別子を元にハッシュ関数により計算処理を実行し（ステップＳ２）、計算結果に基づいて、受け付けたＣＭＤＢ処理要求を各ＤＢ処理要求キューに登録する（ステップＳ３）。テーブル識別子は各テーブルに通番で振られるテーブル番号とし、レコード識別子はレコードキー番号と定義する。また、ハッシュ関数の計算結果の値は、入力値を元にアクセス要求キュー番号に一意に対応するように設定する。
【００１８】
ここでは、３つのＤＢ処理要求キューが存在するので、テーブル番号とレコードキーの和を３で割った余りをハッシュ計算結果値とする。具体的に、以下の式（１）の様に定義する。
ハッシュ関数 Ｆ（ｘ、ｙ、ｚ）＝ＭＯＤ（ｘ＋ｙ、ｚ） …（１）
（ｘ＝テーブル番号、ｙ＝レコードキー番号、ｚ＝ＤＢ処理要求キュー数）
本実施の形態ではｚ＝３となる。すなわち、振分処理部１０は、ハッシュ値が２の場合はＤＢ処理要求キュー１１、ハッシュ値が１の場合はＤＢ処理要求キュー１２、ハッシュ値が０の場合はＤＢ処理要求キュー１３の各ＤＢ処理要求キューに振り分ける。
【００１９】
計算の簡素化のため、テーブル１８のテーブル番号を１、レコード１８１〜１８３のレコードキー番号を１〜３とし、テーブル１９のテーブル番号を２、レコード１９１〜１９３のレコードキー番号を１〜３とする。上記式（１）を適用すると、上位管理アプリケーション装置２、ＥＭＳ利用者端末３からのＣＭＤＢ処理要求に対するハッシュ値は、（テーブル番号１＋レコードキー番号１）＝２の数値を３で割った余りとして計算結果２を得る。振分処理部１０は、２件とも、ハッシュ値２であるため、ＤＢ処理要求キュー１１に登録する。同様に、管理対象通信装置４からのＣＭＤＢ処理要求に対するハッシュ値は、（テーブル番号２＋レコードキー番号２）＝４を３で割った余りとして計算結果１を得る。振分処理部１０は、ハッシュ値１に対応してＤＢ処理要求キュー１２に登録する。
【００２０】
ＤＢ処理部１４〜１６は、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を順次取り出し（ステップＳ４）、構成管理ＤＢ１７に対してＣＭＤＢ更新／参照処理を実行する（ステップＳ５）。ここでは、ＤＢ処理部１４がＤＢ処理要求キュー１１から２件のＣＭＤＢ処理要求を取り出し、上位管理アプリケーション装置２、ＥＭＳ利用者端末３からの順に実行し、テーブル１８のレコード１８１を、「１０」、「２０」と順次書き換える。また、ＤＢ処理部１５がＤＢ処理要求キュー１２からＣＭＤＢ処理要求を取り出して実行し、テーブル１９のレコード１９２を、「３０」に書き換える。
【００２１】
このように、各ＤＢ処理部が更新対象とするレコードが他のＤＢ処理部と競合することが無いため、各ＤＢ処理部によって構成管理ＤＢ１７に対するレコード更新の並列処理が可能となる。
【００２２】
以上説明したように、本実施の形態によれば、単一レコード処理が単一トランザクション単位である場合に、振分処理部が受け付けたＣＭＤＢ処理要求に対してハッシュ関数による計算を実行し、同一テーブルの同一レコードに対するＣＭＤＢ処理要求を同一のＤＢ処理要求キューに振り分けた後、各ＤＢ処理要求キューに対応するＤＢ処理部が構成管理ＤＢの更新処理を行うこととした。これにより、同一レコードに対して複数のＤＢ処理部から同時に更新／参照されることはなく競合が発生しない。また、同一レコードに対する更新／参照要求に対して時系列上の順序逆転は発生せず、時系列性を維持しつつ、効率的に並列処理を行うことができる。
【００２３】
なお、３つの並行処理のため、ＤＢ処理要求キューを３つ、ＤＢ処理部も３つを準備し、ハッシュ関数も３で除算することにより０〜２までの３つの数値を算出できるように実装したが、負荷に応じて並列処理度数を式（１）の除数値に設定することで、並列度数を柔軟に変更することが可能である。例えば、並列度数を４に増やしたい場合、式（１）のハッシュ計算式で使用する除数を４に変更することにより、ハッシュ計算式の算出結果は、拡大させた並列に振り分けるキュー番号の範囲として０〜３の値域に適応できる。なお、テーブル識別子とレコード識別子の連係として、テーブル番号とレコード番号の和としたが、各々一意に識別できる連結計算値であればどのような連携であってもよい。例えば、テーブル名称、レコードキー値を数値化した値でもよく、また相互連携は、和算である必要ななく、乗算、除算、指数計算等、２つの数値を使った連携計算のいずれにおいても、同様の効果を得ることができる。
【００２４】
実施の形態２．
本実施の形態では、トランザクションが複数のレコードの更新／参照処理のまとまりである場合において、デッドロックを回避するシステムについて説明する。実施の形態１と異なる部分について説明する。
【００２５】
本実施の形態では、ＥＭＳ利用者端末３等からのＣＭＤＢ処理要求がトランザクション単位であり、トランザクションは、複数のレコードの更新／参照処理のまとまりであり、他の対象レコード更新／参照の介在を許可しない一連の処理とする。トランザクションは、通信装置管理システムの振分処理部において、複数の異なるレコード処理単位のＣＭＤＢ処理要求に分解できることとする。また、各トランザクションには、トランザクション番号（ＴＲ−１、ＴＲ−２、・・・と明示する）が割り当てられ、分解されたＣＭＤＢ処理要求には所属するトランザクション番号が含まれ、通信装置管理システムのＤＢ処理部によって読み出し可能とする。
【００２６】
まず、従来においてデッドロックが発生する処理について説明する。図３は、通信装置管理システムの構成例を示す図である。通信装置管理システム１ａは、振分処理部１０ａと、ＤＢ処理要求キュー１１ａ、１２ａと、ＤＢ処理部１４ａ、１５ａと、構成管理ＤＢ１７と、を備える。振分処理部１０ａは、ＥＭＳ利用者端末３等からのトランザクションについて、トランザクション単位で振り分け処理を行う。ＤＢ処理要求キュー１１ａ、１２ａは、振り分けされたトランザクションを登録する。ＤＢ処理要求キュー１１ａは、ＥＭＳ利用者端末３からのトランザクションＴＲ−１を登録する。また、ＤＢ処理要求キュー１２ａは、管理対象通信装置４からのトランザクションＴＲ−２を登録する。ＤＢ処理部１４ａ、１５ａは、各ＤＢ処理要求キューに登録されたトランザクションを取り出して、トランザクションに含まれるＣＭＤＢ処理要求に基づくアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。
【００２７】
ここで、トランザクションＴＲ−１は、（１）テーブル１８のレコード１８１のロックおよび更新をする要求、および、（３）テーブル１９のレコード１９１のロックおよび更新をする要求、の２つのＣＭＤＢ処理要求から構成される。また、トランザクションＴＲ−２は、（２）テーブル１９のレコード１９１のロックおよび更新をする要求、および、（４）テーブル１８のレコード１８１のロックおよび更新をする要求、の２つのＣＭＤＢ処理要求から構成される。すなわち、２つのトランザクションＴＲ−１、ＴＲ−２は、同じ２レコードを更新するが、双方で更新順序が逆転するトランザクションとなっている。処理の順序としては、ＤＢ処理部１４ａ、１５ａが並行して各ＤＢ処理要求キューの要求を処理するため、各ＤＢ処理要求キューに登録されて要求は非同期で処理される。ここでは、（１）、（２）、（３）、（４）の順で実行されるとする。
【００２８】
つづいて、通信装置管理システム１ａの動作について説明する。まず、ＥＭＳ利用者端末３、管理対象通信装置４が、それぞれ、トランザクションＴＲ−１、ＴＲ−２の個別のＣＭＤＢ処理要求を送信する。トランザクションＴＲ−１は、（１）テーブル１８のレコード１８１の更新と、（３）テーブル１９のレコード１９１の更新、の２つのＣＭＤＢ処理要求に分解できる。また、トランザクションＴＲ−２も、（２）テーブル１９のレコード１９１の更新と、（４）テーブル１８のレコード１８１の更新、の２つのＣＭＤＢ処理要求に分解できる。
【００２９】
従来ではトランザクション単位でＤＢ処理要求キューに登録していたため、振分処理部１０ａは、同一のトランザクションＴＲ−１に属する（１）と（３）のＣＭＤＢ処理要求を、まとめてＤＢ処理要求キュー１１ａに振り分けて登録する。同様に、振分処理部１０ａは、同一のトランザクションＴＲ−２に属する（２）と（４）のＣＭＤＢ処理要求を、まとめてＤＢ処理要求キュー１２ａに振り分けて登録する。
【００３０】
ＤＢ処理部１４ａ、１５ａは、ＣＭＤＢ処理要求キュー１１ａ、１２ａにそれぞれ登録されたＣＭＤＢ処理要求を取り出し、非同期、かつ独立に構成管理ＤＢ１７を更新する。上述のように、（１）、（２）、（３）、（４）の順に取り出され実行される。
【００３１】
その結果、まず、ＤＢ処理部１４ａが、先頭の（１）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１８のレコード１８１にロックを掛け、本レコードの更新を行う。レコードにロックが掛けられた場合、他のＤＢ処理部からは対象レコードの参照や更新ができなくなる。ロックが掛ったレコードを更新／参照する他のＤＢ処理部は、先にロックを掛けたＤＢ処理部がロック解除するまで待ち状態に置かれる。ロックを掛ける処理を含むトランザクション処理全体が終了してレコードのロックが解除されると、始めて、ロックにより発生した待ち状態が解け、レコードの更新／参照ができるようになる。
【００３２】
ここでは、（１）の実行により、テーブル１８のレコード１８１にロックが掛けられた状態となる。つぎに、ＤＢ処理部１５ａが、（２）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１９のレコード１９１にロックが掛けられた状態となる。さらに、ＤＢ処理部１４ａが、（３）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１９のレコード１９１の更新を試みる。しかしながら、既に、（２）の更新処理の際、レコードロックが掛けられているため、トランザクションＴＲ−１の（３）の処理は待ち状態となる。また、ＤＢ処理部１４ｂが、（４）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１８のレコード１８１の更新を試みる。この場合も同様に、（１）の更新処理の際、レコードロックが掛けられているため、トランザクションＴＲ−２の（４）の処理は待ち状態となる。
【００３３】
このように、相互にロックを掛け合っているため、トランザクションＴＲ−１、ＴＲ−２が、ともに待ち状態となる。相互に他のＤＢ処理部側からトランザクションのロック解除がされないと先に進めないが、相互に停止状態でロック解除ができないため、永久的な待ち状態が継続する、いわゆるデッドロック状態に陥る。デッドロックを解消する方法として、定期的にデッドロック状態を監視するプロセスを起動してデッドロックが発生していないか監視し、デッドロック発生時に、双方または片方のトランザクションをキャンセルする方法が一般的である。キャンセルされたトランザクションについては、再度、同様の操作を実行する。
【００３４】
デッドロックが発生した場合、ＤＢ処理の遅延または永久停止が発生する。また、デッドロックを検出した場合、デッドロック監視プロセスにより、片方または両方のトランザクション処理を一旦消去して、トランザクションの最初からやり直しをする方法が一般的である。このような処理を行うと、システム負荷の増大、デッドロック検出やデッドロック時の処理のやり直しによる応答性能の大幅な悪化が発生する。
【００３５】
つぎに、デッドロックを回避する処理について説明する。図４は、通信装置管理システムの構成例を示す図である。通信装置管理システム１ｂは、振分処理部１０ｂと、ＤＢ処理要求キュー１１ｂ、１２ｂと、ＤＢ処理部１４ｂ、１５ｂと、構成管理ＤＢ１７と、現トランザクションリスト１００と、を備える。振分処理部１０ｂは、ＥＭＳ利用者端末３等からのトランザクションについて、トランザクションに含まれるレコード処理単位のＣＭＤＢ処理要求に対してハッシュ関数の計算を行い、振り分け処理を行う。ＤＢ処理要求キュー１１ｂ、１２ｂは、振り分けされたＣＭＤＢ処理要求を登録する。ＤＢ処理要求キュー１１ｂは、テーブル１８のレコード１８１を更新するＣＭＤＢ処理要求を登録する。また、ＤＢ処理要求キュー１２ｂは、テーブル１９のレコード１９１を更新するＣＭＤＢ処理要求を登録する。ＤＢ処理部１４ｂ、１５ｂは、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出してアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。また、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求の並べ替えを行う。現トランザクションリスト１００は、各ＤＢ処理要求キュー内の順序を決定するトランザクション番号を管理する現トランザクション優先順位テーブルである。
【００３６】
ここでは、振分処理部１０ｂが、トランザクション単位ではなく、トランザクションに含まれるレコード処理単位のＣＭＤＢ処理要求に対してテーブル番号とレコードキー番号を元にしたハッシュ関数の計算を行い、ハッシュ関数値に基づき、レコード処理単位に分解して各ＤＢ処理要求キューに振り分けて登録する。具体的には、ＤＢ処理要求キュー１１ｂには、トランザクションＴＲ−１の（１）テーブル１８のレコード１８１の更新要求、トランザクションＴＲ−２の（４）テーブル１８のレコード１８１の更新要求が登録される。また、ＤＢ処理要求キュー１２ｂには、トランザクションＴＲ−１の（３）テーブル１９のレコード１９１の更新要求、トランザクションＴＲ−２の（２）テーブル１９のレコード１９１の更新要求が登録される。
【００３７】
つづいて、通信装置管理システム１ｂの動作について説明する。図５は、通信装置管理システムにおける構成管理ＤＢ１７の更新処理を示すフローチャートである。まず、ＥＭＳ利用者端末３、管理対象通信装置４が、それぞれ、トランザクションＴＲ−１、ＴＲ−２の個別のＣＭＤＢ処理要求を送信する。それぞれに含まれるレコード更新の内容は、図３におけるデッドロックが発生する場合のものと同一である。
【００３８】
ここで、ＣＭＤＢ処理要求を送信する各装置は、トランザクション毎に、ユニークなトランザクションＩＤ（ＴＲ−ＩＤとする）を決定し、同一トランザクションの全ＣＭＤＢ処理要求に本ＴＲ−ＩＤを付与する。さらに、トランザクションの最初のＣＭＤＢ処理要求には、トランザクション開始マーク（ＳｔａｒｔＴＲとする）、最後のＣＭＤＢ処理要求にはトランザクション終了マーク（ＥｎｄＴＲとする）を付与する。
【００３９】
通信装置管理システム１ｂでは、振分処理部１０ｂにおいて、各装置から送信されたトランザクションを受け付け（ステップＳ１１）、受信したトランザクションＴＲ−１、ＴＲ−２をレコード処理単位のＣＭＤＢ処理要求に分解する（ステップＳ１２）。振分処理部１０ｂは、分解したレコード処理単位のＣＭＤＢ処理要求について、ＣＭＤＢ処理要求に付与されているＤＢ処理対象のテーブル識別子、レコード識別子を元にハッシュ関数により計算処理を実行し（ステップＳ１３）、計算結果に基づいて、ＣＭＤＢ処理要求を各ＤＢ処理要求キューに登録する（ステップＳ１４）。
【００４０】
ハッシュ関数による計算方法は実施の形態１と同様である。すなわち、同一テーブルの同一レコードに対するＣＭＤＢ処理要求は同じＤＢ処理要求キューに振り分けられて登録される。具体的に、振分処理部１０ｂは、テーブル１８のレコード１８１に対する処理要求であるトランザクションＴＲ−１の（１）、およびトランザクションＴＲ−２の（４）をＤＢ処理要求キュー１１ｂに登録する。また、振分処理部１０ｂは、テーブル１９のレコード１９１に対する処理要求であるトランザクションＴＲ−１の（３）、およびトランザクションＴＲ−２の（２）をＤＢ処理要求キュー１２ｂに登録する。
【００４１】
このとき、振分処理部１０ｂは、現トランザクションリスト１００に、トランザクションＴＲ−１、ＴＲ−２の受信順に現在実行中のトランザクションとして登録する。トランザクションの優先度は現トランザクションリスト１００の登録順であるため、トランザクションＴＲ−１の方がトランザクションＴＲ−２より優先度が高いことを示す。
【００４２】
つぎに、各ＤＢ処理部が、ＣＭＤＢ処理要求の実行するにあたり、現トランザクションリスト１００の登録順（優先順位）に基づいて、各ＤＢ処理要求キュー内のＣＭＤＢ処理要求を並べ替える（ステップＳ１５）。並べ替えの方法としては、例えば、最も優先順位の高いＴＲ−ＩＤと同一のＴＲ−ＩＤが付与されたＣＭＤＢ処理要求を抜き出し、各ＢＤ処理要求キュー内で当該ＴＲ−ＩＤが付与された全てのＣＭＤＢ処理要求をまとめて、ＴＲ−ＩＤの優先順位に従って各ＤＢ処理要求キュー内で並び替える。このとき、２番目以降の優先順位のＴＲ−ＩＤと同一のＴＲ−ＩＤが付与されたＣＭＤＢ処理要求について並び替えを行ってもよい。なお、並べ替える方法は、これに限定するものではない。
【００４３】
また、並び替えるタイミングとしては、例えば、いずれかのＤＢ処理部でＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求を処理した場合に現トランザクションリスト１００から当該ＴＲ−ＩＤを削除する処理を行うため、このタイミングとしてもよい。なお、並べ替えるタイミングは、これに限定するものではない。
【００４４】
具体的には、ＤＢ処理部１４ｂが、トランザクションＴＲ−１に属するＣＭＤＢ処理要求を優先して並び替える。その結果、ＤＢ処理要求キュー１１ｂにおいて、トランザクションＴＲ−１の（１）を先頭に登録し、つぎに、トランザクションＴＲ−２の（４）が位置するように再登録する。同様に、ＤＢ処理部１５ｂが、ＤＢ処理要求キュー１２ｂにおいて、トランザクションＴＲ−１の（３）を先頭に登録し、つぎに、トランザクションＴＲ−２の（２）が位置するように再登録する。
【００４５】
ＤＢ処理部１４ｂ、１５ｂは、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出し（ステップＳ１６）、構成管理ＤＢ１７に対してＣＭＤＢ更新／参照処理を実行する（ステップＳ１７）。構成管理ＤＢ１７に対する処理は、上述の説明と同様である。
【００４６】
いずれかのＤＢ処理部において、ＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求を取り出した場合は、他のＤＢ処理要求キューに同一ＴＲ−ＩＤのＣＭＤＢ処理要求が残っているかどうかを確認する。残っていた場合は、ＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求の処理を行わない。残っていない場合は、取り出したＣＭＤＢ処理要求の処理を行った後、現トランザクションリスト１００から当該ＴＲ−ＩＤを削除する。
【００４７】
このように、各ＤＢ処理部が、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を現トランザクションリスト１００の登録順序で並べ替えるため、その結果、トランザクションの優先順で各レコード単位のＣＭＤＢ処理要求が実行されるため、デッドロックが発生しない。なお、各ＤＢ処理部が、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を並べ替えることとしたが、振分処理部１０ｂが各ＤＢ処理要求キューに登録する際に行ってもよい。
【００４８】
なお、本実施の形態では、トランザクションの優先順位として、振分処理部１０ｂで受信した順番としているが、これに限定するものではない。例えば、各ＤＢ処理部において、トランザクション開始時期を現トランザクションリスト１００に記録することにより、トランザクションの開始タイミングが早い程、優先順位を高くすると定義してもよい。また、利用者によりＣＭＤＢ処理要求時に優先順位を明示的に設定する等、他の規則によりトランザクションの優先順位を決定した場合においても同様の効果が期待できる。
【００４９】
例えば、開始タイミングの早いトランザクションの優先順位を高くする場合では、ＳｔａｒｔＴＲが付与されたＣＭＤＢ処理要求を取り出したいずれかのＤＢ処理部が、当該ＳｔａｒｔＴＲが付与されたトランザクションのＴＲ−ＩＤを現トランザクションリスト１００に記録する。その後、各ＤＢ処理が当該ＴＲ−ＩＤが付与されたＣＭＤＢ要求を各ＤＢ処理要求キューから抜き出し、各ＤＢ処理要求キュー内において優先順位に基づいて並べ替えを行う。待ちフラグの立っているＣＭＤＢ処理要求についてはリセットする。待ちフラグは、現トランザクションリスト１００に無いＣＭＤＢ処理要求を取り出したＤＢ処理部が、当該ＣＭＤＢ処理要求に立て、処理の対象としない。なお、トランザクションの優先順位を受信順で決める場合では、各ＤＢ処理要求キューに登録されているＣＭＤＢ処理要求に付与されているＴＲ−ＩＤは、必ず現トランザクションリスト１００に登録されている。そのため、現トランザクションリスト１００に基づいて並べ替えることが可能であり、待ちフラグの必要はない。
【００５０】
以上説明したように、本実施の形態によれば、トランザクションが複数のレコードの更新／参照処理のまとまりである場合に、振分処理部が、受け付けたトランザクションをレコード処理単位のＣＭＤＢ処理要求に分解してハッシュ関数による計算を実行し、また、ＤＢ処理部が、トランザクションの優先順位に基づいてＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を並び替えることとした。これにより、実施の形態１の効果に加え、デッドロックを防止することができ、システム全体として負荷を軽減することができる。
【００５１】
なお、これまでの説明では、通信装置管理システムに対して、上位管理アプリケーション装置等が全て共通のインタフェイスでＣＭＤＢ処理要求を送信する方式を想定している。しかしながら、全てのＣＭＤＢ処理要求側のインタフェイスを一括変更することが困難な場合がある。このように、共通でないＣＭＤＢ処理要求元が存在した場合でも、メッセージ形式を共通形式に変換するゲートウェイ等を用いることによって並列処理することが可能となる。
【００５２】
図６は、変換ゲートウェイを配置した通信装置管理システムとの接続例を示す図である。例えば、管理対象通信装置４からは、通信装置管理システム１と通信できない独自のメッセージ形式のＣＭＤＢ処理要求を送信する。このような場合に、独自形式のメッセージを共通形式のメッセージに変換する変換ゲートウェイ５を用いる。
【００５３】
変換ゲートウェイ５は、管理対象通信装置４から入力した独自メッセージ形式のＣＭＤＢ処理要求を通信装置管理システム１が受け付け可能な共通のメッセージ形式のＣＭＤＢ処理要求に変換して出力する。通信装置管理システム１は、変換後の共通メッセージ形式のＣＭＤＢ処理要求を受信することにより、ＣＭＤＢ処理要求を受け付け可能となる。
【００５４】
このように、ＣＭＤＢ処理要求メッセージが共通でない場合でも、変換ゲートウェイ５が異なるメッセージ形式を共通の要求メッセージ形式に変換し、通信装置管理システムに送信することにより、異なるメッセージ形式のＣＭＤＢ処理要求についても、共通に処理して通信装置管理システムにおける処理負荷を分散することができる。
【００５５】
なお、メッセージ形式を変換する構成を通信装置管理システムとＣＭＤＢ処理要求を送信する装置との間に配置する場合について説明したが、これに限定するものではなく、通信装置管理システム内の備えてもよい。
【００５６】
また、ＣＭＤＢ処理要求のメッセージ形式だけでなく、通信プロトコルやコード体系等が標準と異なる場合等、共通の通信インタフェイス仕様から異なる場合においても、変換ゲートウェイを介在させることで、通信装置管理システムに対するインタフェイスを共通化することが可能であり、データベースの更新／参照処理の負荷分散の同等の効果を得ることが期待できる。
【００５７】
また、単一のデータベースを想定しているが、複数のデータベースに跨るデータベースシステムを対象とする場合においても、ハッシュ関数対象をデータベース識別子まで拡張し、データベース識別子、テーブル識別子、レコード識別子の３つの連結計算とすることで適用可能であり、同様の効果を得ることができる。
【００５８】
また、本並列処理方式では、並列度数に応じて、ＤＢ処理要求キューを複数設けたが、ＤＢ処理要求キューは論理的に分離したキューであればよく、物理的には単一キューに実装しても問題なく同様の効果が期待できる。すなわち、物理的に単一のＤＢ処理要求キューとして実装した場合でも、振分処理部において、ＣＭＤＢ処理要求を受信後、単一キューにＣＭＤＢ処理要求を登録する際、ハッシュ関数の計算値を各ＣＭＤＢ処理要求に付加して登録する。その後、複数のＤＢ処理部が、単一キューからＣＭＤＢ処理要求を取り出す際、付加されたハッシュ関数値を参照して各ＤＢ処理部に割り当てられたハッシュ関数値に属するＣＭＤＢ処理要求のみを取り出し、並列して実行することで同様の効果を得ることが期待できる。
【産業上の利用可能性】
【００５９】
以上のように、本発明にかかる通信装置管理システムは、構成管理データベースに対するデータ処理に有用であり、特に、構成管理データベースに対して並列処理を行うシステムに適している。
【符号の説明】
【００６０】
１ 通信装置管理システム
２ 上位管理アプリケーション装置
３ ＥＭＳ利用者端末
４ 管理対象通信装置
５ 変換ゲートウェイ
１０、１０ａ、１０ｂ 振分処理部
１１、１１ａ、１１ｂ、１２、１２ａ、１２ｂ、１３ ＤＢ処理要求キュー
１４、１４ａ、１４ｂ、１５、１５ａ、１５ｂ、１６ ＤＢ処理部
１７ 構成管理ＤＢ
１８、１９ テーブル
１００ 現トランザクションリスト
【技術分野】
【０００１】
本発明は、構成管理データベースに対して並列処理を行う通信装置管理システムに関する。
【背景技術】
【０００２】
従来、通信装置管理システム（ＥＭＳ：Element Management System）に対して、非同期に発生する複数の構成管理データベース（ＣＭＤＢ：Configuration Management Database）の更新／参照処理要求（以下、ＣＭＤＢ処理要求とする）を効率的に負荷分散するため、一連の複数のレコードアクセスであるトランザクション単位で複数のキューにランダムに分散して振り分け、キュー毎に起動されたデータベースアクセス処理アプリケーションプロセス群が、各キューに登録された要求をひとつずつ順番に取り出してＣＭＤＢアクセス処理を行っている。
【０００３】
ＣＭＤＢ処理要求をトランザクション単位で各キューに割り振る場合、同一レコードに対する処理要求を含む複数のトランザクションが異なるキューに振り分けられるため、同一レコードに対する競合が発生する。また、各トランザクション内のレコードの更新／参照順序が異なると、実行順序によってデッドロックが発生する。そのため、定期的にデッドロック状態を監視し、デッドロック発生時は、デッドロックを発生させているトランザクションによるＣＭＤＢ処理要求をリセットし、再度ＣＭＤＢ処理要求を発行し直す必要がある。デッドロック状態を監視するプロセスを定期的に起動し、デッドロック発生時は処理負荷が高くなるため、応答性能が悪化する等の問題が生じていた。
【０００４】
このような問題の解決策として、ＣＭＤＢ処理キューを一元化する方式がある。ＥＭＳに対して非同期に発生する複数のＣＭＤＢ処理要求間の競合やデッドロックを回避するため、ＣＭＤＢ処理要求を単一のキュー（待ち行列）に一元的に集約し、先頭から登録された順序で処理する。しかしながら、単一キュー方式では、ＣＭＤＢ処理要求が大量に発生して負荷が増大した場合、並列処理して負荷分散する本来の目的の実現が困難であった。
【０００５】
そこで、同一レコードに対するＣＭＤＢ処理要求ごとにキューに割り振る方法が考えられる。例えば、ＣＭＤＢ処理要求が対象とするデータベース上のレコードキーにハッシュ関数を使用する方法である。具体的に、データベースへの更新／参照要求の処理においてハッシュ関数を適用する技術が、下記特許文献１〜４において開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平５−０４６４５４号公報
【特許文献２】特開平５−２９８３６６号公報
【特許文献３】特開２０００−１８７６６８号公報
【特許文献４】特開２０００−２５０９２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来の技術によれば、登録後のレコード状態の分散化や平均化、アクセス頻度の平滑化や検索の迅速性等の登録後の処理を目的としてハッシュ関数を使用するものである。そのため、レコード更新処理を目的とするＣＭＤＢ処理要求が大量に発生した場合には更新対象が競合するため、並列処理を実行しても処理負荷を軽減することができない、という問題があった。
【０００８】
本発明は、上記に鑑みてなされたものであって、レコードの競合やデッドロックを回避しつつ、処理負荷の軽減が可能な通信装置管理システムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明は、構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システムであって、同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、他装置からのアクセス要求を受信し、当該アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて、受信したアクセス要求の振り分け先を決定する振分処理手段と、複数のキューを備え、ハッシュ計算値ごとに、同一のハッシュ計算値のアクセス要求を同一キューに格納する格納手段と、前記キューごとに、格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理手段と、を備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、レコードの競合やデッドロックを回避しつつ、処理負荷を軽減できる、という効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】図１は、通信装置管理システムの構成例を示す図である。
【図２】図２は、構成管理ＤＢの更新処理を示すフローチャートである。
【図３】図３は、通信装置管理システムの構成例を示す図である。
【図４】図４は、通信装置管理システムの構成例を示す図である。
【図５】図５は、構成管理ＤＢの更新処理を示すフローチャートである。
【図６】図６は、通信装置管理システムの接続例を示す図である。
【発明を実施するための形態】
【００１２】
以下に、本発明にかかる通信装置管理システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１３】
実施の形態１．
図１は、通信装置管理システム（ＥＭＳ：Element Management System）の構成例を示す図である。通信装置管理システム１は、同時に発生する複数のＣＭＤＢ（Configuration Management Database）処理要求に対して、競合を防止しつつ並行して処理する。ＣＭＤＢ処理要求は、通信装置管理システム１が備える構成管理データベース（ＣＭＤＢ)に対する更新／参照処理を要求するメッセージである。ここでは、トランザクション単位が、１レコード単位の更新／参照とする簡易なシステムとする。なお、ＣＭＤＢ処理要求を送信する装置として、上位管理アプリケーション装置２と、ＥＭＳ利用者端末３と、管理対象通信装置４を想定する。
【００１４】
通信装置管理システム１は、振分処理部１０と、データベース（ＤＢ）処理要求キュー１１〜１３と、データベース（ＤＢ）処理部１４〜１６と、構成管理データベース（ＤＢ）１７と、を備える。振分処理部１０は、上位管理アプリケーション装置２等からのＣＭＤＢ処理要求に対してハッシュ関数の計算を行い、計算結果に基づいて振り分け処理を行う。ＤＢ処理要求キュー１１〜１３は、振り分けされたＣＭＤＢ処理要求を登録する。ＤＢ処理部１４〜１６は、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出してアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。構成管理ＤＢ１７は、システムに関する情報を管理するデータベースである。
【００１５】
構成管理ＤＢ１７は、テーブル１８、１９を備える。テーブル１８、１９は、データベース上に登録されているリレーショナルデータベーステーブルである。レコード１８１、１８２、１８３は、テーブル１８に登録されたレコードを示し、レコード１９１、１９２、１９３は、テーブル１９に登録されたレコードを示す。
【００１６】
つづいて、通信装置管理システム１の動作について説明する。図２は、通信装置管理システムにおける構成管理ＤＢ１７の更新処理を示すフローチャートである。まず、上位管理アプリケーション装置２、ＥＭＳ利用者端末３、および管理対象通信装置４においてＣＭＤＢ処理要求が非同期に複数発生する。ここでは、上位管理アプリケーション装置２、ＥＭＳ利用者端末３、管理対象通信装置４の順に各装置がＣＭＤＢ処理要求を送信する。なお、上位管理アプリケーション装置２およびＥＭＳ利用者端末３からのＣＭＤＢ処理要求はテーブル１８のレコード１８１に対するレコード更新要求、管理対象通信装置４からのＣＭＤＢ処理要求はテーブル１９のレコード１９２に対するレコード更新要求とする。
【００１７】
通信装置管理システム１では、振分処理部１０において、各装置から送信されたＣＭＤＢ処理要求を受け付ける（ステップＳ１）。振分処理部１０は、ＣＭＤＢ処理要求に付与されているＤＢ処理対象のテーブル識別子、レコード識別子を元にハッシュ関数により計算処理を実行し（ステップＳ２）、計算結果に基づいて、受け付けたＣＭＤＢ処理要求を各ＤＢ処理要求キューに登録する（ステップＳ３）。テーブル識別子は各テーブルに通番で振られるテーブル番号とし、レコード識別子はレコードキー番号と定義する。また、ハッシュ関数の計算結果の値は、入力値を元にアクセス要求キュー番号に一意に対応するように設定する。
【００１８】
ここでは、３つのＤＢ処理要求キューが存在するので、テーブル番号とレコードキーの和を３で割った余りをハッシュ計算結果値とする。具体的に、以下の式（１）の様に定義する。
ハッシュ関数 Ｆ（ｘ、ｙ、ｚ）＝ＭＯＤ（ｘ＋ｙ、ｚ） …（１）
（ｘ＝テーブル番号、ｙ＝レコードキー番号、ｚ＝ＤＢ処理要求キュー数）
本実施の形態ではｚ＝３となる。すなわち、振分処理部１０は、ハッシュ値が２の場合はＤＢ処理要求キュー１１、ハッシュ値が１の場合はＤＢ処理要求キュー１２、ハッシュ値が０の場合はＤＢ処理要求キュー１３の各ＤＢ処理要求キューに振り分ける。
【００１９】
計算の簡素化のため、テーブル１８のテーブル番号を１、レコード１８１〜１８３のレコードキー番号を１〜３とし、テーブル１９のテーブル番号を２、レコード１９１〜１９３のレコードキー番号を１〜３とする。上記式（１）を適用すると、上位管理アプリケーション装置２、ＥＭＳ利用者端末３からのＣＭＤＢ処理要求に対するハッシュ値は、（テーブル番号１＋レコードキー番号１）＝２の数値を３で割った余りとして計算結果２を得る。振分処理部１０は、２件とも、ハッシュ値２であるため、ＤＢ処理要求キュー１１に登録する。同様に、管理対象通信装置４からのＣＭＤＢ処理要求に対するハッシュ値は、（テーブル番号２＋レコードキー番号２）＝４を３で割った余りとして計算結果１を得る。振分処理部１０は、ハッシュ値１に対応してＤＢ処理要求キュー１２に登録する。
【００２０】
ＤＢ処理部１４〜１６は、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を順次取り出し（ステップＳ４）、構成管理ＤＢ１７に対してＣＭＤＢ更新／参照処理を実行する（ステップＳ５）。ここでは、ＤＢ処理部１４がＤＢ処理要求キュー１１から２件のＣＭＤＢ処理要求を取り出し、上位管理アプリケーション装置２、ＥＭＳ利用者端末３からの順に実行し、テーブル１８のレコード１８１を、「１０」、「２０」と順次書き換える。また、ＤＢ処理部１５がＤＢ処理要求キュー１２からＣＭＤＢ処理要求を取り出して実行し、テーブル１９のレコード１９２を、「３０」に書き換える。
【００２１】
このように、各ＤＢ処理部が更新対象とするレコードが他のＤＢ処理部と競合することが無いため、各ＤＢ処理部によって構成管理ＤＢ１７に対するレコード更新の並列処理が可能となる。
【００２２】
以上説明したように、本実施の形態によれば、単一レコード処理が単一トランザクション単位である場合に、振分処理部が受け付けたＣＭＤＢ処理要求に対してハッシュ関数による計算を実行し、同一テーブルの同一レコードに対するＣＭＤＢ処理要求を同一のＤＢ処理要求キューに振り分けた後、各ＤＢ処理要求キューに対応するＤＢ処理部が構成管理ＤＢの更新処理を行うこととした。これにより、同一レコードに対して複数のＤＢ処理部から同時に更新／参照されることはなく競合が発生しない。また、同一レコードに対する更新／参照要求に対して時系列上の順序逆転は発生せず、時系列性を維持しつつ、効率的に並列処理を行うことができる。
【００２３】
なお、３つの並行処理のため、ＤＢ処理要求キューを３つ、ＤＢ処理部も３つを準備し、ハッシュ関数も３で除算することにより０〜２までの３つの数値を算出できるように実装したが、負荷に応じて並列処理度数を式（１）の除数値に設定することで、並列度数を柔軟に変更することが可能である。例えば、並列度数を４に増やしたい場合、式（１）のハッシュ計算式で使用する除数を４に変更することにより、ハッシュ計算式の算出結果は、拡大させた並列に振り分けるキュー番号の範囲として０〜３の値域に適応できる。なお、テーブル識別子とレコード識別子の連係として、テーブル番号とレコード番号の和としたが、各々一意に識別できる連結計算値であればどのような連携であってもよい。例えば、テーブル名称、レコードキー値を数値化した値でもよく、また相互連携は、和算である必要ななく、乗算、除算、指数計算等、２つの数値を使った連携計算のいずれにおいても、同様の効果を得ることができる。
【００２４】
実施の形態２．
本実施の形態では、トランザクションが複数のレコードの更新／参照処理のまとまりである場合において、デッドロックを回避するシステムについて説明する。実施の形態１と異なる部分について説明する。
【００２５】
本実施の形態では、ＥＭＳ利用者端末３等からのＣＭＤＢ処理要求がトランザクション単位であり、トランザクションは、複数のレコードの更新／参照処理のまとまりであり、他の対象レコード更新／参照の介在を許可しない一連の処理とする。トランザクションは、通信装置管理システムの振分処理部において、複数の異なるレコード処理単位のＣＭＤＢ処理要求に分解できることとする。また、各トランザクションには、トランザクション番号（ＴＲ−１、ＴＲ−２、・・・と明示する）が割り当てられ、分解されたＣＭＤＢ処理要求には所属するトランザクション番号が含まれ、通信装置管理システムのＤＢ処理部によって読み出し可能とする。
【００２６】
まず、従来においてデッドロックが発生する処理について説明する。図３は、通信装置管理システムの構成例を示す図である。通信装置管理システム１ａは、振分処理部１０ａと、ＤＢ処理要求キュー１１ａ、１２ａと、ＤＢ処理部１４ａ、１５ａと、構成管理ＤＢ１７と、を備える。振分処理部１０ａは、ＥＭＳ利用者端末３等からのトランザクションについて、トランザクション単位で振り分け処理を行う。ＤＢ処理要求キュー１１ａ、１２ａは、振り分けされたトランザクションを登録する。ＤＢ処理要求キュー１１ａは、ＥＭＳ利用者端末３からのトランザクションＴＲ−１を登録する。また、ＤＢ処理要求キュー１２ａは、管理対象通信装置４からのトランザクションＴＲ−２を登録する。ＤＢ処理部１４ａ、１５ａは、各ＤＢ処理要求キューに登録されたトランザクションを取り出して、トランザクションに含まれるＣＭＤＢ処理要求に基づくアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。
【００２７】
ここで、トランザクションＴＲ−１は、（１）テーブル１８のレコード１８１のロックおよび更新をする要求、および、（３）テーブル１９のレコード１９１のロックおよび更新をする要求、の２つのＣＭＤＢ処理要求から構成される。また、トランザクションＴＲ−２は、（２）テーブル１９のレコード１９１のロックおよび更新をする要求、および、（４）テーブル１８のレコード１８１のロックおよび更新をする要求、の２つのＣＭＤＢ処理要求から構成される。すなわち、２つのトランザクションＴＲ−１、ＴＲ−２は、同じ２レコードを更新するが、双方で更新順序が逆転するトランザクションとなっている。処理の順序としては、ＤＢ処理部１４ａ、１５ａが並行して各ＤＢ処理要求キューの要求を処理するため、各ＤＢ処理要求キューに登録されて要求は非同期で処理される。ここでは、（１）、（２）、（３）、（４）の順で実行されるとする。
【００２８】
つづいて、通信装置管理システム１ａの動作について説明する。まず、ＥＭＳ利用者端末３、管理対象通信装置４が、それぞれ、トランザクションＴＲ−１、ＴＲ−２の個別のＣＭＤＢ処理要求を送信する。トランザクションＴＲ−１は、（１）テーブル１８のレコード１８１の更新と、（３）テーブル１９のレコード１９１の更新、の２つのＣＭＤＢ処理要求に分解できる。また、トランザクションＴＲ−２も、（２）テーブル１９のレコード１９１の更新と、（４）テーブル１８のレコード１８１の更新、の２つのＣＭＤＢ処理要求に分解できる。
【００２９】
従来ではトランザクション単位でＤＢ処理要求キューに登録していたため、振分処理部１０ａは、同一のトランザクションＴＲ−１に属する（１）と（３）のＣＭＤＢ処理要求を、まとめてＤＢ処理要求キュー１１ａに振り分けて登録する。同様に、振分処理部１０ａは、同一のトランザクションＴＲ−２に属する（２）と（４）のＣＭＤＢ処理要求を、まとめてＤＢ処理要求キュー１２ａに振り分けて登録する。
【００３０】
ＤＢ処理部１４ａ、１５ａは、ＣＭＤＢ処理要求キュー１１ａ、１２ａにそれぞれ登録されたＣＭＤＢ処理要求を取り出し、非同期、かつ独立に構成管理ＤＢ１７を更新する。上述のように、（１）、（２）、（３）、（４）の順に取り出され実行される。
【００３１】
その結果、まず、ＤＢ処理部１４ａが、先頭の（１）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１８のレコード１８１にロックを掛け、本レコードの更新を行う。レコードにロックが掛けられた場合、他のＤＢ処理部からは対象レコードの参照や更新ができなくなる。ロックが掛ったレコードを更新／参照する他のＤＢ処理部は、先にロックを掛けたＤＢ処理部がロック解除するまで待ち状態に置かれる。ロックを掛ける処理を含むトランザクション処理全体が終了してレコードのロックが解除されると、始めて、ロックにより発生した待ち状態が解け、レコードの更新／参照ができるようになる。
【００３２】
ここでは、（１）の実行により、テーブル１８のレコード１８１にロックが掛けられた状態となる。つぎに、ＤＢ処理部１５ａが、（２）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１９のレコード１９１にロックが掛けられた状態となる。さらに、ＤＢ処理部１４ａが、（３）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１９のレコード１９１の更新を試みる。しかしながら、既に、（２）の更新処理の際、レコードロックが掛けられているため、トランザクションＴＲ−１の（３）の処理は待ち状態となる。また、ＤＢ処理部１４ｂが、（４）のＣＭＤＢ処理要求に基づく更新処理により、テーブル１８のレコード１８１の更新を試みる。この場合も同様に、（１）の更新処理の際、レコードロックが掛けられているため、トランザクションＴＲ−２の（４）の処理は待ち状態となる。
【００３３】
このように、相互にロックを掛け合っているため、トランザクションＴＲ−１、ＴＲ−２が、ともに待ち状態となる。相互に他のＤＢ処理部側からトランザクションのロック解除がされないと先に進めないが、相互に停止状態でロック解除ができないため、永久的な待ち状態が継続する、いわゆるデッドロック状態に陥る。デッドロックを解消する方法として、定期的にデッドロック状態を監視するプロセスを起動してデッドロックが発生していないか監視し、デッドロック発生時に、双方または片方のトランザクションをキャンセルする方法が一般的である。キャンセルされたトランザクションについては、再度、同様の操作を実行する。
【００３４】
デッドロックが発生した場合、ＤＢ処理の遅延または永久停止が発生する。また、デッドロックを検出した場合、デッドロック監視プロセスにより、片方または両方のトランザクション処理を一旦消去して、トランザクションの最初からやり直しをする方法が一般的である。このような処理を行うと、システム負荷の増大、デッドロック検出やデッドロック時の処理のやり直しによる応答性能の大幅な悪化が発生する。
【００３５】
つぎに、デッドロックを回避する処理について説明する。図４は、通信装置管理システムの構成例を示す図である。通信装置管理システム１ｂは、振分処理部１０ｂと、ＤＢ処理要求キュー１１ｂ、１２ｂと、ＤＢ処理部１４ｂ、１５ｂと、構成管理ＤＢ１７と、現トランザクションリスト１００と、を備える。振分処理部１０ｂは、ＥＭＳ利用者端末３等からのトランザクションについて、トランザクションに含まれるレコード処理単位のＣＭＤＢ処理要求に対してハッシュ関数の計算を行い、振り分け処理を行う。ＤＢ処理要求キュー１１ｂ、１２ｂは、振り分けされたＣＭＤＢ処理要求を登録する。ＤＢ処理要求キュー１１ｂは、テーブル１８のレコード１８１を更新するＣＭＤＢ処理要求を登録する。また、ＤＢ処理要求キュー１２ｂは、テーブル１９のレコード１９１を更新するＣＭＤＢ処理要求を登録する。ＤＢ処理部１４ｂ、１５ｂは、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出してアプリケーションを並行して実行し、構成管理ＤＢ１７にアクセスする。また、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求の並べ替えを行う。現トランザクションリスト１００は、各ＤＢ処理要求キュー内の順序を決定するトランザクション番号を管理する現トランザクション優先順位テーブルである。
【００３６】
ここでは、振分処理部１０ｂが、トランザクション単位ではなく、トランザクションに含まれるレコード処理単位のＣＭＤＢ処理要求に対してテーブル番号とレコードキー番号を元にしたハッシュ関数の計算を行い、ハッシュ関数値に基づき、レコード処理単位に分解して各ＤＢ処理要求キューに振り分けて登録する。具体的には、ＤＢ処理要求キュー１１ｂには、トランザクションＴＲ−１の（１）テーブル１８のレコード１８１の更新要求、トランザクションＴＲ−２の（４）テーブル１８のレコード１８１の更新要求が登録される。また、ＤＢ処理要求キュー１２ｂには、トランザクションＴＲ−１の（３）テーブル１９のレコード１９１の更新要求、トランザクションＴＲ−２の（２）テーブル１９のレコード１９１の更新要求が登録される。
【００３７】
つづいて、通信装置管理システム１ｂの動作について説明する。図５は、通信装置管理システムにおける構成管理ＤＢ１７の更新処理を示すフローチャートである。まず、ＥＭＳ利用者端末３、管理対象通信装置４が、それぞれ、トランザクションＴＲ−１、ＴＲ−２の個別のＣＭＤＢ処理要求を送信する。それぞれに含まれるレコード更新の内容は、図３におけるデッドロックが発生する場合のものと同一である。
【００３８】
ここで、ＣＭＤＢ処理要求を送信する各装置は、トランザクション毎に、ユニークなトランザクションＩＤ（ＴＲ−ＩＤとする）を決定し、同一トランザクションの全ＣＭＤＢ処理要求に本ＴＲ−ＩＤを付与する。さらに、トランザクションの最初のＣＭＤＢ処理要求には、トランザクション開始マーク（ＳｔａｒｔＴＲとする）、最後のＣＭＤＢ処理要求にはトランザクション終了マーク（ＥｎｄＴＲとする）を付与する。
【００３９】
通信装置管理システム１ｂでは、振分処理部１０ｂにおいて、各装置から送信されたトランザクションを受け付け（ステップＳ１１）、受信したトランザクションＴＲ−１、ＴＲ−２をレコード処理単位のＣＭＤＢ処理要求に分解する（ステップＳ１２）。振分処理部１０ｂは、分解したレコード処理単位のＣＭＤＢ処理要求について、ＣＭＤＢ処理要求に付与されているＤＢ処理対象のテーブル識別子、レコード識別子を元にハッシュ関数により計算処理を実行し（ステップＳ１３）、計算結果に基づいて、ＣＭＤＢ処理要求を各ＤＢ処理要求キューに登録する（ステップＳ１４）。
【００４０】
ハッシュ関数による計算方法は実施の形態１と同様である。すなわち、同一テーブルの同一レコードに対するＣＭＤＢ処理要求は同じＤＢ処理要求キューに振り分けられて登録される。具体的に、振分処理部１０ｂは、テーブル１８のレコード１８１に対する処理要求であるトランザクションＴＲ−１の（１）、およびトランザクションＴＲ−２の（４）をＤＢ処理要求キュー１１ｂに登録する。また、振分処理部１０ｂは、テーブル１９のレコード１９１に対する処理要求であるトランザクションＴＲ−１の（３）、およびトランザクションＴＲ−２の（２）をＤＢ処理要求キュー１２ｂに登録する。
【００４１】
このとき、振分処理部１０ｂは、現トランザクションリスト１００に、トランザクションＴＲ−１、ＴＲ−２の受信順に現在実行中のトランザクションとして登録する。トランザクションの優先度は現トランザクションリスト１００の登録順であるため、トランザクションＴＲ−１の方がトランザクションＴＲ−２より優先度が高いことを示す。
【００４２】
つぎに、各ＤＢ処理部が、ＣＭＤＢ処理要求の実行するにあたり、現トランザクションリスト１００の登録順（優先順位）に基づいて、各ＤＢ処理要求キュー内のＣＭＤＢ処理要求を並べ替える（ステップＳ１５）。並べ替えの方法としては、例えば、最も優先順位の高いＴＲ−ＩＤと同一のＴＲ−ＩＤが付与されたＣＭＤＢ処理要求を抜き出し、各ＢＤ処理要求キュー内で当該ＴＲ−ＩＤが付与された全てのＣＭＤＢ処理要求をまとめて、ＴＲ−ＩＤの優先順位に従って各ＤＢ処理要求キュー内で並び替える。このとき、２番目以降の優先順位のＴＲ−ＩＤと同一のＴＲ−ＩＤが付与されたＣＭＤＢ処理要求について並び替えを行ってもよい。なお、並べ替える方法は、これに限定するものではない。
【００４３】
また、並び替えるタイミングとしては、例えば、いずれかのＤＢ処理部でＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求を処理した場合に現トランザクションリスト１００から当該ＴＲ−ＩＤを削除する処理を行うため、このタイミングとしてもよい。なお、並べ替えるタイミングは、これに限定するものではない。
【００４４】
具体的には、ＤＢ処理部１４ｂが、トランザクションＴＲ−１に属するＣＭＤＢ処理要求を優先して並び替える。その結果、ＤＢ処理要求キュー１１ｂにおいて、トランザクションＴＲ−１の（１）を先頭に登録し、つぎに、トランザクションＴＲ−２の（４）が位置するように再登録する。同様に、ＤＢ処理部１５ｂが、ＤＢ処理要求キュー１２ｂにおいて、トランザクションＴＲ−１の（３）を先頭に登録し、つぎに、トランザクションＴＲ−２の（２）が位置するように再登録する。
【００４５】
ＤＢ処理部１４ｂ、１５ｂは、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を取り出し（ステップＳ１６）、構成管理ＤＢ１７に対してＣＭＤＢ更新／参照処理を実行する（ステップＳ１７）。構成管理ＤＢ１７に対する処理は、上述の説明と同様である。
【００４６】
いずれかのＤＢ処理部において、ＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求を取り出した場合は、他のＤＢ処理要求キューに同一ＴＲ−ＩＤのＣＭＤＢ処理要求が残っているかどうかを確認する。残っていた場合は、ＥｎｄＴＲマークが付与されたＣＭＤＢ処理要求の処理を行わない。残っていない場合は、取り出したＣＭＤＢ処理要求の処理を行った後、現トランザクションリスト１００から当該ＴＲ−ＩＤを削除する。
【００４７】
このように、各ＤＢ処理部が、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を現トランザクションリスト１００の登録順序で並べ替えるため、その結果、トランザクションの優先順で各レコード単位のＣＭＤＢ処理要求が実行されるため、デッドロックが発生しない。なお、各ＤＢ処理部が、各ＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を並べ替えることとしたが、振分処理部１０ｂが各ＤＢ処理要求キューに登録する際に行ってもよい。
【００４８】
なお、本実施の形態では、トランザクションの優先順位として、振分処理部１０ｂで受信した順番としているが、これに限定するものではない。例えば、各ＤＢ処理部において、トランザクション開始時期を現トランザクションリスト１００に記録することにより、トランザクションの開始タイミングが早い程、優先順位を高くすると定義してもよい。また、利用者によりＣＭＤＢ処理要求時に優先順位を明示的に設定する等、他の規則によりトランザクションの優先順位を決定した場合においても同様の効果が期待できる。
【００４９】
例えば、開始タイミングの早いトランザクションの優先順位を高くする場合では、ＳｔａｒｔＴＲが付与されたＣＭＤＢ処理要求を取り出したいずれかのＤＢ処理部が、当該ＳｔａｒｔＴＲが付与されたトランザクションのＴＲ−ＩＤを現トランザクションリスト１００に記録する。その後、各ＤＢ処理が当該ＴＲ−ＩＤが付与されたＣＭＤＢ要求を各ＤＢ処理要求キューから抜き出し、各ＤＢ処理要求キュー内において優先順位に基づいて並べ替えを行う。待ちフラグの立っているＣＭＤＢ処理要求についてはリセットする。待ちフラグは、現トランザクションリスト１００に無いＣＭＤＢ処理要求を取り出したＤＢ処理部が、当該ＣＭＤＢ処理要求に立て、処理の対象としない。なお、トランザクションの優先順位を受信順で決める場合では、各ＤＢ処理要求キューに登録されているＣＭＤＢ処理要求に付与されているＴＲ−ＩＤは、必ず現トランザクションリスト１００に登録されている。そのため、現トランザクションリスト１００に基づいて並べ替えることが可能であり、待ちフラグの必要はない。
【００５０】
以上説明したように、本実施の形態によれば、トランザクションが複数のレコードの更新／参照処理のまとまりである場合に、振分処理部が、受け付けたトランザクションをレコード処理単位のＣＭＤＢ処理要求に分解してハッシュ関数による計算を実行し、また、ＤＢ処理部が、トランザクションの優先順位に基づいてＤＢ処理要求キューに登録されたＣＭＤＢ処理要求を並び替えることとした。これにより、実施の形態１の効果に加え、デッドロックを防止することができ、システム全体として負荷を軽減することができる。
【００５１】
なお、これまでの説明では、通信装置管理システムに対して、上位管理アプリケーション装置等が全て共通のインタフェイスでＣＭＤＢ処理要求を送信する方式を想定している。しかしながら、全てのＣＭＤＢ処理要求側のインタフェイスを一括変更することが困難な場合がある。このように、共通でないＣＭＤＢ処理要求元が存在した場合でも、メッセージ形式を共通形式に変換するゲートウェイ等を用いることによって並列処理することが可能となる。
【００５２】
図６は、変換ゲートウェイを配置した通信装置管理システムとの接続例を示す図である。例えば、管理対象通信装置４からは、通信装置管理システム１と通信できない独自のメッセージ形式のＣＭＤＢ処理要求を送信する。このような場合に、独自形式のメッセージを共通形式のメッセージに変換する変換ゲートウェイ５を用いる。
【００５３】
変換ゲートウェイ５は、管理対象通信装置４から入力した独自メッセージ形式のＣＭＤＢ処理要求を通信装置管理システム１が受け付け可能な共通のメッセージ形式のＣＭＤＢ処理要求に変換して出力する。通信装置管理システム１は、変換後の共通メッセージ形式のＣＭＤＢ処理要求を受信することにより、ＣＭＤＢ処理要求を受け付け可能となる。
【００５４】
このように、ＣＭＤＢ処理要求メッセージが共通でない場合でも、変換ゲートウェイ５が異なるメッセージ形式を共通の要求メッセージ形式に変換し、通信装置管理システムに送信することにより、異なるメッセージ形式のＣＭＤＢ処理要求についても、共通に処理して通信装置管理システムにおける処理負荷を分散することができる。
【００５５】
なお、メッセージ形式を変換する構成を通信装置管理システムとＣＭＤＢ処理要求を送信する装置との間に配置する場合について説明したが、これに限定するものではなく、通信装置管理システム内の備えてもよい。
【００５６】
また、ＣＭＤＢ処理要求のメッセージ形式だけでなく、通信プロトコルやコード体系等が標準と異なる場合等、共通の通信インタフェイス仕様から異なる場合においても、変換ゲートウェイを介在させることで、通信装置管理システムに対するインタフェイスを共通化することが可能であり、データベースの更新／参照処理の負荷分散の同等の効果を得ることが期待できる。
【００５７】
また、単一のデータベースを想定しているが、複数のデータベースに跨るデータベースシステムを対象とする場合においても、ハッシュ関数対象をデータベース識別子まで拡張し、データベース識別子、テーブル識別子、レコード識別子の３つの連結計算とすることで適用可能であり、同様の効果を得ることができる。
【００５８】
また、本並列処理方式では、並列度数に応じて、ＤＢ処理要求キューを複数設けたが、ＤＢ処理要求キューは論理的に分離したキューであればよく、物理的には単一キューに実装しても問題なく同様の効果が期待できる。すなわち、物理的に単一のＤＢ処理要求キューとして実装した場合でも、振分処理部において、ＣＭＤＢ処理要求を受信後、単一キューにＣＭＤＢ処理要求を登録する際、ハッシュ関数の計算値を各ＣＭＤＢ処理要求に付加して登録する。その後、複数のＤＢ処理部が、単一キューからＣＭＤＢ処理要求を取り出す際、付加されたハッシュ関数値を参照して各ＤＢ処理部に割り当てられたハッシュ関数値に属するＣＭＤＢ処理要求のみを取り出し、並列して実行することで同様の効果を得ることが期待できる。
【産業上の利用可能性】
【００５９】
以上のように、本発明にかかる通信装置管理システムは、構成管理データベースに対するデータ処理に有用であり、特に、構成管理データベースに対して並列処理を行うシステムに適している。
【符号の説明】
【００６０】
１ 通信装置管理システム
２ 上位管理アプリケーション装置
３ ＥＭＳ利用者端末
４ 管理対象通信装置
５ 変換ゲートウェイ
１０、１０ａ、１０ｂ 振分処理部
１１、１１ａ、１１ｂ、１２、１２ａ、１２ｂ、１３ ＤＢ処理要求キュー
１４、１４ａ、１４ｂ、１５、１５ａ、１５ｂ、１６ ＤＢ処理部
１７ 構成管理ＤＢ
１８、１９ テーブル
１００ 現トランザクションリスト
【特許請求の範囲】
【請求項１】
構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システムであって、
同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、他装置からのアクセス要求を受信し、当該アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて、受信したアクセス要求の振り分け先を決定する振分処理手段と、
複数のキューを備え、ハッシュ計算値ごとに、同一のハッシュ計算値のアクセス要求を同一キューに格納する格納手段と、
前記キューごとに、格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理手段と、
を備えることを特徴とする通信装置管理システム。
【請求項２】
前記振分処理手段は、前記格納手段が備えるキューの数の範囲内の種類のハッシュ計算値を算出する、
ことを特徴とする請求項１に記載の通信装置管理システム。
【請求項３】
前記各装置からのアクセス要求が、複数のアクセス要求を含むトランザクションで送信された場合、
前記振分処理手段は、受信したトランザクションを個々のアクセス要求の単位に分解し、分解したアクセス要求についてハッシュ関数の計算値を算出し、
前記データベース処理手段は、前記格納手段が備える各キューに格納されたアクセス要求を、当該アクセス要求が含まれていたトランザクションの優先順位に基づいて並べ替え、優先順位の高いアクセス要求から前記構成管理データベースに対するアクセス処理を行う、
ことを特徴とする請求項１または２に記載の通信装置管理システム。
【請求項４】
前記振分処理手段は、トランザクションの受信順に基づいて優先順位を決定する、
ことを特徴とする請求項３に記載の通信装置管理システム。
【請求項５】
前記データベース処理手段は、トランザクションの処理の開始順に基づいて優先順位を決定する、
ことを特徴とする請求項３に記載の通信装置管理システム。
【請求項６】
さらに、
前記他装置が前記振分処理手段において受信できない通信形式でアクセス要求を送信した場合に、当該アクセス要求を前記振分処理手段が受信可能な通信形式のアクセス要求に変換する変換手段、
を備えることを特徴とする請求項１〜５のいずれか１つに記載の通信装置管理システム。
【請求項７】
構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システム、が採用するデータベースアクセス処理方法であって、
他装置からのアクセス要求を受信する受信ステップと、
同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、前記アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行うハッシュ計算ステップと、
前記ハッシュ計算値に基づいて受信したアクセス要求の振り分け先を決定する振り分けステップと、
同一のハッシュ計算値のアクセス要求を同一キューに格納する格納ステップと、
前記キューに格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理ステップと、
を含むことを特徴とするデータベースアクセス処理方法。
【請求項８】
前記各装置からのアクセス要求が、複数のアクセス要求を含むトランザクションで送信された場合、
前記受信ステップでは、受信したトランザクションを個々のアクセス要求の単位に分解し、
前記ハッシュ計算ステップでは、分解された個々のアクセス要求についてハッシュ計算値を算出し、
さらに、
所定の規則に基づいて前記トランザクションに優先順位を付ける優先順位付与ステップと、
前記キューに格納されたアクセス要求を優先順位に基づいて並べ替える並べ替えステップと、
を含むことを特徴とする請求項７に記載のデータベースアクセス処理方法。
【請求項９】
さらに、
前記他装置が前記受信ステップにおいて受信できない通信形式でアクセス要求を送信した場合に、当該アクセス要求を前記受信ステップで受信可能な通信形式のアクセス要求に変換する変換ステップ、
を含むことを特徴とする請求項７または８に記載のデータベースアクセス処理方法。
【請求項１】
構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システムであって、
同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、他装置からのアクセス要求を受信し、当該アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行い、ハッシュ計算値に基づいて、受信したアクセス要求の振り分け先を決定する振分処理手段と、
複数のキューを備え、ハッシュ計算値ごとに、同一のハッシュ計算値のアクセス要求を同一キューに格納する格納手段と、
前記キューごとに、格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理手段と、
を備えることを特徴とする通信装置管理システム。
【請求項２】
前記振分処理手段は、前記格納手段が備えるキューの数の範囲内の種類のハッシュ計算値を算出する、
ことを特徴とする請求項１に記載の通信装置管理システム。
【請求項３】
前記各装置からのアクセス要求が、複数のアクセス要求を含むトランザクションで送信された場合、
前記振分処理手段は、受信したトランザクションを個々のアクセス要求の単位に分解し、分解したアクセス要求についてハッシュ関数の計算値を算出し、
前記データベース処理手段は、前記格納手段が備える各キューに格納されたアクセス要求を、当該アクセス要求が含まれていたトランザクションの優先順位に基づいて並べ替え、優先順位の高いアクセス要求から前記構成管理データベースに対するアクセス処理を行う、
ことを特徴とする請求項１または２に記載の通信装置管理システム。
【請求項４】
前記振分処理手段は、トランザクションの受信順に基づいて優先順位を決定する、
ことを特徴とする請求項３に記載の通信装置管理システム。
【請求項５】
前記データベース処理手段は、トランザクションの処理の開始順に基づいて優先順位を決定する、
ことを特徴とする請求項３に記載の通信装置管理システム。
【請求項６】
さらに、
前記他装置が前記振分処理手段において受信できない通信形式でアクセス要求を送信した場合に、当該アクセス要求を前記振分処理手段が受信可能な通信形式のアクセス要求に変換する変換手段、
を備えることを特徴とする請求項１〜５のいずれか１つに記載の通信装置管理システム。
【請求項７】
構成管理データベースを備え、他装置からのデータ更新またはデータ参照の処理要求であるアクセス要求に基づいて、当該構成管理データベースへのアクセス処理を行う通信装置管理システム、が採用するデータベースアクセス処理方法であって、
他装置からのアクセス要求を受信する受信ステップと、
同一テーブルの同一レコードにアクセスするアクセス要求に対してハッシュ計算を行うと同一のハッシュ計算値を得るハッシュ関数を適用する場合において、前記アクセス要求に記載されている前記構成管理データベースのアクセス先を特定するテーブル識別子およびレコード識別子に基づいてハッシュ計算を行うハッシュ計算ステップと、
前記ハッシュ計算値に基づいて受信したアクセス要求の振り分け先を決定する振り分けステップと、
同一のハッシュ計算値のアクセス要求を同一キューに格納する格納ステップと、
前記キューに格納されたアクセス要求を取り出して前記構成管理データベースに対するアクセス処理を行うデータベース処理ステップと、
を含むことを特徴とするデータベースアクセス処理方法。
【請求項８】
前記各装置からのアクセス要求が、複数のアクセス要求を含むトランザクションで送信された場合、
前記受信ステップでは、受信したトランザクションを個々のアクセス要求の単位に分解し、
前記ハッシュ計算ステップでは、分解された個々のアクセス要求についてハッシュ計算値を算出し、
さらに、
所定の規則に基づいて前記トランザクションに優先順位を付ける優先順位付与ステップと、
前記キューに格納されたアクセス要求を優先順位に基づいて並べ替える並べ替えステップと、
を含むことを特徴とする請求項７に記載のデータベースアクセス処理方法。
【請求項９】
さらに、
前記他装置が前記受信ステップにおいて受信できない通信形式でアクセス要求を送信した場合に、当該アクセス要求を前記受信ステップで受信可能な通信形式のアクセス要求に変換する変換ステップ、
を含むことを特徴とする請求項７または８に記載のデータベースアクセス処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−５９８０４（Ｐ２０１１−５９８０４Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２００９−２０６２９４（Ｐ２００９−２０６２９４）
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年９月７日（２００９．９．７）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]