JP2016081169A - 情報処理装置、データ処理システム、データ処理管理プログラム、及び、データ処理管理方法 - Google Patents

Abstract

【課題】複数のデータ処理装置間でデータがレプリケートされるシステムにおいて、他のデータ処理装置の処理実行完了を待たずに、他の処理を実行するデータ処理装置を提供する。【解決手段】検知部５は、第１の処理の完了を検知する。通知部６は、検知に応じて、自処理装置内または他のデータ処理装置２のデータ処理管理手段４それぞれに対し、第１の処理の処理開始時刻を含む第１の処理完了予告を通知する。判定部７は、他のデータ処理管理手段４それぞれからの第１の処理完了予告に対する応答内容に基づき、第１の処理の確定可否を判定する。送信部８は、第２の処理完了予告を受信した場合、第２の処理完了予告から特定される処理開始時刻より前に開始された処理それぞれが、第２の処理対象データを処理対象としているか否か、および、第２の処理完了予告を送付した処理手段３の性能情報に基づき、第２の処理完了予告に対する応答を生成し送信する。【選択図】図４

Description

本発明は、情報処理装置、データ処理システム、データ処理管理プログラム、及び、データ処理管理方法に関する。

東日本大震災以降、災害時の業務継続要件から、Wide Area Network（ＷＡＮ）を経由してデータをレプリケーションする技術（以下、ＷＡＮレプリケーション技術と記す）が重要性を増している。ＷＡＮレプリケーション技術について、データセンター（ＤＣ）での運用形態には、例えば「Active/Mirror」型と「Active/Active」型がある。このうち、ＤＣ資源の有効活用の観点から、マルチマスタで多拠点間をレプリケーションする「Active/Active」型へとトレンドが移りつつある。

ＷＡＮレプリケーション技術は、例えばDataBase（ＤＢ）サーバ間、キャッシュサーバ間といった同種製品内に閉じて機能が提供されることが多い。また、ＤＢサーバとキャッシュサーバのどちらか一方がマスタとなり他方がスレーブとなる一方向レプリケーションが行われる場合が多い。

しかし、Online Transaction Processing（ＯＬＴＰ）処理結果のマスタとしてのキャッシュサーバと、Online Analytical Processing（ＯＬＡＰ）等の目的で利用される過去からの蓄積データのマスタであるＤＢサーバとでは、マスタデータとしての特性が異なっている。このため、ＤＢアプリケーションとキャッシュアプリケーションの両者を備えたシステムの使用者からは、キャッシュサーバとＤＢサーバの双方をマスタとして扱いたいという要望が挙がっている。この場合、キャッシュサーバとＤＢサーバ間は双方向レプリケーションとなる。

同一のＤＣ内、及び異なるＤＣ間で、データの同期を取るための手順として、トランザクションをＤＢサーバとキャッシュサーバそれぞれに対して実行した後、コンフリクトが存在しないかを検証してから確定するという手順が考えられる。

特開平５−１９７６０４号公報 特開平９−１６４５３号公報

しかしながら、ＤＢサーバとキャッシュサーバは、処理速度の差が大きい。例えば、ＤＢサーバの処理速度はミリ秒オーダーであり、キャッシュサーバの処理速度はマイクロ秒オーダーである。キャッシュサーバの処理が終了した時点において、ＤＢサーバの処理が実行中である場合、キャッシュサーバは、ＤＢサーバの処理が終了するのを待ってからコンフリクトが存在しないかを確認し、その後に処理の確定を行うこととなる。このため、処理速度の速いキャッシュサーバの処理性能が、処理速度の遅いＤＢサーバの処理性能に引きずられることとなる。

そこで、１つの側面では、本発明は、複数のデータ処理装置間で連動してデータを更新するシステムにおいて、他のデータ処理装置における処理実行完了を待たずに他の処理を実行するデータ処理装置を提供することを目的とする。

一態様による情報処理装置は、データ処理手段と、データ処理手段に対応づけられて動作するデータ処理管理手段を有するデータ処理装置を複数備え、各データ処理装置のデータ処理手段が連動してデータの更新を行うデータ処理システムにおける、第１のデータ処理装置である。データ処理管理手段は、検知部、通知部、判定部、及び送信部を含む。検知部は、対応するデータ処理手段への第１の処理要求に対する第１の処理の完了を検知する。通知部は、検知部による検知に応じて、第１のデータ処理装置内または他のデータ処理装置の他のデータ処理管理手段それぞれに対し、第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知する。判定部は、他のデータ処理管理手段それぞれからの第１の処理完了予告に対する応答内容に基づき、第１の処理の確定可否を判定する。送信部は、他のデータ処理管理手段のいずれかから第２の処理完了予告を受信した場合は、対応するデータ処理手段において、第２の処理完了予告から特定される処理開始時刻より前に対応するデータ処理手段で開始された処理それぞれが、第２の処理完了予告から特定される処理対象データを処理対象としているか否か、および、第１のデータ処理装置が有する第２の処理完了予告を送付したデータ処理管理手段に対応する処理手段の性能情報に基づき、第２の処理完了予告に対する応答を生成し送信する。

一側面によれば、複数のデータ処理装置間で連動してデータを更新するシステムにおいて、他のデータ処理装置における処理実行完了を待たずに他の処理を実行するデータ処理装置を提供することができる。

ＤＣ間でキャッシュ層のみをＷＡＮレプリケーションするモデルの処理の流れの一例を示す。 ＤＣ間でキャッシュ層とＤＢ層をＷＡＮレプリケーションするモデルの処理の流れの一例を示す。 比較例３の処理の流れの一例を示す。 実施形態に係るデータ処理システムの構成の一例を示す。 実施形態に係るデータ処理システムの構成と処理の流れの一例（その１）を示す。 実施形態に係るデータ処理システムの構成と処理の流れの一例（その２）を示す。 実施形態に係るデータ処理システムの構成と処理の流れの一例（その３）を示す。 実施形態に係るデータ処理システムの構成と処理の流れの一例（その４）を示す。 ＲＰＡ間の処理のやり取りの一例を時系列で示す。 第１のパターンの処理の流れを示す。 第２のパターンの処理の流れを示す。 第３のパターンの処理の流れを示す。 第４のパターンの処理の流れを示す。 第１−１のパターンの処理の流れを示す。 第１−２のパターンの処理の流れを示す。 実施形態の処理の流れの一例を示す。 実施形態に係るデータ処理装置の構成の一例を示す。 トランザクション管理情報の構成の一例を示す。 性能情報の構成の一例を示す。 予告管理情報の構成の一例を示す。 実施形態に係るデータ処理装置の第１のトランザクションについての処理の詳細を図解したフローチャートの一例（その１）である。 実施形態に係るデータ処理装置の第１のトランザクションについての処理の詳細を図解したフローチャートの一例（その２）である。 実施形態に係るデータ処理装置の第２のトランザクションについての処理の詳細を図解したフローチャートの一例（その１）である。 実施形態に係るデータ処理装置の第２のトランザクションについての処理の詳細を図解したフローチャートの一例（その２）である。 制御部によるアクセス制御の処理の詳細を図解したフローチャートの一例である。 データ処理装置のハードウェア構成の一例を示す。 実施形態に係るデータ処理システムの構成の一例を示す

ＤＢサーバとキャッシュサーバの双方をマスタとし、Active/Activeで運用されるデータセンタ間をレプリケーションする手法として、以下の比較例１と比較例２の技術がある。

比較例１は、ＤＣ間でキャッシュ層のみをＷＡＮレプリケーションするモデルである。図１は、ＤＣ間でキャッシュ層のみをＷＡＮレプリケーションするモデルの処理の流れの一例を示す。図１では、キャッシュサーバ（Ａ〜Ｃ）間でのレプリケーションが行われているため、キャッシュサーバ（Ａ〜Ｃ）のうちの何れかのデータが更新された場合、自動的にその他のキャッシュサーバのデータも更新される。その結果、常にキャッシュサーバ（Ａ〜Ｃ）間では同期が取れた状態となる。

図１においてＳ１１〜Ｓ１６は、アプリケーションサーバ（以下、ＡＰサーバと記す）ＢからキャッシュサーバＡのデータに対する更新が発生した場合の、処理の流れを示している。ＡＰサーバＢによりキャッシュサーバＡのデータが更新される（Ｓ１１）と、キャッシュサーバ（Ａ〜Ｃ）の間でレプリケーションによる同期が行われる（Ｓ１２、Ｓ１３）。その後、所定のタイミングで、各ＤＣ内のキャッシュサーバとＤＢサーバ間でデータの同期処理が行われる（Ｓ１４〜Ｓ１６）。Ｓ２１〜Ｓ２６は、ＡＰサーバＡからＤＢサーバＡのデータに対する更新が発生した場合の、処理の流れを示している。ＡＰサーバＡによりＤＢサーバＡのデータが更新される（Ｓ２１）と、所定のタイミングでＤＢサーバＡとキャッシュサーバＡとの間でデータの同期処理が行われる（Ｓ２２）。そしてキャッシュサーバ（Ａ〜Ｃ）の間でレプリケーションによる同期が行われる（Ｓ２３、Ｓ２４）。その後、所定のタイミングで、各ＤＣ内のキャッシュサーバとＤＢサーバ間でデータの同期処理が行われる（Ｓ２５、Ｓ２６）。

図１において、ＤＢサーバのデータは、そのＤＢサーバが属するＤＣ内の何れかのサーバから更新され、他のＤＣに属するサーバから直接更新されることはない。この場合ＤＣ間では、キャッシュサーバ間のトランザクションの整合性は保障されるが、キャッシュサーバとＤＢサーバとの間や、ＤＢサーバ間のデータの整合性は保障されない。

比較例２は、ＤＣ間でキャッシュ層とＤＢ層をそれぞれＷＡＮレプリケーションするモデルである。図２は、ＤＣ間でキャッシュ層とＤＢ層をＷＡＮレプリケーションするモデルの処理の流れの一例を示す。図２では、キャッシュサーバ（Ａ〜Ｃ）間、ＤＢサーバ（Ａ〜Ｃ）間でそれぞれレプリケーションが行われている。そのため、キャッシュサーバ（Ａ〜Ｃ）のうちの何れかのデータが更新された場合、自動的にその他のキャッシュサーバのデータも更新され、常にキャッシュサーバ（Ａ〜Ｃ）間では同期が取れた状態となる。また、ＤＢサーバ（Ａ〜Ｃ）のうちの何れかのデータが更新された場合、自動的にその他のＤＢサーバのデータも更新され、常にＤＢサーバ（Ａ〜Ｃ）間では同期が取れた状態となる。

図２においてＳ３１〜Ｓ３６は、ＡＰサーバＢからキャッシュサーバＡのデータに対する更新が発生した場合の、処理の流れを示している。ＡＰサーバＢによりキャッシュサーバＡのデータが更新される（Ｓ３１）と、キャッシュサーバＡ〜Ｃの間でレプリケーションによる同期が行われる（Ｓ３２、Ｓ３３）。その後、所定のタイミングで、キャッシュサーバＡとＤＢサーバＡの間でデータの同期処理が行われ（Ｓ３４）、ＤＢサーバ（Ａ〜Ｃ）の間でレプリケーションによる同期が行われる（Ｓ３５、Ｓ３６）。Ｓ４１〜Ｓ４６は、ＡＰサーバＡからＤＢサーバＡのデータに対する更新が発生した場合の、処理の流れを示している。ＡＰサーバＡによりＤＢサーバＡのデータが更新される（Ｓ４１）と、ＤＢサーバ（Ａ〜Ｃ）の間でレプリケーションによる同期が行われる（Ｓ４２、Ｓ４３）。その後、所定のタイミングで、キャッシュサーバＡとＤＢサーバＡの間でデータの同期処理が行われ（Ｓ４４）、キャッシュサーバＡ〜Ｃの間でレプリケーションによる同期が行われる（Ｓ４５、Ｓ４６）。

