JP5241722B2 - 要求処理のデータ処理システムおよび方法 - Google Patents

Description

本発明は、データベース・システムおよびメッセージング・システムなどの分散データ処理環境での応用を有する。本発明は、複数のリクエスタからの要求に応答して高可用性データ・ストアを更新するデータ処理システムでの特定の応用を有する。

ますます、コンピュータ・ハードウェアおよびコンピュータ・ソフトウェアを使用して実施される発注システムなどのビジネス・アプリケーションが、高可用性および高信頼性を有することを要求される。多くの会社は、彼らのデータ処理システムが毎日２４時間動作し、絶対にデータを失わないことを求め、最高の情報テクノロジ会社は、これらの需要に応えてきた（いくつかの場合に、９９．９９％を超えるデータ処理システムの信頼性を達成する）。会社は、通常、高性能（信頼性の低下を伴わない高スループット）をも求め、これは、データ処理要件が高まる際のスケーラブルな解決策を必要とするが、会社は、高コストを望まない。

高可用性データ処理システムは、単一故障点を避けるために冗長性（ストレージ、プロセッサ、およびネットワーク接続の）および回復特徴（バックアップおよびフェールオーバ）の組合せを使用して開発されてきた。１つのそのような解決策は、単一システム・イメージとして一緒に働く高信頼性ＩＢＭメインフレーム・コンピュータのクラスタなど、冗長ストレージ配置を使用するサーバの密に一体化されたクラスタにまたがって分散された高可用性データベース（ＨＡＤＢ）を含む。高性能および高可用性を達成するためにデータ共用を並列処理と組み合わせるプロセッサのクラスタは、時々、並列システム・コンプレックスまたは「並列シスプレックス」と呼ばれる。並列シスプレックス内で実施される通常のＨＡＤＢは、多数の分散リクエスタからのデータ取出しおよびデータ更新に関する複数の並列要求を高性能および高信頼性を伴って処理することができる。

ＨＡＤＢシステムは、メッセージ・キューをビジネス・ロジックおよびルーティング機能と組み合わせてデータ・アクセスを管理する、堅牢な高可用性メッセージ処理システムを含むことができる。これは、保証された１回のみのメッセージ送達を提供することができ、そのようなシステムは、減らされた遅延を伴って障害を効率的に処理することができる。しかし、通常そのような高可用性システム内で実施されるトランザクション管理、冗長性管理、および回復特徴は、通常の要求処理中にかなりの処理オーバーヘッドをこうむる。そのような処理のいずれもが、潜在的なビジネス・コストを有する。というのは、高可用性データ処理システムが、より信頼性の低いシステムより高価であるからである。この追加処理の例が、ＨＡＤＢシステム内の２フェーズ・コミット処理すなわち、より具体的には、ＨＡＤＢシステム内のリソースとそのシステムの外部のリソースとの間の２フェーズ・コミット処理の要件である。また、ＨＡＤＢシステム内でのメッセージ・キューの実施は、通常、ＨＡＤＢ内でのメッセージ・データのログ記録を必要とする。

代替の解決策は、各サーバが包括的な高可用性特徴を実施しない従来のアプリケーション・サーバ・クラスタ内など、ＨＡＤＢシステムとは別々の並列メッセージ・ディスパッチャのクラスタを使用することである。並列処理は、単一メッセージ・ディスパッチャと比較して、スループットを改善し、障害の影響を減らすことができ、ＨＡＤＢシステムからのメッセージ・ディスパッチャ機能の分離は、処理オーバーヘッドを減らすことができる。しかし、メッセージ・ディスパッチャが、高可用性特徴なしでサーバ上で動作する場合には、１つのサーバに影響する障害が、そのサーバに送られたメッセージの処理を遅延させる。これは、その間に他のメッセージが他のメッセージ・ディスパッチャによって成功裏に処理される可能性にもかかわらず、問題になり得る。障害を発生したメッセージ・ディスパッチャに送られたメッセージ（本明細書では、「孤立メッセージ（orphan message）」または「孤立要求（orphan request）」と称する）は、通常、そのメッセージ・ディスパッチャがオンラインに戻るまで遅延される。孤立メッセージとは矛盾した状態を作ってしまうメッセージのことである。

一部の既知のクラスタ化されたメッセージング・システムは、孤立メッセージの処理における遅延を減らすためにノード障害に続く高速回復のための複数の特徴を実施するが、そのような手法は、まだ、孤立メッセージの遅延される処理という問題を完全には解決していない。

本発明は、複数のリクエスタからの要求に応答して高可用性データ・ストアを更新するデータ処理システム内での処理オーバーヘッドを低減させることである。

本発明の第１の態様は、データ・ストアと少なくとも１つのサービス・リクエスタとを含むデータ処理環境内で使用される、サービス要求を管理する方法であって、
リクエスタのサービス要求を複数の要求処理コンポーネントのうちの少なくとも２つに複製するステップであって、複数の要求処理コンポーネントのそれぞれが、通信経路内でリクエスタとデータ・ストアとの間に配置される、ステップと、
サービス要求に関する責任を成功裏に主張しなかったすべての要求処理コンポーネントによるサービス要求の処理を阻止するステップと、
第１要求処理コンポーネントがサービス要求に関する責任を主張するステップと、
第１要求処理コンポーネントがデータ・ストア内のデータにアクセスすることを含めて主張されたサービス要求の第１要求処理コンポーネントの複製を処理するステップと
を含む方法を提供する。

一実施形態で、責任を主張するステップは、サービス要求の識別子をデータ・ストア内のリポジトリに入力することを含み、この方法は、複数の要求処理コンポーネントのいずれもがサービス要求の重複する識別子をリポジトリに入力するのを阻止することをさらに含む。

一実施形態で、サービス要求の処理を阻止するステップは、要求処理ロジックの実行を阻止することを含む。代替実施形態で、サービス要求の処理を阻止するステップは、データ・ストア内のデータの更新を阻止することを含む（すなわち、あるビジネス・ロジックの実行およびおそらくはデータ・ストアからのデータの読み取りを含む、要求の処理の一部を可能とすることができるが、データ更新の書き込みは防がれる）。

本発明の一実施形態で、データ処理環境は、複数の分散サービス・リクエスタを含み、データ・ストアは、高可用性データ処理システムで動作するデータベースを含む。

一実施形態で、要求処理コンポーネントは、どのデータ・アクセス動作がデータ・ストア内で要求されるかを判定するために、受け取られた要求を処理するビジネス・ロジックと、その要求の複製のサービス・リクエスタからデータ・ストアへの非同期送達を処理する要求ディスパッチャ機能とを含む。

本発明の第２の態様は、
データ・ストアと、
複数の要求処理コンポーネントであって、複数の要求処理コンポーネントのそれぞれが、通信経路内で少なくとも１つのサービス・リクエスタとデータ・ストアとの間に配置される、複数の要求処理コンポーネントと、
サービス・リクエスタのサービス要求を複数の要求処理コンポーネントのうちの少なくとも２つに複製するレプリケータと、
サービス要求の責任を成功裏に主張しなかったすべての要求処理コンポーネントがサービス要求を処理するのを阻止する機能と、第１要求処理コンポーネントのためにサービス要求の責任を主張し、これによって第１処理コンポーネントがサービス要求の複製を処理することを可能にする機能とを含む主張マネージャと
を含むデータ処理システムを提供する。

責任を主張する機能は、データ・ストア内のリポジトリ内にサービス要求の識別子を入力することを含むことができ、主張マネージャは、複数の要求処理コンポーネントのいずれもが重複するサービス要求識別子をリポジトリに入力するのを阻止する機能をさらに含むことができる。

