(57)【要約】【課題】コモディティ・ハードウェアを、少なくとも、データベースに対するフロント・エンドとして作用するように利用することができるシステムを提供する。【解決手段】  トランザクションが以前にコミットされたことがあるか否か追跡するために、別個のテーブルを設ける。好ましくは、この別個のステートレス・プロトコル（ＳＴＰ）テーブルは、ユーザに関するインデックス、および個々の要求に関するインデックスを利用して、個々のトランザクションが以前にコミットされたことがあるか否か判定を行う。トランザクションをプライマリ・トランザクション・データベースに供給するのに先だってこのテーブルを調査することにより、トランザクションが以前にコミットされたことがあるか否か判定を行うことができる。コミットされたことがある場合、ＳＴＰテーブルに格納されている応答を単に供給する。コミットされたことがない場合、トランザクションをコミットし、このコミットメントを示すために、ＳＴＰテーブルにエントリを作る。好適な実施形態では、同一のトランザクションによって、プライマリ・トランザクション・データベース・テーブルへの入力と、ＳＴＰテーブル内への入力がコミットされる。【選択図】      図１
2009505223.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する方法であって、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
コミットするために新しいトランザクションを前記データベースに供給し、トランザクション応答を受信するステップと、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と、前記トランザクション応答とを前記テーブルに供給し、応答を受信するステップと、
前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給したときに成功応答を受信した場合、前記データベースへの前記新しいトランザクション、ならびに前記テーブルへの前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットするステップと、
コミットした後、前記クライアントに伝達するために、前記トランザクション応答を供給するステップと、
を備えている、方法。
【請求項２】
請求項１記載の方法において、前記新しいトランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値とに基づく、方法。
【請求項３】
請求項２記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。
【請求項４】
請求項２記載の方法において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、方法。
【請求項５】
請求項４記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。
【請求項６】
請求項２記載の方法において、前記新しいトランザクションを識別する値を前記テーブルに供給するステップは、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行うステップと、
このようなトランザクションがある場合、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを更新動作において供給するステップと、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを挿入動作において供給するステップと、
を含む、方法。
【請求項７】
請求項１記載の方法であって、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作をロール・バックするステップと、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作をロール・バックするステップと、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントに伝達するためにエラー応答を供給するステップと、
を備えている、方法。
【請求項８】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する方法であって、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
クライアントから新しいトランザクションを受信するステップと、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給しないステップと、
を備えている、方法。
【請求項９】
請求項８記載の方法であって、更に、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記クライアントに伝達するために、前記テーブルにおける前記トランザクションと関連がある応答を供給するステップを備えている、方法。
【請求項１０】
請求項８記載の方法において、前記トランザクションを識別する値は、前記ユーザを識別する値と、前記新しいトランザクションにおけるデータを識別する値とに基づく、方法。
【請求項１１】
請求項１０記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。
【請求項１２】
請求項１０記載の方法において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、方法。
【請求項１３】
請求項１２記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。
【請求項１４】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する方法であって、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
クライアントから新しいトランザクションを受信するステップと、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給せずに、前記クライアントに伝達するために、前記テーブルにおける前記トランザクションと関連がある応答を供給するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がない場合、コミットさせるために前記新しいトランザクションを前記データベースに供給し、トランザクション応答を受信するステップと、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給し、応答を受信するステップと、
前記新しいトランザクションを識別する値および前記テーブルに対する前記トランザクション応答を供給したときに成功応答を受信した場合、前記データベースに対する前記新しいトランザクション、ならびに前記テーブルに対する前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットするステップと、
コミットした後、前記クライアントに伝達するために、前記トランザクション応答を供給するステップと、
を備えている、方法。  
【請求項１５】
請求項１４記載の方法において、前記トランザクションを識別する値は、前記ユーザを識別する値と、前記新しいトランザクションにおけるデータを識別する値とに基づく、方法。
【請求項１６】
請求項１５記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。
【請求項１７】
請求項１５記載の方法において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、方法。
【請求項１８】
請求項１７記載の方法において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、方法。  
【請求項１９】
請求項１５記載の方法において、前記新しいトランザクションを識別する値を前記テーブルに供給するステップは、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行うステップと、
このようなトランザクションがある場合、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを更新動作において供給するステップと、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを挿入動作において供給するステップと、
を含む、方法。
【請求項２０】
請求項１４記載の方法であって、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作をロール・バックするステップと、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作をロール・バックするステップと、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントに伝達するためにエラー応答を供給するステップと、
を備えている、方法。
【請求項２１】
クライアントとの通信を実行するフロント・エンド・モジュールによって、前記クライアントからデータベースへのトランザクションの二重コミットメントを防止するシステムであって、  
コモディティ・サーバに結合され、前記フロント・エンド・モジュールに結合されているデータベース・コード・モジュールと、該データベース・コード・モジュールに結合されているデータベースとを含む、データベース・サーバを備えており、
前記データベースは、コミットしたトランザクションを追跡するためのテーブルを含み、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含み、
前記データベース・コード・モジュールは、
コミットするために新しいトランザクションを前記データベースに供給し、トランザクション応答を受信し、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と、前記トランザクション応答とを前記テーブルに供給し、更に応答を受信し、
前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給したときに成功応答を受信した場合、前記データベースへの前記新しいトランザクション、ならびに前記テーブルへの前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットし、
コミットした後、前記フロント・エンド・モジュールに伝達するために、前記トランザクション応答を供給する、システム。
【請求項２２】
請求項２１記載のシステムにおいて、前記データベース・サーバはコモディティ・サーバである、システム。
【請求項２３】
請求項２１記載のシステムにおいて、前記データベース・サーバは、メインフレーム、NonStopサーバ、またはOracleクラスタの内の１つである、システム。
【請求項２４】
請求項２１記載のシステムであって、更に、
前記クライアントに結合し、該クライアントから新しいトランザクションを受信するコモディティ・サーバを備えており、該コモディティ・サーバは、前記フロント・エンド・モジュールを含み、前記データベース・サーバに結合されている、システム。
【請求項２５】
請求項２１記載のシステムにおいて、複数のクライアントがあり、前記システムは、更に、
前記複数のクライアントに結合し、該複数のクライアントから新しいトランザクションを受信する複数のコモディティ・サーバを備えており、該複数のコモディティ・サーバの各々は、前記複数のクライアントの少なくとも一部と通信を実行するフロント・エンド・モジュールを含み、前記複数のクライアントは、前記複数のコモディティ・サーバ間に分散されており、
前記データベース・サーバは、前記複数のコモディティ・サーバの各々に結合されており、前記データベース・コード・モジュールが前記フロント・エンド・モジュールの各々に結合されている、システム。
【請求項２６】
請求項２１記載のシステムにおいて、前記新しいトランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値とに基づく、システム。
【請求項２７】
請求項２６記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項２８】
請求項２６記載のシステムにおいて、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、システム。
【請求項２９】
請求項２８記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項３０】
請求項２６記載のシステムにおいて、前記新しいトランザクションを識別する値を前記テーブルに供給する際に、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行い、
このようなトランザクションがある場合、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを更新動作において供給し、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを挿入動作において供給する、システム。
【請求項３１】
請求項２５記載のシステムにおいて、前記データベース・コード・モジュールは、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作をロール・バックし、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作のロール・バックを要求し、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントにエラー応答を供給する、システム。
【請求項３２】
クライアントとの通信を実行するフロント・エンド・モジュールによって、前記クライアントからデータベースへのトランザクションの二重コミットメントを防止するシステムであって、  
コモディティ・サーバに結合され、前記フロント・エンド・モジュールに結合されているデータベース・コード・モジュールと、該データベース・コード・モジュールに結合されているデータベースとを含む、データベース・サーバを備えており、
前記データベースは、コミットしたトランザクションを追跡するためのテーブルを含み、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含み、
前記データベース・コード・モジュールは、
クライアントから新しいトランザクションを受信し、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較し、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給しない、システム。
【請求項３３】
請求項３２記載のシステムにおいて、前記データベース・コード・モジュールは、更に、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記フロント・エンド・モジュールに伝達するために、前記テーブルにおける前記トランザクションと関連がある応答を供給する、システム。
【請求項３４】
請求項３２記載のシステムにおいて、前記新しいトランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値とに基づく、システム。
【請求項３５】
請求項３４記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項３６】
請求項３４記載のシステムにおいて、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、システム。
【請求項３７】
請求項３６記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項３８】
請求項３２記載のシステムであって、更に、
前記クライアントに結合し、該クライアントから新しいトランザクションを受信するコモディティ・サーバを備えており、該コモディティ・サーバは、前記フロント・エンド・モジュールを含み、前記データベース・サーバに結合されている、システム。
【請求項３９】
請求項３２記載のシステムにおいて、複数のクライアントがあり、前記システムは、更に、
前記複数のクライアントに結合し、該複数のクライアントから新しいトランザクションを受信する複数のコモディティ・サーバを備えており、該複数のコモディティ・サーバの各々は、前記複数のクライアントの少なくとも一部と通信を実行するフロント・エンド・モジュールを含み、前記複数のクライアントは、前記複数のコモディティ・サーバ間に分散されており、
前記データベース・サーバは、前記複数のコモディティ・サーバの各々に結合されており、前記データベース・コード・モジュールが前記フロント・エンド・モジュールの各々に結合されている、システム。
【請求項４０】
クライアントとの通信を実行するフロント・エンド・モジュールによって、前記クライアントからデータベースへのトランザクションの二重コミットメントを防止するシステムであって、  
コモディティ・サーバに結合され、前記フロント・エンド・モジュールに結合されているデータベース・コード・モジュールと、該データベース・コード・モジュールに結合されているデータベースとを含む、データベース・サーバを備えており、
前記データベースは、コミットしたトランザクションを追跡するためのテーブルを含み、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含み、
前記データベース・コード・モジュールは、
クライアントから新しいトランザクションを受信し、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較し、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給せず、前記クライアントに前記テーブルにおける前記トランザクションと関連がある応答を供給し、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がない場合、コミットさせるために前記新しいトランザクションを前記データベースに供給し、トランザクション応答を受信し、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と、前記トランザクション応答とを前記テーブルに供給し、更に応答を受信し、
前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給したときに成功応答を受信した場合、前記データベースへの前記新しいトランザクション、ならびに前記テーブルへの前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットし、
コミットした後、前記フロント・エンド・モジュールに伝達するために、前記トランザクション応答を供給する、システム。
【請求項４１】
請求項４０記載のシステムにおいて、前記トランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値とに基づく、システム。
【請求項４２】
請求項４１記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項４３】
請求項４１記載のシステムにおいて、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、システム。
【請求項４４】
請求項４３記載のシステムにおいて、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、システム。
【請求項４５】
請求項４１記載のシステムにおいて、前記新しいトランザクションを識別する値を前記テーブルに供給する際に、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行い、
このようなトランザクションがある場合、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを更新動作において供給し、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを挿入動作において供給する、システム。
【請求項４６】
請求項４０記載のシステムにおいて、前記データベース・コード・モジュールは、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作のロール・バックを要求し、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作のロール・バックを要求し、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントに伝達するためにエラー応答を供給する、システム。
【請求項４７】
請求項４０記載のシステムであって、更に、
前記クライアントに結合し、該クライアントから新しいトランザクションを受信するコモディティ・サーバを備えており、該コモディティ・サーバは、前記フロント・エンド・モジュールを含み、前記データベース・サーバに結合されている、システム。
【請求項４８】
請求項４０記載のシステムにおいて、複数のクライアントがあり、前記システムは、更に、
前記複数のクライアントに結合し、該複数のクライアントから新しいトランザクションを受信する複数のコモディティ・サーバを備えており、該複数のコモディティ・サーバの各々は、前記複数のクライアントの少なくとも一部と通信を実行するフロント・エンド・モジュールを含み、前記複数のクライアントは、前記複数のコモディティ・サーバ間に分散されており、
前記データベース・サーバは、前記複数のコモディティ・サーバの各々に結合されており、前記データベース・コード・モジュールが前記フロント・エンド・モジュールの各々に結合されている、システム。
【請求項４９】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する以下の方法を実行するアプリケーションのコンピュータ実行可能命令を、格納した１つ以上のコンピュータ読み取り可能媒体であって、前記方法は、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
コミットするために新しいトランザクションをデータベースに供給し、トランザクション応答を受信するステップと、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と、前記トランザクション応答とを前記テーブルに供給し、応答を受信するステップと、
前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給したときに成功応答を受信した場合、前記データベースへの前記新しいトランザクション、ならびに前記テーブルへの前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットするステップと、
コミットした後、前記クライアントに伝達するために、前記トランザクション応答を供給するステップと、
を備えている、１つ以上のコンピュータ読み取り可能媒体。
【請求項５０】
請求項４９記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値とに基づく、１つ以上のコンピュータ読み取り可能媒体。
【請求項５１】
請求項５０記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項５２】
請求項５０記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項５３】
請求項５２記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項５４】
請求項５０記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションを識別する値を前記テーブルに供給するステップは、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行うステップと、
このようなトランザクションがある場合、前記新しいトランザクションにおけるデータを識別する値と、前記トランザクション応答とを更新動作において供給するステップと、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおけるデータを識別する値と、前記トランザクション応答とを挿入動作において供給するステップと、
を含む、１つ以上のコンピュータ読み取り可能媒体。
【請求項５５】
請求項４９記載の１つ以上のコンピュータ読み取り可能媒体において、前記方法は、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作をロール・バックするステップと、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作をロール・バックするステップと、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントに伝達するためにエラー応答を供給するステップと、
を備えている、１つ以上のコンピュータ読み取り可能媒体。
【請求項５６】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する以下の方法を実行するアプリケーションのコンピュータ実行可能命令を格納した１つ以上のコンピュータ読み取り可能媒体であって、前記方法は、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
クライアントから新しいトランザクションを受信するステップと、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給しないステップと、
を備えている、１つ以上のコンピュータ読み取り可能媒体。
【請求項５７】
請求項５６記載の１つ以上のコンピュータ読み取り可能媒体において、前記方法は、更に、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記クライアントに伝達するために、前記テーブルにおける前記トランザクションと関連がある応答を供給するステップを備えている、１つ以上のコンピュータ読み取り可能媒体。
【請求項５８】
請求項５６記載の１つ以上のコンピュータ読み取り可能媒体において、前記トランザクションを識別する値は、前記ユーザを識別する値と、前記新しいトランザクションにおけるデータを識別する値とに基づく、１つ以上のコンピュータ読み取り可能媒体。
【請求項５９】
請求項５８記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項６０】
請求項５８記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項６１】
請求項６０記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項６２】
クライアントからデータベースへのトランザクションの二重コミットメントを防止する以下の方法を実行するアプリケーションのコンピュータ実行可能命令を格納した１つ以上のコンピュータ読み取り可能媒体であって、前記方法は、
コミットされたトランザクションを追跡するためのテーブルを用意するステップであって、該テーブルは、前記トランザクションを識別する値のエントリと、前記トランザクションをコミットする応答を示す値のエントリとを含む、ステップと、
クライアントから新しいトランザクションを受信するステップと、
前記テーブルにおいてトランザクションを識別する値のエントリと、前記新しいトランザクションを識別する値のエントリとを比較するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がある場合、前記データベースに対してコミットさせる前記新しいトランザクションを供給せずに、前記クライアントに伝達するために、前記テーブルにおける前記トランザクションと関連がある応答を供給するステップと、
前記新しいトランザクションを識別する値と、前記テーブルにおいてトランザクションを識別する値との間に一致がない場合、コミットさせるために前記新しいトランザクションを前記データベースに供給し、トランザクション応答を受信するステップと、
前記新しいトランザクションを供給したときに成功応答を受信した場合、前記新しいトランザクションを識別する値と前記トランザクション応答とを前記テーブルに供給し、応答を受信するステップと、
前記新しいトランザクションを識別する値および前記テーブルに対する前記トランザクション応答を供給したときに成功応答を受信した場合、前記データベースに対する前記新しいトランザクション、ならびに前記テーブルに対する前記新しいトランザクションを識別する値および前記トランザクション値の双方をコミットするステップと、
コミットした後、前記クライアントに伝達するために、前記トランザクション応答を供給するステップと、
を備えている、１つ以上のコンピュータ読み取り可能媒体。  
【請求項６３】
請求項６２記載の１つ以上のコンピュータ読み取り可能媒体において、前記トランザクションを識別する値は、ユーザを識別する値と、前記新しいトランザクションにおけるデータを識別する値とに基づく、１つ以上のコンピュータ読み取り可能媒体。
【請求項６４】
請求項６３記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項６５】
請求項６３記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションにおける前記データを識別する値は、前記データにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。
【請求項６６】
請求項６５記載の１つ以上のコンピュータ読み取り可能媒体において、前記ユーザを識別する値は、ユーザ識別、前記データベースにおいて要求したテーブル、および前記データベースにおいて要求したカラムにおけるハッシュである、１つ以上のコンピュータ読み取り可能媒体。  
【請求項６７】
請求項６３記載の１つ以上のコンピュータ読み取り可能媒体において、前記新しいトランザクションを識別する値を前記テーブルに供給するステップは、
前記新しいトランザクションのユーザを識別する値と同一である前記ユーザを識別する値を有するトランザクションがあるか否か判定を行うステップと、
このようなトランザクションがある場合、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを更新動作において供給するステップと、
このようなトランザクションがない場合、前記ユーザを識別する値と、前記新しいトランザクションにおける前記データを識別する値と、前記トランザクション応答とを挿入動作において供給するステップと、
を含む、１つ以上のコンピュータ読み取り可能媒体。
【請求項６８】
請求項６２記載の１つ以上のコンピュータ読み取り可能媒体において、前記方法は、更に、
前記新しいトランザクションを供給したときに前記受信した応答が不成功である場合、前記データベースにおける前記トランザクション動作をロール・バックするステップと、
前記新しいトランザクションを識別する値および前記トランザクション応答を供給したときに前記受信した応答が不成功である場合、前記テーブルに対する前記動作および前記データベースにおける前記トランザクション動作をロール・バックするステップと、
いずれかのロール・バックが発生した場合、ロール・バックした後に前記クライアントに伝達するためにエラー応答を供給するステップと、
を備えている、１つ以上のコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願に対する相互引用）
本願は、２００５年８月８日に出願した、Daniel B. GrayおよびPaul Buschによる"Transaction Protection Using Commodity Servers"（コモディティ・サーバを用いたステートレス・アーキテクチャにおけるトランザクション保護）と題する米国仮特許出願第６０／７０６，３３４号、および２００５年１１月１１日に出願した米国特許出願第１１／２７２，３７５号の優先権を、３５Ｕ．Ｓ．Ｃ§１１９（ｅ）に基づいて主張する。
（発明の分野）
本発明は、ネットワーク上で提供されるトランザクションに関し、更に特定すれば、ネットワーク上で供給されるこれらのトランザクションの信頼性の高い記憶に関する。
【背景技術】
【０００２】
インターネット上でのトランザクションは急速に増大しつつある。ショッピング・サイトがトランザクションを利用するだけでなく、他の多くのサイトも同様に利用してデータを提供および維持している。しかしながら、インターネットのようなネットワーク上で遂行されるトランザクションに伴う問題の１つに、トランザクション・プロセス自体の信頼性がある。多くの場合、トランザクションが２回ポスト(post)されるのを許容することは容認できない。これは、トランザクションが実際にポストされたが、クライアントまたは発信元がポストされた応答を全く受信しないためにトランザクションを繰り返す場合に、起こる可能性がある。この問題のために、二重ポスティングを防止する精巧な技法が開発されているが、高価で精巧なコンピュータ・ハードウェアが必要となることが多い。
【０００３】
一般に、トランザクション毎に完全な状態追跡を実行して、応答またはその他の通信が多少なりとも失われた場合には、トランザクションの正確な状態を判定できるようにすることが必要であると考えられている。しかしながら、このためには、クライアントおよびサーバ・エンド双方によって状態を維持することが必要となる。
【０００４】
代替案を１つあげるとすれば、エラー検出後クライアントがいずれのトランザクションをも再提出するステートレス環境(stateless environment)であろう。しかしながら、ステートレス環境では、先に論じた二重ポスティングの問題が増大する。これらの場合、信頼性を高めるためには、トランザクションおよびデータベースを、同じ論理ユニット、個々のユニットまたはクラスタ上に位置付けることが好ましい。システムの例には、Hewlett-Packard NonStopサーバおよびOracleクラスタ等、種々のメインフレームが含まれる。これに伴う問題は、これらのシステムが非常に高価となることである。これは、システムが大きくなる程悪化する。サーバを２つの部分、即ち、トランザクション・フロント・エンドとデータベース・バック・エンドとに分離することによって、いくらかのコスト削減を得ることができる。しかし、これらの部分も双方共、要求される信頼性を有するためには、先に羅列したようなクラスタ化システムまたは冗長システムでなければならないので、コスト削減は必ずしも非常に大きくはない。
【０００５】
これは、Intelアーキテクチャを用いて構築し、LinuxまたはWindowsのような信頼性のないオペレーティング・システム即ちノン・フォールト・トレラント・オペレーティング・システムを走らせる、コモディティ・サーバ(commodity server)とは対照的である。しかし、MySQL、PostgresまたはSQLサーバのような、スケーラビリティが劣るノン・フォールト・トレラント・データベースを走らせるLinuxおよびWindowsのコモディティ・ハードウェア・システムは、信頼性が高いトランザクション・システムを扱うのに必要な形式のデータ保全性を全く提供することができない。したがって、唯一の実用的な代案は、トランザクション信頼性があるステートレス・アーキテクチャ(stateless architecture)を断念して、容認できないようなその他の技法を用いること、あるいは高価なハードウェア環境を利用することのいずれかであった。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
高信頼性を維持し、トランザクションの重複を排除しつつ、コストを抑えてスループット向上を可能にするために、安価なハードウェアを用いたステートレス・アーキテクチャにおいてトランザクションの信頼性の高いコミットメント(commitment)を実行することができれば、望ましいであろう。
【課題を解決するための手段】
【０００７】
本発明によるシステムでは、ステートレス・アーキテクチャにおけるトランザクション・コミットメントの信頼性を維持しつつ、コモディティ・ハードウェアを、データベース・システムに対するフロント・エンドとして作用するように利用することができる。本発明によるシステムは、別個のテーブルを利用して、個々のトランザクションを追跡し、個々のトランザクションが既にプライマリ・トランザクション・データベースに対してコミットされたことがあるか否か判定を行う。好ましくは、この別個のテーブル、即ち、ステートレス・トランザクション・プロトコル（ＳＴＰ）テーブルは、ユーザおよび個々の要求双方に関するインデックスを利用して、個々のトランザクションが既にコミットされたことがあるか否か、そして当該トランザクションに対して応答が供給されているか否か判定を行う。プライマリ・トランザクション・データベースに対していずれのトランザクションを実際に開始する前にこのテーブルを調査することによって、プライマリ・トランザクション・データベースに対してトランザクションが既にコミットされたことがあるか否か判定を行うことができる。コミットされたことがある場合、ＳＴＰテーブルに格納されている応答を単に供給するだけで、元のトランザクションはもはや不要となる。しかしながら、コミットされたことがない場合、トランザクションをコミットし、このコミットメントを示すために、ＳＴＰテーブルにエントリを作る。好適な実施形態では、同一のトランザクションによるプライマリ・トランザクション・データベース・テーブルへの入力と、ＳＴＰテーブル内への入力が保護され、こうして潜在的な乱調状態(race condition)を軽減する。
【０００８】
この別個のテーブルを利用してトランザクションの以前のコミットメントを追跡することによって、信頼性は低くなるが極めて安価なコモディティ・サーバ・ハードウェアを、少なくとも、クライアントに接続するフロント・エンドとして利用して、コンピュータ・システムの全体的なコストを削減することが可能となる。実施形態の中には、従来技術におけるようなメインフレームまたは同様の機器の代わりに、データベース・サーバ自体が、コモディティ・データベースを備えたコモディティ・サーバとなることもできる場合がある。
【発明を実施するための最良の形態】
【０００９】
図１Ａは、従来技術のトランザクション・データベース・システムの図である。クライアント１００がメインフレーム／NonStopサーバ／Oracleクラスタ１０２に接続されている（以後、簡略化のために単にメインフレームと呼ぶ）。メインフレーム１０２内部で走るソフトウェアには、トランザクション・フロント・エンド・モジュール１０４、データベース・コード・モジュール１０５、およびメインフレーム・データベース、ＳＱＬ／ＭＸ、またはOracleのようなデータベース１０６（以後、メインフレーム・データベース）１０６を含む。データベース１０６は、トランザクションに関連のあるデータ・テーブル１０７を収容する。クライアント１００は、通信の目的のために、トランザクション・フロント・エンド・モジュール１０４と通信を行い、次いで、トランザクション・フロント・エンド・モジュール１０４は、データベース・コード・モジュール１０５と通信する。一方、データベース・コード・モジュール１０５は、データベース１０６と通信して、実際にトランザクションをコミットし格納する。尚、データベース・コード・モジュール１０５は、データベース１０６の一体部分であってもよいが、本発明を理解し易くするために、データベースを分離して、前処理および後処理機能を実行するデータベース・コード・モジュールと、実際のテーブル入力およびテーブル参照を実行する、データベース１０６と呼称する、データベース・コアとに分けていることは言うまでもない。
【００１０】
通常の動作では、トランザクションのコミットメント後、即ち、書き込み動作が実際にデータベース１０６において行われた後には、トランザクション・フロント・エンド１０４からクライアント１００への応答は、失われている可能性がある。応答が受信されない場合の殆どでは、クライアント１００が応答を再試行することになるが、これによってデータベース１０６に対して１回余分な書き込み動作をコミットすることになり、重複エントリが生ずる。これは、回避すべき状態である。
【００１１】
この従来技術のステートフル・メインフレーム・アーキテクチャに伴う問題の一部は、クライアント数、つまり、トランザクションが増大するに連れて、メインフレーム１０２内において必要なモジュールの数がかなり劇的に増大することにある。トランザクション・フロント・エンド・モジュール１０４による通信動作を実行するために容量の多くが利用されているので、これはメインフレーム１０２の最も効率的な使用であるとは考えられない。つまり、非常に大量の動作を処理するためには、ステートフル・アーキテクチャを維持するためにはばく大なコストをかけなければならないのである。ここで生ずる疑問は、コスト削減を促すために、何故トランザクション・フロント・エンド１０４をいっそのことメインフレーム１０２から除外しないのかということである。これは、従来技術のステートフル・プロトコルによれば、異なるユニットに分離した場合、即ち、データベース・コード・モジュール１０５とトランザクション・フロント・エンド・モジュール１０４との間において応答障害が発生する潜在的な可能性が１つ余計に生ずることに他ならない。つまり、問題を解決するどころか、追跡しなければならない状態が増加するに過ぎないので、問題が悪化する潜在的な可能性があるだけである。
【００１２】
このスケーラビリティおよび信頼性には、図１Ｂに示すようにトランザクション・フロント・エンド・モジュール１０４を別個のフロント・エンド・クラスタ１０５に移動させることによって、部分的に対処することができる。しかし、移動とはいってもクラスタまでなので、スケーリングはなおもクラスタの限界に制限され、トランザクション当たりのコストは、クラスタの冗長性のために相変わらず高いままである。
【００１３】
本発明によるシステムを図２に示すが、ここでは、クラスタ化するのではなく、トランザクション・フロント・エンド・モジュール１０４を外部に移動させるので、最小のコストで最高のスケーラビリティが得られる。２つのクライアント１００が、コモディティ・ハードウェア・サーバ１０８にリンクされている。サーバ１０８はトランザクション・フロント・エンド・モジュール１０４も走らせている。第３クライアント１００が第２コモディティ・ハードウェア・サーバ１１０に接続されており、サーバ１１０はトランザクション・フロント・エンド・モジュール１０４も走らせている。好ましくは、これらのコモディティ・ハードウェア・サーバ１０８および１１０は、Linuxオペレーティング・システムを走らせているが、Windowsまたはその他のオペレーティング・システムも、望ましければ、利用することができる。そして、コモディティ・サーバ１０８および１１０ならびにフロント・エンド・モジュール１０４は、メインフレーム１１２に接続されており、以前と同様、メインフレーム１１２はメインフレーム・データベース１０６を走らせている。本例では異なるデータベース・コード・モジュール１１１が走っており、フロント・エンド・モジュール１０４からの通信を受信して、データベース１０６と通信する。これと従来技術による潜在的なアーキテクチャとの間の相違は、データベース・コード・モジュール１１１において利用されているプロトコルが、重複トランザクションが生じないことを確保するように変更されていることである。これについては、以下で更に詳しく説明する。加えて、データベース１０６の中には、新しいステートレス・トランザクション・プロトコル（ＳＴＰ）テーブル１１３がある。これは、データベース・コード・モジュール１１１と共動し、以下で更に詳しく説明する。
【００１４】
図３は、本発明による第２実施形態を示す。この場合も、クライアント１００がコモディティ・サーバ１０８および１１０と通信する。しかしながら、この場合、メインフレーム１１２がコモディティ・サーバ１１４と入れ代わっており、コモディティ・サーバ１１４は、メインフレーム・データベース１０６を走らせる代わりに、コモディティ・データベース１１６または同様物を走らせている。その例には、MySQL、Postgres、およびSQLサーバがある。本発明によるコミットメント・プロセスの動作に基づくと、サーバ１１４に対する稼働時間要件を別の方法で維持することができれば、メインフレーム１１２の信頼性は要求されない。とは言え、他のスケーラビリティ、可用性、および保守性を考慮することから、メインフレーム環境が妥当であることは言うまでもない。
【００１５】
図４は、本発明の第３実施形態を示す。この場合、クライアント１００が直接コモディティ・サーバ１１８に接続されている。コモディティ・サーバ１１８は、トランザクション・フロント・エンド・モジュール１０４、データベース・コード・モジュール１１１、およびデータベース１１６を含む。この場合、１つのサーバ１１８のみを利用する。何故なら、クライアント１００の数が十分小さく、通信タスクを実行するために別個のサーバを設けなくても、通信要件を満たすことができるからである。多数のクライアントがあり、規模を最大限まで拡大した環境では、図２または図３に示すようなアーキテクチャが好ましい。
【００１６】
前述のように、トランザクション・システムにおける主要な問題の１つは、書き込みトランザクションの二重コミットメントに対する潜在的な可能性である。図５Ａおよび図５Ｂに示す本発明によるシステムでは、ステップ５００において、クライアント１００は新たなトランザクションをトランザクション・フロント・エンド・モジュール１０４に供給する。すると、トランザクション・フロント・エンド・モジュール１０４は、必要な処理動作を実行し、この新しいトランザクションをデータベース・コード・モジュール１１１に供給し、ステップ５０２における追加動作によって、これが新しいトランザクションであることを示すために、トランザクション開始ビットをセットする。ステップ５０４において、データベース・コード・モジュール１１１はトランザクションを受信する。データベース・コード・モジュール１１１の最初の動作は、ステップ５０６において、これが読み取り動作または書き込み動作のどちらか判定を行うことである。読み取り動作である場合、制御はステップ５０７に進み、従来技術による通常の処理を実行する。本発明の焦点は、二重コミット動作が発生する潜在的な可能性がある書き込み動作にある。
【００１７】
書き込み動作の場合、制御はステップ５０８に進み、トランザクションにおける要求情報をハッシュして(hash)一意の値を得る。好ましくは、要求情報は、データベースに入力すべき実際の値を含む。これは、好ましくは、空間を節約し、データを表す一意の値を得るために、６４または１２８ビットの値にハッシュする。次に、制御はステップ５０９に進み、同様に、ユーザ情報もハッシュする。好適な実施形態では、ユーザ情報は、ユーザの追跡を可能にするユーザ識別、１つまたは複数の動作を要求する１つまたは複数のテーブルの名称、および作用を受ける１つ以上のテーブルにおける特定のカラムを含む。多数のテーブルまたはカラムがある場合、単純なハッシュ値を得るためのタスク動作の一部として、各々を供給する。同様に、各テーブルおよびカラム毎に、要求値の各々から、要求ハッシュを生成する。この場合でも、所望に応じて種々のハッシング技法を用いて、これを６４または１２８ビット値にハッシュする。尚、所望であれば、双方の一意性を維持し格納値を最適化するように、他の値を利用することもできる。ステップ５１０においてハッシングを実行した後、制御はステップ５１２に進み、ＳＴＰテーブル１１３を調査して、ユーザ・ハッシュ値が既にＳＴＰテーブル１１３内にあるか否か判定を行う。これを行うには、データベース・コード・モジュール１１１がクエリをデータベース１０６または１１６に供給する。この種の動作は、同様な全ての場合に実行されるので、明確化のために以後省略する。既にある場合、制御はステップ５１２に進み、要求ハッシュもＳＴＰテーブル１１３の中にあるか否か判定を行う。ステップ５１０または５１２において、関連するハッシュがない場合、制御はステップ５１４に進み、検査値を偽（ｆａｌｓｅ）値に設定する。ステップ５１２において、要求ハッシュがあった場合、ユーザ・ハッシュがあることが既に判定されていることになるので、これは、コミットしようとしているトランザクションが実際に既にコミットされており、再度コミットしてはならないこと、即ち、重複トランザクション要求であることを示す。制御はステップ５１５に進み、ＳＴＰテーブル１１３からの以前にコミットした動作から応答を読み出す。ステップ５１６において、検査値を真（ｔｒｕｅ）に設定する。
【００１８】
ステップ５１４またはステップ５１６の後、制御はステップ５１８に進み、重複トランザクションが判定されたか否か判定を行う。重複トランザクションが判定された場合、制御はステップ５２０に進み、セットされているトランザクション開始ビットをクリアし、この場合ＳＴＰテーブル１１３から読み出した応答を、トランザクション・フロント・エンド・モジュール１０４に返し、次いでトランザクション・フロント・エンド・モジュール１０４は応答をクライアント１００に返す。
【００１９】
ステップ５１８において重複トランザクションが判定されなかった場合、制御はステップ５２２に進み、実際にトランザクションをデータベース１０６または１１６に供給し、データベース１０６または１１６による動作が成功したか否かを示す応答を受信する。制御はステップ５２４に進み、データベース１０６または１１６の動作が成功であったか否か判定を行う。成功であった場合、制御はステップ５２６に進み、ユーザ・ハッシュ値が既にＳＴＰテーブル１１３の中にあるか否か判定を行う。既にある場合、制御はステップ５２８に進み、要求ハッシュと、データベース１０６または１１６から受信した応答とを、単にＳＴＰテーブル１１３において更新する。ユーザ・ハッシュが既にあるので、以前の要求ハッシュに対してその中にある値、および応答値のみを更新すればよい。しかしながら、ユーザ・ハッシュがない場合、制御はステップ５３０に進み、ユーザ・ハッシュ値、要求ハッシュ値、および応答をＳＴＰテーブル１１３に挿入する。ステップ５２８または５３０が完了した後、ステップ５３２において、更新または挿入動作に対する応答を評価する。値をＳＴＰテーブル１１３に供給する動作が成功でなかった場合、制御はステップ５３４に進み、ＳＴＰ動作をロール・バックする。制御はステップ５３６に進む。ステップ５２４において挿入に成功しなかったときにも、制御はこのステップ５３６に進む。ステップ５３６において、データベース動作自体をロール・バックして、双方を、この場合、ＳＴＰ動作およびデータベース動作自体を全くコミットしていないことにする。制御はステップ５３８に進み、トランザクション・フロント・エンド・モジュール１０４からクライアント１００にエラーを返す。通常、ここでトランザクションを再度試す。再度試した場合、ＳＴＰテーブル１１３にはエントリも重複もない。何故なら、これらはコミットされておらず、したがって正常な再試行応答状況となるからである。
【００２０】
ステップ５３２において、ＳＴＰテーブルへの情報提供が成功であった場合、制御はステップ５４０に進み、トランザクション値自体およびＳＴＰテーブル１１３の値双方に対してコミット要求を与える。これらは、データベース１０６または１１６に対する１回のトランザクションの中でカプセル化されているので、競合状態は発生しない。つまり、ステップ５４０において、データベース１０６または１１６はトランザクション要求値およびＳＴＰテーブル１１３の値をそれぞれのテーブルに対して実際にコミットする。制御はステップ５２０に進み、トランザクションが完了し、開始ビットをクリアし、肯定的応答(positive response)を返す。
【００２１】
このように、二重コミットメント動作が生ずることができないように、ＳＴＰテーブル１１３を利用して、個々のユーザによって試された最後の書き込みトランザクションの値を追跡する。一般に、１つのクライアントからのトランザクションが２回も未処理になっていることはないので、ＳＴＰテーブル１１０において所与のユーザから１回のトランザクションのみを追跡すれば、殆どの状況では適当であると考えられる。しかしながら、望ましければ、エントリが多数あるテーブルを用いることができ、最長時間未使用交換技法等を用いて、所与のユーザに対するテーブルの値を更新する。
【００２２】
図６は、ＳＴＰテーブル１１３のテーブル構造の好適な実施形態を示す。プライマリ・キーはユーザ・ハッシュ値であり、代替キーは要求ハッシュ値であり、各行における３番目のエントリは応答、即ち、トランザクションが本来コミットされた場合にデータベース・コアから供給された応答である。
【００２３】
つまり、このプロセスを利用することによって、トランザクションが１回しかコミットされず、二重コミットの可能性がなくなることがわかる。何故なら、実際にトランザクションがコミットされ、次いでシステムのいずれかの場所においてクライアントに返される応答が失われ、クライアントが直ちにそれを再試行した場合、この重複コミットメントが検出されるので、実際に動作全てを実行することなく、応答が再度供給されるだけで終わるからである。これによって、トランザクション・フロント・エンド、即ち、最もスケーラビリティ要件が厳しい構成要素を、クラスタリングの必要なく、コモディティ・ハードウェアに移動させることが可能となる。その他の要件によっては、メインフレームまたはコモディティ・サーバおよびリレーショナル・データベース(related databases)も、トランザクション・フロント・エンド用コモディティ・ハードウェアと合わせて用いることができる。
【００２４】
以上の説明から、本発明の種々の実施形態から逸脱することなく、その真の主旨から逸脱することなく、修正や変更が可能であることは理解されてしかるべきである。本明細書における記載は、例示を目的とするに過ぎず、限定的な意味で解釈してはならない。本発明の範囲は、特許請求の範囲の文言によってのみ限定されるものとする。
【図面の簡単な説明】
【００２５】
【図１Ａ】図１Ａは、従来技術によるトランザクション・データベース・システムの記述である。
【図１Ｂ】図１Ｂは、従来技術によるトランザクション・データベース・システムの記述である。
【図２】図２は、本発明によるコモディティ・ハードウェアを利用するトランザクション・データベース・システムの第１実施形態である。
【図３】図３は、本発明によるコモディティ・ハードウェアを利用するトランザクション・データベース・システムの第２実施形態である。
【図４】図４は、本発明によるコモディティ・ハードウェアを利用するトランザクション・データベース・システムの第３実施形態である。
【図５Ａ】図５Ａは、本発明による高信頼性コミット・プロセスのフロー・チャートである。
【図５Ｂ】図５Ｂは、本発明による高信頼性コミット・プロセスのフロー・チャートである。
【図６】図６は、図５Ａおよび図５Ｂのプロセスにおいて用いられるテーブルの図である。
【図１Ａ】
2009505223.tif 000003
【図１Ｂ】
2009505223.tif 000004
【図２】
2009505223.tif 000005
【図３】
2009505223.tif 000006
【図４】
2009505223.tif 000007
【図５Ａ】
2009505223.tif 000008
【図５Ｂ】
2009505223.tif 000009
【図６】
2009505223.tif 000010