図２の例の場合、ＤＣ間では、キャッシュサーバ間、ＤＢサーバ間のトランザクションの整合性は保障されるが、キャッシュサーバとＤＢサーバとの間のデータ整合性は保障されない。

以上のように、比較例１と比較例２のいずれの場合も、キャッシュサーバとＤＢサーバとの間のデータの整合性は保証されない。このため比較例１と比較例２の技術では、キャッシュサーバとＤＢサーバの両者をマスタとした場合、同じデータにキャッシュサーバ側からアクセスする場合とＤＢサーバ側からアクセスする場合で結果が異なってしまうことがある。

キャッシュサーバとＤＢサーバの間のデータの整合性を保証するレプリケーション技術として、分散トランザクションを使ったレプリケーションを行う比較例３の技術がある。

比較例３では、トランザクションの処理がＤＢサーバとキャッシュサーバのそれぞれに対して実行された後、コンフリクトが存在しないかの検証が行われてからトランザクションが確定される。これにより、キャッシュサーバとＤＢサーバの間のデータの整合性が保証される。

図３は、比較例３の処理の流れの一例を示す。図３において、ＡＰサーバ１ａとＡＰサーバ１ｂは、それぞれ、キャッシュサーバとＤＢサーバに対して、トランザクションの処理を実行している。ＡＰサーバ１ａは、キャッシュサーバに対して先に処理を実行し、その後ＤＢサーバに対して処理を実行している。一方、ＡＰサーバ１ｂは、ＤＢサーバに対して先に処理を実行し、その後キャッシュサーバに対して処理を実行している。また、ＡＰサーバ１ａと、ＡＰサーバ１ｂのトランザクションで扱われるリソースはＲ１とＲ２であり、同じリソースである。ＡＰサーバ１ａ、１ｂはともに、キャッシュサーバとＤＢサーバの両方に対するトランザクションの処理が終了してから、処理の確定（コミット）が可能か否かを問い合わせる処理完了予告を送信している。処理の確定が可能か否かは、２つのトランザクション間でコンフリクトが発生しているか否か、及び、コンフリクトが発生しているトランザクションのうち先に処理が開始されたトランザクションか否かに基づいて決定される。

図３に示すように、ＡＰサーバ１ａは、キャッシュサーバに対して処理完了予告を送信すると、その応答として、コミットが可能であることを示す応答を受信する。これは、キャッシュサーバでは、ＡＰサーバ１ａの処理がＡＰサーバ１ｂの処理よりも先に実行されているためである。同様に、ＡＰサーバ１ｂは、ＤＢサーバに対して処理完了予告を送信すると、その応答として、コミットが可能であることを示す応答を受信する。一方、ＡＰサーバ１ａは、ＤＢサーバに対して処理完了予告を送信すると、その応答として、コミットが不可能であることを示す応答を受信する。これは、ＤＢサーバでは、ＡＰサーバ１ｂの処理がＡＰサーバ１ａの処理よりも先に実行されているからである。同様にＡＰサーバ１ｂは、キャッシュサーバに対して処理完了予告を送信すると、その応答として、コミットが不可能であることを示す応答を受信する。

比較例３では、キャッシュサーバ及びＤＢサーバの両方から処理の確定が可能であることを示す応答を受信した場合に、両方のサーバの処理を確定することで、データの整合性を保証している。しかしながら図３のように、ＡＰサーバ１ａ、１ｂともに、キャッシュサーバ及びＤＢサーバに対する処理完了予告のうち、何れかのサーバから応答として、処理の確定が不可能であることを示す応答を受信する場合がある。この場合、ＡＰサーバ１ａ、１ｂともに、トランザクションのロールバックを実行することとなる。

また、図３では、ＡＰサーバ１ａ、１ｂは、キャッシュサーバとＤＢサーバの両方に対する処理が終了してから、処理完了予告を送信している。よって、キャッシュサーバのトランザクションのコンフリクト検出が、ＤＢサーバの処理性能に引きずられて遅延してしまう。これは、システムをスケールアウトしてもインメモリキャッシュのスループットが伸びない原因となる。また、シーケンシャルなトランザクション制御の結果、両ＡＰサーバ１ａ、１ｂのトランザクションのロールバックが発生しやすい状況となり、処理確定のために何度もロールバックが発生する可能性がある。さらに、ＡＰサーバからの各トランザクション命令（処理開始、処理完了予告、コミットまたはロールバック）が同期的であるため、レプリケーション対象となるデータ処理装置の数の増加に従って、トランザクションの完了までにかかる合計時間が線形に増加する。

実施形態に係るデータ処理システムの構成について説明する。図４は、実施形態に係るデータ処理システムの構成の一例を示す。

図４において、データ処理システム１は、データ処理手段（３ａ〜３ｃ）と、データ処理手段に対応づけられて動作するデータ処理管理手段（４ａ〜４ｃ）を有するデータ処理装置（２ａ〜２ｃ）を複数備える。そして、各データ処理装置（２ａ〜２ｃ）のデータ処理手段（３ａ〜３ｃ）は連動してデータの更新を行う。図４の説明においては、データ処理システム１に含まれる複数のデータ処理装置（２ａ〜２ｃ）のうち、データ処理装置２ａを第１のデータ処理装置として着目し説明を行うが、データ処理装置２ｂ、２ｃの構成についてもデータ処理装置２ａと同様である。また、データ処理システム１に含まれるデータ処理装置の数は、３つに限定されない。また、データ処理システムは、複数のデータセンタを含み、各々のデータセンタに複数のデータ処理装置を含む構成としてもよい。

第１のデータ処理装置２ａのデータ処理管理手段４ａは、検知部５、通知部６、判定部７、送信部８、確定通知送信部９、及び制御部１０を含む。

検知部５は、対応するデータ処理手段３ａへの第１の処理要求に対する第１の処理の完了を検知する。

通知部６は、検知部５による検知に応じて、第１のデータ処理装置２ａ内または他のデータ処理装置（２ｂ〜２ｃ）の他のデータ処理管理手段（４ｂ〜４ｃ）それぞれに対し、第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知する。

判定部７は、他のデータ処理管理手段（４ｂ〜４ｃ）それぞれからの第１の処理完了予告に対する応答内容に基づき、第１の処理の確定可否を判定する。

送信部８は、他のデータ処理管理手段（４ｂ〜４ｃ）のいずれかから第２の処理完了予告を受信した場合、以下の処理を実行する。すなわち送信部８は、対応するデータ処理手段３ａにおいて、第２の処理完了予告から特定される処理開始時刻より前に対応するデータ処理手段３ａで開始された処理それぞれが、第２の処理完了予告から特定される処理対象データを処理対象としているか否か、および、第１のデータ処理装置２ａが有する第２の処理完了予告を送付したデータ処理管理手段に対応する処理手段の性能情報に基づき、第２の処理完了予告に対する応答を生成し送信する。

これにより、実施形態では、複数のデータ処理装置間でデータがレプリケートされるシステムにおいて、最初に処理が開始された処理を確定し、かつ、処理性能に応じた応答が行われる。そのため、他のデータ処理装置のデータ処理手段における処理実行完了を待たずに、他の処理を実行することができる。これにより、処理の確定可否の判定のタイミングが、他のデータ処理装置の処理性能に引きずられることを防ぐことができる。その結果、各データ処理装置及びデータ処理システム全体のトランザクションに対する処理性能を向上させることができる。

また、通知部６は、第１の処理完了予告を通知する際に、マルチキャスト通信を利用する。マルチキャスト通信を利用することで、複数のデータ処理装置を同時に管理して処理完了予告の送信タイミングを合わせることができる。

また、判定部７はさらに、他のデータ処理管理手段（４ｂ〜４ｃ）より、第１の応答を受信した場合、第１の処理の処理対象データを第１の処理の開始前の状態に戻すように対応するデータ処理手段３ａを制御する。第１の応答とはすなわち、第１の処理完了予告から特定される第１の処理の処理開始時刻より前に、他のデータ処理装置（２ｂ〜２ｃ）において開始された処理のいずれかが、第１の処理完了予告から特定される処理対象データを処理対象としていることを示す通知である。これにより、データ処理装置間でデータの不整合が生じることを防ぐことができる。

また、判定部７はさらに、他のデータ処理管理手段（４ｂ〜４ｃ）より、第２の応答を受信した場合、処理対象データを第１の処理の開始前の状態に戻し、第３の処理を実行した後に、第１の処理を再実行するように対応するデータ処理手段３ａを制御する。ここで、第３の処理は、第２の処理の処理対象データとは異なるデータを処理対象とする処理である。また、第２の応答は、第１の処理完了予告から特定される第１の処理の処理開始時刻より前に、他のデータ処理装置（２ｂ〜２ｃ）において開始された処理のいずれかが、第１の処理完了予告から特定される処理対象データを処理対象としていることを示す。さらに第２の応答は、対応するデータ処理手段３ａの性能が、他のデータ処理装置（２ｂ〜２ｃ）内のデータ処理手段の性能以上であることを示す。

処理性能が低い他のデータ処理手段により第２の処理が行われている間に、第２の処理の処理対象データとは異なるデータを扱う第３の処理を、対応するデータ処理手段３ａが実行することで、処理効率を高めることができる。また、これにより、ロールバックが発生する可能性を低減できる。

確定通知送信部９は、判定部７により第１の処理が確定可能であると判定された場合、第１の処理の確定処理を行うようにデータ処理手段を制御し、他のデータ処理管理手段（４ｂ〜４ｃ）に対して、第１の処理が確定されたことを示す確定通知を送信する。

制御部１０は、対応するデータ処理手段３ａにおいて、第２の処理完了予告から特定される処理開始時刻より前に開始された処理のそれぞれが、第２の処理完了予告から特定される処理対象データを処理対象としていない場合、以下の処理を行う。すなわち制御部１０は、第２の処理完了予告に対する応答を送信した後に第２の処理完了予告から特定される処理対象データに対するアクセス要求が発生すると、第２の処理に対応する確定通知を受信して第２の処理の確定処理を実行した後にアクセスするように対応するデータ処理手段３ａを制御する。

制御部１０による制御により、第２の処理完了予告に対する応答を送信してから、第２の処理の確定処理を実行するまでの間に、第２の処理完了予告から特定される処理対象データに対する他のアクセスを防ぐことができる。これにより、データ処理装置間でデータの不整合が生じることを防ぐことができる。

実施形態に係るデータ処理システムの全体の構成と処理の流れについて説明する。図５〜図８は、実施形態に係るデータ処理システムの構成と処理の流れの一例（その１〜その４）を示す。図５〜図８は、データ処理システムの処理の変化を時系列順に示している。

実施形態において、データ処理装置でトランザクションの処理が終了した場合、他のデータ処理装置に対して確定処理（コミット）が実行可能であるかの問い合わせが行われ、その応答結果に応じて、コミットまたはロールバックが行われる。以下の説明では、コミットが実行可能であるかの問い合わせを、処理完了予告と記す。