本発明の一実施形態は、複数の要求処理コンポーネント（要求ディスパッチャおよび関連するビジネス・ロジック）を提供することと、要求を２つ以上の要求処理コンポーネントに複製することと、その後、特定の要求の１つの複製だけが高可用性データ・ストアを更新できることを保証するために高可用性システム内での要求の処理を管理することとによって、既存の高可用性サーバ環境の１つまたは複数の問題を軽減する。

互いに並列に働く複数の要求処理コンポーネントを提供することと、並列要求処理コンポーネントにまたがって各要求を複製することとによって、遅延された孤立要求の問題を減らすことが可能である。ある複製要求が、大幅に遅延される場合に、別の複製要求が成功しなければならない。これらの要求処理コンポーネントを高可用性システムの外部で実施することによって、高可用性システムに高い処理オーバーヘッドを課すことなく孤立要求の問題のこの軽減を実施することが可能になるが、高可用性システム内の１回のみのデータ更新の管理がデータ保全性を維持する。本発明の一実施形態では、要求メッセージが、エンキューされ、メッセージのビジネス・ロジック処理は、高可用性システムの外部で実行されるが、結果のＨＡＤＢ更新およびキューからの要求メッセージの最終的除去は、高可用性システムによってトランザクショナル・スコープの下で処理される。本発明の特定の実施形態は、ＨＡＤＢシステム内で１回のみの更新を管理する効率的な機構を提供する。

本発明は、どのメッセージもが並列に配置されたコンポーネントのセットのうちの１つだけに割り当てられる従来の並列処理とは異なる。というのは、本発明では、要求またはメッセージが、並列要求処理コンポーネントのセットのうちの複数にまたがって複製されるからである。

本発明のもう１つの態様は、メッセージをキューに挿入する動作の信頼性とエンキューされたメッセージの比較的高い可用性とを達成するのに複製を使用するが、単一の高可用性データベース（ＨＡＤＢ）システムと通信し、ＨＡＤＢの保証された１回のみの更新のためにトランザクション処理およびロック機構を使用する、メッセージ・キューイング・システムを提供する。メッセージの処理（およびＨＡＤＢのすべての必要な更新）の後のキューからのメッセージの最終的な除去の動作は、ＨＡＤＢシステム内で保持されるデータによって制御される。

伝統的なキューイング・システムでは、キューにメッセージを挿入するアクション（たとえば、PUT_messageコマンドに応答する）、キュー上のメッセージのストレージ、およびメッセージを取り出すアクション（たとえば、GET_messageコマンドに応答する）のすべてが、同一のシステム内で実施され、したがって、同一の信頼性機構を使用する。本発明によるメッセージ・キューイング・システムは、キューの端でのデータ保全性および可用性を保証するためにキューの他端で単一高可用性システムの機能を利用しながらキューの一端で複製を使用することによって（安価なコンポーネントの使用にかかわらず信頼性を達成することを可能にする）、そのような伝統的システムから区別される。これは、メッセージを挿入している可能性があるアプリケーション・プログラムが、安価で比較的信頼性のないコンポーネントに頼る環境で既に動作しているが、メッセージが高可用性システム内のリソースを更新することを意図されている時に、かなりの利益を有する。

一実施形態で、各要求のＨＡＤＢ更新の１回のみの処理は、ＨＡＤＢのリポジトリ内に、ＨＡＤＢ内で処理される要求の要求識別子を保存することと、複製された要求がＨＡＤＢを更新できる前に要求識別子のリポジトリをチェックすることとによって達成される。要求識別子のリポジトリ内のエントリは、要求が処理されつつある間にロックすることができ（通常のＨＡＤＢロック機能を使用して）、この処理のコミットは、高可用性システム内で管理される。要求識別子の後続認識は、その要求のすべての複製の削除を保証する。要求識別子のリポジトリエントリ内のエントリのロックおよび重複エントリの回避は、同一要求の複数の複製がＨＡＤＢを複数回更新できないことを保証する。

本発明の一実施形態では、要求識別子のリポジトリは、テーブルの１行が１つの要求に対応するデータベース・テーブルである。このテーブルを、以下では「主張テーブル」と称する。第１要求処理コンポーネントが、要求識別子を主張テーブルに挿入し、主張テーブル行に対するロックを入手し、ＨＡＤＢのうちで関連するデータ・アイテムを保持している部分に対するもう１つのロックを入手する。ロックは、従来のＨＡＤＢ機構によって実施され、特定の要求の処理が完了するまで維持され、この時に、この要求によって要求されるすべてのＨＡＤＢ更新がコミットされ、この要求のすべての複製が削除される。

本発明の一実施形態は、要求識別子を主張テーブル内に挿入することの１つまたは複数の失敗した試みを単一のＨＡＤＢトランザクションが包含できるようにすること、ならびに要求識別子の最終的な成功の挿入とメッセージ・ディスパッチャおよびビジネス・ロジックによる対応する要求処理（「書き込み」要求の場合のＨＡＤＢ更新を含む）を包含することによって、ＨＡＤＢトランザクションを浪費せずにメッセージの１回のみの処理を実施する。

本発明のもう１つの実施形態は、上で説明した方法を実行するためにデータ処理装置を制御する命令のセットを含むコンピュータ・プログラムを提供する。このコンピュータ・プログラムは、記録媒体に記録されたプログラム・コードを含むコンピュータ・プログラム製品として使用可能にすることができ、あるいは、インターネットを介するダウンロードのためなど、データ転送媒体を介する転送のために使用可能にすることができる。

本発明の実施形態を、添付図面を参照して、例として下でより詳細に説明する。

本発明は、データ・ストアにアクセスできることと、最小限の遅延および障害からの最小限の影響を伴ってデータ・ストアに更新を適用できることとが必要である、高可用性データ処理環境に関する特定の利益を有する。

当技術分野で既知の通り、高可用性は、さまざまな形で達成することができる。第１の既知の解決策は、多数の冗長コンポーネントと、これらの冗長コンポーネントの間でフェールオーバを配置構成するための特殊化された追加コンポーネントとを含む複雑なハードウェアを使用する。これらの冗長コンポーネントには、プロセッサ、メモリ、コントローラ、ハード・ドライブ、および通信バスを含めることができる。そのような複雑なハードウェアは、適当なコンピュータ・ソフトウェアによって補足することができる。そのような高可用性システムの例が、ＩＢＭ社のＤＢ２データベース・システム・ソフトウェアおよびＩＢＭ社のｚ／ＯＳオペレーティング・システムを動作させるＩＢＭ ｚＳｅｒｉｅｓデータ処理システムである。ＩＢＭ、ｚＳｅｒｉｅｓ、ｚ／ＯＳ、およびＤＢ２は、International Business Machines Corporation社の商標である。

第２の既知の解決策は、それぞれが障害を受けやすいが比較的安価な多数の単純なシステムに、それらの間で作業を共用し、障害を発生したシステムを回避する比較的単純なソフトウェア機構を提供する。そのようなシステム上で動作するソフトウェアの各インスタンスは、通常、高可用性システム内より回復力が低く、任意の一時に動作している十分なシステムが必ずあることを保証するために多重度に頼る。この第２の解決策は、一般に、大量処理およびステートレス・ロジックに使用されるが、複数のコピーがある時にどれがデータの最終的インスタンスであるかを判断するという問題のゆえに、ステートフル情報に使用するのはよりむずかしい。

