JP2020098598A

JP2020098598A - クライアント側のキャッシュによる透過的なデータベースセッションの回復

Info

Publication number: JP2020098598A
Application number: JP2019224632A
Authority: JP
Inventors: ドンイン・シン; Dongin Shin; ヨンフン・ジョン; Yeonghun Jeong; ジョン・ヒ・ウォン; Jung Hee Won; ジュチャン・リー; Juchang Lee
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2018-12-17
Filing date: 2019-12-12
Publication date: 2020-06-25
Anticipated expiration: 2039-12-12
Also published as: US11663091B2; US20200192766A1; CN111324632A; EP3671482C0; EP3671482B1; CN111324632B; JP7104016B2; EP3671482A1

Abstract

【課題】システム障害、およびその後のセッションコンテキスト情報の損失の可能性から保護するために、追加の防御コードを追加すること【解決手段】クライアントコンピュータは、DBMSとの1つ以または複数のセッションを確立する。セッションごとのセッションコンテキスト情報は、クライアント側のセッションキャッシュにキャッシュされる。セッションの切断が検出された場合、セッションの回復は、DBMSとの新しいセッションを確立するステップと、セッションキャッシュに記憶された切断されたセッションのセッション情報から切断されたセッションのセッションコンテキストを復元するステップとを含む。【選択図】図1

Description

データベースシステムの重要な長所のうちの1つは、データベースがほとんどのシステム障害に対して通常表(persistent tables)の回復を保証できることである。しかしながら、それでもなお、クライアント-サーバデータベースセッションが切断され、すべてのセッションコンテキスト情報が失われる可能性があるため、システム障害はデータベースシステムにアクセスするデータベースアプリケーションにとって破壊的なイベントである。たとえば、データベースクライアントは、そのロケールを「ドイツ語」に設定し、クライアントによって確立された特定のデータベースセッションに対して、データベースセッションのコンテキストに記憶されるこのローカル値ですべての後続クエリが実行されるようにする。しかしながら、サーバが再起動された場合、ロケールは「米国」などのデフォルト値にリセットされ、クエリに影響する可能性がある。アプリケーションプログラマは、そのようなシステム障害、およびその後のセッションコンテキスト情報の損失の可能性から保護するために、追加の防御コードを追加することができる。

以下の議論、および具体的には図面に関して、示される詳細は、例示的な議論の目的のための例を表し、本開示の原理および概念的側面の説明を提供するために提示されることが強調される。これに関して、本開示の基本的な理解に必要なものを超える実装形態の詳細を示すための試みはなされていない。以下の議論は、図面と併せて、本開示による実施形態がどのように実施され得るかを当業者に明らかにする。様々な図面およびサポートする説明における類似または同じ要素を識別または参照するために、類似または同じ参照番号が使用され得る。

添付の図面において:
本開示のいくつかの実施形態によるシステムを示す図である。本開示のいくつかの実施形態による、クライアントコンピュータ上で実行しているアプリケーションの詳細を示す図である。本開示のいくつかの実施形態に従って構成され得る例示的なコンピュータシステムを示す図である。本開示のいくつかの実施形態による、クライアント側のセッションキャッシングのプロセスフローを示す図である。本開示のいくつかの実施形態による、クライアント側のセッションキャッシュからセッションを復元するためのプロセスフローを示す図である。本開示のいくつかの実施形態による、クライアント側のセッションキャッシュからセッションを復元するためのフローを示すシーケンス図である。本開示のいくつかの実施形態による、テイクオーバユースケース(takeover use case)においてクライアント側のセッションキャッシュからセッションを復元するためのフローを示すシーケンス図である。

以下の説明では、説明の目的で、本開示の完全な理解を提供するために、多数の例および特定の詳細が示されている。しかしながら、当業者には、特許請求の範囲において表される本開示が、これらの例における機能のうちの一部またはすべてを、単独で、または以下に説明する他の機能と組み合わせて含み得、さらに、本明細書に記載の機能および概念の修正および同等物をさらに含み得ることは明らかであろう。

図1は、本開示のいくつかの実施形態によるデータベースシステム100を示している。データベースシステム100は、基礎となるデータベース102aと、データベース102aにアクセスして維持するための対応するデータベースサービスとを備えるデータベース管理サーバ(DBMS)102を含むことができる。ユーザは、クライアントコンピュータ104を介してDBMS102にアクセスすることができる。通信ネットワーク106は、クライアントコンピュータ104とDBMS102との間の通信を提供することができる。通信ネットワーク106は、公衆交換網、ローカルエリアネットワーク、ワイドエリアネットワーク、DBMS102への直接接続(たとえば、管理ユーザ向け)などを含むがこれらに限定されない、任意の適切な形態の通信インフラストラクチャを表す。