図５において、データ処理システムは、複数のＤＣ（ＤＣ５１ａ〜５１ｃ）を含む。各ＤＣ間は通信ネットワークを介して接続される。各ＤＣは、ＡＰサーバ５２（ａ〜ｆ）、ＤＢサーバ５３（ａ〜ｃ）、キャッシュサーバ５４（ａ〜ｃ）を含む。ＡＰサーバ５２、ＤＢサーバ５３、キャッシュサーバ５４は、互いに通信ネットワークまたはバス等を介して接続される。

データ処理システムにおいて、ＤＢサーバ５３、及びキャッシュサーバ５４では、複数のＤＣ間でレプリケーションが行われる。以下の説明では、レプリケーション対象となるデータ処理装置をレプリケーションポイント（ＲＰ）と記す場合がある。ＲＰは、具体的にはＤＢサーバ５３及びキャッシュサーバ５４である。各ＲＰには、マルチキャストを送受信する常駐エージェントであるソフトウェア（ＲＰＡ）５５（ａ〜ｆ）が動作する。マルチキャストでは、例えば高信頼User Datagram Protocol（ＵＤＰ）（ＲＵＤＰ）等の所定のプロトコルが使用される。高信頼ＵＤＰは、到達パケットの順序組み立て、再送要求、重複パケット破棄、及びACKnowledgement（ＡＣＫ）応答に対応する。ＲＰは、データ処理装置２の一例である。ＲＰＡは、データ処理管理手段４の一例である。

ＲＰはそれぞれ非同期にトランザクションを開始する。図５において、ＲＰＡ５５ａはリソースＲ１に対するトランザクションＴｘ（Ｒ１）を実行している。ここで図面及び以下の説明では、ＲＰで実行されるトランザクションを「Ｔｘｓ（処理対象データ）」（ｓは正の整数）の形式で記載する場合がある。処理対象データは、対応するトランザクションで更新またはアクセスされるデータを示す。リソースＲ１に対するトランザクションは、Ｔｘ１（Ｒ１）と記載される。図５においては、さらにＲＰＡ５５ｃ、ＲＰＡ５５ｅ、ＲＰＡ５５ｆにおいてそれぞれ、Ｔｘ２（Ｒ２）、Ｔｘ３（Ｒ３）、Ｔｘ４（Ｒ４）が実行されている。

トランザクションの処理が終了すると、ＲＰはトランザクションのコミットの実行前に、ＲＰＡ経由で処理完了予告をマルチキャストする。図６では、Ｔｘ１（Ｒ１）のトランザクションの処理が終了し、ＲＰＡ５５ａは、Ｔｘ１（Ｒ１）のコミット（またはロールバック）が行われる直前に、処理完了予告を他のＲＰＡ（５５ｂ〜５５ｆ）にマルチキャストしている。

処理完了予告を受信した各ＲＰＡは、所定の条件に応じて、処理完了予告に対する応答を生成し、処理完了予告の送信元のＲＰＡに送信する。後ほど詳しく説明するが、処理完了予告に対する応答は、ＯＫ応答、ＰＥＮＤＩＮＧ応答、ＲＥＴＲＹ応答の３種類が存在する。判定のための所定の条件についても後ほど説明する。図７では、処理完了予告を受信したＲＰＡ（５５ｂ〜５５ｆ）は、処理完了予告に対する応答を生成しＲＰＡ５５ａに送信している。図７の例では、コミットが可能であることを示すＯＫ応答が生成されて送信される。

次に処理完了予告の送信元のＲＰＡは、処理完了予告に対する応答を受信し、その応答結果に応じて、トランザクションをコミットするかロールバックするかを決定する。そしてこの決定に応じてＲＰＡは、トランザクションのコミットまたはロールバックを実行するように制御する。さらにＲＰＡは、ロールバックを実行する場合には、ロールバック後にトランザクションのリトライを即時実施するか遅延させるかを応答結果に応じて決定する。この決定に応じてＲＰＡは、ロールバック後の処理を制御する。図７では、処理完了予告に対するＯＫ応答を受信したＲＰＡ５５ａは、Ｔｘ１（Ｒ１）をコミットすると決定し、Ｔｘ１（Ｒ１）のコミットを実行するように制御している。

トランザクションのコミットまたはロールバックの完了後、ＲＰＡは、コミット通知またはロールバック通知を他のＲＰＡにマルチキャストする。コミット通知を受信するとＲＰＡは、コミット通知の送信元と整合性がとれるように、データを更新するように制御する。図８において、ＲＰＡ５５ａは、Ｔｘ１（Ｒ１）のコミットが完了すると、コミット通知を各ＲＰＡ（５５ｂ〜５５ｆ）に送信している。そして、コミット通知を受信したＲＰＡ（５５ｂ〜５５ｆ）は、Ｔｘ１（Ｒ１）に対応するデータの更新を行っている。

図９は、図５〜図８のＲＰＡ間の処理のやり取りを時系列で示す。
ここで、図９及び以下で説明する図１０〜図１５で用いられる記号の意味を説明する。Ｒr（rは正の整数）は、リソースＲrに対するアクセスが発生したことを示す。ＴｘＢ、ＴｘＰ、ＴｘＣ、ＴｘＲ、ＴｘＳ、ＴｘＲｍは、それぞれ、トランザクションの開始時点、処理完了予告を送信する時点、コミットの実行時点、ロールバックの実行時点、処理の一時停止時点、処理の再開時点を示す。

図９において、ＲＰＡ１は、Ｔｘ１において、リソースＲ１へのアクセスを行い、ＴｘＰで示される時点においてトランザクションの処理が終了すると、処理完了予告をマルチキャストしている。処理完了予告を受信した各ＲＰＡ（５５ｂ〜５５ｆ）は、応答を生成してＲＰＡ５５ａに送信している。ＲＰＡ５５ａは応答を受信するとトランザクションのコミットを行い、コミット通知を他のＲＰＡ（５５ｂ〜５５ｆ）に送信している。

上記の図５〜図９では、ＲＰＡ５５ａのトランザクションＴｘ１が、他のＲＰＡ（５５ｂ〜５５ｆ）で実行されているどのトランザクション（Ｔｘ２〜Ｔｘ５）よりも先に開始されている。この場合、ＲＰＡ５５ａからの処理完了予告に対する応答として、各ＲＰＡ（５５ｂ〜５５ｆ）は、コミットの実行が可能であることを示すＯＫ応答を生成し、ＲＰＡ５５ａに送信する。しかしながら、例えば、Ｔｘ１と同じリソースＲ１にアクセスするＴｘ５が、Ｔｘ１よりも前に開始されている場合には、ＲＰＡ５５ｃは、コミットの実行が不可能であることを示すＲＥＴＲＹ応答またはＰＥＮＤＩＮＧ応答を生成して送信することとなる。そしてこの応答を受信したＲＰＡ５５ａは、Ｔｘ１のロールバックを実行することとなる。このように実施形態では、処理の流れは、トランザクションの処理対象のリソース、及びトランザクションの開始時刻に応じて変化する。さらに、実施形態における処理の流れは、各ＲＰＡが稼動するデータ処理装置のトランザクション処理性能に応じても変化する。

以下、実施形態のデータ処理システムにおけるトランザクションの処理の流れのパターンを説明する。処理の流れのパターンは、第１〜第４の４つのパターンが存在する。ここでは処理完了予告を送信するＲＰＡと、その処理完了予告を受信するＲＰＡの２つのＲＰＡの関係に着目し、図１０〜図１３を参照して処理の流れのパターンを説明する。

第１のパターンは、着目する２つのＲＰＡで実行されるトランザクション内で扱われるリソースが異なる場合の処理のパターンである。扱われるリソースが異なるため、２つのトランザクション間でコンフリクトは発生しない。このため双方のトランザクションは、他のトランザクションの処理に関係なくコミットが可能である。図１０は、第１のパターンの処理の流れを示す。

図１０において、ＲＰＡ１は処理完了予告を先に送信するＲＰＡであり、ＲＰＡ２は処理完了予告を受信するＲＰＡである。ＲＰＡ１で実行されるトランザクションＴｘ１では、リソースＲ１、Ｒ２に対するアクセスが発生し、ＲＰＡ２で実行されるトランザクションＴｘ２では、リソースＲ３に対するアクセスが発生している。従って、Ｔｘ１とＴｘ２で扱うリソースは異なっている。この場合、ＲＰＡ１から処理完了予告を受信したＲＰＡ２は、コミットの実行が可能であることを示すＯＫ応答を生成しＲＰＡ１に送信する。ＯＫ応答を受信するとＲＰＡ１は、Ｔｘ１のコミットを実行し、コミット通知をＲＰＡ２に送信する。ＲＰＡ２はコミット通知を受信すると、Ｔｘ１の内容を反映する。

第２〜第４のパターンは、いずれも、２つのトランザクション内で扱われるリソースのうちで共通するものが存在する場合の処理のパターンである。このうち第２のパターンは、処理完了予告を送信するトランザクションが先行トランザクションである場合の処理のパターンである。本実施形態では、着目する２つのトランザクションのうち、処理開始時刻が前であるトランザクションを先行トランザクションと記し、処理開始時刻が後であるトランザクションを後行トランザクションと記す。

図１１は、第２のパターンの処理の流れを示す。図１１において、ＲＰＡ１で実行されるトランザクションＴｘ１では、リソースＲ１、Ｒ２に対するアクセスが発生し、ＲＰＡ２で実行されるトランザクションＴｘ２では、リソースＲ２に対するアクセスが発生している。従って、Ｔｘ１とＴｘ２で扱うリソースのうち、Ｒ２は共通している。また、Ｔｘ１の開始時刻はＴｘ２よりも前である。

第２のパターンでは、２つのトランザクションで扱われるリソースに同じものが存在するため、Ｔｘ１とＴｘ２の間でコンフリクトが発生する。この場合、先行トランザクションであるＴｘ１に対して優先的にコミットが実行され、後行トランザクションであるＴｘ２に対してはロールバックが実行される。

ＲＰＡ２はＲＰＡ１から処理完了予告を受信すると、Ｔｘ１のコミットの実行が可能であることを示すＯＫ応答を作成して、ＲＰＡ１に送信するとともに、Ｔｘ２をロールバックする。ＯＫ応答を送信した時点からＴｘ１のコミット完了までの時間は短時間で済むと考えられるため、ＲＰＡ２は、ＲＰＡ１のコミットが完了したことを示すコミット通知を待ってから、Ｔｘ２を再度実行する。

第２のパターンでは、具体的には、ＲＰＡ１から処理完了予告を受信したＲＰＡ２は、ＯＫ応答を生成しＲＰＡ１に送信するとともに、Ｔｘ２をロールバックする。Ｔｘ２のロールバック後、ＲＰＡ２は、Ｔｘ１のコミット通知を受信するまでＴｘ２に関する処理を停止する。一方ＲＰＡ１は、ＯＫ応答を受信するとＴｘ１のコミットを実行し、コミット通知をＲＰＡ２に送信する。ＲＰＡ２はコミット通知を受信すると、Ｔｘ１の内容を反映し、Ｔｘ２を再度実行する。