上で説明した第１の既知の解決策をもう一度参照すると、図１は、高可用性データ・ストア（ＨＡＤＢ）１０が、キュー８０、ビジネス・ロジック３０の実行から生じるデータ・アクセス動作をディスパッチするのに使用されるメッセージ・ディスパッチャ２０を含むメッセージング・システムに関連する、分散データ処理システムの概略表現である。ビジネス・ロジック３０は、ＨＡＤＢに対するどの更新が必要であるかを判定し、次に、ＨＡＤＢと協力してその更新を管理し、その更新をキューからのメッセージの除去と調整する責任を負う。たとえば、ＨＡＤＢ １０は、図１では、それぞれがそれ自体のデータ処理能力およびデータ・ストレージ能力を有する３つ以上のサーバ１２、１４、および１６にまたがって分散されて図示されている。複数のリクエスタ４０、５０、および６０が、メッセージ・ディスパッチャ２０を介してデータ・アクセスに関する要求をサブミットする。

システム全体として高可用性を達成するために、メッセージ・ディスパッチャ２０およびそのビジネス・ロジック３０を、ＨＡＤＢを保持する高可用性サーバ内に一体化することができる。上で注記したように、ＨＡＤＢは、IBM Corporation社のＤＢ２データベースとすることができ、サーバは、ｚ／ＯＳオペレーティング・システムを動作させるＩＢＭ ｚＳｅｒｉｅｓコンピュータ・システムとすることができ、ＩＢＭ ｚＳｅｒｉｅｓコンピュータ・システムは、最大の信頼性および可用性を提供するために冗長プロセッサ、ストレージ回復特徴およびフェールオーバ回復特徴を含む。この信頼性および可用性は、望ましく、いくつかの応用例に関してクリティカルな要件であるが、メッセージ・ディスパッチャおよびビジネス・ロジックは、それでも、望ましくない処理オーバーヘッドを高可用性サーバに課す。たとえば、ＨＡＤＢへの１回のみの更新の保証は、通常、ＨＡＤＢ更新と対応する要求メッセージの最終的な削除との間の障害に対する保護のために２フェーズ・コミット処理を伴う。具体的に言うと、リクエスタ４０、５０、および６０によるキューへのメッセージの挿入が、メッセージ・ストアとリクエスタによって使用される他のリソースとの間の調整を必要とする場合がある。この調整は、高可用性メッセージ・ストアに関するかなりのオーバーヘッドを課す。本発明は、この問題を軽減する。

代替案では、メッセージ・ディスパッチャおよびビジネス・ロジック機能を、高可用性特徴を有さないハードウェア上で動作する標準アプリケーション・サーバ内で実施することができる。そのようなアプリケーション・サーバは、当技術分野で周知であり、IBM Corporation社のWebSphere Application Serverなどの製品を、高可用性に関する包括的サポートを提供しない比較的安価なコンピュータ・システム上で動作させることができる。WebSphereは、InternationalBusiness Machines Corporation社の商標である。

上で説明した異なる処理スタイルを混合し、一部のデータ処理システムを低コストの重複するハードウェアで実行するが長期データ・ストレージに関して堅牢な高可用性データベース（ＨＡＤＢ）にアクセスすることも既知である。ビジネス・ロジックおよびメッセージ・ディスパッチャ機能をＨＡＤＢシステムから分離する手法は、少なくとも通常の順方向処理中に、ＨＡＤＢを動作させている高可用性サーバに対するより少ない影響を有する。しかし、ビジネス・ロジックおよびメッセージ・ディスパッチャを標準アプリケーション・サーバおよび低コスト・ハードウェアで動作させることは、「孤立要求」に関する遅延のリスクを高める。すなわち、障害を発生したアプリケーション・サーバに送られる要求は、そのアプリケーション・サーバがオンラインに戻るまで遅延される。

本発明は、この問題を軽減する。下で詳細に説明する第１の実施形態では、複数の分散サービス・リクエスタが、サービス要求を要求処理システムに入力することができる。要求処理システムは、高可用性データ・ストアと通信する複数の安価な要求処理コンポーネントを含む。サービス要求は、複数の要求処理コンポーネントのうちの少なくとも２つに複製される。サービス要求に関する責任を成功裏に主張しなかったすべての要求処理コンポーネントは、データ・ストアに対する更新の重複を避けるために、そのサービス要求を処理するのを阻止される。第１の要求処理コンポーネントが、サービス要求に関する責任を主張し、その後、データ・ストア内のデータへのアクセスを含めて、主張されたサービス要求の複製を処理する。複数の要求処理コンポーネントのすべてが、サービス要求の責任に対する重複主張に入ることを阻止され、このサービス要求に関する責任の保証された１回のみの主張は、データ・ストアに対する更新の重複を阻止する。

図２に、本発明の実施形態による分散データ処理システムを示す。図１と同様に、複数の分散並列リクエスタであるリクエスタ４０、５０、および６０が、サービスを要求しており、サービスのビジネス・ロジックは、ＨＡＤＢからのデータ・アクセスを必要とする。しかし、図２の解決策では、要求は、並列に配置された複数のメッセージ・ディスパッチャ２０、２２、２４、および２６に関連する複数の関連するキュー８０、８２、８４、および８６のうちの２つ以上にまたがって複製される。図１のリクエスタは、メッセージを単一のメッセージ・ディスパッチャ２０の入力キューに置くが、図２では、メッセージは、レプリケータ７０を介する分配のためにエンキューされる。レプリケータ７０は、Ｎ個の並列メッセージ・ディスパッチャのセットの選択されたサブセットｋにメッセージを複製するという限定された役割を満足し、ここで、１＜ｋ＝Ｎである。特定の実施態様では、ｋが２であり、もう１つの実施態様では、ｋが３である。

図２に示されているように、レプリケータ７０は、すべての要求がリクエスタ４０、５０、および６０によって送られる、受け取るコンポーネントとすることができる。もう１つの実施形態（後で図３を参照して説明する）では、レプリケータ機能を、リクエスタのシステムで、またはネットワーク内の他所の中間プロキシ・サーバで実施することができる。

図２の実施形態によれば、レプリケータ７０による要求の分配は、各メッセージを少なくとも２つのメッセージ・キュー（８０、８４）に置くｋウェイ・ファン・アウト分配であるが、例外に関しては下の説明を参照されたい。図示の実施形態では、各メッセージ・ディスパッチャが単一のキューに関連付けられ、たとえば、メッセージ・ディスパッチャ２０は、キュー８０に関連付けられる。代替実施形態は、キューとメッセージ・ディスパッチャとの間のより複雑な関連付けを可能にする。レプリケータによる特定のｋ個のキューの選択は、セットＮ内からのラウンドロビン割振りほどの単純なものとすることができるが、作業負荷平衡化技法を使用する他の選択を実施することができる。

本発明の一実施形態で、数ｋ（ならびに特定のｋ個のキューのどれを選択するか）は、メッセージごとの基礎で決定され、比較的高価値の緊急のメッセージについては大きい値のｋを、低価値のメッセージについては小さい値のｋを選択する。特定の実施形態は、メッセージの複製に対する例外を提供し、識別可能に低価値のまたは非緊急のメッセージについて単一のメッセージ・ディスパッチャ（ｋ＝１）の選択を可能にする。したがって、これらのメッセージは、従来技術と同様に処理され、本発明からは利益を得ないが、他のメッセージへの本発明の適用を妨げない。

短く図３を参照すると、これは、分散複製機能の異なる実施態様によって図２とは異なる。各リクエスタは、めいめいのレプリケータ７０、７１、および７２のサービスを利用し、レプリケータ７０、７１、および７２は、個々のリクエスタ４０、５０、および６０にローカルとし、そのリクエスタ４０、５０、および６０専用とすることができ、あるいは、分散ネットワーク内のある中間位置に配置することができる。レプリケータごとに、複製要求を送るべきキューの個数ｋおよびｋ個のキューの特定のセットの選択は、動的に決定することができ、あるいは、図３によって暗示されるように事前定義とすることができる。