いくつかの実施形態では、クライアントコンピュータ104上のユーザは、DBMS102と通信するために、1つまたは複数のデータベースアプリケーション108を実行することができる。各アプリケーション108は、データベース102a上で何らかの作業を行うために、DBMS102との1つまたは複数のセッションを作成することができる。DBMS102におけるセッションマネージャ110は、クライアントコンピュータ104間で実行されるアプリケーション108に関連付けられる様々なセッションを管理することができる。本開示によれば、クライアントコンピュータ104とDBMS102はセッションコンテキスト情報を交換することができる。いくつかの実施形態では、たとえば図1に示されるように、クライアントコンピュータ104は、(たとえば、データベースコマンドを使用して)セッションコンテキスト情報を設定することができ、DBMS102は、クライアントコンピュータ104にセッションコンテキスト情報を提供することができる。本開示のこれらの態様について、以下で説明する。

本開示の文脈において、セッションは、アプリケーション108とDBMS102との間の対話型交換を指す。たとえば、アプリケーション108を使用するユーザは、たとえばDBMSにログオンすることによってデータベース102aにアクセスするために、DBMS102上でセッションを確立することができる。所与のセッション中に、セッションに関連する追加情報が確立され得る。そのような情報は、特定のセッションに固有であり、特定のセッションにのみ関連するため、セッションコンテキスト情報と呼ぶことができる。たとえば、ユーザは、(たとえば、タイムゾーンの目的で)地理的な場所を指定するセッションロケールを設定し得る。ユーザは、言語、通貨単位などを指定し得る。ユーザは、セッション中に特定のセッション設定を変更し得る。たとえば、ユーザは1つのインスタンスにおいて通貨単位を米ドルで指定し、その後同じセッションにおいて韓国ウォンに変更し得る。セッションコンテキスト情報は、現在のデータベースなどのデータベース固有の情報、および一時表などのユーザ一時オブジェクトなどであり得る。

DBMS102におけるセッションマネージャ110は、セッションコンテキスト情報を追跡することができ、セッション中にDBMS102における様々な機能ユニット(図示せず)にそのような情報を提供することができる。たとえば、DBMS102は、ユーザのロケール設定に応じてタイムゾーン変換を実行し得る。ユーザが通貨単位(たとえば、米ドル、韓国ウォンなど)を指定した場合、DBMS102は適切な通貨単位変換などを実行することができる。セッションが終了する(たとえば、ユーザがログオフする)と、セッションコンテキスト情報は「忘れられる」。言い換えれば、セッションコンテキスト情報は一時的であり、クライアントコンピュータ104において、またはセッションマネージャ110によって永続化されない。同じユーザが再びログインする場合、セッションコンテキストを再度セットアップする必要がある。

図2は、本開示のいくつかの実施形態による、データベースアプリケーション108のいくつかの詳細を示している。アプリケーション108は、DBMS102にアクセスするために、たとえば、データベースを開くこと、データ表を作成することなどの共通の機能を共有することができる。これらの共通機能は、各アプリケーション108がリンクできるクライアントライブラリ202において提供することができる。

クライアントライブラリ202は、キャッシュマネージャ204、および具体的にはキャッシュ機能に対するアプリケーションプログラミングインターフェース(API)を含むことができる。本開示によれば、キャッシュマネージャ204は、アプリケーション108にセッションキャッシングを提供することができる。いくつかの実施形態では、たとえば、キャッシュマネージャ204は、アプリケーション108が作成するセッションごとにセッションキャッシュ206を維持することができる。いくつかの実施形態では、セッションキャッシュ206は、不揮発性メモリ(たとえば、スタティックRAM)、ディスクストレージなどの任意の適切な永続的ストレージであり得る。

クライアントライブラリ202は、接続マネージャ208を含むことができる。接続マネージャ208は、たとえば、DBMS102との接続を確立/作成するために、DBMS102と通信することができる。図2は、たとえば、DBMS102との、それぞれのアプリケーションA、B、Cとの3つの接続、A、B、Cを示している。接続マネージャ208は、DBMS102と通信するために、任意の適切な通信プロトコルを使用することができる。いくつかの実施形態では、たとえば、接続マネージャ208は、インターネットを介する通信のためにTCP/IPプロトコルを使用することができる。他の実施形態では、他の通信プロトコルを使用することができる。たとえば、接続A、B、Cは、アプリケーション108とDBMS102の間のSQL処理(クエリの送信と応答の受信)をサポートするために使用することができる。場合によっては、アプリケーション108は、図2に示されるような単一の接続をセットアップすることができる。他の例(図示せず)では、アプリケーション108はDBMS102とのいくつかの接続をセットアップし得、たとえば、複数のスレッドを有するアプリケーションでは、スレッドのうちのいくつかがDBMS102との独自の接続を有し得る。