第３と第４のパターンは、いずれも、２つのトランザクション内で扱われるリソースのうちで共通するものが存在し、且つ、処理完了予告を送信するトランザクションが後行トランザクションである場合の処理のパターンである。このうち第３のパターンは、後行トランザクションを実行するデータ処理装置のトランザクション処理性能が、先行トランザクションを実行するデータ処理装置のトランザクション処理性能以下である場合の処理のパターンである。

図１２は、第３のパターンの処理の流れを示す。図１２において、ＲＰＡ１で実行されるトランザクションＴｘ１では、リソースＲ１、Ｒ２に対するアクセスが発生し、ＲＰＡ２で実行されるトランザクションＴｘ２では、リソースＲ２、Ｒ３、Ｒ４に対するアクセスが発生している。従って、Ｔｘ１とＴｘ２で扱うリソースのうち、Ｒ２は共通している。また、Ｔｘ１の開始時刻はＴｘ２よりも後である。さらに、ＲＰＡ１が動作するデータ処理装置のトランザクション処理性能はＲＰＡ２が動作するデータ処理装置のトランザクション処理性能以下である。

第３のパターンでは、第２のパターンと同様に、２つのトランザクションで扱われるリソースに同じものが存在するため、Ｔｘ１とＴｘ２の間でコンフリクトが発生する。この場合、後行トランザクションであるＴｘ１に対してはロールバックが実行され、先行トランザクションであるＴｘ２に対して優先的にコミットが実行される。

ＲＰＡ２はＲＰＡ１から処理完了予告を受信すると、Ｔｘ１の即時リトライを指示するＲＥＴＲＹ応答を作成して、ＲＰＡ１に送信する。ここで即時リトライを指示する理由は、ＲＰＡ１のトランザクション処理性能はＲＰＡ２と同等以下であるため、ＲＰＡ１のトランザクションのリトライで再度コンフリクトする可能性が低いからである。これはすなわち、ＲＰＡ１がリトライを行うときには、コンフリクトしているＲＰＡ２のトランザクションが既に完了していることが期待できるためである。これにより、再度Ｔｘ１を実行した場合に、再びコンフリクトが発生する可能性を低減することができる。尚、ＲＥＴＲＹ応答は、Ｔｘ１のコミットが不可能であることを示すものであるともいえる。

ＲＥＴＲＹ応答を受け取ったＲＰＡ１は、Ｔｘ１をロールバックする。尚、ＲＰＡ２のトランザクション処理性能はＲＰＡ１のトランザクション処理性能よりも高いため、ＲＥＴＲＹ応答を受信した時点からＴｘ２のコミット完了までの時間は、ＲＰＡ１の他のトランザクション処理時間と比較して短時間で済むと考えられる。そこでＲＰＡ１は、ＲＰＡ２のコミットが完了したことを示すコミット通知を待ってから、Ｔｘ１を再度実行する。

第３のパターンでは、具体的には、ＲＰＡ１から処理完了予告を受信したＲＰＡ２は、Ｔｘ２の処理を継続しつつ、ＲＥＴＲＹ応答を生成しＲＰＡ１に送信する。ＲＥＴＲＹ応答を受信するとＲＰＡ１は、Ｔｘ１のロールバックを実行し、ＲＰＡ２からＴｘ２のコミット通知を受信するまでＴｘ１に関する処理を停止する。ＲＰＡ２はＴｘ２の処理が完了次第、処理完了予告をＲＰＡ１に送信する。そしてＲＰＡ２はＲＰＡ１からＯＫ応答を受信すると、Ｔｘ２のコミットを実行し、コミット通知をＲＰＡ１に送信する。ＲＰＡ１はコミット通知を受信すると、Ｔｘ２の内容を反映し、その後、Ｔｘ１を再度実行しなおす。

第４のパターンは、上述したように、２つのトランザクション内で扱われるリソースのうちで共通するものが存在し、且つ、処理完了予告を送信するトランザクションが後行トランザクションである場合の処理のパターンである。そしてさらに第４のパターンは、後行トランザクションを実行するデータ処理装置のトランザクション処理性能が、先行トランザクションを実行するデータ処理装置のトランザクション処理性能より高い場合の処理のパターンである。

図１３は、第４のパターンの処理の流れを示す。図１３において、ＲＰＡ１で実行されるトランザクションＴｘ１では、リソースＲ１、Ｒ２に対するアクセスが発生し、ＲＰＡ２で実行されるトランザクションＴｘ２では、リソースＲ２、Ｒ３、Ｒ４に対するアクセスが発生している。従って、Ｔｘ１とＴｘ２で扱うリソースのうち、Ｒ２は共通している。また、Ｔｘ１の開始時刻はＴｘ２よりも後である。さらに、ＲＰＡ１が動作するデータ処理装置のトランザクション処理性能はＲＰＡ２が動作するデータ処理装置のトランザクション処理性能より高い。

第４のパターンでは、第３のパターンと同様に、２つのトランザクションで扱われるリソースに同じものが存在するため、Ｔｘ１とＴｘ２の間でコンフリクトが発生する。この場合、後行トランザクションであるＴｘ１に対してはロールバックが実行され、先行トランザクションであるＴｘ２に対して優先的にコミットが実行される。

ＲＰＡ２はＲＰＡ１から処理完了予告を受信すると、ＰＥＮＤＩＮＧ応答を作成して、ＲＰＡ１に送信する。ＰＥＮＤＩＮＧ応答は、Ｔｘ１の処理をペンディングし、他のリソースを扱うトランザクションを実行した後に、Ｔｘ１のリトライを行うように指示する内容を含む応答である。ここでＴｘ１の処理のペンディングを指示する理由は、ＲＰＡ１のトランザクション処理性能はＲＰＡ２より高いため、Ｔｘ１を即時リトライしてもＴｘ２が完了していない可能性が高く、コンフリクトが発生し続ける可能性が高いと考えられるからである。尚、ＰＥＮＤＩＮＧ応答は、Ｔｘ１のコミットが不可能であることを示すものであるともいえる。

ＰＥＮＤＩＮＧ応答を受け取ったＲＰＡ１は、Ｔｘ１をロールバックする。ここで、ＲＰＡ２はＲＰＡ１よりもトランザクション処理性能が低く、Ｔｘ２のコミット完了までの時間は、ＲＰＡ１の他のトランザクション処理時間と比較して、長い時間がかかる可能性が高いと考えられる。Ｔｘ２が完了するまでにかかる時間で、処理可能な他のトランザクションを処理することで、ＲＰＡ１の処理効率を高めることができる。そこでＲＰＡ１は、Ｔｘ１のロールバックを実行後、Ｔｘ１の処理をペンディングし、他のリソースを扱うトランザクションを実行する。その後、ＲＰＡ１は、ＲＰＡ２のコミットが完了したことを示すコミット通知を待ってから、Ｔｘ１を再度実行する。

第４のパターンでは、具体的には、ＲＰＡ１から処理完了予告を受信したＲＰＡ２は、Ｔｘ２の処理を継続しつつ、ＰＥＮＤＩＮＧ応答を生成しＲＰＡ１に送信する。このＰＥＮＤＩＮＧ応答を受信するとＲＰＡ１は、Ｔｘ１のロールバックを実行し、ＲＰＡ２からＴｘ２のコミット通知を受信するまでＴｘ１に関する処理を停止する。Ｔｘ１をロールバックした後、ＲＰＡ１はＴｘ２で扱われたリソースを扱わないトランザクションＴｘ３を先に処理する。一方、ＲＰＡ２はＴｘ２の処理が終了し次第、処理完了予告をＲＰＡ１に送信する。そしてＲＰＡ２は、処理完了予告に対するＯＫ応答をＲＰＡ１から受信すると、Ｔｘ２のコミットを実行し、コミット通知をＲＰＡ１に送信する。ＲＰＡ１はコミット通知を受信すると、Ｔｘ２の内容を反映し、Ｔｘ１を再度実行しなおす。

第１のパターンは、さらに、ＯＫ応答を送信したトランザクションにおいて、応答送信後に扱われるリソースに応じて、第１−１のパターンと、第１−２のパターンの２つに分類される。

ＯＫ応答を送信したトランザクションＴｘ２においては、ＯＫ応答送信後に、処理完了予告の送信元のトランザクションＴｘ１で扱われたリソースに対してアクセスが発生する可能性がある。このようなアクセスが、Ｔｘ１のコミット通知の受信後のＴｘ１の内容の反映前に実行されると、不整合が生じる可能性がある。よって実施形態では、このようなアクセスが発生した場合と、そうでない場合とで処理を分ける。以下の説明では、コミット通知とロールバック通知をまとめて処理確定通知と記す場合がある。

第１−１のパターンは、Ｔｘ１に対するＯＫ応答の生成時からＴｘ１の処理確定通知を受信する前までの間に、Ｔｘ２において、Ｔｘ１で扱われたリソースと同じリソースに対するアクセスが発生しない場合の処理のパターンである。ここで以下の説明では、処理確定通知を受信する前とは、処理確定通知がコミット通知の場合には、厳密には、受信した処理確定通知に基づいたトランザクションの反映処理が実行される前までを指す。

図１４は、第１−１のパターンの処理の流れを示す。図１４において、ＲＰＡ１で実行されるトランザクションＴｘ１では、リソースＲ１、Ｒ２に対するアクセスが発生している。そしてＲＰＡ２で実行されるトランザクションＴｘ２では、処理完了予告を受信する前までにリソースＲ３に対するアクセスが発生し、コミット通知を受信した後に、リソースＲ２、Ｒ４に対するアクセスが発生している。ここでは、コミット通知を受信したと同時にＲＰＡ２によるＴｘ１の内容の反映も行われるものとする。よって処理完了予告を受信した時点では、Ｔｘ１とＴｘ２で扱うリソースは異なっている。また、ＯＫ応答の送信後からコミット通知を受信する前までの間に、Ｔｘ２では、Ｔｘ１内で扱われたリソースと同じリソースに対するアクセスが発生していない。

この場合、ＲＰＡ２がＴｘ１の処理完了予告を受信した時点では、トランザクションＴｘ１とコンフリクトするトランザクションは存在しないため、ＲＰＡ２はＯＫ応答を生成し、ＲＰＡ１に送信する。ＯＫ応答を受信したＲＰＡ１は、Ｔｘ１のコミットを実行し、ＲＰＡ２にコミット通知を送信する。コミット通知を受信したＲＰＡ２は、Ｔｘ１に対応するリソースの更新を行う。その後Ｔｘ２では、リソースＲ２、Ｒ４に対するアクセスが発生する。このＲ２、Ｒ４に対するアクセスは、Ｔｘ１に基づくリソースの反映後であるため、そのまま、リソースＲ２、Ｒ４に対するアクセスを行う。ここで、ＲＰＡ２がアクセスするリソースＲ２が、ＲＰＡ１のトランザクションＴｘ１で更新済みのＲ２であることが保障される。

第１−２のパターンは、Ｔｘ１に対するＯＫ応答の生成時からＴｘ１の処理確定通知を受信する前までの間に、Ｔｘ２において、Ｔｘ１で扱われたリソースと同じリソースに対するアクセスが発生する場合の処理のパターンである。

図１５は、第１−２のパターンの処理の流れを示す。図１５では、ＯＫ応答が送信されるまでのＴｘ１とＴｘ２の間の処理は、第１−１のパターンと同様となっている。しかしＯＫ応答を送信してからコミット通知を受信するまでの間に、Ｔｘ２では、Ｔｘ１で扱われたリソースＲ２に対するアクセスが発生している。