図２と図３との両方の実施形態では、メッセージ・ディスパッチャ（２０、２２、２４、２６）のそれぞれが、要求ディスパッチャ機能と、ＨＡＤＢ １０に更新を適用できるビジネス・ロジック（３０、３２、３４、３６）とを実施する。第１の実施形態では、ＨＡＤＢは、メッセージ・ディスパッチャによって、単一のシステムとみなされ、効率または可用性に関するすべてのＨＡＤＢ内部セグメンテーションは、リクエスタおよびメッセージ・ディスパッチャに不可視である。そのようなシステムでは、メッセージ・ディスパッチャは、その入力キューからメッセージを取り出し、ビジネス・ロジックを呼び出し、主張テーブル内のエントリの挿入を要求する責任を負うが、ＨＡＤＢ内のルーティングは、メッセージ・ディスパッチャの責任ではない。上で注記し、下でより詳細に説明するように、「主張テーブル」は、要求処理コンポーネントが処理する責任があると主張したサービス要求を識別するサービス要求識別子のリポジトリである。ＨＡＤＢ構造が外部リクエスタから不可視である解決策、およびＨＡＤＢ内部特徴が要求されたＨＡＤＢセグメントを識別する責任を負う解決策は、当技術分野で周知である。ビジネス・ロジックは、通常、アプリケーション固有であり、たとえば、商品またはサービスの注文を処理し、その注文を反映するためにＨＡＤＢに適用すべき特定の更新命令を生成する。複数のディスパッチャへのメッセージの複製のゆえに、メッセージ・ディスパッチャ（２０、２２、２４、２６）およびその入力キュー（８０、８２、８４、８６）は、下で説明するように、高可用性特徴を実施するのに必要ではない。

ＨＡＤＢ １０は、ＨＡＤＢビジネス・データ９０に加えて、主張テーブル１００を含む。主張テーブル１００は、要求識別子（メッセージ識別子または別の要求識別子など）を含む単一のキー列を有するデータベース・テーブルである。メッセージ・ディスパッチャのうちの１つだけが、任意の特定の要求識別子について主張テーブルにエントリを挿入することを許可される。主張マネージャ１１０は、主張テーブル１００に関連し、主張テーブルを更新できる前にそのテーブルを検査する責任を負う。本発明の現在の実施形態では、レプリケータ７０、メッセージ・ディスパッチャ２０、ビジネス・ロジック３０、および主張マネージャ１１０の機能が、ソフトウェアで実施されるが、これらの論理動作を、電子回路を使用するなど、ハードウェアで実施することができる。

主張テーブルには、サービス要求に対する責任を成功裏に主張した時刻および主張者のアイデンティティなどの追加情報をも含めることができる。これは、本発明の動作に必須ではないが、システム挙動に関する貴重な診断情報および統計情報を提供することができる。

実際には、主張マネージャの動作は、メッセージ・ディスパッチャの分散プロセッサ内で実行される主張マネージャ固有コードと、ＨＡＤＢ内で動作する包括的データベース・ロック・コードとの間で区分される可能性が高い。これを、後でより詳細に示す。

一実施形態で、メッセージ・ディスパッチャ機能およびビジネス・ロジックは、Ｊ２ＥＥアプリケーションがJava (R) Messaging Service（ＪＭＳ）メッセージを非同期に処理することを可能にする、ＪＭＳを実施するEnterpriseJava (R) Beans（ＥＪＢ）であるMessage-Driven Beans内で実施される。この実施形態では、メッセージ・ディスパッチャを動作させるアプリケーション・サーバは、ＪＭＳメッセージを多数の分散リクエスタ（Ｊ２ＥＥアプリケーション・クライアントまたは他のＪＭＳアプリケーションもしくはＪＭＳシステム）から受け取るＪ２ＥＥアプリケーション・サーバである。単一のMessage-DrivenBeanが、複数のクライアントからのメッセージを処理することができる。主張マネージャ１１０のロジックは、Message-Driven Beansのメソッドを呼び出すＥＪＢコンテナの関数として実施することができる。メッセージが到着する時に、コンテナは、まず、主張マネージャ１１０ロジックを呼び出して、メッセージが、既に処理されているメッセージの複製ではないことを保証する。次に、コンテナは、Message-DrivenBeanのメソッドを呼び出し、このメソッドは、特定のＪＭＳメッセージ・タイプを識別し、アプリケーション固有ビジネス・ロジックに従ってそのメッセージを処理する（標準Ｊ２ＥＥ解決策と同様に）。このアプリケーション固有ビジネス・ロジックは、メッセージ内の情報を処理して、特定のデータベース更新命令を生成し、このデータベース更新命令は、その後、ＨＡＤＢに送られる。Ｊａｖａ（Ｒ）およびＪａｖａ（Ｒ）ベースの商標は、SunMicrosystems, Inc.社の商標である。

代替実施形態では、メッセージのディスパッチが、従来のメッセージング・プログラムがメッセージＧＥＴ動作を実行することによって実施される。この場合に、主張マネージャ１１０は、メッセージング・システムの一部になり、主張テーブル１００は、メッセージ・ストアへのＨＡＤＢ拡張であるが、メッセージ・ストアの残りは、異なるテクノロジを使用して実施することができる。

潜在的に多数のリクエスタ４０、５０、および６０のいずれもが、レプリケータ７０を介して要求メッセージを送ることによってサービスを要求することができる。各メッセージは、使用可能なキュー８０および８４のサブセットｋで複製され、エンキューされる。関連するｋ個のメッセージ・ディスパッチャ（２０、２４）のいずれもが、複製メッセージに関する次の動作を実行することができる。これらの動作を、図４、５、６、７、および８を参照して説明する。メッセージ・ディスパッチャのうちの１つによる要求メッセージの受取時に、ＨＡＤＢトランザクションが開始され２１０、その後、現在のメッセージ・ディスパッチャ２４が、そのキュー８４から第１のメッセージを取り出す２２０。これらのステップを、図６、７、および８に示す。ＨＡＤＢのビジネス・データおよび主張テーブルに対する更新（下で説明する）は、同一のＨＡＤＢトランザクション内で行われて、主張テーブルとビジネス・データとの両方が成功裏に更新され、あるいは、更新が不成功の場合には両方がバック・アウトされることを保証する。

メッセージ・ディスパッチャ２４は、このメッセージに対する主張をＨＡＤＢ １０の主張テーブル１００に挿入することを試み２３０、具体的には、一意の要求識別子を主張テーブル内に新しい行として挿入することを試みる。主張が挿入される前に、要求識別子のスキャンが実行される２４０（主張テーブルの行のすべてのスキャンに対応する論理スキャンであるが、テーブルの完全な物理的スキャンの必要を避けるために主張テーブルのインデックスに対して実行される）。このスキャンは、すべての一致する要求識別子を識別する。図５、６、および８に示されているように、試みられる主張は、別のメッセージ・ディスパッチャが主張テーブル内にこの要求識別子を既に入力していると判定される２５０場合には成功しないが、図４、６、および７に示されているように、主張テーブル内に一致するエントリがない場合には、主張は成功する。主張テーブル１００への主張の成功の入力２６０の時に、ＨＡＤＢは、他のメッセージ・ディスパッチャ２０、２２、２６による変更を阻止するために主張テーブルのこの行をロックする２７０。

取り出されたメッセージのコピーは、メッセージ・ディスパッチャのキュー８４内に残るが、メッセージ状況は、主張テーブルを更新するアクションによって、「受取済み」状況（すなわち、メッセージが、キュー上で使用可能であり、取出しの準備ができている）から「取り出されたが未確定」状況（すなわち、メッセージが処理のためにキューから取り出されたが、メッセージの処理がまだコミットされていない）に暗黙のうちに変更される。