図2は、DBMS102上のセッションマネージャ110が、それぞれの接続A、B、Cごとに対応するセッションデータA、B、Cを維持できることを示している。セッションデータは、セッションに関連する任意の適切な情報を備えることができる。たとえば、セッションデータは、たとえば、アプリケーション名(たとえば、HDBStudio)、アプリケーションが定義したユーザ名などのユーザ情報、大文字と小文字の区別(T/F)、ロケールなどの、アプリケーションによって定義された情報を含むことができる。たとえば、オペレーティングシステムアカウントおよびその他のシステムレベルの情報などのセッションデータは、クライアントライブラリ202によって定義することができる。ユーザは、たとえばSQL SETコマンド(たとえば、SET FOO="BAR")などの適切なAPIを使用することによって、セッションデータをセットアップすることができる。

図3は、本明細書に記載の実施形態(たとえば、クライアントコンピュータ104、DBMS102、図1)のうちの1つまたは複数を実装するための例示的なコンピューティングシステム300の簡略ブロック図である。コンピューティングシステム300は、単独で、または他の要素と組み合わせて、本開示による動作を実行することができ、および/または実行するための手段であり得る。コンピューティングシステム300はまた、本明細書で説明される任意の他のステップ、方法、またはプロセスを実行することができ、および/または実行するための手段であり得る。

コンピューティングシステム300は、コンピュータ可読命令を実行することができる任意のシングルまたはマルチプロセッサコンピューティングデバイス、あるいはシステムを含むことができる。コンピューティングシステム300の例には、たとえば、ワークステーション、ラップトップ、サーバ、分散コンピューティングシステムなどが含まれる。基本構成においては、コンピューティングシステム300は、少なくとも1つの処理ユニット312およびシステム(メイン)メモリ314を含むことができる。

処理ユニット312は、データを処理する、または命令を解釈および実行することができる任意のタイプまたは形態の処理ユニットを備えることができる。処理ユニット312は、ある実施形態では単一プロセッサ構成とすることができ、他の実施形態では、1つまたは複数のコンピュータプロセッサを備えるマルチプロセッサアーキテクチャとすることができる。いくつかの実施形態では、処理ユニット312は、プログラムおよびデータモジュール330から命令を受信することができる。これらの命令は、処理ユニット312に、本開示の様々な開示される実施形態(たとえば、図4、図5)に従って動作を実行させることができる。

システムメモリ314(メインメモリと呼ばれることもある)は、データおよび/または他のコンピュータ可読命令を記憶することができる任意のタイプまたは形態のストレージデバイスまたはストレージ媒体とすることができ、揮発性メモリおよび/または不揮発性メモリを備える。システムメモリ314の例には、任意の適切なバイト-アドレス可能メモリ、たとえば、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、フラッシュメモリ、または任意の他の同様のメモリアーキテクチャが含まれる。必須ではないが、いくつかの実施形態では、コンピューティングシステム300は、揮発性メモリユニット(たとえば、システムメモリ314)と不揮発性ストレージデバイス(たとえば、データストレージ316)の両方を含むことができる。

いくつかの実施形態では、コンピューティングシステム300は、処理ユニット312およびシステムメモリ314に加えて、1つまたは複数のコンポーネントまたは要素を含むことができる。たとえば、図3に示されるように、コンピューティングシステム300は、システムバス324を介して相互接続された内部データストレージ316、通信インターフェース320、およびI/Oインターフェース322を含むことができる。システムバス324は、コンピューティングシステム300を備える1つまたは複数のコンポーネント間の通信を容易にすることができる任意のタイプまたは形態のインフラストラクチャを含むことができる。システムバス324の例には、たとえば、通信バス(ISA、PCI、PCIe、または類似のバスなど)およびネットワークが含まれる。

内部データストレージ316は、本開示に従ってコンピューティングシステム300を動作させるためのデータ、データ構造、コンピュータ実行可能命令などの不揮発性ストレージを提供するための、非一時的コンピュータ可読ストレージ媒体を備えることができる。たとえば、内部データストレージ316は、本明細書に開示される様々な処理および動作をサポートおよび実行するために、たとえばオペレーティングシステム332、1つまたは複数のアプリケーションプログラム334、プログラムデータ336、および他のプログラム/システムモジュール338を含む、様々なプログラムおよびデータモジュール330を記憶することができる。いくつかの実施形態では、内部データストレージ316は、図2に示されるセッションキャッシュ206の永続的ストレージを提供することができる。

通信インターフェース320は、コンピューティングシステム300と1つまたは複数の追加のデバイスとの間の通信を容易にすることができる任意のタイプまたは形態の通信デバイスまたはアダプタを含むことができる。たとえば、いくつかの実施形態では、通信インターフェース320は、コンピューティングシステム300と、追加のコンピューティングシステムを含むプライベートまたはパブリックネットワークとの間の通信を容易にすることができる。通信インターフェース320の例には、たとえば、ワイヤードネットワークインターフェース(ネットワークインターフェースカードなど)、ワイヤレスネットワークインターフェース(ワイヤレスネットワークインターフェースカードなど)、モデム、および任意の他の適切なインターフェースが含まれる。