この場合、そのままＲ２にアクセスすると不整合が生じる可能性があるため、ＲＰＡ２は、Ｒ２に対するアクセスの直前でＴｘ２を一時停止する。そしてＲＰＡ２は、ＲＰＡ１からＴｘ１のコミット通知を受信した後にＴｘ１に基づくリソースの更新を行ってから、Ｔｘ２を再開し、更新済みのＲ２にアクセスする。このように制御することで、ＯＫ応答の生成時からＴｘ１の処理確定通知を受信する前までの間に発生したＴｘ１で扱われたリソースに対するアクセスにより、データの不整合が発生することを防ぐことができる。

図１６は、実施形態の処理の流れの一例を示す。図１６において、ＡＰサーバ１ｂは、ＤＢサーバに対して、トランザクションの処理を実行している。ＡＰサーバ１ａは、ＡＰサーバ１ｂのトランザクションの開始後に、キャッシュサーバに対してトランザクションの処理を実行している。また、ＡＰサーバ１ａと、ＡＰサーバ１ｂのトランザクションで扱われるリソースはＲ１とＲ２であり、同じリソースである。

図３とは異なり、ＡＰサーバ１ａ、１ｂはともに、キャッシュサーバとＤＢサーバのうち一方に対するトランザクションの処理が終了する毎に、各トランザクションの処理の確定が可能か否かを問い合わせる処理完了予告を送信している。

図１６に示すように、キャッシュサーバは、ＡＰサーバ１ａからのトランザクションが終了すると、処理完了予告をＤＢサーバに送信している。図１６の例の場合、同じリソースＲ１、Ｒ２を扱うＤＢサーバのトランザクションが先に開始されているため、その応答としてＤＢサーバから処理の確定が不可能であることを示す応答を受信している。尚、キャッシュサーバはＤＢサーバよりもトランザクションの処理性能が高いため、ここでは、ＰＥＮＤＩＮＧ応答が返信されている。ＰＥＮＤＩＮＧ応答を受信すると、キャッシュサーバはトランザクションをロールバックする。このように、実施形態では、キャッシュサーバのトランザクションのコンフリクト検出が、ＤＢサーバの処理性能に引きずられて遅延することを防ぐことができる。尚、図１６においては、ＤＢサーバの処理完了予告の送信等の処理は省略して記載している。

次に、実施形態に係るデータ処理装置の構成の詳細について説明する。図１７は、実施形態に係るデータ処理装置の構成の一例を示す。

図１７において、データ処理装置６０は、処理部６１、リソース記憶部６２、制御情報記憶部６３、及び管理部６４を含む。

データ処理装置６０は、データ処理装置２の一例である。処理部６１は、データ処理手段３の一例である。管理部６４は、データ処理管理手段４の一例である。

処理部６１は、トランザクションの処理要求を受信し、受信した処理要求に応じたトランザクションの処理を実行する。

リソース記憶部６２は、リソースを記憶する。リソースは、トランザクションで扱われ処理部６１によりアクセスされるデータである。

制御情報記憶部６３は、トランザクション管理情報、予告管理情報、及び、性能情報を記憶する。トランザクション管理情報は、データ処理装置で実行中のトランザクションと、実行中のトランザクションでアクセスされるリソースを管理するための情報である。予告管理情報は、データ処理装置が受信した処理完了予告についての情報であって、対応するコミット通知またはロールバック通知を未受信の処理完了予告を管理するための情報である。性能情報は、データ処理システム内の全てのデータ処理装置のトランザクションの処理性能を示す情報である。

管理部６４は、検知部６５、予告通知部６６、判定部６７、結果通知部６８、応答部６９、制御部７０、及び通知受信部７１を含む。ここで管理部６４が実行する処理は、自装置で処理が実行されたトランザクション（以下、第１のトランザクションと記す）に関する処理と、他装置で処理が実行されたトランザクション（以下、第２のトランザクションと記す）に関する処理の２つがある。検知部６５、予告通知部６６、判定部６７、及び結果通知部６８は、第１のトランザクションに関するものである。応答部６９、制御部７０、及び通知受信部７１は、第２のトランザクションに関するものである。

検知部６５は検知部５の一例である。予告通知部６６は通知部６の一例である。判定部６７は判定部７の一例である。応答部６９は送信部８の一例である。結果通知部６８は確定通知送信部９の一例である。制御部７０は制御部１０の一例である。

検知部６５は、処理部６１による第１のトランザクションの処理の終了を検知する。
予告通知部６６は、検知部６５が第１のトランザクションの処理の終了を検知した場合に、処理完了予告を他のデータ処理装置の管理部６４にマルチキャストで送信する。処理完了予告は、第１のトランザクションの識別情報、第１のトランザクションの開始時刻、第１のトランザクションでアクセスされた処理対象データの識別情報、及び、第１のトランザクションでアクセスされた処理対象データの更新前後の差分情報を含む。

判定部６７は、予告通知部６６が通知した処理完了予告に対する他のデータ処理装置からの応答に基づいて、第１のトランザクションをコミットするかロールバックするかを判定する。そして判定部６７は、判定結果に応じて第１のトランザクションをコミットまたはロールバックするように処理部６１を制御する。

結果通知部６８は、第１のトランザクションがコミットされたまたはロールバックされたことを示す処理確定通知を他のデータ処理装置にマルチキャストで通知する。すなわち、第１のトランザクションがコミットされた場合、結果通知部６８は、第１のトランザクションがコミットされたことを示すコミット通知を送信する。第１のトランザクションがロールバックされた場合、結果通知部６８は、第１のトランザクションがロールバックされたことを示すロールバック通知を送信する。

応答部６９は、他のデータ処理装置から、他のデータ処理装置で実行された第２のトランザクションに対応する処理完了予告を受信する。すると応答部６９は、受信した処理完了予告、トランザクション管理情報、及び性能情報に基づいて、その処理完了予告に対する応答を生成する。応答の生成の詳細については後ほど説明する。そして応答部６９は、生成した応答を、第２のトランザクションに対応する処理完了予告の送信元にユニキャストで送信する。

制御部７０は、データ処理装置で実行されるトランザクションの状況に応じて、トランザクション管理情報の更新を行う。また、制御部７０は、処理完了予告の受信状況とその処理完了予告に対する応答の種類、及び、処理確定通知の受信状況に応じて、予告管理情報の更新を行う。また制御部７０は、第２のトランザクションに対応する処理完了予告に対する応答を送信してから、第２のトランザクションに対応する処理確定通知を受信するまでの間に、第２のトランザクションでアクセスされたものと同じリソースに対するアクセスを制御する。アクセスの制御については、制御部７０は予告管理情報に基づいて行う。アクセスの制御の詳細については後ほど説明する。

通知受信部７１は、他のデータ処理装置から、第２のトランザクションのコミット通知またはロールバック通知を受信する。コミット通知を受信した場合、通知受信部７１は、第２のトランザクションの処理完了予告の内容に基づいてリソースを更新（コミット）するように処理部６１を制御する。すなわち通知受信部７１は、第２のトランザクションで更新されたリソースの更新後の状態を、自装置の対応するリソースに反映するように処理部６１を制御する。

次に、応答部６９による処理完了予告に対する応答の生成について説明する。上述したように実施形態において応答の種類は、ＯＫ応答、ＲＥＴＲＹ応答、ＰＥＮＤＩＮＧ応答の３種類がある。ＯＫ応答は、第２のトランザクションのコミットが可能であることを示す応答である。ＲＥＴＲＹ応答は、第２のトランザクションのコミットが不可能であることを示し、処理完了予告の送信元に対して、第２のトランザクションのロールバック後の即時リトライを指示する内容を含む応答である。ＰＥＮＤＩＮＧ応答は、第２のトランザクションのコミットが不可能であることを示し、処理完了予告の送信元に対して、第２のトランザクションのロールバックとリトライ開始までの間に他のトランザクションの実行を指示する内容を含む応答である。このような３種類の応答の生成は、処理完了予告、トランザクション管理情報、及び性能情報に基づいて行われる。先ず、トランザクション管理情報と性能情報について説明する。

トランザクション管理情報は、データ処理装置で実行中のトランザクションについての管理情報である。図１８は、トランザクション管理情報の構成の一例を示す。図１８においてトランザクション管理情報は、「トランザクションＩＤ」、「開始時刻」、及び「リソース」のデータ項目を含む。「トランザクションＩＤ」、「開始時刻」、及び「リソース」のデータ項目は、レコード毎に対応付けて記憶される。「トランザクションＩＤ」は、データ処理装置で実行中のトランザクションを一意に識別するための識別情報を示す。「開始時刻」は、トランザクションＩＤで示されるトランザクションの開始時刻を示す。「リソース」は、トランザクションＩＤで示されるトランザクションでアクセスされるリソースの識別情報を示す。尚、一つのトランザクションでアクセスされるリソースは複数であってもよい。

トランザクション管理情報は、制御部７０により管理される。すなわち制御部７０は、処理部６１によりトランザクションが開始されると、開始されたトランザクションについての情報を、トランザクション管理情報に記録する。また制御部７０は、処理部６１によりトランザクションがコミットまたはロールバックされると、そのトランザクションについての情報を、トランザクション管理情報から削除する。

性能情報は、データ処理システム内の全てのデータ処理装置のトランザクションの処理性能を示す情報である。図１９は、性能情報の構成の一例を示す。図１９において性能情報は、「装置ＩＤ」及び「性能値」のデータ項目を含み、「装置ＩＤ」及び「性能値」はレコード毎に対応付けて記憶される。「装置ＩＤ」は、データ処理システムに含まれるデータ処理装置を一意に識別するための識別情報を示す。「性能値」は、「装置ＩＤ」で示されるデータ処理装置の処理部６１のトランザクションの処理性能の値を示す。

次に応答部６９による応答の生成処理の具体的な動作について説明する。応答部６９は、他のデータ処理装置から第２のトランザクションに対応する処理完了予告を受信すると、先ず、第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションが存在するかを判定する。この判定は、受信した処理完了予告とトランザクション管理情報を用いて行われる。

第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションが存在しない場合は、第２のトランザクションと実行中のトランザクションとの間にコンフリクトが起こらない。従ってこの場合、応答部６９は、第２のトランザクションのコミットが可能であることを示すＯＫ応答を生成して、処理完了予告の送信元に返信する。尚この動作は、上記パターン１に対応する動作である。

第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションが存在する場合は、第２のトランザクションと実行中のトランザクションとの間にコンフリクトが発生する。この場合データ処理システムでは、データの不整合の発生を防ぐために、コンフリクトが発生する２つのトランザクションのうち、開始時刻が遅いほうのトランザクションでロールバックが行われるように制御される。このために先ず、応答部６９は、第２のトランザクションと、第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションとの処理開始時刻を比較して、処理開始時刻の遅いトランザクションを特定する。具体的には応答部６９は、処理完了予告から第２のトランザクションの処理開始時刻を取得し、トランザクション管理情報から第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションの処理開始時刻を取得する。そして、取得した２つのトランザクションの開始時刻を比較することによって、応答部６９は処理開始時刻の遅いトランザクションを特定する。