図４、６、および７を参照すると、新しい要求識別子を主張テーブル１００に挿入することを試みる第１のメッセージ・ディスパッチャ２４（ｋ個のディスパッチャのセットからの）が、成功する。主張テーブルは、その要求識別子を含む新しい行１３０を挿入すること２６０によって拡張され、この第１のディスパッチャは、標準ＨＡＤＢロッキング機構を使用して主張テーブルのその行に対するロックを入手する２７０。具体的に言うと、ＨＡＤＢは、主張マネージャ１１０からの要求に応答して主張テーブルに対するロックを実施し、どのメッセージ・ディスパッチャ２４がロックされた行に関連するかのレコードを維持する。行ロックは、第１のメッセージ・ディスパッチャのメッセージが処理されつつある間に（すなわち、下でより詳細に説明するように、ＨＡＤＢトランザクションおよびメッセージ・トランザクションのコミットまたは打切りまで）、他のメッセージ・ディスパッチャ２０、２２、２６による変更を阻止する。

主張テーブルへの新しい入力は、テーブルが現在その特定の要求識別子のエントリを含まない場合に限って、主張マネージャ１１０によって許可され、したがって重複するテーブル入力は可能ではない。主張マネージャ１１０が、一致する要求識別子を有する主張テーブル内のエントリを見つける２４０、２５０場合には、図５、６、および８に示されているように、第１のメッセージ・ディスパッチャ２４によって入手された主張エントリは、変更がすべての他の要求ディスパッチャのために行われるのを阻止する。

第１のメッセージ・ディスパッチャ２４のためにロックされるべき一致する主張テーブルの行１３０が見つかる場合２９０には、異なるメッセージ・ディスパッチャの、主張テーブルに重複エントリを挿入する要求は、メモリ内に保持されて、一致するエントリを保持している主張テーブルの行のアンロックを待つ３００。第１のメッセージ・ディスパッチャの主張テーブルの行１３０は、対応するＨＡＤＢトランザクションおよびメッセージ・トランザクションの結果に応じて、アンロックされる前に削除されるかコミットされる場合があり、したがって、この段階では、主張テーブルを更新する後続の試みが成功するのか失敗するのかを予測することは不可能である。これが、重複する主張要求が再試行を可能にするためにメモリ内に保持される場合がある理由である。

主張テーブルを更新する要求がメモリ内で保持されている間に、メッセージ・ディスパッチャ２０の入力キュー上のメッセージのコピーは、今や、暗黙の状況「取り出されたが未確定」を有する。ＨＡＤＢは、この複製要求のデータ更新の処理を開始してはいないが、同一の要求のもう１つの複製が処理されつつあり、したがって、現在の複製の主張要求は、その処理の結果を待つためにメモリ内で保持される。したがって、それに関してＨＡＤＢ更新が試みられるメッセージのすべての複製が、今や、同一の暗黙の状況「取り出されたが未確定」を有するが、これらは、そのめいめいのメッセージ・ディスパッチャのキュー８０、８２、８４、８６上で未コミットのままになる。メッセージ・ディスパッチャ２０、２２、２４、２６が、明示的な状況情報を書き込む必要は全くない。というのは、暗黙の状況が、主張テーブル１００から簡単に判定されるからである。複製メッセージを取り出し、処理する試みが行われる場合に、状況が簡単に判定され、状況は、そのような取出しおよび更新が試みられるまでは重要ではない。

代替案では、一致する主張テーブル行が、既にコミットされ、アンロックされている場合には、主張テーブルに重複エントリを挿入するすべての後続の試みが、障害を発生しなければならない。この場合に、障害レポートが、主張テーブルへの重複エントリの挿入を試みているメッセージ・ディスパッチャに返され３１０、そのメッセージ・ディスパッチャは、その入力キューから対応するメッセージを削除する３２０。

テーブル全体または関連する主張テーブル・エントリを含むページに対する、より粒度の大きいロックではなく、行固有ロックが、主張テーブルに対して入手される。というのは、要求の複製が、主張テーブルを更新しようとする頻繁な衝突する試みがある可能性を高くするからである。より粒度の小さい行ロックは、より粒度の大きいページ・ロックと比較して、延期されなければならない要求の個数を減らし、ページ・ロックが実施される場合に発生するはずの異なるメッセージの間の衝突を回避する。主張テーブル・レベルでの頻繁な衝突の可能性にもかかわらず、主張要求の処理は、高可用性システム内でほとんど処理を必要とせず、具体的には、メッセージ・ディスパッチャ機能およびビジネス・ロジックのすべてが高可用性システム内で実施される場合より少ない性能コストを伴うものとすることができる。

また、本発明の一実施形態は、レプリケータ７０によって生成される複製のタイミングにわずかな「よろめき」を導入することによって、同一メッセージの複数の複製の間の衝突を減らす。通常、すべてのメッセージ・ディスパッチャが、同一のレートで動作している場合に、最初に解放される複製は、第２の複製をスケジューリングする試みが行われる前に完全に処理される。第１のディスパッチャが一時的に動作不能である場合には、第２の複製は、それでも、タイムリーな形で処理される。両方の複製を処理する同時の試みがある場合があるが、そのような場合の回数は、減らされる。

上で注記したように、衝突する更新の阻止は、ＨＡＤＢが、一致する主張テーブル・エントリを識別すること２４０、２５０に応答して、主張テーブルを更新する新しい要求を一時的に格納することを伴う場合がある（すなわち、主張要求が、メモリ内のキューに保持される場合がある）。主張要求は、現在処理されつつあるサービス要求の結果（または、タイムアウトが先に発生する場合にはタイムアウト３３０）を待ち３００、その後に限って、新しい主張要求を受け入れるのか拒否するのかを判断する。メモリ内に保持される主張要求は、「アンロック済み」信号が主張マネージャから受け取られるまで、またはタイムアウトまで（いずれであれ先に発生した方）残る。タイムアウトには、たとえば事前定義の遅延期間の後に、タイムアウトしたメッセージ・ディスパッチャのために主張テーブルを更新する試みの繰返しを続けることができる。「アンロック済み」信号は、主張要求に関するすべての一致する要求識別子を識別する２５０ための主張テーブル１００の繰り返されるスキャン２４０を促す。

主張テーブル更新が成功する２６０時に、ロックが、主張テーブルの関連する行に対して入手され２７０、ロックが、ＨＡＤＢマネージャ１２０がページ・ロックを入手する図４に概略的に示されているように、ＨＡＤＢの関連する部分に対して入手される（たとえば、指定されたサーバ上のデータベース行またはページ１４０をロックする）。両方のロックが、ＨＡＤＢ内で使用可能な標準機構を使用して実施される。主張テーブル１００の成功の更新は、ＨＡＤＢマネージャ１２０がＨＡＤＢ内のＨＡＤＢビジネス・データ９０を更新することの先行条件であり、１つのメッセージ・ディスパッチャ２４だけが、各要求について主張テーブルを更新することができる。ＨＡＤＢビジネス・データ９０の更新は、ＨＡＤＢ内に衝突するロックがない時に限って発生し得る。これは、更新要求のｋウェイ複製にかかわらず、キュー・データのそれぞれにかわからずに、複製された要求ごとのＨＡＤＢビジネス・データの１回のみの更新を保証し、メッセージ・ディスパッチャおよびビジネス・ロジックは、ＨＡＤＢの高可用性システムの外部で実施される。