いくつかの実施形態では、通信インターフェース320はまた、外部バスまたは通信チャネルを介するコンピューティングシステム300と1つまたは複数の追加のネットワークあるいはストレージデバイスとの間の通信を容易にするように構成されるホストアダプタを表すことができる。ホストアダプタの例には、たとえば、SCSIホストアダプタ、USBホストアダプタ、IEEE1394ホストアダプタ、SATAおよびeSATAホストアダプタ、ATAおよびPATAホストアダプタ、ファイバーチャネルインターフェースアダプタ、イーサネット（登録商標）アダプタなどが含まれる。

コンピューティングシステム300はまた、たとえば、管理者へのアクセスを提供するために、I/Oインターフェース322を介してシステムバス324に結合された少なくとも1つの出力デバイス342(たとえば、ディスプレイ)を含むことができる。出力デバイス342は、I/Oインターフェース322から受信した情報の視覚的および/または音声的提示が可能な任意のタイプまたは形態のデバイスを含むことができる。

コンピューティングシステム300はまた、たとえば管理者アクセスのために、I/Oインターフェース322を介してシステムバス324に結合された少なくとも1つの入力デバイス344を含むことができる。入力デバイス344は、コンピュータまたは人間が生成した入力をコンピューティングシステム300に提供することができる任意のタイプまたは形態の入力デバイスを含むことができる。入力デバイス344の例には、たとえば、キーボード、ポインティングデバイス、音声認識デバイス、または任意の他の入力デバイスがある。

次に、図4および他の図面を参照して、たとえばクライアントコンピュータ104上で実行しているデータベースアプリケーション108を介して、本開示に従ってセッションコンテキスト情報をキャッシュする(セッションキャッシング)ためのクライアントコンピュータ104における処理の高レベルの説明に移る。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、処理ユニット(たとえば、図3の312)によって実行されると、クライアントコンピュータ104に、図4に従って処理を実行させることができるコンピュータ実行可能プログラムコード(たとえば、アプリケーション108)を含み得る。コンピュータシステムによって実行される動作のフローは、必ずしも示された動作の順序に限定されない。

動作402において、クライアントコンピュータ104は、DBMS102とのセッションを作成または確立することができる。たとえば、ユーザがDBMS102上で作業するためにアプリケーション108を呼び出すとき、ユーザは、DBMS102にログオンするためにログインシーケンスを実行する必要があり得る。このアクティビティは、ログインセッションを作成することができる。DBMS102におけるセッションマネージャ110は、ユーザのログインセッションに関する情報を記憶および維持するために、いくつかのローカルデータ構造をセットアップすることができる。

動作404において、クライアントコンピュータ104は、セッションコンテキスト情報をDBMS102に送信することができる。たとえば、ログインプロセス中に、クライアントコンピュータ104は、ユーザのIDをセッション情報としてDBMS102に送信することができる。クライアントコンピュータ104は、ロケール、言語、通貨単位、ユーザのアクセスレベルなどのユーザに関するいくつかのローカルに記憶された情報にアクセスし(たとえば、嗜好ファイルから)、セッション確立の一部として、そのような情報をデフォルト設定として送信し得る。ユーザは、ログインセッション中にそのような設定を変更すること、および/またはセッション情報を追加することができる。いくつかの実施形態では、たとえば、SQLデータベースシステムでは、セッション情報を設定するためにSETコマンド
SETキー、値
を使用することができ、この場合、キーは、ロケール、言語などの特定のセッション属性を指定し、値は、ドイツ語(ロケール用)、英語(言語用)など、キャッシュされるセッションデータである。

動作406において、クライアントコンピュータ104は、DBMS102からセッションコンテキスト情報を受信することができる。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、DBMSに送信される特定のコマンドがセッション情報を含むことを知らない場合がある。DBMS102がコマンドをコンパイルするまで、コマンドがセッション情報を含むと決定することはできない。したがって、いくつかの実施形態では、DBMS102は、そのような情報を応答または他の適切なメッセージにおいてクライアントコンピュータ104に送り返すことができる。しかしながら、他の実施形態では、クライアントコンピュータ104で実行するアプリケーション108は、DBMS102への特定の通信がセッション情報を含むことを決定する能力で構成することができ、したがってこの特定の動作を不要にできることが理解されよう。

動作408において、クライアントコンピュータ104は、セッションが終了したかどうかを決定することができる。これは、たとえば、接続がドロップされ、ドロップされた接続の回復に失敗したとき、ユーザがログアウトした場合などに発生する可能性がある。セッションが終了したと決定された場合、処理は動作412から続行することができ、それ以外の場合、処理は動作410から続行することができる。