応答部６９は、処理開始時刻の遅いトランザクションは自装置で実行中のトランザクションであると判定すると、ＯＫ応答を生成して、処理完了予告の送信元に返信する。そして応答部６９は、自装置で実行中のトランザクションのロールバックを行い、第２のトランザクションのコミット通知またはロールバック通知を受信してから、ロールバックしたトランザクションをリトライする。尚この動作は、上記パターン２に対応する動作である。

一方、応答部６９は、処理開始時刻の遅いトランザクションは第２のトランザクションであると判定すると、第２のトランザクションのコミットが不可能であることを示すＲＥＴＲＹ応答、もしくは、ＰＥＮＤＩＮＧ応答を生成して、送信する。尚、この場合、自装置で実行中のトランザクションの処理は継続して行われる。

ここで、ＲＥＴＲＹ応答とＰＥＮＤＩＮＧ応答のどちらを生成するかは、自装置と、第２のトランザクションを実行した他のデータ処理装置との間のトランザクション処理性能の大小に基づいて判定される。具体的に応答部６９は、性能情報を参照して、自装置の処理部６１と、第２のトランザクションを実行したデータ処理装置の処理部６１のトランザクション処理性能を比較する。自装置の処理性能が第２のトランザクションを実行したデータ処理装置に対して同等以上の場合、応答部６９は、第２のトランザクションの即時リトライを指示するＲＥＴＲＹ応答を生成して処理完了予告の送信元へ返信する。尚、応答部６９は、ＲＥＴＲＹ応答に、コンフリクトしたトランザクションの識別情報を含ませて生成する。このように即時リトライを指示する理由は、処理性能が高い自装置によって実行されるトランザクションは、短い時間で処理が完了する可能性が高く、即時リトライ時に再びコンフリクトが発生する可能性が低いためである。尚この動作は、上記パターン３に対応する動作である。

一方、自装置の処理性能が第２のトランザクションを実行したデータ処理装置に対して低い場合、応答部６９は、ＰＥＮＤＩＮＧ応答を生成して処理完了予告の送信元へ返信する。ＰＥＮＤＩＮＧ応答は、処理完了予告の送信元に対して、第２のトランザクションのロールバックとリトライ開始までの間に他のトランザクションの実行を指示する内容を含む応答である。このように指示する理由は、処理性能が低い自装置によって実行されるトランザクションは、処理が完了するまでに長い時間がかかる可能性が高く、ロールバック後に即時リトライをした場合に再びコンフリクトが発生する可能性が高いためである。よってロールバックとリトライ開始の間で他のリソースを扱うトランザクションを実行することにより、トランザクションの処理効率を向上させることができる。尚この動作は、上記パターン４に対応する動作である。

具体的には応答部６９は、ＰＥＮＤＩＮＧ応答に、コンフリクトしたトランザクションの識別情報と、コンフリクトしたリソースの識別情報を含ませて生成する。ＰＥＮＤＩＮＧ応答を受信したデータ処理装置は、ＰＥＮＤＩＮＧ応答に含まれるリソースの識別情報に基づいて、コンフリクトしたリソースとは異なるリソースを扱うトランザクションを特定して、そのトランザクションを実行する。

次に制御部７０によるアクセス制御について詳細に説明する。アクセスの制御については、制御部７０は予告管理情報に基づいて行う。先ず予告管理情報の詳細について説明する。

図２０は、予告管理情報の構成の一例を示す。予告管理情報は、「処理完了予告ＩＤ」、及び「リソース」のデータ項目をレコード毎に対応付けて記憶する。「処理完了予告ＩＤ」は、自装置が受信した処理完了予告の識別情報を示す。「リソース」は、処理完了予告に対応するトランザクションで扱われたリソースの識別情報を示す。

予告管理情報は、制御部７０により管理される。すなわち制御部７０は、応答部６９が処理完了予告を受信すると、受信された処理完了予告についての情報を、予告管理情報に記録する。また制御部７０は、他のデータ処理装置からコミット通知またはロールバック通知を受信すると、それらの通知に対応する処理完了予告についての情報を、予告管理情報から削除する。

制御部７０によるアクセス制御は、第２のトランザクションの処理完了予告に対するＯＫ応答を送信してから、第２のトランザクションのコミット通知またはロールバック通知を受信するまでの間で行われる。この間、制御部７０は、第２のトランザクションで扱われたリソースに対するアクセスを一時的に制限する。すなわち制御部７０は、第２のトランザクションで扱われたリソースに対するアクセスが発生したトランザクションの処理を一時停止するように処理部６１を制御する。第２のトランザクションで扱われたリソースに対するアクセスが発生したか否かは、予告管理情報を用いて判定される。そして、第２のトランザクションのコミット通知またはロールバック通知を受信した後に、制御部７０は、アクセスの制限を解除し、一時停止していたトランザクションの処理を再開するように処理部６１を制御する。このようにすることで、ＯＫ応答の送信後に発生する不整合を防ぐことができる。尚この動作は、上記パターン１−２に対応する動作である。尚、コミット通知受信後またはロールバック通知受信後に、第２のトランザクションで扱われたリソースに対するアクセスが発生した場合には、制御部７０はアクセス制御を行わない。

図２１及び図２２は、実施形態に係るデータ処理装置の第１のトランザクションについての処理の詳細を図解したフローチャートの一例（その１、その２）である。

図２１において、先ず処理部６１は、第１のトランザクションの処理要求を受信する（Ｓ１０１）。次に制御部７０は、トランザクション管理情報に、第１のトランザクションについての情報を記録する（Ｓ１０２）。

次に処理部６１は、第１のトランザクションの処理を実行する（Ｓ１０３）。Ｓ１０３では、後ほど図２５を参照して説明するアクセス制御に関する処理が行われる。次に検知部６５は、第１のトランザクションの処理の終了を検知する（Ｓ１０４）。

次に予告通知部６６は、第１のトランザクションに対応する処理完了予告を生成して、他のデータ処理装置にマルチキャストで送信する（Ｓ１０５）。次に判定部６７は、他のデータ処理装置から、Ｓ１０５で送信した処理完了予告に対する応答を受信する（Ｓ１０６）。

次に判定部６７は、Ｓ１０６で受信した応答がＯＫ応答か否かを判定する（Ｓ１０７）。Ｓ１０６で受信した応答がＯＫ応答でないと判定された場合（Ｓ１０７でＮｏ）、処理は、図２２のＳ１１３に遷移する。一方、Ｓ１０６で受信した応答がＯＫ応答であると判定された場合（Ｓ１０７でＹｅｓ）、判定部６７は、処理部６１を制御することにより第１のトランザクションのコミットを実行する（Ｓ１０８）。ここで、コミットが異常終了した場合には、処理部６１は第１のトランザクションをロールバックする。

次に結果通知部６８は、処理部６１により実行されたコミットが正常終了したか否かを判定する（Ｓ１０９）。処理部６１により実行されたコミットが正常終了したと判定した場合（Ｓ１０９でＹｅｓ）、結果通知部６８はコミット通知を他のデータ処理装置に送信する（Ｓ１１０）。一方、処理部６１により実行されたコミットが異常終了したと判定した場合（Ｓ１０９でＮｏ）、結果通知部６８はロールバック通知（図面ではＲＢ通知と記す）を他のデータ処理装置に送信する（Ｓ１１１）。

次に制御部７０は、トランザクション管理情報から、第１のトランザクションについての情報を削除する（Ｓ１１２）。そして処理は終了する。

Ｓ１０７で応答がＯＫ応答でないと判定した場合（Ｓ１０７でＮｏ）、判定部６７は、Ｓ１０６で受信した応答がＲＥＴＲＹ応答か否かを判定する（図２２のＳ１１３）。Ｓ１０６で受信した応答がＲＥＴＲＹ応答でないと判定された場合（Ｓ１１３でＮｏ）、すなわち、受信した応答がＰＥＮＤＩＮＧ応答であると判定された場合、処理は、Ｓ１１７に遷移する。一方、Ｓ１０６で受信した応答がＲＥＴＲＹ応答であると判定された場合（Ｓ１１３でＹｅｓ）、処理部６１は、第１のトランザクションのロールバックを実行する（Ｓ１１４）。ここで、ＲＥＴＲＹ応答に含まれる、第１のトランザクションとコンフリクトしたトランザクションの識別情報は第３のトランザクションを示すものとして説明する。

次に制御部７０は、トランザクション管理情報から、第１のトランザクションについての情報を削除する（Ｓ１１５）。次に制御部７０は、他のデータ処理装置から、第３のトランザクションについてのコミットまたはロールバック通知を受信したか否かを判定する（Ｓ１１６）。第３のトランザクションについてのコミットまたはロールバック通知を受信していないと判定した場合（Ｓ１１６でＮｏ）、制御部７０はＳ１１６の処理を繰り返す。一方、第３のトランザクションについてのコミットまたはロールバック通知を受信したと判定された場合（Ｓ１１６でＹｅｓ）、処理は図２１のＳ１０２に遷移し、再度Ｓ１０２からの第１のトランザクションについての処理が実行される。

Ｓ１１３で応答がＲＥＴＲＹ応答でないと判定された場合（Ｓ１１３でＮｏ）、すなわち、応答はＰＥＮＤＩＮＧ応答であると判定された場合、処理部６１は、第１のトランザクションのロールバックを実行する（Ｓ１１７）。ここで、ＰＥＮＤＩＮＧ応答に含まれる、第１のトランザクションとコンフリクトしたトランザクションの識別情報は第３のトランザクション示すものとして説明する。

次に制御部７０は、トランザクション管理情報から、第１のトランザクションについての情報を削除する（Ｓ１１８）。

次に制御部７０は、第３のトランザクションでアクセスされるリソースを扱わない他のトランザクションを実行するように制御する（Ｓ１１９）。具体的には制御部７０は、ＰＥＮＤＩＮＧ応答から、第３のトランザクションで扱われるリソースの識別情報を取得する。そして制御部７０は、取得した識別情報で示されるリソースを扱わないトランザクションを実行するように処理部６１を制御する。

次に制御部７０は、他のデータ処理装置から、第３のトランザクションについてのコミットまたはロールバック通知を受信したか否かを判定する（Ｓ１２０）。第３のトランザクションについてのコミットまたはロールバック通知を受信していないと判定された場合（Ｓ１２０でＮｏ）、処理はＳ１１９に遷移する。一方、第３のトランザクションについてのコミットまたはロールバック通知を受信したと判定された場合（Ｓ１２０でＹｅｓ）、処理は図２１のＳ１０２に遷移し、再度Ｓ１０２からの第１のトランザクションについての処理が実行される。

図２３及び図２４は、実施形態に係るデータ処理装置の第２のトランザクションについての処理の詳細を図解したフローチャートの一例（その１、その２）である。

図２３において先ず、応答部６９は、他のデータ処理装置から、第２のトランザクションについての処理完了予告を受信する（Ｓ２０１）。

次に応答部６９は、第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションが存在するかを判定する（Ｓ２０２）。具体的には応答部６９は、処理完了予告から、第２のトランザクションでアクセスされた処理対象データの識別情報を取得する。そして応答部６９はトランザクション管理情報を参照し、「リソース」が処理完了予告から取得した識別情報と一致するレコードが存在するか否かを判定する。以下の図の説明においては、第２のトランザクションで扱われるリソースと同じリソースを扱う実行中のトランザクションを、該当トランザクションと記す。

