(57)【要約】【課題】複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの不整合を発生させないデータ管理方法及びデータ管理システムを提供する。【解決手段】ＸＣＡＰサーバＸＳ０が、ＸＣＡＰクライアントＸＣから一括更新要求を受け付けた複数データのアクセス順序を一意に決定する。決定したアクセス順序にしたがって各データを管理するＸＣＡＰサーバＸＳ１，ＸＳ２がマルチホップ処理要求を中継することで、各データの排他制御とデータ値の収集とを行ったのち、最終段のＸＣＡＰサーバＸＳ２が全てのデータ値を含んだコールバック処理要求をトランザクション処理部ＸＴに送信する。トランザクション処理部ＸＴによって一括更新された更新後のデータ値を含む応答情報を、元のアクセス順序と逆のルートで各ＸＣＡＰサーバＸＳ２，ＸＳ１が中継することで、各データのデータ値の更新と排他制御の解除とを行う。【選択図】図１
2014056451.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続された複数のクライアントからアクセスされるデータを管理するデータ管理システムにおけるデータ管理方法であって、
前記データ管理システムは、前記データを管理する１以上のデータ管理サーバと、指定された複数の前記データの一括更新を行うトランザクション処理手段と、を備えており、
前記データ管理サーバが、前記クライアントから指定された複数の前記データの一括更新要求を受け付けて、当該複数のデータのアクセス順序を一意に決定し、決定したアクセス順序の先頭のデータを管理する前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報を含んで当該先頭のデータの取得を要求するマルチホップ処理要求を送信する第１のステップと、
前記データ管理サーバのそれぞれが、受信した前記マルチホップ処理要求にて取得が要求されたデータの値を取得して当該データの排他制御を行ったのち、当該マルチホップ処理要求に含まれる前記アクセス順序の情報における先頭のデータを管理する次段の前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報と前記取得したデータの値とを含んで当該先頭のデータの取得を要求する次段のマルチホップ処理要求を送信する処理を、指定された前記データの値が全て取得されるまで繰り返したのち、最終段の前記データ管理サーバが、前記トランザクション処理手段に、取得された全ての前記データの値を含んでデータの一括更新を要求するコールバック処理要求を送信する第２のステップと、
前記トランザクション処理手段が、前記コールバック処理要求に含まれる前記データの値を一括更新し、更新後のデータの値を含んだ応答情報を要求元の前記データ管理サーバに返送する第３のステップと、
前記応答情報を受信した前記データ管理サーバのそれぞれが、自身が管理する前記データの値を、前記応答情報に含まれている自身が管理する前記データの更新後のデータの値に更新して当該データの排他制御を解除したのち、前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに、当該データの値を削除した応答情報を返送する処理を、全ての前記更新後のデータの値が削除されるまで繰り返す第４のステップと、
前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバが、前記クライアントに前記一括更新要求に対する応答情報を返送する第５のステップと、
を含むことを特徴とするデータ管理方法。
【請求項２】
請求項１に記載のデータ管理方法において、
前記第３のステップにて、前記トランザクション処理手段が前記データの値の一括更新に失敗した場合は、前記応答情報の代わりにエラー情報を要求元の前記データ管理サーバに返送し、
前記第４のステップでは、前記データ管理サーバのそれぞれは、前記データの更新を行うことなく前記排他制御を解除したのち、受信した前記エラー情報を前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに返送する処理を繰り返し、
前記第５のステップでは、前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバは、前記クライアントに前記エラー情報を返送する
ことを特徴とするデータ管理方法。
【請求項３】
請求項１または請求項２に記載のデータ管理方法において、
前記一括更新要求、前記マルチホップ処理要求、及び前記コールバック処理要求は、ＰＯＳＴリクエストにそれぞれ固有のヘッダ情報が追加されたものである
ことを特徴とするデータ管理方法。
【請求項４】
ネットワーク接続された複数のクライアントからアクセスされるデータを管理するデータ管理システムであって、
処理部及び前記データの値が保持される記憶部を備える１以上のデータ管理サーバと、
指定された複数の前記データの一括更新を行うトランザクション処理手段と、を有してなり、
前記データ管理サーバの前記処理部は、
前記クライアントから指定された複数の前記データの一括更新要求を受け付けて、当該要求に対する処理結果を応答する要求受付応答部と、
当該複数のデータのアクセス順序を一意に決定するデータアクセス順序決定部と、
決定したアクセス順序の先頭のデータの値を記憶する前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報を含んで当該先頭のデータの取得を要求するマルチホップ処理要求を送信し、
他の前記データ管理サーバから受信した前記マルチホップ処理要求にて取得が要求されたデータの値を取得したのち、当該マルチホップ処理要求に含まれる前記アクセス順序の情報における先頭のデータの値を記憶する次段の前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報と前記取得したデータの値とを含んで当該先頭のデータの取得を要求する次段のマルチホップ処理要求を送信する処理を、指定された前記データの値が全て取得されるまで繰り返し、
指定された前記データの値が全て取得された場合は、前記トランザクション処理手段に、取得された全ての前記データの値を含んでデータの一括更新を要求するコールバック処理要求を送信するとともに、送信したそれらの要求に対する応答情報を受信して、要求元の前記データ管理サーバに中継するマルチホップ処理要求中継部と、
他の前記データ管理サーバから受信した前記マルチホップ処理要求にて取得が要求されたデータの排他制御を行ったのち、当該データの値を取得して前記マルチホップ処理要求中継部に引き渡し、前記マルチホップ処理要求中継部が受信した前記応答情報に自身が記憶する前記データの更新後のデータの値が含まれている場合は、自身が記憶する前記データの値を、前記応答情報に含まれている前記更新後のデータの値に更新して当該データの排他制御を解除する、データ管理部と、を備え、
前記トランザクション処理手段は、前記コールバック処理要求に含まれるデータの値を一括更新して更新後のデータの値を含んだ前記応答情報を要求元の前記データ管理サーバに返送する
ことを特徴とするデータ管理システム。
【請求項５】
請求項４に記載のデータ管理システムにおいて、
前記トランザクション処理手段は、前記データの値の一括更新に失敗した場合は、前記応答情報の代わりにエラー情報を要求元の前記データ管理サーバに返送し、
前記エラー情報を受信した前記データ管理サーバの前記データ管理部は、自身が記憶する前記データの更新を行うことなく前記排他制御を解除し、前記マルチホップ処理要求中継部は、受信した前記エラー情報を前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに返送する処理を繰り返し、
前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバは、前記クライアントに前記エラー情報を返送する
ことを特徴とするデータ管理システム。
【請求項６】
請求項４または請求項５に記載のデータ管理システムにおいて、
前記一括更新要求、前記マルチホップ処理要求、及び前記コールバック処理要求は、ＰＯＳＴリクエストにそれぞれ固有のヘッダ情報が追加されたものである
ことを特徴とするデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＣＡＰ（XML Configuration Access Protocol）などのＨＴＴＰ（Hyper-Text Transport Protocol）ベースのプロトコルを用いてデータを管理するネットワークサーバ装置において、複数データの一括更新が行われる場合のデータの整合性を保証するための技術に関する。
【背景技術】
【０００２】
次世代ネットワーク（ＮＧＮ：Next Generation Network）の中核技術であるＩＭＳ（IP Multimedia Subsystem）では、共有データを管理する仕組みとして、ＸＭＬ（Extensible Markup Language）形式のドキュメント（以下、「ＸＭＬドキュメント」という）によって記述されるデータをアクセスするためのＸＣＡＰが規定されている。
【０００３】
ＸＣＡＰサーバは、ネットワーク接続されるコンピュータによって構成され、ＸＭＬドキュメントを記憶し管理するサーバであり、ＸＣＡＰによるクライアントからの遠隔アクセスが可能である。ＸＣＡＰは、ＨＴＴＰ（Hypertext Transfer Protocol）をベースとしたプロトコルであり、リクエストとレスポンスとの対で完結する単純なプロトコルである。それ故、標準で規定されているオペレーションにおいては、読み込み（ＧＥＴ）、生成・置換（ＰＵＴ）、削除（ＤＥＬＥＴＥ）といったオペレーションが、１回１回独立して実行されるものとなっている（例えば、非特許文献１参照）。
【０００４】
ＸＣＡＰを用いて遠隔からＸＣＡＰサーバのデータ（ＸＭＬドキュメント）を更新する場合、複数の更新要求を同時に処理するとデータの整合性が保てなくなる可能性がある。ＸＣＡＰサーバにおいてデータの整合性を保証する方式については、標準化文書であるＲＦＣ４８２５に記載されている方式や、標準仕様の独自拡張による方式が提案されている（例えば、非特許文献２）。ただし、それらの技術は、いずれも単一データとしての整合性を保証するための技術であり、複数データが一括取得されたり一括更新されたりする場合のデータ間の整合性までは考慮がなされていない。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ゴンザロ・カマリロ／ミゲール・A・マーチン共著、「ＩＭＳ標準テキスト  改訂版」、リックテレコム、2010年3月
【非特許文献２】金子雅志、外３名、「ＸＣＡＰサーバにおけるトランザクション処理方式に関する一検討」、電子情報通信学会ソサイエティ大会講演論文集、2011年8月30日、B-6-35
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、前記従来技術の課題を解決するためになされたものであり、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムにおいて、複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの不整合を発生させないデータ管理方法及びデータ管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
前記の目的を達成するために、本発明に係るデータ管理方法は、ネットワーク接続された複数のクライアントからアクセスされるデータを管理するデータ管理システムにおけるデータ管理方法であって、前記データ管理システムは、前記データを管理する１以上のデータ管理サーバと、指定された複数の前記データの一括更新を行うトランザクション処理手段と、を備えており、前記データ管理サーバが、前記クライアントから指定された複数の前記データの一括更新要求を受け付けて、当該複数のデータのアクセス順序を一意に決定し、決定したアクセス順序の先頭のデータを管理する前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報を含んで当該先頭のデータの取得を要求するマルチホップ処理要求を送信する第１のステップと、前記データ管理サーバのそれぞれが、受信した前記マルチホップ処理要求にて取得が要求されたデータの値を取得して当該データの排他制御を行ったのち、当該マルチホップ処理要求に含まれる前記アクセス順序の情報における先頭のデータを管理する次段の前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報と前記取得したデータの値とを含んで当該先頭のデータの取得を要求する次段のマルチホップ処理要求を送信する処理を、指定された前記データの値が全て取得されるまで繰り返したのち、最終段の前記データ管理サーバが、前記トランザクション処理手段に、取得された全ての前記データの値を含んでデータの一括更新を要求するコールバック処理要求を送信する第２のステップと、前記トランザクション処理手段が、前記コールバック処理要求に含まれる前記データの値を一括更新し、更新後のデータの値を含んだ応答情報を要求元の前記データ管理サーバに返送する第３のステップと、前記応答情報を受信した前記データ管理サーバのそれぞれが、自身が管理する前記データの値を、前記応答情報に含まれている自身が管理する前記データの更新後のデータの値に更新して当該データの排他制御を解除したのち、前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに、当該データの値を削除した応答情報を返送する処理を、全ての前記更新後のデータの値が削除されるまで繰り返す第４のステップと、前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバが、前記クライアントに前記一括更新要求に対する応答情報を返送する第５のステップと、を含むものとした。
【０００８】
こうすることにより、複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの排他制御に伴うデッドロックの発生を回避しつつデータ間の整合性を保つことができる。
【０００９】
また、本発明に係るデータ管理方法は、前記のデータ管理方法において、前記第３のステップにて、前記トランザクション処理手段が前記データの値の一括更新に失敗した場合は、前記応答情報の代わりにエラー情報を要求元の前記データ管理サーバに返送し、前記第４のステップでは、前記データ管理サーバのそれぞれは、前記データの更新を行うことなく前記排他制御を解除したのち、受信した前記エラー情報を前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに返送する処理を繰り返し、前記第５のステップでは、前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバは、前記クライアントに前記エラー情報を返送するものとした。
【００１０】
こうすることにより、複数データの一括更新処理に失敗した場合は、各データ管理サーバにて管理されるデータの値が更新されないので、ロールバック処理の発生を回避することができる。
【００１１】
また、本発明に係るデータ管理方法は、前記のデータ管理方法において、前記一括更新要求、前記マルチホップ処理要求、及び前記コールバック処理要求は、ＰＯＳＴリクエストにそれぞれ固有のヘッダ情報が追加されたものとした。
【００１２】
こうすることにより、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムを実現することができる。
【００１３】
また、本発明に係るデータ管理システムは、ネットワーク接続された複数のクライアントからアクセスされるデータを管理するデータ管理システムであって、処理部及び前記データの値が保持される記憶部を備える１以上のデータ管理サーバと、指定された複数の前記データの一括更新を行うトランザクション処理手段と、を有してなり、前記データ管理サーバの前記処理部は、前記クライアントから指定された複数の前記データの一括更新要求を受け付けて、当該要求に対する処理結果を応答する要求受付応答部と、当該複数のデータのアクセス順序を一意に決定するデータアクセス順序決定部と、決定したアクセス順序の先頭のデータの値を記憶する前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報を含んで当該先頭のデータの取得を要求するマルチホップ処理要求を送信し、他の前記データ管理サーバから受信した前記マルチホップ処理要求にて取得が要求されたデータの値を取得したのち、当該マルチホップ処理要求に含まれる前記アクセス順序の情報における先頭のデータの値を記憶する次段の前記データ管理サーバに、当該先頭のデータ以外の残りのデータのアクセス順序の情報と前記取得したデータの値とを含んで当該先頭のデータの取得を要求する次段のマルチホップ処理要求を送信する処理を、指定された前記データの値が全て取得されるまで繰り返し、指定された前記データの値が全て取得された場合は、前記トランザクション処理手段に、取得された全ての前記データの値を含んでデータの一括更新を要求するコールバック処理要求を送信するとともに、送信したそれらの要求に対する応答情報を受信して、要求元の前記データ管理サーバに中継するマルチホップ処理要求中継部と、他の前記データ管理サーバから受信した前記マルチホップ処理要求にて取得が要求されたデータの排他制御を行ったのち、当該データの値を取得して前記マルチホップ処理要求中継部に引き渡し、前記マルチホップ処理要求中継部が受信した前記応答情報に自身が記憶する前記データの更新後のデータの値が含まれている場合は、自身が記憶する前記データの値を、前記応答情報に含まれている前記更新後のデータの値に更新して当該データの排他制御を解除する、データ管理部と、を備え、前記トランザクション処理手段は、前記コールバック処理要求に含まれるデータの値を一括更新して更新後のデータの値を含んだ前記応答情報を要求元の前記データ管理サーバに返送するものとした。
【００１４】
こうすることにより、複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの排他制御に伴うデッドロックの発生を回避しつつデータ間の整合性を保つことができる。
【００１５】
また、本発明に係るデータ管理システムは、前記のデータ管理システムにおいて、前記トランザクション処理手段は、前記データの値の一括更新に失敗した場合は、前記応答情報の代わりにエラー情報を要求元の前記データ管理サーバに返送し、前記エラー情報を受信した前記データ管理サーバの前記データ管理部は、自身が記憶する前記データの更新を行うことなく前記排他制御を解除し、前記マルチホップ処理要求中継部は、受信した前記エラー情報を前記マルチホップ処理要求を送信してきた前段の前記データ管理サーバに返送する処理を繰り返し、前記クライアントから前記一括更新要求を受け付けた初段の前記データ管理サーバは、前記クライアントに前記エラー情報を返送するものとした。
【００１６】
こうすることにより、複数データの一括更新処理に失敗した場合は、各データ管理サーバにて保持されるデータの値が更新されないので、ロールバック処理の発生を回避することができる。
【００１７】
また、本発明に係るデータ管理システムは、前記のデータ管理システムにおいて、前記一括更新要求、前記マルチホップ処理要求、及び前記コールバック処理要求は、ＰＯＳＴリクエストにそれぞれ固有のヘッダ情報が追加されたものとした。
【００１８】
こうすることにより、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムを実現することができる。
【発明の効果】
【００１９】
本発明によれば、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムにおいて、複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの不整合を発生させないデータ管理方法及びデータ管理システムを提供することができる。
【図面の簡単な説明】
【００２０】
【図１】本発明の実施形態に係るデータ管理システムの概要を示す説明図である。
【図２】本実施形態に係るＸＣＡＰサーバの機能ブロック図である。
【図３】本実施形態における複数データの一括更新動作の基本シーケンス図である。
【図４】本実施形態における競合制御動作の部分シーケンス図である。
【図５】トランザクション処理が失敗したときのシーケンス図である。
【図６】従来のデータ管理システムの概要を示す説明図である。
【図７】従来の競合制御動作のシーケンス図である。
【図８】従来の競合制御動作におけるロールバック動作例を示すシーケンス図である。
【発明を実施するための形態】
【００２１】
以下、本発明の実施形態を適宜図面を参照して詳細に説明する。
図６は、非特許文献２に係るコールバック方式による従来のデータ管理システムの概要を示す説明図である。このコールバック方式では、データ管理サーバとしてのＸＣＡＰサーバが管理しているデータの更新処理は、ＸＣＡＰサーバとは独立したトランザクション処理部によって行われる。
【００２２】
図６に示すように、２台のＸＣＡＰクライアント（クライアント）ＸＣ１及びＸＣ２から、データＡを管理するＸＣＡＰサーバＸＳに対して、データＡの更新を要求するコールバック処理要求（コールバック処理によるトランザクション処理要求）I，IIが並列に発行された場合、ＸＣＡＰサーバＸＳが備えるコールバック処理機能は、これらを先着順に受け付け、受け付けたコールバック処理要求I，IIにデータＡの値を付加して１つずつ順番にトランザクション処理部ＸＴに転送する。トランザクション処理部ＸＴでは、転送されたデータＡの値を更新するトランザクション処理プログラムを実行することにより、データＡの値を１回目のコールバック処理要求Iでは「Ａ０」→「Ａ１」に更新し、２回目のコールバック処理要求では「Ａ１」→「Ａ２」に更新して、更新後の値を含む応答情報をＸＣＡＰサーバＸＳに返送する。
【００２３】
ＸＣＡＰサーバＸＳは、この応答情報を受信した時点で自身が管理しているデータＡの値を更新し、この更新が終了するまでは次のコールバック処理要求をトランザクション処理部ＸＴに送信しない。このように、ＸＣＡＰサーバＸＳがデータＡに対して排他制御（悲観的ロック）を行うことで、データＡの整合性（一貫性）を保証する。
【００２４】
図７は、非特許文献２に係るコールバック方式における競合制御動作のシーケンス図である。図７に示すように、コールバック動作は、ＸＣＡＰクライアントＸＣ１からＸＣＡＰサーバＸＳへのリクエスト（Ｓ７０１）及び応答（Ｓ７０６）と、ＸＣＡＰサーバＸＳからトランザクション処理部ＸＴへのリクエスト（Ｓ７０２）及び応答（Ｓ７０４）との２段階によって構成される。ただし、ＸＣＡＰクライアントＸＣ１から見た場合は、１つのリクエストによって更新処理が行われているように見える。
【００２５】
具体的には、図７の例のように、コールバック動作によってデータＡの更新を行う場合には、ＸＣＡＰクライアントＸＣ１からデータＡ（保存先のアドレス：[XS_A_URI]）を管理しているＸＣＡＰサーバＸＳに対して、ＨＴＴＰヘッダに「X-Callback:[XT_URI]」パラメータを記述した[XS_A_URI]宛のＰＯＳＴリクエストをコールバック処理要求として送信する（Ｓ７０１）。
【００２６】
これにより、ＸＣＡＰサーバＸＳのコールバック処理機能が呼び出され、データＡに対する排他制御（悲観的ロック）を開始したのち、「X-Callback」パラメータで指定されたアドレス[XT_URI]宛、すなわち、トランザクション処理部ＸＴに対して、ＨＴＴＰヘッダに「X-Callback-Source:[XS_A_URI]」パラメータを記述し、コンテンツ（content）にデータＡの値「Ａ０」を付加したＰＯＳＴリクエストをコールバック処理要求として送信する（Ｓ７０２）。
【００２７】
このＰＯＳＴリクエスト（Ｓ７０２）を受信したトランザクション処理部ＸＴは、所定のトランザクション処理プログラムを実行することによってデータＡの値「Ａ０」を「Ａ１」に更新し、更新後の値「Ａ１」をコンテンツに付加したコールバック処理要求への応答をＸＣＡＰサーバＸＳに返送する（Ｓ７０４）。この応答を受信したＸＣＡＰサーバＸＳは、自身が管理しているデータＡの値を「Ａ０」から「Ａ１」に更新する。このとき、応答Ｓ７０４のＨＴＴＰヘッダに、トランザクション処理プログラムの実行結果や他の任意の情報を記述した「X-Callback-Return」パラメータを付加することにより、当該パラメータがＸＣＡＰサーバＸＳからＸＣＡＰクライアントＸＣ１に返送される応答Ｓ７０６にも付加される。これにより、トランザクション処理部ＸＴからＸＣＡＰクライアントＸＣ１に必要な情報を伝達することができる。
【００２８】
ここで、ＸＣＡＰサーバＸＳがＸＣＡＰクライアントＸＣ１に対応して送信したコールバック処理要求Ｓ７０２に対する応答Ｓ７０４が返送される前に、他のＸＣＡＰクライアントＸＣ２から同様なコールバック処理要求Ｓ７０３（破線矢印）がＸＣＡＰサーバＸＳに送信されたものとする。この場合、ＸＣＡＰサーバＸＳのコールバック処理機能は、データＡにロックがかかっているので、新たに受信したコールバック処理要求Ｓ７０３の処理を、応答Ｓ７０４が返送されてデータＡの値が更新されロックが解除されるまで待機させる（Ｓ７０５）。これにより、ＸＣＡＰサーバＸＳは、データＡに対する排他制御を行い、データの整合性（一貫性）を確保する。なお、図７では、ＸＣＡＰクライアントＸＣ２からのコールバック処理要求Ｓ７０３に対して開始される排他制御の記載を省略している。
【００２９】
このように、非特許文献２に係るコールバック方式によれば、単一データに対しては更新処理時の整合性を保証することができるが、複数データに対する一括更新が行われる場合については、それらのデータ間の整合性を保証することはできない。その具体例を図８のシーケンス図に示す。図８は、２台のＸＣＡＰサーバＸＳ１とＸＳ２とによりそれぞれ回線数ＸとＹとが個別に管理されており、回線確保処理によってこれら両者の値が一括して更新（減算処理）される例を示すシーケンス図である。ここでは、回線数Ｘ及びＹの双方が１以上の場合のみ回線確保処理が成功し、そうでない場合には回線確保処理が失敗するため回線数Ｘ及びＹの減算処理は行わないものと仮定する。
【００３０】
図８に示すように、この回線確保処理を前記のコールバック方式によって実装する場合には、回線数Ｘに対する更新処理（Ｓ８０１〜Ｓ８０４）と、回線数Ｙに対する更新処理（Ｓ８０５〜Ｓ８０８）とが、個別に（順番にまたは並列に）実行されることになる。そのため、例えば回線数Ｘが１以上であり回線数Ｙが０であった場合は、回線数Ｘに対する更新処理（Ｓ８０１〜Ｓ８０４）は成功してＸの値は減算されるが、回線数Ｙに対する更新処理（Ｓ８０５〜Ｓ８０８）が失敗して回線数Ｙは減算されない。そこで、すでに減算したＸの値を元に戻すために、回線数Ｘに対するロールバック処理（Ｓ８０９〜Ｓ８１２）が必要となる。
【００３１】
このように、前記のコールバック方式では、複数データの一括更新を行うトランザクション処理を実装しようとすると、ＸＣＡＰクライアントの実装が複雑化してしまうこととなる。
【００３２】
そこで、本発明では、前記のコールバック方式を拡張したマルチホップ方式によってこの問題を解決する。図１は、本発明の実施形態に係るデータ管理システムの概要を示す説明図である。このマルチホップ方式では、データ管理サーバとしてのＸＣＡＰサーバによって分散管理されている複数データの一括更新処理を、ＸＣＡＰサーバとは論理的に分離されたトランザクション処理部（トランザクション処理手段）ＸＴで行うとともに、ＸＣＡＰクライアント（クライアント）ＸＣからの複数データの一括更新要求を受け付けたＸＣＡＰサーバＸＳ０が、データのアクセス順序を決定して、決定したアクセス順序にしたがったルートで各ＸＣＡＰサーバに一括更新要求をマルチホップ中継させ、必要な全てのデータが順次追加された一括更新要求を最終的にトランザクション処理部（トランザクション処理手段）ＸＴに到達させる。なお、トランザクション処理部（トランザクション処理手段）ＸＴは、ＸＣＡＰサーバとは異なるサーバ内に実装してもよいし、任意のＸＣＡＰサーバ内に実装するものとしてもよい。
【００３３】
図１に示すように、このマルチホップ方式における動作は、大きく次の５ステップから構成される。
【００３４】
［第１ステップ（Ｓ１０１）］
ＸＣＡＰサーバＸＳ０のマルチホップ処理機能が、ＸＣＡＰクライアントＸＣから複数データの一括更新に係るマルチホップ処理要求を受け付ける。ＸＣＡＰサーバＸＳ０のマルチホップ処理機能は、複数データが同時に排他制御されることによるデッドロックの発生を回避するために、指定された複数データに含まれるデータ間のアクセス順序関係が常に一定となるように、それら複数データのアクセス順序を一意に決定する。アクセス順序の決定方法としては、例えば、データ識別名（ＵＲＩ：Uniform Resource Identifier）のアルファベット昇順とする方法などが考えられる。これにより、仮に「Ａ→Ｂ」のデータ順で指定されたマルチホップ処理要求と、「Ｂ→Ａ」のデータ順で指定されたマルチホップ処理要求とが同時に発生したとしても、両者のロックが開始される順序は例えば「Ａ」→「Ｂ」の一定順となるので、デッドロックの発生を回避することができる。
【００３５】
［第２ステップ（Ｓ１０２）］
ＸＣＡＰサーバＸＳ０によって決定されたアクセス順序にしたがって、複数データの一括更新に係るマルチホップ処理要求（処理要求I，II）が、ＸＣＡＰサーバＸＳ０→ＸＣＡＰサーバＸＳ１→ＸＣＡＰサーバＸＳ２の順でマルチホップ中継される。このマルチホップ処理要求を受信したＸＣＡＰサーバＸＳ１，ＸＳ２のマルチホップ処理機能は、自サーバが管理している該当データの値を付加した次段のマルチホップ処理要求を次段のＸＣＡＰサーバに中継するとともに、当該データに対して排他制御（悲観的ロック）を行う。これにより、指定された全てのデータに順次ロックがかけられながら、それらのデータの値がマルチホップ処理要求に順次付加されて中継され、最終段のＸＣＡＰサーバＸＳ２のマルチホップ処理機能は、指定された全てのデータが付加されたコールバック処理要求をトランザクション処理手段としてのトランザクション処理部ＸＴに送信する。
【００３６】
［第３ステップ（Ｓ１０３）］
コールバック処理要求を受信したトランザクション処理部ＸＴは、所定のトランザクション処理プログラムを実行することにより、指定された複数データの一括更新を行い、更新後の値をコンテンツに付加したコールバック処理要求への応答を要求元である最終段のＸＣＡＰサーバＸＳ２に返送する。
【００３７】
［第４ステップ（Ｓ１０４）］
ＸＣＡＰサーバＸＳ０によって決定されたアクセス順序の逆順で、マルチホップ処理要求への応答が、ＸＣＡＰサーバＸＳ２→ＸＣＡＰサーバＸＳ１→ＸＣＡＰサーバＸ０の順でマルチホップ中継される。この応答を受信したＸＣＡＰサーバＸＳ２，ＸＳ１のマルチホップ処理機能は、自サーバが管理している該当データの値を更新後の値に更新したのち当該データの排他制御（悲観的ロック）を解除する。
【００３８】
［第５ステップ（Ｓ１０５）］
初段のＸＣＡＰサーバＸＳ０のマルチホップ処理機能は、指定された全てのデータの更新とロックの解除が完了したのち、先に受け付けたマルチホップ処理要求への応答をＸＣＡＰクライアントＸＣに送信する。これにより一連の動作が完了する。
【００３９】
図２は、本実施形態に係るＸＣＡＰサーバの機能ブロック図である。図２に示すように、本実施形態に係るＸＣＡＰサーバＸＳは、処理部１０と記憶部２０と通信インタフェース部３０とを備えるコンピュータによって構成される。処理部１０は、マルチホップ処理要求受付応答部（要求受付応答部）１１、マルチホップ処理条件判定部１２、データアクセス順序決定部１３、マルチホップ処理要求中継部１４、データ管理部１５を有してなる。図１で示したマルチホップ処理機能を構成するこれらの各機能部は、処理部１０が備える不図示のＣＰＵ（Central Processing Unit）が、対応するそれぞれのプログラムを実行することによって具現化される。ハードディスク装置や半導体メモリなどによって構成される記憶部２０には、ＸＣＡＰクライアントＸＣからアクセスされる共有データ２１が保持される。通信インタフェース部３０は、不図示の通信ネットワークを介して他装置との間で各種データの送受信を行う。
【００４０】
マルチホップ処理要求受付応答部１１は、ＸＣＡＰクライアントＸＣから送信される複数データの一括更新についてのマルチホップ処理要求を受け付け、マルチホップ処理条件判定部１２に引き渡す。また、マルチホップ処理要求中継部１４から引き渡されるマルチホップ処理要求への応答を、要求元のＸＣＡＰクライアントＸＣに返送する。
【００４１】
マルチホップ処理条件判定部１２は、ＸＣＡＰクライアントＸＣまたは他のＸＣＡＰサーバＸＳから受信したマルチホップ処理要求が所定の処理条件に一致するか否かを判定し、それぞれの処理条件に対応する処理を実行させる。所定の処理条件とそれに対応して実行させる処理との組合せとして、次の３つがある。
【００４２】
［処理条件１］
マルチホップ処理要求としてのＰＯＳＴリクエストの宛先ＵＲＩが、自サーバのアドレスに一致する。
［処理１］
マルチホップ処理条件判定部１２は、データアクセス順序決定部１３を起動して複数データのアクセス順序を一意に決定させたのち、マルチホップ処理要求中継部１４を起動して、最初にアクセスするデータを管理しているＸＣＡＰサーバＸＳへマルチホップ処理要求を送信させる。
【００４３】
［処理条件２］
マルチホップ処理要求としてのＰＯＳＴリクエストの宛先ＵＲＩが、自サーバが管理しているデータの保存先アドレスに一致し、かつ、まだ次のアクセスデータが存在する。
［処理２］
マルチホップ処理条件判定部１２は、データ管理部１５を起動して宛先ＵＲＩに該当するデータの値を取得させ、マルチホップ処理要求中継部１４を起動して、当該データの値を付加したマルチホップ処理要求を、次にアクセスするデータを管理しているＸＣＡＰサーバＸＳへ中継させる。
【００４４】
［処理条件３］
マルチホップ処理要求としてのＨＴＴＰリクエストの宛先ＵＲＩが、自サーバが管理しているデータの保存先アドレスに一致し、かつ、次のアクセスデータが存在しない。
［処理３］
マルチホップ処理条件判定部１２は、データ管理部１５を起動して宛先ＵＲＩに該当するデータの値を取得させ、マルチホップ処理要求中継部１４を起動して、受信したマルチホップ処理要求に記述されている他のデータの値とともに、複数データの一括更新を要求するコールバック処理要求を、トランザクション処理部ＸＴへ送信させる。
【００４５】
データアクセス順序決定部１３は、複数データの排他制御（悲観的ロック）によるデッドロックの発生を回避するために、ＸＣＡＰクライアントＸＣから受信したマルチホップ処理要求によって指定された複数データに含まれる各データ間のアクセス順序関係が常に一定となるように、当該複数データのアクセス順序を一意に決定する。
【００４６】
マルチホップ処理要求中継部１４は、次段のＸＣＡＰサーバＸＳへのマルチホップ処理要求の中継またはトランザクション処理部ＸＴへのコールバック処理要求の送信を行い、その応答を受信して前段のＸＣＡＰサーバに中継する。また、応答に含まれる自サーバに係る更新後のデータの値をコンテンツから取り出してデータ管理部１５に引き渡す。
【００４７】
データ管理部１５は、記憶部２０に保持されている共有データ２１のデータ値の取得及び更新と排他制御（悲観的ロック）とを行う。
【００４８】
図３は、本実施形態における複数データの一括更新動作の基本シーケンス図である。図３の例のように、マルチホップ機能を用いてデータＡとデータＢとの一括更新を行う場合には、ＸＣＡＰクライアントＸＣからアドレス[XS0_URI]をもつ初段のＸＣＡＰサーバＸＳ０に対して、各データのＵＲＩ（保存先アドレス）が記述された「X-Multihop-Route:[XS_A_URI],[XS_B_URI]」パラメータをＨＴＴＰヘッダに含むＰＯＳＴリクエストを、マルチホップ処理要求として送信する（Ｓ３０１）。
【００４９】
このマルチホップ処理要求（Ｓ３０１）は、ＸＣＡＰサーバＸＳ０のマルチホップ処理要求受付応答部１１によって受け付けられ、マルチホップ処理条件判定部１２は、前記の［処理条件１］に一致すると判定して前記の［処理１］を実行する。それにより、データアクセス順序決定部１３は、「X-Multihop-Route」パラメータで指定されたデータＡとデータＢとのアクセス順序を、例えば「Ａ→Ｂ」の順に決定する。そして、マルチホップ処理要求中継部１４は、宛先ＵＲＩに先頭のデータであるデータＡのＵＲＩ[XS_A_URI]を設定し、「X-Multihop-Route」パラメータから[XS_A_URI]を削除したＰＯＳＴリクエストを、データＡを管理しているＸＣＡＰサーバＸＳ１にマルチホップ処理要求として送信する（Ｓ３０２）。
【００５０】
このマルチホップ処理要求（Ｓ３０２）は、ＸＣＡＰサーバＸＳ１のマルチホップ処理要求中継部１４によって受信され、マルチホップ処理条件判定部１２は、前記の［処理条件２］に一致すると判定して前記の［処理２］を実行する。それにより、データ管理部１５は、宛先ＵＲＩで指定されたデータＡに排他制御（悲観的ロック）をかけたのち、データＡの値「Ａ０」を取得する。そして、マルチホップ処理要求中継部１４は、取得した値「Ａ０」をコンテンツとして付加し、宛先ＵＲＩを[XS_B_URI]とした新たなＰＯＳＴリクエストを生成して、データＢを管理しているＸＣＡＰサーバＸＳ２にマルチホップ処理要求として送信する（Ｓ３０３）。このとき、マルチホップ処理要求中継部１４は、このＰＯＳＴリクエスト（Ｓ３０３）に、コンテンツに付加した値「Ａ０」のＵＲＩを示す「X-Multihop-Via:[XS_A_URI]」パラメータを新たに追加する。
【００５１】
このマルチホップ処理要求（Ｓ３０３）は、ＸＣＡＰサーバＸＳ２のマルチホップ処理要求中継部１４によって受信され、マルチホップ処理条件判定部１２は、マルチホップ処理要求（Ｓ３０３）には「X-Multihop-Route」パラメータが存在しないので、前記の［処理条件３］に一致すると判定して前記の［処理３］を実行する。それにより、データ管理部１５は、宛先ＵＲＩで指定されたデータＢに排他制御（悲観的ロック）をかけたのち、データＢの値「Ｂ０」を取得する。そして、マルチホップ処理要求中継部１４は、取得した値「Ｂ０」を受信した元のコンテンツに付加し、宛先ＵＲＩを[XT_URI]とした新たなＰＯＳＴリクエストを生成して、トランザクション処理部ＸＴにコールバック処理要求として送信する（Ｓ３０４）。このとき、マルチホップ処理要求中継部１４は、このＰＯＳＴリクエスト（Ｓ３０４）に、コンテンツに記述されている値「Ａ０」及び「Ｂ０」のＵＲＩを示す「X-Callback-Source:[XS_A_URI],[XS_B_URI]」パラメータを新たに追加する。
【００５２】
このコールバック処理要求（Ｓ３０４）を受信したトランザクション処理部ＸＴは、所定のトランザクション処理プログラムを実行することにより、受信したデータＡ及びデータＢの値をそれぞれ「Ａ０」→「Ａ１」及び「Ｂ０］→「Ｂ１」へと更新し、更新後の値「Ａ１」、「Ｂ１」をコンテンツとする２００ＯＫレスポンスを、ＸＣＡＰサーバＸＳ２に返送する（Ｓ３０５）。このとき、「X-Callback-Return」パラメータには、一括更新処理が成功したことを示す情報（例えば「Success」）を設定する。
【００５３】
この２００ＯＫレスポンス（Ｓ３０５）を受信したＸＣＡＰサーバＸＳ２のマルチホップ処理要求中継部１４は、受信したコンテンツからデータＢの更新後の値「Ｂ１」を取り出してデータ管理部１５に引き渡し、データ管理部１５は、引き渡されたデータＢの値「Ｂ１」を用いて自身が管理しているデータＢの値を「Ｂ０」→「Ｂ１」へと更新したのち、データＢの排他制御（悲観的ロック）を解除する。そして、マルチホップ処理要求中継部１４は、受信したコンテンツから値「Ｂ１」が削除された２００ＯＫレスポンスをＸＣＡＰサーバＸＳ１に返送する（Ｓ３０６）。
【００５４】
この２００ＯＫレスポンス（Ｓ３０６）を受信したＸＣＡＰサーバＸＳ１のマルチホップ処理要求中継部１４は、受信したコンテンツからデータＡの更新後の値「Ａ１」を取り出してデータ管理部１５に引き渡し、データ管理部１５は、引き渡されたデータＡの値「Ａ１」を用いて自身が管理しているデータＡの値を「Ａ０」→「Ａ１」へと更新したのち、データＡの排他制御（悲観的ロック）を解除する。そして、マルチホップ処理要求中継部１４は、コンテンツのない（<no-content>の）２００ＯＫレスポンスをＸＣＡＰサーバＸＳ０に返送する（Ｓ３０７）。
【００５５】
この２００ＯＫレスポンス（Ｓ３０７）を受信したＸＣＡＰサーバＸＳ０のマルチホップ処理要求中継部１４は、コンテンツのない（<no-content>の）２００ＯＫレスポンスをＸＣＡＰクライアントＸＣに返送する（Ｓ３０８）。ＸＣＡＰクライアントＸＣは、この２００ＯＫレスポンス（Ｓ３０８）を受信することで、先に送信したマルチホップ処理要求（Ｓ３０１）への応答待ちの状態が解除され、元の制御が続行される。このとき、ＸＣＡＰクライアントＸＣは、トランザクション処理部ＸＴによって設定され、ＸＣＡＰサーバＸＳ２，ＸＳ１，ＸＳ０によって中継された「X-Callback-Return」パラメータの情報（例えば「Success」）から、一括更新処理が成功したことを把握する。
【００５６】
図４は、本実施形態における競合制御動作の部分シーケンス図である。なお、図４では、トランザクション処理部ＸＴの記載を省略している。
【００５７】
まず、Ｓ４０１にて、１つ目のＸＣＡＰクライアントＸＣ１から、図３と同様に、データＡとデータＢとの一括更新を行うためのマルチホップ処理要求が、ＸＣＡＰサーバＸＳ０に送信されたものとする。そののち、Ｓ４０２及びＳ４０３にて、マルチホップ処理要求がＸＣＡＰサーバＸＳ２に中継されるまでの動作は図３と同様である。Ｓ４０２のマルチホップ処理要求がＸＣＡＰサーバＸＳ１に受信された時点で、図４の太い縦の実線で示すように、ＸＣＡＰサーバＸＳ１が管理しているデータＡに排他制御（悲観的ロック）がかけられる。このロックは、不図示のトランザクション処理部ＸＴの処理が完了してＳ４０６の２００ＯＫレスポンスが返送されるまで継続する。
【００５８】
その間に、２つ目のＸＣＡＰクライアントＸＣ２から、Ｓ４０４にて、再びデータＡとデータＢとの一括更新を行うためのマルチホップ処理要求が、ＸＣＡＰサーバＸＳ０に送信されたものとする。この場合、ＸＣＡＰサーバＸＳ０が、図３と同様に、Ｓ４０５にて、マルチホップ処理要求をＸＣＡＰサーバＸＳ１に中継すると、ＸＣＡＰサーバＸＳ１は、データＡがロック中となっているので、このマルチホップ処理要求の中継処理をデータＡの排他制御（悲観的ロック）が解除されるまで一時中断する。
【００５９】
そののち、Ｓ４０６にて、先に送信したマルチホップ処理要求Ｓ４０３に対する２００ＯＫレスポンスがＸＣＡＰサーバＸＳ２から返送されると、ＸＣＡＰサーバＸＳ１はデータＡの値を「Ａ０」→「Ａ１」へと更新したのちに、データＡの排他制御（悲観的ロック）を解除する。これにより、ＸＣＡＰサーバＸＳ１は、中断していたＸＣＡＰクライアントＸＣ２からのマルチホップ処理要求の中継処理を再開し、再びデータＡに排他制御をかけたのち（図示せず）、Ｓ４０７にて、更新後のデータＡの値「Ａ１」を含んだマルチホップ処理要求をＸＣＡＰサーバＸＳ２に送信する。
【００６０】
このように、同一のデータを含んだ複数データの一括更新要求が、同時に複数のＸＣＡＰクライアントから発行された場合には、所定のデータアクセス順序決定規則によって決められた順に各データに排他制御（悲観的ロック）がかけられていき、複数データの一括更新を行うトランザクション処理の結果が返送された時点でロックが順次解除されることになる。したがって、複数データの一括更新要求が複数のＸＣＡＰクライアントから同時に発行される場合であっても、デッドロックの発生を回避しつつデータ間の整合性を保つことができる。
【００６１】
図５は、トランザクション処理部ＸＴにおいて実行されるトランザクション処理が失敗したときのシーケンス図である。
【００６２】
トランザクション処理部ＸＴにおいて、何らかの理由によってトランザクション処理プログラムが複数データの一括更新に失敗したものとする。このとき、トランザクション処理部ＸＴは、ＸＣＡＰサーバＸＳ２から送信されたコールバック処理要求に対してエラーレスポンスを返送する（Ｓ５０１）。図５の例では、リソース競合を示す４０９Ｃｏｎｆｌｉｃｔレスポンスが返送され、「X-Callback-Return」パラメータには、発生したエラーの詳細を示す情報（例えば「Error Code XXXX」）が記述されている。
【００６３】
このエラーレスポンス（Ｓ５０１）を受信したＸＣＡＰサーバＸＳ２のマルチホップ処理要求中継部１４は、トランザクション処理が失敗したことをデータ管理部１５に伝達し、データ管理部１５は、データＢの値の更新を行うことなくその排他制御（悲観的ロック）を解除する。そして、マルチホップ処理要求中継部１４は、Ｓ５０１と同様なエラーレスポンスをＸＣＡＰサーバＸＳ１に返送する（Ｓ５０２）。
【００６４】
このエラーレスポンス（Ｓ５０２）を受信したＸＣＡＰサーバＸＳ１のマルチホップ処理要求中継部１４は、トランザクション処理が失敗したことをデータ管理部１５に伝達し、データ管理部１５は、データＡの値の更新を行うことなくその排他制御（悲観的ロック）を解除する。そして、マルチホップ処理要求中継部１４は、Ｓ５０２と同様なエラーレスポンスをＸＣＡＰサーバＸＳ０に返送する（Ｓ５０３）。
【００６５】
このエラーレスポンス（Ｓ５０３）を受信したＸＣＡＰサーバＸＳ０のマルチホップ処理要求中継部１４は、Ｓ５０３と同様なエラーレスポンスをＸＣＡＰクライアントＸＣに返送する（Ｓ５０４）。このエラーレスポンス（Ｓ５０４）を受信したＸＣＡＰクライアントＸＣは、図３のＳ３０１にて先に送信したマルチホップ処理要求が失敗したことを認識し、「X-Callback-Return」パラメータの情報から、発生したエラーの詳細を把握することができる。
【００６６】
このように、本マルチホップ方式によれば、トランザクション処理が失敗した場合には、データの更新が行われないので、従来のコールバック方式では必要であったロールバック処理を不要とすることができる。
【００６７】
以上説明したように、本実施形態によれば、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムにおいて、複数のクライアントから同時に複数データの一括更新が要求される場合にも、データの不整合を発生させないデータ管理方法及びデータ管理システムを提供することができる。
【００６８】
また、本発明によれば、複数サーバにおいてデータを分散管理するようなデータ管理システムにおいても、特定サーバに処理を集中させることなくデータの整合性を保つことができるので、システムのスケーラビリティを阻害しない（分散システムを構成するサーバの台数や管理するデータ数が増えても処理が分散される）。
【００６９】
以上にて本発明を実施するための形態の説明を終えるが、本発明の実施の態様はこれに限られるものではなく、本発明の趣旨を逸脱しない範囲内で各種の変更が可能である。
【符号の説明】
【００７０】
１０  処理部
１１  マルチホップ処理要求受付応答部（要求受付応答部）
１２  マルチホップ処理条件判定部
１３  データアクセス順序決定部
１４  マルチホップ処理要求中継部
１５  データ管理部
２０  記憶部
２１  共有データ
３０  通信インタフェース部
ＸＣ，ＸＣ１，ＸＣ２  ＸＣＡＰクライアント（クライアント）
ＸＳ，ＸＳ０，ＸＳ１，ＸＳ２  ＸＣＡＰサーバ（データ管理サーバ）
ＸＴ，ＸＴ１，ＸＴ２  トランザクション処理部（トランザクション処理手段）
【図１】
2014056451.tif 000003
【図２】
2014056451.tif 000004
【図３】
2014056451.tif 000005
【図４】
2014056451.tif 000006
【図５】
2014056451.tif 000007
【図６】
2014056451.tif 000008
【図７】
2014056451.tif 000009
【図８】
2014056451.tif 000010