動作410において、クライアントコンピュータ104は、セッションコンテキスト情報をキャッシュすることができる。たとえば、クライアントコンピュータ104における接続マネージャ208は、セッションに対応するセッションキャッシュ206内のセッション情報を含む応答または他の適切なメッセージをDBMS102から受信することができる。いくつかの実施形態では、接続マネージャ208は、受信したセッション情報をキャッシュするためにキャッシュマネージャ204内の適切なAPIを呼び出すことができる。セッションキャッシュ206は、[キー、値]ストレージとして構成することができ、この場合、キーは特定のセッション属性を識別し、値は実際のセッションデータであり、たとえば、キー=通貨単位、値=米ドルである。キーがセッションキャッシュ206内に見つからない場合、新しいエントリをセッションキャッシュに追加することができる。見つかった場合、既存のエントリは最新の値で更新される。したがって、更新の履歴ではなく、セッション情報に対して行われた最新の更新のみがキャッシュされる。たとえば、通貨単位というセッション属性が複数回更新された場合、その属性の1つのエントリのみがキャッシュされ、それは最新の更新を含むことになる。

動作412において、クライアントコンピュータ104は、終了した所与のセッションのセッションキャッシュ206を消去することができる。しかしながら、他のセッションで実行されている任意のセッションキャッシングは続行することができる。

アプリケーション108の実行中に、ユーザは、新しいセッション情報を設定してもよく、または以前に設定されたセッション情報を変更してもよい。クライアントコンピュータ104は、新しいまたは変更されたセッション情報をキャッシュするために、動作404において始まるプロセスを繰り返すことができる。新しいセッション情報は、新しい[キー、値]ペアとしてセッションキャッシュ(キャッシュメモリ)206に追加することができる。セッションキャッシュ206を検索するためにキーを使用することによって、既存のセッション情報の修正を記憶することができる。

次に、図5および他の図面を参照して、たとえばクライアントコンピュータ104上で実行しているデータベースアプリケーション108を介して、本開示に従って切断されたセッションを再確立するためのクライアントコンピュータ104における処理の高レベルの説明に移る。これらの動作は、切断されたセッションごとに実行することができることが理解されよう。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、処理ユニット(たとえば、図3の312)によって実行されると、クライアントコンピュータ104に、図5に従って処理を実行させることができるコンピュータ実行可能プログラムコード(たとえば、アプリケーション108)を含み得る。コンピュータシステムによって実行される動作のフローは、示された動作の順序に必ずしも限定されない。

動作502において、クライアントコンピュータ104は、DBMS102とのセッション(第1のセッション)が切断されたことを検出することができる。状況によっては、DBMS102との通信が中断されたときにセッションの切断が発生する可能性があり、その場合、クライアントコンピュータ104におけるすべてのセッションが切断される。DBMS102との接続の中断は、DBMS102との接続または通信のタイプに応じて、任意の適切な方法で検出または決定することができる。いくつかの実施形態では、たとえば、接続マネージャ208は、DBMS102と通信するためにTCP/IPプロトコルを使用することができる。DBMS102との通信中に発生するTCP/IPソケットエラーは、セッションの切断を示すために役立つことができる。他の状況では、たとえDBMS102との通信が影響を受けない場合でも、セッションの切断が発生する可能性がある。たとえば、DBMS102におけるデータ表が破損した場合、そのイベントにより、破損したデータ表を使用していたセッションのみが切断される可能性があり、他のセッションは必ずしも影響を受けるとは限らない。

動作504において、クライアントコンピュータ104は、セッション切断の検出に応答して、DBMS102との再接続を試みることができる。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、m回の試行に対して、n単位の時間(秒、分)ごとに再接続を試みることができる。m回の試行の終わりに接続が確立されない場合、クライアントコンピュータ104は、接続例外を示すエラーを投げることができる(動作501)。

動作506において、クライアントコンピュータ104は、DBMS102との切断されたセッション(第2のセッション)を再確立することができる。クライアントコンピュータ104がDBMS102と再接続した後、クライアントコンピュータ104は、セッションを再確立するためのステップをとることができる。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、たとえばログインシーケンスを繰り返すことによって、ユーザを再びログインさせることができる。

動作508において、クライアントコンピュータ104は、デフォルトでないセッションコンテキスト情報があるかどうかを決定することができる。いくつかの実施形態では、セッションは、デフォルトセッション属性のセットに対してデフォルト設定を有することができ、それにより、セッションが確立されると、クライアントコンピュータ104はデフォルトセッション設定を読み込み(たとえば、ディスクから)、DBMS102においてセッションコンテキストを設定することができる(たとえば、一連のSETコマンドを使用して)。いくつかの実施形態では、クライアントコンピュータ104は、デフォルト設定において変更が行われたこと、またはデフォルトセッション情報以外のセッション情報がキャッシュされたことを示すセッションフラグを記憶することができる。セッションフラグは、最初は「0」に設定することができ、データがセッションキャッシュ206にキャッシュされると、デフォルト以外のセッション情報の存在を示すために、「1」に設定することができる。デフォルト以外のセッション情報がキャッシュされている場合、処理は動作510から続行することができ、それ以外の場合、処理は動作514から続行することができる。