上で注記したように、ＨＡＤＢの関連部分の識別は、ＨＡＤＢ自体の中でまたはメッセージ・ディスパッチャの機能として（どちらの場合でも、通常のデータ・アクセス機構を使用して）実行することができる。ＨＡＤＢのロックされたページ１４０への書き込みアクセスは、現在、現在のメッセージ・ディスパッチャ２４に関連するビジネス・ロジック３４用に予約される（いくつかの実施態様では、ロックは、排他的読み取りアクセスをも予約する）。メッセージ・ディスパッチャ２４内のビジネス・ロジック３４が実行されて、要求を処理し３５０、ＨＡＤＢに対する必要な更新のすべてを判定する。次に、判定された更新が、ＨＡＤＢビジネス・データ９０に適用される３６０。

たとえば、ビジネス・ロジックは、商品またはサービスに関する注文を指定するメッセージを処理し、注文のデータベースを更新することができる。もう１つの例の要求は、おそらくは製品の準備または配送の進行状況を検査する、既存の注文に関連する状況情報の取出しに関する要求とすることができる。多数の他のビジネス・アプリケーションを、本発明を使用して実施することができる。

要求の処理３５０、３６０が成功の場合に３７０、ＨＡＤＢに対するすべての変更（主張テーブル・エントリ更新およびビジネス・データ更新を含む）がコミットされる３８０。次に、ＨＡＤＢトランザクションのコミットが、メッセージ・ディスパッチャ・システムに確認され、このメッセージ・ディスパッチャ・システムは、次に、処理されたメッセージを削除する３２０。

１つの成功のメッセージ・ディスパッチャによるメッセージ・トランザクションのコミットにもかかわらず、そのメッセージの複製は、ｋ個のメッセージ・ディスパッチャ２０、２２、２６のうちの他の１つのキュー８０、８２、８６上に、ある期間の間残る場合がある。そのメッセージの各残っている複製は、今や、コミット済みという暗黙の状況を有し、単にそのめいめいのキューからの削除を待つ。

要求の成功の処理３５０、３６０に続いて、要求の処理がコミットされた３９０時に、同一要求の別の複製に関する主張テーブル内の主張の挿入のすべての新しい試みが、拒否される。この場合に、要求メッセージの一意の要求識別子と主張テーブル内の要求識別子のセットとの間の比較が、一致を識別し、一致する要求は、今や、アンロックされた主張テーブル・エントリによって反映される、「コミット済み」状況を有する。その状況は、そのメッセージを、今や、重複するエントリを主張テーブルに追加することを不成功に試みているめいめいのメッセージ・ディスパッチャ２０のキュー８０から削除しなければならないことを確認するのに十分である。

メッセージの他の複製をも削除しなければならないが、コミットされた要求メッセージに関する最終的な削除命令は、すべての複製の瞬間的な削除を要求はしない。コミットされたＨＡＤＢ更新は、メッセージ取出しをコミットする（すなわち、すべてのメッセージ・ディスパッチャの入力キューからそのメッセージを削除する）最終的な命令として有効であるが、特定の入力キューの実際の削除は、対応するメッセージ・ディスパッチャが主張テーブルに主張を入力することを試みるまで延期することができる。

上で説明した、第１のメッセージ処理が進行中である（まだコミットされていない）間の、重複する主張要求のメモリへの保存、ならびに第１のメッセージ処理が成功の場合の重複する主張要求の拒否および対応する複製メッセージの削除は、比較的わずかな処理オーバーヘッドを伴い、具体的には、高可用性システムおよびＨＡＤＢでの高価な処理を最小にする。

勝つ複製の成功の処理および削除は、ＨＡＤＢとメッセージ・ストアとの間の高価な２フェーズ・コミット動作を伴わない。メッセージ・ディスパッチャが、勝つ複製メッセージのコミット動作３８０とメッセージ削除動作３２０との間に障害を発生する場合には、主張機構は、負ける複製の実行を阻止するのと正確に同一の形で、勝つ複製メッセージの再実行を阻止する。単一インスタンス・メッセージの再実行を阻止する機構が、既に当技術分野で既知である（時々、「one-and-a-half phase」コミットと称する）ことを了解されたい。

上で観察したように、本発明が使用されるシステムにおいてさえ、レプリケータ７０が、ある種の低価値メッセージについて本発明を利用しないことを選択する場合がある。これらのメッセージが、複製されないものとしてレプリケータによってタグ付けされ、特殊な形で処理されるかもしれない。他の実施形態では、低価値の非緊急要求メッセージは、one-and-a-half phaseコミットの利益を達成するために、上で説明した主張機構を使用して処理される。

代替実施形態では、主張テーブルのロックされた一致する行の識別が、主張要求の明示的拒絶を伴うめいめいのメッセージ・ディスパッチャへの応答をトリガすることができる（上で説明したメモリへの主張要求の保存ではなく）。これは、データベースが「presumed commit」ロッキング戦略を使用する場合に発生する可能性がある。この明示的拒否は、主張テーブルを更新する試みの後続の再試行まで、複製メッセージをめいめいのメッセージ・ディスパッチャのキューに残すはずであり、これは、主張テーブルのロックされた行を更新する要求が一時的にメモリに保存される実施形態より多くの処理を伴う可能性が高い。

上で説明した実施形態のいずれにおいても、主張テーブルを更新する試みは、要求メッセージの第１の複製の処理がまだ進行中である（すなわち、その処理がまだ完了しておらず、まだ失敗する可能性がある）間は、拒否される可能性がある。したがって、拒否される主張要求に対応する要求メッセージを保持するメッセージ・ディスパッチャは、そのメッセージ・ディスパッチャがその要求を削除する暗黙の命令（すなわち、一致する主張テーブル・エントリがアンロックされていることの判定に応答する主張テーブル更新障害レポート（これが、メッセージ処理が成功裏に完了し、コミットされたことを暗示するので））を受け取らない限り、その後に主張テーブルの更新を再試行することができる。そのような後続の再試行は、事前定義の遅延期間の後に実行することができ、あるいは、再試行の頻度を、現在のシステム・アクティビティに依存するものとすることができる。

メッセージ処理中に障害を経験する場合には、ＨＡＤＢトランザクションを打ち切らなければならない４００、４１０。この状況では、主張テーブル・エントリが削除され、主張テーブル行がアンロックされる４１０。障害の性質に応じて、メッセージ・ディスパッチャは、［ａ］後に再び試みられる処理のために複製メッセージを入力キューに残すこと、［ｂ］複製メッセージを送達不能キューに移動すること、または［ｃ］複製メッセージを削除し、オリジナル・リクエスタに障害通知を送ることを含むさまざまな処置を講じることができる。その代わりに、障害を発生するのがメッセージ・ディスパッチャ自体である場合があり、その場合には、システムは、ＨＡＤＢトランザクションを暗黙のうちに打ち切り（未確定の主張テーブル・エントリを除去することを含む）、複製メッセージは、後続再試行のために入力キューに残る。障害処理のこれらの例は、当技術分野で既知である。

特定の最適化が、本発明の一実施形態で、ＨＡＤＢ処理オーバーヘッドを減らすために実施される。新しいＨＡＤＢトランザクションが開始されたが、特定の要求の複製が既に処理されているので主張テーブル更新が不成功であった場合に、新しいＨＡＤＢトランザクションは、終了されない。そうではなく、次の要求メッセージが、第１のＨＡＤＢトランザクション内で特定のメッセージ・ディスパッチャの入力キューから取り出される。これを、図８に示す。次に、メッセージ・ディスパッチャは、この、次の要求メッセージの主張テーブル・エントリの追加（テーブルへの要求識別子の入力）を試み、前に説明した理由のうちの１つのゆえに成功するか失敗するかのいずれかになる。この形で、ＨＡＤＢの１回のみの更新の達成に用いられるトランザクション処理機構が、処理オーバーヘッドを減らすために最適化される（主張テーブルにエントリを追加する試みごとにトランザクションを開始し、終了することを要求される解決策と比較して）。