該当トランザクションが存在しないと判定した場合（Ｓ２０２でＮｏ）、応答部６９はＯＫ応答を生成し、処理完了予告の送信元のデータ処理装置にユニキャストで送信する（Ｓ２０３）。ＯＫ応答は、第２のトランザクションのコミットが可能であることを示す情報を含む。

次に制御部７０は、予告管理情報に第２のトランザクションについての情報を記録する（Ｓ２０４）。そして処理は図２４のＳ２１８に遷移する。

Ｓ２０２で該当トランザクションが存在すると判定した場合（Ｓ２０２でＹｅｓ）、応答部６９は、第２のトランザクションよりも前に開始された該当トランザクションが存在するか否かを判定する（Ｓ２０５）。具体的には応答部６９は、処理完了予告から、第２のトランザクションの開始時刻を示す情報を取得する。そして応答部６９はトランザクション管理情報を参照し、該当トランザクションのレコードであって、「開始時刻」が処理完了予告から取得した開始時刻より前の時刻であるレコードが存在するか否かを判定する。

第２のトランザクションよりも前に開始された該当トランザクションが存在すると判定された場合（Ｓ２０５でＹｅｓ）、処理は図２４のＳ２１５に遷移する。一方、第２のトランザクションよりも前に開始された該当トランザクションが存在しないと判定した場合（Ｓ２０５でＮｏ）、応答部６９はＯＫ応答を生成し、処理完了予告の送信元のデータ処理装置にユニキャストで送信する（Ｓ２０６）。

次に制御部７０は、予告管理情報に第２のトランザクションについての情報を記録する（Ｓ２０７）。

次に制御部７０は、処理部６１を制御して、該当トランザクションをロールバックする（Ｓ２０８）。次に制御部７０は、該当トランザクションについての情報を、トランザクション管理情報から削除する（Ｓ２０９）。

次に通知受信部７１は、他のデータ処理装置から第２のトランザクションに対応するコミット通知またはロールバック通知を受信する（Ｓ２１０）。そして通知受信部７１は、受信した通知がコミット通知かロールバック通知かを判定する（Ｓ２１１）。

コミット通知を受信しなかったと判定された場合（Ｓ２１１でＮｏ）、すなわち、ロールバック通知を受信したと判定された場合、処理はＳ２１３に遷移する。一方、コミット通知を受信したと判定された場合（Ｓ２１１でＹｅｓ）、通知受信部７１は、Ｓ２０１で受信した処理完了予告の内容に基づいてリソースを更新するように処理部６１を制御する（Ｓ２１２）。すなわち通知受信部７１は、第２のトランザクションで更新されたリソースの更新後の状態を、自装置の対応するリソースに反映するように処理部６１を制御する。

次に制御部７０は、予告管理情報から、第２のトランザクションについての情報を削除する（Ｓ２１３）。次に制御部７０は、Ｓ２０７でロールバックした該当トランザクションを再実行するように制御する（Ｓ２１４）。そして処理は終了する。

Ｓ２０５で第２のトランザクションよりも前に開始された該当トランザクションが存在すると判定した場合（Ｓ２０５でＹｅｓ）、応答部６９は以下の処理を行う。すなわち応答部６９は、自装置の処理部６１のトランザクション処理性能が、第２のトランザクションを実行したデータ処理装置の処理部６１トランザクション処理性能を下回るか否かを判定する（図２４のＳ２１５）。自装置のトランザクション処理性能が、第２のトランザクションを実行したデータ処理装置の性能以上であると判定した場合（Ｓ２１５でＮｏ）、応答部６９はＲＥＴＲＹ応答を生成し、処理完了予告の送信元のデータ処理装置にユニキャストで送信する（Ｓ２１６）。そして処理はＳ２１８に遷移する。一方、自装置のトランザクション処理性能が、第２のトランザクションを実行したデータ処理装置のトランザクション処理性能を下回ると判定した場合（Ｓ２１５でＹｅｓ）、応答部６９は以下の処理を行う。すなわち応答部６９は、ＰＥＮＤＩＮＧ応答を生成し、処理完了予告の送信元のデータ処理装置にユニキャストで送信する（Ｓ２１７）。ここで、Ｓ２１６、Ｓ２１７の後も該当トランザクションに関する処理は継続して実行される。

次に通知受信部７１は、他のデータ処理装置から第２のトランザクションに対応するコミット通知またはロールバック通知を受信する（Ｓ２１８）。そして通知受信部７１は、受信した通知がコミット通知かロールバック通知かを判定する（Ｓ２１９）。

コミット通知を受信しなかったと判定された場合（Ｓ２１９でＮｏ）、すなわち、ロールバック通知を受信したと判定された場合、処理はＳ２２１に遷移する。一方、コミット通知を受信したと判定された場合（Ｓ２１９でＹｅｓ）、通知受信部７１は、Ｓ２０１で受信した処理完了予告の内容に基づいてリソースを更新するように処理部６１を制御する（Ｓ２２０）。すなわち通知受信部７１は、第２のトランザクションで更新されたリソースの更新後の状態を、自装置の対応するリソースに反映するように処理部６１を制御する。

次に制御部７０は、予告管理情報に第２のトランザクションについての情報が存在する場合には、第２のトランザクションについての情報を削除する（Ｓ２２１）。そして処理は終了する。

図２５は、制御部７０によるアクセス制御の処理の詳細を図解したフローチャートの一例である。この処理は図２１のＳ１０３において、実行される処理である。図２５の説明では、第２のトランザクションに関する処理である、図２３及び図２４のＳ２０３〜Ｓ２２０、及び、Ｓ２０６からＳ２１２の処理の実行中に、所定のトランザクション（第１のトランザクションとして説明する）が実行される場合について説明する。

図２５において先ず、制御部７０は、第１のトランザクションのアクセス対象のリソース（以下、アクセス対象リソースと記す）が、第２のトランザクションで扱われたリソースか否かを判定する（Ｓ３０１）。具体的には制御部７０は、予告管理情報を参照して、アクセス対象リソースと「リソース」が同じであるレコードが存在するか否かを判定する。

アクセス対象リソースが、第２のトランザクションで扱われたリソースでないと判定された場合（Ｓ３０１でＮｏ）、処理はＳ３０３に遷移する。

一方、アクセス対象リソースが、第２のトランザクションで扱われたリソースと同じであると判定された場合（Ｓ３０１でＹｅｓ）、制御部７０は以下の処理を行う。すなわち制御部７０は、第２のトランザクションに対応するコミット通知またはロールバック通知を受信したか否かを判定する（Ｓ３０２）。具体的には制御部７０は、予告管理情報を参照し、アクセス対象リソースと「リソース」が同じである予告管理情報のレコードが存在するか否かを判定する。

第２のトランザクションに対応するコミット通知またはロールバック通知のいずれも受信していないと判定した場合（Ｓ３０２でＮｏ）、制御部７０は再度Ｓ３０２を実行する。

第２のトランザクションに対応するコミット通知またはロールバック通知を受信したと判定した場合（Ｓ３０２でＹｅｓ）、制御部７０は、第１のトランザクションにおいてアクセス対象リソースに対するアクセスを行うように処理部６１を制御する（Ｓ３０３）。そして処理は終了する。

次に、データ処理装置６０のハードウェア構成の一例を説明する。図２６は、実施形態に係るデータ処理装置のハードウェア構成の一例を示す。

図２６において、データ処理装置６０は、Central Processing Unit（ＣＰＵ）８１、メモリ８２、記憶装置８３、読取装置８４、及び通信インターフェース８５を含む。ＣＰＵ８１、メモリ８２、記憶装置８３、読取装置８４、及び通信インターフェース８５はバスを介して接続される。

ＣＰＵ８１は、メモリ８２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、処理部６１及び管理部６４の一部または全部の機能を提供する。

メモリ８２は、例えば半導体メモリであり、Random Access Memory（ＲＡＭ）領域およびRead Only Memory（ＲＯＭ）領域を含んで構成される。記憶装置８３は、例えばハードディスクである。なお、記憶装置８３は、Solid State Drive（ＳＳＤ）やフラッシュメモリ等の半導体メモリであってもよい。また、記憶装置８３は、外部記録装置であってもよい。データ処理装置６０がキャッシュサーバの場合、メモリ８２はリソース記憶部６２、制御情報記憶部６３の一部または全部の機能を提供する。データ処理装置６０がＤＢサーバの場合、メモリ８２は制御情報記憶部６３の一部または全部の機能を提供し、記憶装置８３はリソース記憶部６２の機能の一部または全部を提供する。尚、データ処理装置６０がキャッシュサーバの場合、データは全てメモリ８２上で管理されてもよいし、ＳＳＤやフラッシュメモリ等で管理されてもよい。ここで、キャッシュサーバとＤＢサーバの処理部６１の性能差が発生する主な要因の一つは、キャッシュサーバのデータは通常インメモリ上で管理され、ＤＢサーバのデータは通常オンディスク上で管理されるためである。

読取装置８４は、ＣＰＵ８１の指示に従って着脱可能記憶媒体９０にアクセスする。着脱可能記憶媒体９０は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置８４はデータ処理装置６０に含まれなくてもよい。

通信インターフェース８５は、ＣＰＵ８１の指示に従ってネットワークを介して、他のデータ処理装置、及びトランザクションの要求元の装置（例えばＡＰサーバ）と通信する。

実施形態のプログラムは、例えば、下記の形態でデータ処理装置６０に提供される。
（１）記憶装置８３に予めインストールされている。
（２）着脱可能記憶媒体９０により提供される。
（３）プログラムサーバ（図示せず）から通信インターフェース８５を介して提供される。

さらに、実施形態のデータ処理装置６０の一部は、ハードウェアで実現してもよい。或いは、実施形態のデータ処理装置６０は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

尚、複数のデータ処理装置６０の機能のそれぞれを仮想サーバ等で実行し、一つの情報処理装置内で実行してもよい。

図４のデータ処理装置２は、１マシンにつき１プロセスの構成に限定されず、複数のサーバ群をまとめた論理的な単位としてもよい。すなわち、データ処理装置２（２ａ〜２ｃ）の一部又は全ては、データ処理手段３の機能を提供する１または複数の情報処理装置と、データ処理管理手段４の機能を提供する情報処理装置とを含むシステムとしてもよい。このような構成の一例を以下で説明する。図２７は、実施形態に係るデータ処理システムの構成の一例を示す。

図２７において、データ処理システムは、ＤＣ１とＤＣ２を含む。ＤＣ１とＤＣ２は、ＷＡＮ等の通信ネットワーク等を介して接続される。各ＤＣは、ＡＰサーバ９１（９１ａ〜９１ｂ、９１ｃ〜９１ｄ）、ＤＢサーバ群９２（９２ａ、９２ｂ）、及びキャッシュサーバ群９３（９３ａ、９３ｂ）を含む。各ＤＣ内のＡＰサーバ９１、ＤＢサーバ群９２、及びキャッシュサーバ群９３は、Local Area Network（ＬＡＮ）等の通信ネットワーク等を介して接続される。ここではＤＣ１について説明するが、ＤＣ２についてもＤＣ１と同様である。

ＡＰサーバ９１は、キャッシュサーバ群９２またはＤＢサーバ群９３へアクセスするアプリケーションを実行する。

ＤＢサーバ群９２は、ＤＢサーバ群９２全体で、図１７のデータ処理装置６０の１つに対応する機能を提供する。ＤＢサーバ群９２は、処理部６１及びリソース記憶部６２の機能を提供する１または複数のＤＢサーバ９４（９４ａ）と、制御情報記憶部６３及び管理部６４の機能を提供するＲＰＡサーバ９５（９５ａ）とを含む。