動作510において、クライアントコンピュータ104は、復元するべきキャッシュされたセッションコンテキストがあるかどうかを決定することができる。動作508において説明したように、セッションキャッシュ206内にキャッシュされたセッションコンテキスト情報があるはずである。しかしながら、セッションキャッシュ206が消去される可能性がある。たとえば、図4において説明したように、所与のセッションのセッションキャッシュは、セッションが終了したときに終了することができる。そのような場合、所与のセッションのセッションキャッシングを終了し、セッションキャッシュ206を消去することができる。キャッシュされたセッションコンテキストがない場合、処理は動作514に進むことができる。

動作512において、クライアントコンピュータ104は、キャッシュされたセッションコンテキストを回復または復元することができる。いくつかの実施形態では、たとえば、クライアントコンピュータ104は、キャッシュされたセッション情報の各々について、一連のSETキー、値動作をDBMS102に発行することができる。キャッシュされたすべてのセッション情報がDBMS102に再送信されると、以前のセッションコンテキストの回復は完了したと見なすことができる。以下で説明する残りの動作は、セッションが切断されたときに進行中だった任意のクエリを処理するためのものである。

動作514において、クライアントコンピュータ104は、セッション切断時に保留中のアクティブなクエリがあったかどうかを決定することができる。アクティブなクエリがなかった場合、処理は完了したとみなすことができ、アクティブなクエリがあった場合、処理は動作516から続行することができる。

動作516において、クライアントコンピュータ104は、アクティブなクエリのうちのいずれかが再試行可能な状態にあるかどうかを決定することができる。アクティブなクエリのうちのいずれも再試行可能でない場合、クライアントコンピュータ104は、アクティブなクエリがあったが、いずれも再試行可能ではなかったことを示すために例外を投げることができるため、アプリケーション108は、たとえば、それらを再試行することを知ることができる。

動作518において、クライアントコンピュータ104は、再試行可能なクエリを再試行することができる。

図6は、図5において説明したプロセスにおける通信パスのうちのいくつかを強調するシーケンスチャートである。たとえば、通信602は、たとえばログインシーケンスを実行することによって、アプリケーション108がDBMS102とのセッションを確立できることを示している。通信604は、アプリケーション108がセッション属性(たとえば、言語=ドイツ語)を設定するためにDBMS102にSETコマンドを発行できることを示している。通信606は、DBMS102がセッション情報をアプリケーション108に送り返すことができることを示している。通信608は、アプリケーション108がセッションキャッシュ206内のセッション情報をキャッシュできることを示している。上記で説明したように、このシーケンスは、セッションの存続中に繰り返すことができる。610において、アプリケーション108はセッション切断を検出する。通信612は、アプリケーション108がDBMS102との新しいセッションを再確立するために再試行を1回または複数回試みることを示している。614において、アプリケーション108は、キャッシュされたセッション情報を読み込み、一連のSETコマンドを発行することによって以前のセッションコンテキストを復元することができる(通信616)。

図7は、これは、プライマリDBMSとして機能する第1のDBMS(たとえば、102)からセカンダリDBMSへの転送のコンテキストにおける、図5において説明したプロセスにおける通信パスのうちのいくつかを強調するシーケンスチャートである。転送は、プライマリDBMSが失敗し、セカンダリDBMSが引き継ぐフェイルオーバの結果である場合がある。他のシナリオでは、転送は、セカンダリDBMSによるプライマリDBMSのスケジューリングされたテイクオーバである場合がある。図7における通信パスは、図6において説明したものと同様であり、いくつかのバリエーションを有する。通信712は、たとえば、プライマリDBMSとの切断されたセッションの検出(610における)に続くセッション再試行が、セカンダリDBMS702に対して行われ得ることを示している。プライマリDBMSからセカンダリDBMSへの切替えは、クライアントコンピュータ104上で実行されるアプリケーション108にとって透過的であり得る。たとえば、アプリケーション108は、610においてそれぞれのセッションの切断を単に経験するだけである。710における再試行中、プライマリDBMSおよびセカンダリDBMSをサポートする基礎となる通信インフラストラクチャは、プライマリDBMSを引き継ぐために、セカンダリDBMSとの通信のためにクライアントコンピュータ104をリダイレクトすることを含む、セカンダリDBMSの回復処理を実行することができる。クライアントコンピュータ104とセカンダリDBMSとの間の通信が再確立されると、614および716において、新しいセッションをセットアップし、以前のセッションのセッションコンテキストを復元することができる。