図９の表１は、ＨＡＤＢ内のデータへのアクセスを要求するサービスに関する要求の処理に対する複数の代替手法の処理オーバーヘッドの一部（トランザクションの個数およびどのリソースが用いられるか）を表す。高可用性システム内で完全に実施される解決策は、キュー、ビジネス・ロジック、およびＨＡＤＢと共に、すべてが同一システム内で実施され、高可用性システム内の２つのトランザクションを用いる。メッセージ挿入トランザクションは、メッセージのデータのログ記録を含み、もう１つの高可用性システム・リソースと調整することができる。これらのトランザクションの両方が、高可用性システム・リソースに関するかなりのオーバーヘッドを伴う。これは、表１の左側の解決策（Ａ）として示されている。

高可用性システムの外部でキューおよびビジネス・ロジックを実施する解決策（Ｂ）は、高可用性システム内のすべてのキュー管理アクティビティを回避する。しかし、通常の手法は、たとえば上で述べた遅延された孤立メッセージ問題のゆえに、１回のみのメッセージ処理の所望の保証を実現しないはずである。また、メッセージ処理トランザクションは、ＨＡＤＢリソースと外部キューイング・システムとの間の調整を伴う可能性が高く、これは、内部的に調整されるトランザクションより高価である。この解決策（Ｂ）は、表１の中央の列で表される。

本発明の実施形態は、表１の右側の解決策（Ｃ）として表される。これは、全体としてより多数の動作を伴う可能性が高く、したがって、直観に反するが、これらの動作のほとんどは、高可用性システムに影響しない。１つのトランザクションだけが、高可用性システム内で必要であり、このトランザクションは、同一ＨＡＤＢ内に保持される他のデータと調整され、同一の主張マネージャ１１０およびＨＡＤＢマネージャ１２０を使用している。また、キュー上の潜在的に大量のデータが、高可用性システムには保存されないので、これが、高可用性システムでのログ記録を節約する。

上で詳細に説明した実施形態では、メッセージ・ディスパッチャおよび関連するビジネス・ロジックは、ＨＡＤＢ内のデータの編成を認識しない。代替実施形態では、メッセージ・ディスパッチャまたは関連するビジネス・ロジックのいずれかが、ＨＡＤＢセグメンテーションおよびＨＡＤＢ構造の認識を伴って実施され、適当なＨＡＤＢセグメントへの最も効率的な経路を保証するルーティング／選択ロジックを含む。そのようなルーティングおよび選択ロジックは、当技術分野で周知である。そのような実施形態では、主張マネージャが、アプリケーション・データ・セグメントと主張テーブル・セグメントとの間のより高いアフィニティのために主張テーブルをセグメント化することができる。

もう１つの例の実施形態では、メッセージが、より効率的なメッセージ処理のために、各メッセージ・ディスパッチャによってバッチで処理される。このバッチ化は、２つ以上のメッセージ処理コンポーネントが主張テーブルに衝突する主張を入力することを試みる可能性を高めるが、衝突する主張の試みの処理は、比較的低い処理コストである。具体的に言うと、衝突する主張の試みの、ＨＡＤＢに対する影響は、少ない。この実施形態によるメッセージ・ディスパッチャによって実行される動作を、下に表す。
メッセージ・バッチに対するループ
メッセージ・トランザクションを開始する
［メッセージに関するループ］
ＨＡＤＢトランザクションを開始する
主張が成功するまでループする
メッセージを得る
主張をＨＡＤＢ主張テーブルに挿入することを試みる
主張の試みが失敗する場合には、次のメッセージの主張を試みるためにループする
主張が成功する場合には、継続する
ビジネス・ロジックを実行し、ＨＡＤＢを更新する
ＨＡＤＢをコミットする
［次のメッセージにループする］
メッセージ（１つまたは複数）をコミットする
次のメッセージ・バッチにループする

上で説明した実施形態は、主張テーブルにエントリを挿入する試みの失敗に応答して、通常処理中にサービス要求メッセージの重複を削除する機構を含む。この機構を、さらなる機構によって増補することができる。たとえば、成功するメッセージ・ディスパッチャが、その成功について他のメッセージ・ディスパッチャに通知することができ、これらの他のメッセージ・ディスパッチャは、その後、メッセージのそのメッセージ・ディスパッチャの複製を削除することができる。さらに、主張テーブルをクリーン・アップする機構を設けることができ、このクリーン・アップには、メッセージ・ディスパッチャの入力キューからの成功して処理されたメッセージの関連する複製のクリーン・アップが付随しなければならない。

多数のメッセージが、１回のみの処理を必要とはしない。たとえば、単純な読み取り専用データベース照会を要求するメッセージは、データ保全性を犠牲にせずに重複させることができる。本発明は、メッセージの１回のみの実行を保証するコストに関連する問題を軽減するが、それでも、この最適化された１回のみの処理でさえ、それに関する必要を避けることが好ましい可能性がある。当技術分野で既知の通り、不必要な１回のみの処理を回避する方法は、メッセージ内での必要なサービス品質の明示的なタグ付けと、非永続メッセージが１回のみの処理のオーバーヘッドをこうむる必要がないなどの仮定の使用とを含む。メッセージ・ゲット・オプションの１つが「syncpoint if persistent（永続ならば同期点）」であるIBM Corporation社のＷｅｂＳｐｈｅｒｅ ＭＱ製品など、一部のシステムは、明示的サポートを含む。

本発明のさまざまな実施形態を、本発明を異なる実施形態でどのように実施できるかの詳細な例示を提供するため、および本発明の特定の実施形態の利益のいくつかを強調するために上で説明した。しかし、本発明は、上で説明した特定の例示的実施形態には限定されず、当業者は、添付の特許請求の範囲に示された本発明の範囲に含まれるさまざまな修正形態を思い浮かべるであろう。

当技術分野で既知のものなど、単一メッセージング・システムが要求メッセージを処理し、更新命令をデータベースに送る、データ処理システムを示す概略図である。 本発明の実施形態による分散データ処理システムを示す概略図である。 本発明のもう１つの実施形態による分散データ処理システムを示す概略図である。 本発明の実施形態による、主張テーブルを更新する要求ディスパッチャを示す概略図である。 主張テーブルの更新を試み、拒否される要求ディスパッチャを示す概略図である。 本発明の実施形態による方法を示す概略流れ図表現である。 要求メッセージが成功して処理される、本発明の実施形態による方法のステップのシーケンスを示す図である。 重複メッセージがデータベースの更新を許可されない、方法のステップのシーケンスを示す図である。 サービス要求の処理に対するさまざまな代替手法に関する相対処理オーバーヘッドを示す図である。

１０ 高可用性データ・ストア（ＨＡＤＢ）
１２ サーバ
１４ サーバ
１６ サーバ
２０ メッセージ・ディスパッチャ
２２ メッセージ・ディスパッチャ
２４ メッセージ・ディスパッチャ
２６ メッセージ・ディスパッチャ
３０ ビジネス・ロジック
３２ ビジネス・ロジック
３４ ビジネス・ロジック
３６ ビジネス・ロジック
４０ リクエスタ
５０ リクエスタ
６０ リクエスタ
７０ レプリケータ
７１ レプリケータ
７２ レプリケータ
８０ キュー
８２ キュー
８４ キュー
８６ キュー
９０ ＨＡＤＢビジネス・データ
１００ 主張テーブル
１１０ 主張マネージャ
１２０ ＨＡＤＢマネージャ
１３０ 行
１４０ ページ

Claims (18)

