2.4 サービス・ハンドラの理解
サービス・ハンドラは、Oracle Databaseへの接続ポイントとして機能します。サービス・ハンドラには、ディスパッチャまたは専用サーバー・プロセス、またはプールがあります。
2.4.1 ディスパッチャについて
共有サーバー・アーキテクチャはディスパッチャ・プロセスを使用して、クライアント接続を共通の要求キューに渡します。サーバー・プロセスの共有プールの中のアイドル状態の共有サーバー・プロセスは、共通キューから要求を取り出します。このアプローチでは、小さいサーバー・プロセス・プールで大量のクライアントを処理することが可能です。専用サーバー・モデルと比較した共有サーバー・モデルの大きな利点は、システム・リソースが少なくて済むため、ユーザー数の増加に対応できることです。
リスナーはサービス・ハンドラのタイプとしてディスパッチャを使用しますが、これにクライアント要求を渡すことができます。クライアント要求を受け取ると、リスナーは次のいずれかの処理を実行します。
-
ディスパッチャのプロトコル・アドレスを含むリダイレクト・メッセージをリスナーに発行します。次に、クライアントは、リスナーに要求したネットワーク・セッションを終了し、リダイレクト・メッセージで提供されたネットワーク・アドレスを使用して、ディスパッチャとのネットワーク・セッションを確立します。
リスナーは可能な場合は必ずダイレクト・ハンドオフを使用します。リダイレクト・メッセージは、たとえばディスパッチャがリスナーに対してリモートである場合に使用します。
次の図では、リスナーが接続要求をディスパッチャに直接渡しています。
-
リスナーがクライアント接続要求を受け取ります。
-
リスナーは、接続要求をディスパッチャに直接渡します。
-
クライアントは、ここでディスパッチャに直接接続します。
次の図では、リダイレクトされた接続におけるディスパッチャの役割を示します。
-
リスナーがクライアント接続要求を受け取ります。
-
リスナーは、ディスパッチャの位置をリダイレクト・メッセージでクライアントに通知します。
-
クライアントがディスパッチャに直接接続します。
親トピック: サービス・ハンドラの理解
2.4.2 専用サーバー・プロセスについて
専用サーバー構成では、リスナーはクライアントの着信接続要求ごとに専用サーバー・プロセスを個別に起動します。このプロセスはクライアントへのサービス提供のみを行います。セッション完了後、専用サーバー・プロセスは終了します。専用サーバー・プロセスは接続ごとに起動する必要があるため、共有サーバー構成よりも多くのシステム・リソースが構成に必要になる場合があります。
専用サーバー・プロセスは、クライアント要求を受け取った時にリスナーが開始するサービス・ハンドラのタイプです。クライアント/サーバー接続を完了するには、次のいずれかの処理が発生します。
-
専用サーバーはリスナーから接続要求を継承します。
-
専用サーバーはリスナーにリスニング・プロトコル・アドレスを通知します。リスナーはリダイレクト・メッセージでプロトコル・アドレスをクライアントに渡し、接続を終了します。クライアントは、そのプロトコル・アドレスを使用して、専用サーバーに直接接続します。
前述の処理のどちらかが選択されるかは、オペレーティング・システムおよび使用中のトランスポート・プロトコルによって決まります。
クライアントとデータベースが同じコンピュータ上に存在する場合、クライアント接続は、リスナーを経由せずに専用サーバー・プロセスに直接渡すことができます。これは、bequeathプロトコルとして知られています。セッションを開始するアプリケーションは、接続要求に対する専用サーバー・プロセスを生成します。データベースの起動に使用されるアプリケーションがデータベースと同じコンピュータ上にある場合、この処理は自動的に実行されます。
ノート:
リモート・クライアントが専用サーバーに接続するためには、リスナーとデータベース・インスタンスを同じコンピュータ上で実行する必要があります。
図2-7では、リスナーがクライアント接続要求を専用サーバー・プロセスに渡す様子を示します。
-
リスナーがクライアント接続要求を受け取ります。
-
リスナーは専用サーバー・プロセスを開始し、専用サーバーはリスナーから接続要求を継承します。
-
クライアントがここで専用サーバーに直接接続します。
図2-8では、リダイレクト接続における専用サーバーの役割を示します。
親トピック: サービス・ハンドラの理解
2.4.3 データベース常駐接続プーリングについて
データベース常駐接続プーリングは、データベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放するような一般的なWebアプリケーション使用シナリオに対して、データベース・サーバーの接続プールを提供します。データベース常駐接続プーリングは、専用サーバーをプールします。プール・サーバーは、サーバー・フォアグラウンド・プロセスとデータベース・セッションの組合せに相当します。データベース常駐接続プーリングは、サーバーとリスナーの間の動的な登録を使用します。静的な登録を使用することはできません。
データベース常駐接続プーリングは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、これを使用すると、同じ中間層ホスト上の中間層プロセス間、および異なる中間層ホスト上の中間層プロセス間でもデータベース接続を共有できます。この結果、大量のクライアント接続をサポートするために必要となる基本データベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と切断のコストが削減されるという利点もあります。
データベース常駐接続プーリングは、すべてのクライアント・アプリケーションとプロセスにわたる専用接続のプーリングを提供します。この機能は、データベースへの永続的な接続を維持してサーバー・リソース(メモリーなど)を最適化する必要があるアプリケーションに役立ちます。
データベース常駐接続プールから接続を取得するクライアントは、専用サーバーのかわりにバックグラウンド・プロセス(接続ブローカ)に永続的に接続されます。接続ブローカはプール機能を実装しており、クライアントから専用サーバーのプールへのセッションを使用したインバウンド接続の多重化を実行します。
クライアントがデータベースの作業を実行する必要がある場合、接続ブローカはプールから専用サーバーを選択し、クライアントに割り当てます。その後、クライアントは要求が処理されるまで専用サーバーに直接接続されます。サーバーがクライアント要求の処理を終了した後、サーバーはプールに戻され、クライアントからの接続は接続ブローカに戻されます。
次の図では、そのプロセスを示します。
親トピック: サービス・ハンドラの理解