結論
本開示による実施形態は、クライアントコンピュータ上のセッションキャッシングを提供し、クライアントコンピュータとデータベース管理システム(DBMS)との間に確立される各セッションは、セッションキャッシュに関連付けられ得る。所与のセッションに対応するセッションコンテキスト情報に加えられた更新は、それぞれのセッションキャッシュにキャッシュすることができる。所与のセッションとの切断が検出されると、DBMSとの新しいセッションを確立することができる。切断されたセッションに関連付けられるセッション情報は、適切なセッションキャッシュから読み込まれ、新しく確立されたセッション上で切断されたセッションのセッション情報を復元するために使用することができる。

セッション回復への従来の手法は、クライアントコンピュータ上のセッションに関連付けられるセッションコンテキスト情報への変更を追跡するために、REDOログを生成するクライアントコンピュータに依存している。セッション情報へのすべての変更(たとえば、DBMSに対して発行されたSETコマンドによる)をログに記録することができる。セッションの切断が発生すると、セッションに対する一連の変更を繰り返すために、新しく確立されたセッション上でREDOログを再生することができる。クライアントコンピュータは複数のデータベースアプリケーションを実行することができ、各データベースアプリケーションはDBMSとの複数のセッションを確立することができることを踏まえると、REDOログを記憶することは、REDOログのストレージを管理するための処理の増加と、REDOログを記憶するためのストレージニーズの増加の観点から、コストがかかる可能性がある。この処理とストレージの負荷は、セッションコンテキストが頻繁に更新される動的な状況では悪化する可能性がある。対照的に、本開示による実施形態は、セッション情報に対して行われた最新の更新をキャッシュし、したがって、セッションキャッシュのストレージニーズを大幅に削減する。

さらに、REDOログを使用したセッション回復は、REDOログの再生を伴う。再生するべきREDOログが多数ある場合、クライアントコンピュータは切断されたセッションを再確立するだけでかなりの時間がかかる可能性がある。対照的に、本開示による実施形態は、セッション情報に対する最新の更新のみをキャッシュするので、ログを再生する必要がなく、セッションの回復が大幅に高速化される。

セッション回復への別の手法は、DBMSに接続されたすべてのクライアントコンピュータ(ユーザ)からのすべてのセッションのセッションコンテキスト情報を管理するDBMSに依存している。DBMSにおいて非常に多くのセッションを管理すると、DBMSのパフォーマンスに影響を与える可能性があり、DBMSはセッション情報を管理するためだけにかなりのリソースを費やす必要がある。対照的に、本開示による実施形態は、DBMSから各クライアントコンピュータへの作業負荷の多くを効果的に再分配する。

上記の説明は、本開示の様々な実施形態を、特定の実施形態の態様がどのように実装され得るかの例とともに示している。上記の例は、唯一の実施形態であると見なされるべきではなく、添付の特許請求の範囲によって定義される特定の実施形態の柔軟性および利点を例示するために提示される。上記の開示および以下の特許請求の範囲に基づいて、特許請求の範囲によって定義される本開示の範囲から逸脱することなしに、他の配置、実施形態、実装形態、および等価物が採用され得る。

100 データベースシステム
102 データベース管理サーバ(DBMS)
102a データベース
104 クライアントコンピュータ
106 通信ネットワーク
108 データベースアプリケーション
110 セッションマネージャ
202 クライアントライブラリ
204 キャッシュマネージャ
206 セッションキャッシュ
208 接続マネージャ
300 コンピューティングシステム
312 処理ユニット
314 システム(メイン)メモリ
316 データストレージ
316 内部データストレージ
320 通信インターフェース
322 I/Oインターフェース
324 システムバス
330 データモジュール
332 オペレーティングシステム
334 アプリケーションプログラム
336 プログラムデータ
338 プログラム/システムモジュール
342 出力デバイス
344 入力デバイス
702 セカンダリDBMS

Claims