キャッシュサーバ群９３は、キャッシュサーバ群９３全体で、図１７のデータ処理装置６０の１つに対応する機能を提供する。処理部６１及びリソース記憶部６２の機能を提供する１または複数のキャッシュサーバ９６（９６ａ〜９６ｄ）と、制御情報記憶部６３及び管理部６４の機能を提供するＲＰＡサーバ９７（９７ａ）とを含む。キャッシュサーバ９６は、インメモリデータベースとして動作してもよい。例えばキャッシュサーバ９６において、リソース記憶部６２及びＡＰサーバとのトランザクションに関するデータは全てメインメモリ上で管理されてもよい。また、リソース記憶部６２のデータを複製して、それらを複数のキャッシュサーバ９６に分散させて記憶する構成としてもよい。尚、キャッシュサーバ９６は、図２７に示すように、ＡＰサーバ９１からの接続を受け付けてトランザクションを実行するアクティブ側のキャッシュサーバ９６ａ、９６ｂと、アクティブ側のデータのミラーリングを行うミラー側のキャッシュサーバ９６ｃ、９６ｄとが含まれてもよい。

ＤＢサーバ９４、ＲＰＡサーバ９５、キャッシュサーバ９６、及びＲＰＡサーバ９７のそれぞれのハードウェア構成は、図２６に示したものと同様である。ただし、ＤＢサーバ９４において、ＣＰＵ８１は処理部６１の機能を提供し、記憶装置８３はリソース記憶部６２の機能を提供する。また、キャッシュサーバ９６において、ＣＰＵ８１は処理部６１の機能を提供し、メモリ８２はリソース記憶部６２の機能を提供する。また、ＲＰＡサーバ９５、９７において、ＣＰＵ８１は管理部６４の機能を提供し、メモリ８２は制御情報記憶部６３の機能を提供する。

尚、ＤＢサーバ９４、ＲＰＡサーバ９５、キャッシュサーバ９６、及びＲＰＡサーバ９７の一部または全ては、仮想サーバで実現してもよい。また、ＤＢサーバ群９２のＲＰＡサーバ９５の機能（制御情報記憶部６３及び管理部６４の機能）は、同一ＤＣ内の任意のＤＢサーバ９４により提供される構成としてもよい。この場合は、ＲＰＡサーバ９５は同一ＤＣ内になくてもよい。さらに、キャッシュサーバ群９３のＲＰＡサーバ９７の機能（制御情報記憶部６３及び管理部６４の機能）は、同一ＤＣ内の任意のキャッシュサーバ９６により提供される構成としてもよい。この場合、ＲＰＡサーバ９７は同一ＤＣ内になくてもよい。

尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

尚、説明のため、実施形態では、データ処理装置の例としてＤＢサーバとキャッシュサーバを例に説明したが、データ処理装置は所定の機能を提供する情報処理装置としてもよい。例えば、ＤＢサーバに限らず任意のSystem of Record（ＳＯＲ）に対しても同じアプローチを適用できる。また、キャッシュ間、ＳＯＲ間は同一の製品で構成されていなくてもよく、別製品間でも同じアプローチを適用可能である。

１ データ処理システム
２ データ処理装置
３ データ処理手段
４ データ処理管理手段
５ 検知部
６ 通知部
７ 判定部
８ 送信部
９ 確定通知送信部
１０ 制御部
６０ データ処理装置
６１ 処理部
６２ リソース記憶部
６３ 制御情報記憶部
６４ 管理部
６５ 検知部
６６ 予告通知部
６７ 判定部
６８ 結果通知部
６９ 応答部
７０ 制御部
７１ 通知受信部
８１ ＣＰＵ
８２ メモリ
８３ 記憶装置
８４ 読取装置
８５ 通信インターフェース
９０ 着脱可能記憶媒体

Claims (8)

1. データ処理手段と、前記データ処理手段に対応づけられて動作するデータ処理管理手段を有するデータ処理装置を複数備え、各データ処理装置の前記データ処理手段が連動してデータの更新を行うデータ処理システムにおける、第１のデータ処理装置である情報処理装置であって、
   前記データ処理管理手段は、
   対応するデータ処理手段への第１の処理要求に対する第１の処理の完了を検知する検知部と、
   前記検知に応じて、前記第１のデータ処理装置内または他のデータ処理装置の他のデータ処理管理手段それぞれに対し、前記第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知する通知部と、
   前記他のデータ処理管理手段それぞれからの前記第１の処理完了予告に対する応答内容に基づき、前記第１の処理の確定可否を判定する判定部と、
   前記他のデータ処理管理手段のいずれかから第２の処理完了予告を受信した場合は、対応するデータ処理手段において、前記第２の処理完了予告から特定される処理開始時刻より前に前記対応するデータ処理手段で開始された処理それぞれが、前記第２の処理完了予告から特定される処理対象データを処理対象としているか否か、および、前記第１のデータ処理装置が有する前記第２の処理完了予告を送付したデータ処理管理手段に対応する処理手段の性能情報に基づき、前記第２の処理完了予告に対する応答を生成し送信する送信部と、
   を有することを特徴とする情報処理装置。
2. 前記通知部は、前記第１の処理完了予告を通知する際に、マルチキャスト通信を利用する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記他のデータ処理管理手段より、前記第１の処理完了予告から特定される前記第１の処理の処理開始時刻より前に、前記他のデータ処理装置において開始された処理のいずれかが、前記第１の処理完了予告から特定される処理対象データを処理対象としていることが通知された場合、前記判定部は、さらに、該処理対象データを前記第１の処理の開始前の状態に戻すように前記対応するデータ処理手段を制御する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記他のデータ処理管理手段より、前記第１の処理完了予告から特定される前記第１の処理の処理開始時刻より前に、前記他のデータ処理装置において開始された処理のいずれかが、前記第１の処理完了予告から特定される処理対象データを処理対象としており、前記対応するデータ処理手段の性能が、前記他のデータ処理装置内のデータ処理手段の性能以上であることが通知された場合、前記判定部は、さらに、前記処理対象データを前記第１の処理の開始前の状態に戻し、前記第２の処理の処理対象データとは異なるデータを処理対象とする第３の処理を実行した後に、前記第１の処理を再実行するように前記対応するデータ処理手段を制御する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記データ処理管理手段は、さらに、
   前記第１の処理が確定可能であると判定された場合、前記第１の処理の確定処理を行うように前記データ処理手段を制御し、前記他のデータ処理管理手段に対して、前記第１の処理が確定されたことを示す確定通知を送信する確定通知送信部と、
   前記対応するデータ処理手段において、前記第２の処理完了予告から特定される処理開始時刻より前に開始された処理のそれぞれが、前記第２の処理完了予告から特定される処理対象データを処理対象としていない場合、前記第２の処理完了予告に対する応答を送信した後に前記第２の処理完了予告から特定される処理対象データに対するアクセス要求が発生すると、前記第２の処理に対応する前記確定通知を受信して前記第２の処理の確定処理を実行した後にアクセスするように前記対応するデータ処理手段を制御する制御部と、
   を有することを特徴とする請求項１〜４のうちいずれか１項に記載の情報処理装置。
6. データ処理手段と、前記データ処理手段に対応づけられて動作するデータ処理管理手段を有するデータ処理装置を複数備え、各データ処理装置の前記データ処理手段が連動してデータの更新を行うデータ処理システムであって、
   第１のデータ処理装置の第１のデータ処理管理手段は、
   前記第１のデータ処理管理手段に対応する第１のデータ処理手段への第１の処理要求に対する第１の処理の完了を検知し、
   前記検知に応じて、前記第１のデータ処理装置内または他のデータ処理装置の他のデータ処理管理手段それぞれに対し、前記第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知し、
   前記他のデータ処理管理手段それぞれからの前記第１の処理完了予告に対する応答内容に基づき、前記第１の処理の確定可否を判定し、
   第２のデータ処理装置の第２のデータ処理管理手段は、
   前記第１のデータ処理管理手段から前記第１の処理完了予告を受信した場合は、前記第２のデータ処理管理手段に対応する第２のデータ処理手段において、前記第１の処理完了予告から特定される処理開始時刻より前に前記第２のデータ処理手段で開始された処理それぞれが、前記第１の処理完了予告から特定される処理対象データを処理対象としているか否か、および、前記第２のデータ処理装置が有する前記第１のデータ処理手段の性能情報に基づき、前記第１の処理完了予告に対する応答を生成し送信する
   ことを特徴とする情報処理システム。
7. データ処理手段と、前記データ処理手段に対応づけられて動作するデータ処理管理プログラムを有するデータ処理装置を複数備え、各データ処理装置の前記データ処理手段が連動してデータの更新を行うデータ処理システムにおける、第１のデータ処理装置で実行されるデータ処理管理プログラムであって、
   対応するデータ処理手段への第１の処理要求に対する第１の処理の完了を検知し、
   前記検知に応じて、前記第１のデータ処理装置内または他のデータ処理装置の他のデータ処理管理プログラムそれぞれに対し、前記第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知し、
   前記他のデータ処理管理プログラムそれぞれからの前記第１の処理完了予告に対する応答内容に基づき、前記第１の処理の確定可否を判定し、
   前記他のデータ処理管理プログラムのいずれかから第２の処理完了予告を受信した場合は、対応するデータ処理手段において、前記第２の処理完了予告から特定される処理開始時刻より前に前記対応するデータ処理手段で開始された処理それぞれが、前記第２の処理完了予告から特定される処理対象データを処理対象としているか否か、および、前記第１のデータ処理装置が有する前記第２の処理完了予告を送付したデータ処理管理プログラムに対応する処理手段の性能情報に基づき、前記第２の処理完了予告に対する応答を生成し送信する
   処理をコンピュータに実行させることを特徴とするデータ処理管理プログラム。
8. データ処理手段と、前記データ処理手段に対応づけられて動作するデータ処理管理手段を有するデータ処理装置を複数備え、各データ処理装置の前記データ処理手段が連動してデータの更新を行うデータ処理システムにおける、第１のデータ処理装置で実行されるデータ処理管理方法であって、
   前記データ処理管理手段は、
   対応するデータ処理手段への第１の処理要求に対する第１の処理の完了を検知し、
   前記検知に応じて、前記第１のデータ処理装置内または他のデータ処理装置の他のデータ処理管理プログラムそれぞれに対し、前記第１の処理の処理開始時刻、および、処理対象データに関する情報を含む第１の処理完了予告を通知し、
   前記他のデータ処理管理プログラムそれぞれからの前記第１の処理完了予告に対する応答内容に基づき、前記第１の処理の確定可否を判定し、
   前記他のデータ処理管理プログラムのいずれかから第２の処理完了予告を受信した場合は、対応するデータ処理手段において、前記第２の処理完了予告から特定される処理開始時刻より前に前記対応するデータ処理手段で開始された処理それぞれが、前記第２の処理完了予告から特定される処理対象データを処理対象としているか否か、および、前記第１のデータ処理装置が有する前記第２の処理完了予告を送付したデータ処理管理プログラムに対応する処理手段の性能情報に基づき、前記第２の処理完了予告に対する応答を生成し送信する
   処理を実行することを特徴とするデータ処理管理方法。
   

Images