1. データ・ストアと少なくとも１つのサービス・リクエスタとを含むデータ処理環境内で使用される、サービス要求を管理する方法であって、
   リクエスタのサービス要求を複数の要求処理コンポーネントのうちの少なくとも２つに複製するステップであって、前記複数の要求処理コンポーネントのそれぞれが、通信経路内で前記リクエスタと前記データ・ストアとの間に配置される、ステップと、
   第１要求処理コンポーネントが前記サービス要求に関する責任を主張するステップと、
   前記サービス要求に関する責任を成功裏に主張しなかったすべての要求処理コンポーネントが前記サービス要求を処理するのを阻止するステップと、
   前記第１要求処理コンポーネントが前記データ・ストア内のデータにアクセスすることを含めて前記主張されたサービス要求の前記第１要求処理コンポーネントの複製を処理するステップと
   を含む方法。
2. 責任を主張する前記ステップが、前記サービス要求の識別子を前記データ・ストア内のリポジトリに入力するステップを含み、前記方法が、前記複数の要求処理コンポーネントのいずれもが前記サービス要求の重複する識別子を前記リポジトリに入力するのを阻止することをさらに含む、請求項１に記載の方法。
3. 前記データ処理環境が、複数の分散サービス・リクエスタを含み、前記データ・ストアが、高可用性データ処理システムで動作するデータベースを含む、請求項１または２に記載の方法。
4. 前記要求処理コンポーネントが、サービス要求に応答して前記データ・ストア内のデータに対する更新を要求するビジネス・ロジックを含み、すべての要求処理コンポーネントが前記サービス要求を処理するのを阻止する前記ステップが、前記めいめいの要求処理コンポーネントのビジネス・ロジックの実行を阻止するステップを含む、請求項１ないし３のいずれか一項に記載の方法。
5. 前記サービス要求の完全な処理が、前記データ・ストア内のデータの更新を必要とし、前記サービス要求の処理を阻止する前記ステップが、前記データ・ストア内のデータの更新を阻止することによって完了した処理を阻止することを含む、請求項１ないし３のいずれか一項に記載の方法。
6. 前記サービス要求の処理を阻止する前記ステップが、前記データ・ストア内のデータへの読み取りアクセスと書き込みアクセスとの両方を阻止することによって完了した処理を阻止することを含む、請求項５に記載の方法。
7. 前記要求処理コンポーネントが、メッセージング・システムであり、前記複製されたサービス要求が、前記メッセージング・システムのうちの少なくとも２つの入力キューにエンキューされたメッセージであり、識別子を入力する前記ステップが、第１メッセージング・システムの入力キューからのメッセージの成功の取出しに応答して、前記第１メッセージング・システムのために実行される、請求項２に記載の方法。
8. 前記要求処理コンポーネントが、メッセージング・システムであり、前記複製されたサービス要求が、前記メッセージング・システムのうちの少なくとも２つの入力キューにエンキューされたメッセージであり、前記複数の要求処理コンポーネントのいずれもが重複する識別子を入力するのを阻止する前記ステップが、メッセージ取出し動作が以前に主張されたサービス要求に関するすべてのメッセージを取り出すのを阻止することを含む、請求項２に記載の方法。
9. 識別子を入力する前記ステップが、前記複製サービス要求を処理する前記ステップが完了するまで前記識別子をロックするステップを含み、いずれかの要求処理コンポーネントが重複する識別子を前記リポジトリに入力するのを阻止する前記ステップが、前記ロックを検査することと、前記ロックが解放されるまで識別子を入力する試みを延期するか拒否することとを含む、請求項２に記載の方法。
10. 前記リポジトリ内のアンロックされた識別子の識別が、前記識別されたサービス要求が成功裏に処理されたことの確認として認識され、前記リポジトリに重複する識別子を入力することを試みるすべての要求処理コンポーネントが、前記めいめいの要求処理コンポーネントの前記サービス要求の複製を削除することによって前記アンロックされた識別子に応答する、請求項９に記載の方法。
11. 前記リポジトリが、各テーブル行が前記識別されたサービス要求の責任に対する主張に対応する単一のサービス要求識別子を含むデータベース・テーブルである、請求項７ないし１０のいずれか一項に記載の方法。
12. 前記データ・ストアが、前記データベース・テーブルを含むデータベースであり、前記主張されたサービス要求の前記複製の成功の処理の影響が、前記データ・ストアに対する更新であり、前記成功の処理が、前記要求を処理する前記ステップおよび前記データ・ストアを更新する前記ステップの単一フェーズ・コミットを含む、請求項１１に記載の方法。
13. リクエスタのサービス要求の前記複製することが、前記サービス要求の前記複製を時間的に分離することを含む、請求項１ないし１２のいずれか一項に記載の方法。
14. データ・ストアと、
    複数の要求処理コンポーネントであって、前記複数の要求処理コンポーネントのそれぞれが、通信経路内で少なくとも１つのサービス・リクエスタと前記データ・ストアとの間に配置される、複数の要求処理コンポーネントと、
    サービス・リクエスタのサービス要求を前記複数の要求処理コンポーネントのうちの少なくとも２つに複製するレプリケータと、
    前記サービス要求の責任を成功裏に主張しなかったすべての要求処理コンポーネントが前記要求を処理するのを阻止する機能と、第１要求処理コンポーネントのために前記サービス要求の責任を主張する機能とを含む主張マネージャと
    を含むデータ処理システム。
15. 責任を主張する前記機能が、前記データ・ストアのリポジトリ内に前記サービス要求の識別子を挿入する機能を含み、前記主張マネージャが、前記複数の要求処理コンポーネントのいずれもが重複するサービス要求識別子を前記リポジトリに入力するのを阻止する機能をさらに含む、請求項１４に記載のデータ処理システム。
16. データ・ストアと少なくとも１つのサービス・リクエスタとを含むデータ処理環境内での動作を制御するコンピュータ・プログラムであって、コンピュータに、
    リクエスタのサービス要求を複数の要求処理コンポーネントのうちの少なくとも２つに複製するステップであって、前記複数の要求処理コンポーネントのそれぞれが、通信経路内で前記リクエスタと前記データ・ストアとの間に配置される、ステップと、
    第１要求処理コンポーネントが前記サービス要求に関する責任を主張するステップと、
    前記サービス要求に関する責任を成功裏に主張しなかったすべての要求処理コンポーネントが前記要求を処理するのを阻止するステップと、
    前記第１要求処理コンポーネントが前記データ・ストア内のデータにアクセスすることを含めて前記主張されたサービス要求の前記第１要求処理コンポーネントの複製を処理するステップと
    を実行させるためのコンピュータ・プログラム。
17. データ・ストアを含むデータ処理環境内で使用される、サービス要求を管理する方法であって、
    データ・ストア・トランザクションの外部で、複数のメッセージ処理コンポーネントのめいめいの入力キューにサービス要求の複数の複製をエンキューするステップと、
    データ・ストア・トランザクション内で、第１メッセージ処理コンポーネントが、前記データ・ストア内のデータにアクセスすることを含む前記サービス要求の第１複製を取り出し、前記サービス要求の前記第１複製を処理すると同時に、前記第１メッセージ処理コンポーネントが障害を経験しない限り、前記第１メッセージ処理コンポーネント以外の前記複数のメッセージ処理コンポーネントのいずれもが同一のサービス要求の他の複製を処理するのを阻止するステップと
    を含む方法。
18. 前記第１メッセージ処理コンポーネントが前記サービス要求を成功裏に処理することに応答して前記データ・ストア・トランザクションの単一フェーズ・コミットを実行することと、前記コミットされたデータ・ストア・トランザクションの識別に応答して前記サービス要求の複製を削除することとをさらに含む、請求項１７に記載の方法。

Images