コンピュータシステムにおける方法であって、
データベースシステムとの第1のデータベースセッションを確立するステップと、
前記第1のデータベースセッションのセッションコンテキストを定義するセッション情報を、前記コンピュータシステムから前記データベースシステムに通信するステップと、
前記第1のデータベースセッションの前記セッション情報を前記コンピュータシステムのキャッシュメモリにキャッシュするステップと、
前記第1のデータベースセッションの前記セッションコンテキストを透過的に復元するために、前記第1のデータベースセッションの前記コンピュータシステムの前記キャッシュメモリにキャッシュされている前記セッション情報を通信するステップを含む、前記第1のデータベースセッションの切断の検出に応答して、第2のデータベースセッションを確立するステップと、
を備える、方法。
前記セッション情報をキャッシュするステップが、前記データベースシステムに通信された前記セッション情報を備える前記データベースシステムから通信を受信するステップと、前記受信した通信に含まれる前記セッション情報をキャッシュするステップとを含む、請求項1に記載の方法。
前記データベースシステムとの前記第2のデータベースセッションが確立される、請求項1に記載の方法。
前記データベースシステムとは異なる第2のデータベースシステムとの前記第2のデータベースセッションが確立される、請求項1に記載の方法。
前記セッション情報を備えるデータの量があらかじめ定められた値を超えると、前記第1のデータベースセッションの前記セッション情報のキャッシングを終了するステップをさらに備える、請求項1に記載の方法。
前記キャッシングを終了するために前記データベースから通信を受信するステップに応答して、前記第1のデータベースセッションの前記セッション情報のキャッシングを終了するステップを備える、請求項1に記載の方法。
キャッシングが終了したときに前記第1のデータベースセッションのセッション情報の前記キャッシュメモリを消去するステップをさらに備える、請求項6に記載の方法。
コンピュータ実行可能命令が記憶された非一時的コンピュータ可読ストレージ媒体であって、コンピュータデバイスによって実行されると、前記コンピュータデバイスに、
データベースシステムとの第1のデータベースセッションを確立することと、
前記第1のデータベースセッションのセッションコンテキストを定義するセッション情報を、前記コンピュータシステムから前記データベースシステムに通信することと、
前記第1のデータベースセッションの前記セッション情報を前記コンピュータシステムのキャッシュメモリにキャッシュすることと、
前記第1のデータベースセッションの前記セッションコンテキストを透過的に復元するために、前記第1のデータベースセッションの前記コンピュータシステムの前記キャッシュメモリにキャッシュされている前記セッション情報を通信することを含む、前記第1のデータベースセッションの切断の検出に応答して、第2のデータベースセッションを確立することと、
を行わせる、非一時的コンピュータ可読ストレージ媒体。
前記セッション情報をキャッシュするステップが、前記データベースシステムに通信された前記セッション情報を備える前記データベースシステムから通信を受信するステップと、前記受信した通信に含まれる前記セッション情報をキャッシュするステップとを含む、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
前記データベースシステムとの前記第2のデータベースセッションが確立される、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
前記データベースシステムとは異なる第2のデータベースシステムとの前記第2のデータベースセッションが確立される、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
前記コンピュータ実行可能命令が、前記コンピュータデバイスによって実行されると、前記コンピュータデバイスに、前記セッション情報を備えるデータの量があらかじめ定められた値を超えると、前記第1のデータベースセッションの前記セッション情報のキャッシングをさらに終了させる、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
前記コンピュータ実行可能命令が、前記コンピュータデバイスによって実行されると、前記コンピュータデバイスに、前記キャッシングを終了するために前記データベースから通信を受信するステップに応答して、前記第1のデータベースセッションの前記セッション情報のキャッシングをさらに終了させる、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
前記コンピュータ実行可能命令が、前記コンピュータデバイスによって実行されると、前記コンピュータデバイスに、キャッシングが終了したときに前記第1のデータベースセッションのセッション情報の前記キャッシュメモリをさらに消去させる、請求項8に記載の非一時的コンピュータ可読ストレージ媒体。
1つまたは複数のコンピュータプロセッサと、
データベースシステムとの第1のデータベースセッションを確立することと、
前記第1のデータベースセッションのセッションコンテキストを定義するセッション情報を、前記コンピュータシステムから前記データベースシステムに通信することと、
前記第1のデータベースセッションの前記セッション情報を前記コンピュータシステムのキャッシュメモリにキャッシュすることと、
前記第1のデータベースセッションの前記セッションコンテキストを透過的に復元するために、前記第1のデータベースセッションの前記コンピュータシステムの前記キャッシュメモリにキャッシュされている前記セッション情報を通信するステップを含む、前記第1のデータベースセッションの切断の検出に応答して、第2のデータベースセッションを確立することと、
を行うように動作可能であるように、前記1つまたは複数のコンピュータプロセッサを制御するための命令を備えるコンピュータ可読ストレージ媒体と
を備える、装置。
前記セッション情報をキャッシュするステップが、前記データベースシステムに通信された前記セッション情報を備える前記データベースシステムから通信を受信するステップと、前記受信した通信に含まれる前記セッション情報をキャッシュするステップとを含む、請求項15に記載の装置。
前記データベースシステムとの前記第2のデータベースセッションが確立される、請求項15に記載の装置。
前記データベースシステムとは異なる第2のデータベースシステムとの前記第2のデータベースセッションが確立される、請求項15に記載の装置。
前記コンピュータ可読ストレージ媒体が、前記セッション情報を備えるデータの量があらかじめ定められた値を超えると、前記第1のデータベースセッションの前記セッション情報のキャッシングを終了するように動作可能であるように前記1つまたは複数のコンピュータプロセッサを制御するための命令をさらに備える、請求項15に記載の装置。
前記コンピュータ可読ストレージ媒体が、前記キャッシングを終了するために前記データベースから通信を受信するステップに応答して、前記第1のデータベースセッションの前記セッション情報のキャッシングを終了するように動作可能であるように前記1つまたは複数のコンピュータプロセッサを制御するための命令をさらに備える、請求項15に記載の装置。