|
|
WebLogic Server でデータベース接続をコンフィグレーションするには、データ ソースを WebLogic ドメインに追加します。WebLogic JDBC データ ソースを使うと、データベースにアクセスし、データベース接続を管理できます。各データ ソースには、データ ソース作成時およびサーバ起動時に作成される、データベース接続のプールが含まれています。アプリケーションは、JNDI ツリーまたはローカル アプリケーション コンテキストでデータ ソースをルックアップし、その後 getConnection() を呼び出すことで、データ ソースからのデータベース接続を予約します。接続を使い終わったら、アプリケーションはできるだけ早くに connection.close() を呼び出す必要があります。それにより、データベース接続はプールに戻され、他のアプリケーションで使用できるようになります。
データ ソースおよびその接続プールは、システムの安定稼動を維持するための接続管理プロセスを備えています。データ ソースのこれらのオプションは、アプリケーションや環境に合わせて設定できます。以下の節では、それらのオプションと、それらを有効にする方法について説明します。
WebLogic ドメインに JDBC データ ソースを作成するには、Administration Console または WebLogic Scripting Tool (WLST) を使用できます。詳細については、以下を参照してください。
SAMPLES_HOME\server\examples\src\examples\wlst\online\jdbc_data_source_creation.py にあります。SAMPLES_HOME は、WebLogic Server のメインのサンプル ディレクトリを表します。『WebLogic Scripting Tool ガイド』の「
WLST オンライン サンプル スクリプト」を参照してください。 | 注意 : | weblogic.Admin コマンドライン ユーティリティは、WLST に置き換えられました。任意指定で WebLogic Server と一緒にインストールされる WebLogic Server サンプルには、weblogic.Admin JDBC コマンドの代わりに使用できるサンプル スクリプトが含まれています。インストールした場合、サンプル スクリプトは WL_HOME\samples\server\examples\src\examples\wlst\online にあります。WL_HOME は、メインの WebLogic ディレクトリ (C:\bea\wlserver_10.0 など) です。 |
JDBC データ ソース属性の詳細については、『WebLogic Server MBean リファレンス』の「JDBCDataSourceBean」およびそのすべての子 MBean を参照してください。
| 注意 : | Administration Console の JDBC データ ソース作成ページにリストされている JDBC ドライバは、必ずしも WebLogic Server で使用されるものとして認定されているわけではありません。JDBC データ ソース ページの主旨に沿って、使用可能な多くのデータベース管理システムへの接続を簡単に作成できるように JDBC ドライバの一覧が表示されます。 |
| 注意 : | データ ソースで JDBC ドライバを使用してデータベース接続を作成するには、データ ソースをデプロイする各サーバに JDBC ドライバをインストールする必要があります。ドライバは、Administration Console の JDBC データ ソース作成ページに、データ ソースのコンフィグレーションに役立つ、既知の必要なコンフィグレーション オプションと一緒に一覧表示されています。一覧にある JDBC ドライバが必ずしもインストールされているとは限りません。ドライバのインストールでは、システム パス、クラスパス、その他の環境変数の設定を行う場合もあります。「Type 4 サードパーティ JDBC ドライバに対する環境設定」を参照してください。 |
| 注意 : | JDBC ドライバを更新すると、コンフィグレーションの要件が変わる場合があります。Administration Console の JDBC データ ソース作成ページでは、WebLogic Server ソフトウェアがリリースされた時点で知られていたコンフィグレーション要件を使用します。JDBC ドライバのコンフィグレーション オプションが変更されていると、データ ソース作成時、またはデータ ソース作成後にそのプロパティ ページで、コンフィグレーション オプションを手動でオーバーライドすることが必要な場合があります。 |
JDBC データ ソースには、データ ソースの ID、データベース接続でのデータの扱われ方、およびデータ ソースからの接続がグローバル トランザクションで使用される場合のトランザクションの扱われ方を決定するオプションがあります。JDBC データ ソースの全般的なオプションは、Administratin Console の [JDBC データ ソース : コンフィグレーション : 全般] ページで参照できます。また、これらのオプションには、JDBCDataSourceBean の子である JDBCDataSourceParamsBean からもアクセスできます。
データベースへの接続に使用する JDBC ドライバを決定する際には、環境内でさまざまなベンダのドライバを試してみることが必要です。通常、JDBC ドライバのパフォーマンスは、アプリケーションで使用する SQL コード、JDBC ドライバの実装など、さまざまな要因によって左右されます。
サポートされる JDBC ドライバの詳細については、『WebLogic Platform 10.0 でサポート対象のコンフィグレーション』の「サポート対象のデータベース コンフィグレーション」を参照してください。
JDBC データ ソース名は、WebLogic ドメイン内でデータ ソースを識別するために使用されます。システム リソース データ ソースの場合、名前は他のすべての JDBC システム リソース (データ ソースとマルチ データ ソースを含む) に渡ってユニークなものとする必要があります。名前の競合を避けるため、データ ソース名はサーバ、クラスタ、JMS キュー、JMS トピック、JMS サーバなど、他のコンフィグレーション オブジェクト名にまたがってもユニークであることが必要です。アプリケーションをスコープ指定した JDBC アプリケーション モジュールの場合、データ ソース名は同様にスコープ指定された JDBC データ ソースとマルチ データ ソースに渡ってユニークなものとする必要があります。
WebLogic Server 9.0 以降のリリースでは、データ ソースをコンフィグレーションできます。そのため、データ ソースは複数の名前で JNDI ツリーにバインドされることになります。1 つの JDBC 接続プールを指す複数のデータ ソースを含む従来のコンフィグレーションの代わりに、複数の JNDI 名を持つデータ ソースを使用できます。
Administration Console を使用して JNDI 名を既存のデータ ソースに追加するには、各 JNDI 名を別々の行に入れて JNDI 名属性に名前を追加します。変更を行った後にシステムを再起動するか、または変更を行う前にデータ ソースをアンデプロイし、変更を行った後に再デプロイする必要があります。次の手順に従います。
変更をアクティベートした後、データ ソースを再デプロイするか、サーバを再起動しないと、変更は有効になりません。
Administration Console を使用して JDBC データ ソースをコンフィグレーションすると、WebLogic Server は JDBC ドライバの種類に基づき、自動的に特定のトランザクション オプションを選択します。
[グローバル トランザクションのサポート] : (デフォルトで選択) XA ドライバを選択していなくても、グローバル トランザクションでデータ ソースからの接続を使用する場合には、このオプションを選択します。詳細については、「XA 以外の JDBC ドライバでのグローバル トランザクションのサポートの有効化」を参照してください。
[グローバル トランザクションのサポート] を選択した場合は、グローバル トランザクションを処理するときに、WebLogic Server がトランザクション ブランチに使用するプロトコルも選択する必要があります。
| 注意 : | [ロギング ラスト リソース] は、マルチ データ ソースで使用されるデータ ソースについてはサポートされていません。 |
XAResource.prepare を呼び出すと、例外が送出されます。
アプリケーションでグローバル トランザクションを使用する場合、JDBC データ ソース内にデータベース接続を作成するのに XA JDBC ドライバを使用する必要があります。XA ドライバが使用できないデータベースの場合、または XA ドライバを使用しないことを選択した場合は、データ ソース内でグローバル トランザクションのサポートを有効化する必要があります。また、アプリケーションが、以下の条件に適合する場合も、グローバル トランザクションのサポートを有効化する必要があります。
EJB アーキテクチャでは、データベース処理を行っている複数の EJB が単一のトランザクションの一部として呼び出されるのは、よくあることです。XA がない場合、これを行える唯一の方法は、すべてのトランザクション参加リソースでまったく同じデータベース接続を使用することです。グローバル トランザクションを有効化して、[ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] のどちらかを選択すると、WebLogic Server は内部で JTS ドライバを使用して、EJB 間で接続を明示的に渡さなくても、すべての EJB が同じトランザクション コンテキスト内で確実に同じデータベース接続を使用するようにします。
複数の EJB が 1 つのトランザクションに参加しており、かつ、データベース接続に XA JDBC ドライバを使用しない場合は、以下のオプションを使用してデータ ソースをコンフィグレーションします。
このようにコンフィグレーションすることによって、同じトランザクション内のすべてのデータベース作業で同じデータベース接続を内部的に使用することが JTS ドライバに強制されます。
XA (XA ドライバが必須) では、EJB はトランザクションの各部分に対して、別々のデータベース接続を使用できます。WebLogic Server は、2 フェーズ コミット プロトコルを使用してトランザクションを調整します。それにより、トランザクションがすべて完了するか、まったく完了しないかであることが保証されます。
WebLogic Server では、JDBC データ ソースを通じてのロギング ラスト リソース (LLR) トランザクションの最適化をサポートしています。LLR は、1 つの XA 以外のリソースが、XA と同じ ACID 保証を伴ってグローバル トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。LLR は、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLR リソースは、トランザクション処理にローカル トランザクションを使用します。WebLogic Server トランザクション マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLR リソースのローカル トランザクションの結果に基づいて、グローバル トランザクションに対するコミットの決定を下します。
LLR の最適化により、次のようにしてパフォーマンスが向上します。
LLR 用にコンフィグレーションされたデータ ソースからの接続が、2 フェーズ コミット (2PC) グローバル トランザクションに参加している場合、WebLogic Server トランザクション マネージャは次の処理によって、トランザクションを完了させます。
1 フェーズ コミット (1PC) のグローバル トランザクションの場合、LLR はローカル トランザクションを使用してデータベース操作を完了させることによって、XA オーバーヘッドを排除しますが、2PC トランザクション レコードはデータベースへ書き込まれません。
ロギング ラスト リソースの最適化により、LLR 参加リソースに対するコミット レコードが書き込まれ、データの整合性が維持されます。ローカル トランザクション コミットの最中にトランザクションが失敗した場合、WebLogic Server トランザクション マネージャは、他のすべてのトランザクション参加リソースに対してトランザクションをロールバックします。失敗から回復するため、WebLogic Server トランザクション マネージャはデフォルトのストアにある他のトランザクション ログ ファイルと一緒に LLR リソース上のトランザクション ログを読み取り、必要なすべてのトランザクション処理を完了させます。XA 参加リソースと関連付けられた処理は、コミット レコードが存在すればコミットされます。そうでなければ、処理はロールバックされます。
LLR を利用可能な JDBC データ ソースを作成する手順については、Administration Console オンライン ヘルプの「LLR を利用可能な JDBC データ ソースの作成」を参照してください。ロギング ラスト リソース トランザクション処理の詳細については、『WebLogic JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
環境によっては、パフォーマンス上の利点を得るために、トランザクション処理に 2 フェーズ コミット プロトコルの代わりに、LLR トランザクション プロトコルの使用を検討する必要があります。LLR トランザクション プロトコルを使用すると、以下の利点が得られます。
| 注意 : | LLR の最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLR での読み取り操作では、XA での読み取り操作と比べて、幾分パフォーマンスが低下します。最高のパフォーマンスを得るためには、読み取り専用操作のための LLR ではない JDBC データ ソースをコンフィグレーションする必要があります。 |
| 注意 : | LLR でのパフォーマンス チューニングの詳細については、『WebLogic JTA プログラマーズ ガイド』の「LLR でのパフォーマンス最適化」を参照してください。 |
LLR トランザクションの最適化を有効化するには、JDBC データ ソースをロギング ラスト リソース トランザクション プロトコルで作成して、アプリケーション内のデータ ソースからデータベース接続を使用します。WebLogic Server は、データベース上に必要なテーブルを自動作成します。
Administration Console オンライン ヘルプの「LLR を利用可能な JDBC データ ソースの作成」を参照してください。
アプリケーションで、LLR を利用可能なデータ ソースからの JDBC 接続を、その他の任意のデータ ソースからの JDBC 接続と同じように使用します。トランザクションの開始後、JNDI ツリーでデータ ソースをルックアップし、その後データ ソースからの接続を要求します。ただし、LLR 最適化が行われていると、WebLogic Server は接続の要求を内部で管理し、トランザクション処理を XA トランザクションとは異なったやり方で扱います。ロギング ラスト リソースのしくみの詳細については、『WebLogic JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
weblogic.transaction.nonxa.NonXAResource インタフェースを実装するリソース アダプタ (コネクタ) は、LLR リソースもまた参加しているグローバル トランザクションには参加できません。どちらも、トランザクションの最後のリソースである必要があるからです。双方のリソース タイプが同じトランザクションに参加している場合、衝突が検出されると、トランザクションの commit() メソッドが、javax.transaction.RollbackException を送出します。
LLR を利用可能な JDBC データ ソースをコンフィグレーションする際には、以下の要件および制限事項を考慮してください。ロギング ラスト リソースのしくみの詳細については、『WebLogic JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
WL_LLR_SERVERNAME です。テーブル名は、Administration Console の [詳細] オプションの下の [サーバ｜コンフィグレーション｜全般] タブでコンフィグレーションできます。
JDBC データ ソースで分散トランザクションのサポートが必要なのに、DBMS で利用できる XA 対応のドライバがない場合は、データ ソースに対して [2 フェーズ コミットのエミュレート] オプションを選択できます。これにより、データ ソースからの接続が参加しているトランザクションについて、データ ソースは 2 フェーズ コミットをエミュレートするようになります。このオプションは、[JDBC データ ソース｜コンフィグレーション｜全般] タブの詳細設定オプションです。
[2 フェーズ コミットのエミュレート] が選択されている (EnableTwoPhaseCommit が true に設定されている) 場合、非 XA JDBC リソースは XAResource.prepare() メソッド呼び出し中に常に XA_OK を返します。リソースは、後続の XAResource.commit() または XAResource.rollback() の呼び出しに応答して、ローカル トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック エラーの結果、アプリケーション データは矛盾した状態のまま残される場合があります。
[2 フェーズ コミットのエミュレート] オプションが Administration Console で選択されていない (EnableTwoPhaseCommit が false に設定されている) 場合、非 XA JDBC リソースにより、XAResource.prepare() が失敗します。トランザクションに参加するリソースが 1 つだけの場合、1 フェーズの最適化が XAResource.prepare() をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットされます。
| 注意 : | [2 フェーズ コミットのエミュレート] オプションを使用していると、データの整合性が損なわれるおそれがあります。[2 フェーズ コミットのエミュレート] オプションを使用するのではなく、XA 対応の JDBC ドライバ、または [ロギング ラスト リソース] オプションを使用することをお勧めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。 |
この非 XA JDBC ドライバのサポートを「JTS ドライバ」と呼ぶこともあります。WebLogic Server では WebLogic JTS ドライバを使用してこの機能をサポートしているためです。JTS ドライバの詳細については、『WebLogic JDBC プログラマーズ ガイド』の「WebLogic JTS ドライバの使い方 (非推奨)」を参照してください。
WebLogic Server では、[2 フェーズ コミットのエミュレート] データ ソース トランザクション オプションで非 XA JDBC リソースのグローバル トランザクションへの参加をサポートしていますが、このリソースを使用するためにアプリケーションを設計する際に考慮すべき制限事項があります。非 XA ドライバは XA/2PC に従わず、1 フェーズのコミットおよびロールバック処理のみをサポートするため、WebLogic Server は (JTS ドライバを介して)、トランザクション マネージャによって制御されるトランザクションにリソースが参加できるように、譲歩する必要があります。
[2 フェーズ コミットのエミュレート] オプションを使用する前に、以下の制限およびリスクを考慮してください。
非 XA リソースで 2 フェーズ コミットのエミュレートを選択する場合 (enableTwoPhaseCommit = true)、非 XA リソースに対するトランザクションの準備フェーズは常に成功します。したがって、非 XA リソースは 2 フェーズ コミット (2PC) プロトコルに実際には参加していないため、失敗しやすくなります。準備フェーズ後に非 XA リソースでエラーが発生した場合、XA トランザクションの参加コンポーネントがトランザクションをコミットする一方で、非 XA リソースはトランザクションをロールバックする可能性があり、ヒューリスティックな終了とデータの矛盾を招きます。
データの整合性が失われるおそれがあるため、2 フェーズ コミットのエミュレートのオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。
非 XA ドライバはローカル データベースのトランザクションのみを操作するため、外部トランザクション マネージャに関して、トランザクションがデータベース内で保留中の状態にあるという概念はありません。非 XA リソースの XAResource.recover() が呼び出されると、コミットまたはロールバックする必要のあるトランザクションが存在する場合でも、常に Xid (トランザクション ID) の空のセットが返されます。そのため、グローバル トランザクションで非 XA リソースを使用するアプリケーションは、システムの障害から回復してデータの整合性を維持することができません。
WebLogic Server は特定の JDBC 接続に関連付けられたデータベース ローカル トランザクションに依存して、非 XA リソースのグローバル トランザクションへの参加をサポートしているため、同じ JDBC データ ソースが、複数の WebLogic Server インスタンス上にグローバル トランザクション コンテキストを持つアプリケーションからアクセスされる場合、JTS ドライバは常に、トランザクション内のアプリケーションによって確立される最初の接続に JDBC の処理をルーティングします。たとえば、あるサーバでアプリケーションがトランザクションを開始して非 XA JDBC リソースにアクセスし、別のサーバに RMI (Remote Method Invocation) 呼び出しを行って、同じ基底の JDBC ドライバを使用するデータ ソースにアクセスすると、JTS ドライバは、そのリソースには別のサーバ上のトランザクションに関連付けられた接続があることを認識して、RMI のリダイレクトを最初のサーバの実際の接続に設定します。接続に対するすべての操作は、最初のサーバで確立された 1 つの接続上で行われます。この動作では、リモート接続を設定して RMI 呼び出しを物理的な接続に対して行うことに関するオーバーヘッドが生じるため、パフォーマンスが低下する可能性があります。
非 XA リソース (2 フェーズ コミットのエミュレートを選択) が WebLogic Server トランザクション マネージャに登録される場合は、XAResource インタフェースを実装するクラスの名前と共に登録されます。2 フェーズ コミットのエミュレートを選択したすべての非 XA リソースは XAResource インタフェースに対する JTS ドライバを使用するため、グローバル トランザクションに参加する (2 フェーズ コミットのエミュレートを選択した) すべての非 XA リソースは、同じ名前で登録されます。グローバル トランザクションで複数の非 XA リソースを使用する場合、名前の衝突やヒューリスティックな終了が起きる可能性があります。
各 JDBC データ ソースには、データ ソースのデプロイ時またはサーバ起動時に作成される、JDBC 接続のプールが含まれています。アプリケーションは、プールから接続を使用し、使用し終わると、プールに戻します。接続のプールにより、アプリケーション用にデータベース接続を作成するという費用のかかるタスクがなくなるため、パフォーマンスが向上します。
以下の節では、JDBC データ ソースの接続プールのオプションについて説明します。
以下で、これらのオプションおよびその他の関連オプションの詳細を参照し、設定できます。
Administration Console を使用して JDBC データ ソースを作成する際、JDBC ドライバを選択するよう求められます。Administration Console にはドライバ クラス名が表示され、ドライバに必要な URL の作成を支援します。選択したドライバは、データ ソースをデプロイするすべてのサーバのクラスパスに入っている必要があります。WebLogic Server に付属しているのは、Administration Console で一覧表示される JDBC ドライバの全部ではなく一部です。
これらのドライバはすべて、weblogic.jar マニフェスト ファイルによって参照され、サーバのクラスパスで明示的に定義される必要はありません。
WebLogic JDBC データ ソースは、JDBC ドライバで実装される javax.sql.ConnectionPoolDataSource インタフェースをサポートしています。JDBC データ ソース内の Properties 属性にプロパティおよびその値を追加して、ドライバ レベルの機能を有効化できます。Properties 属性におけるドライバ レベルのプロパティは、ドライバの ConnectionPoolDataSource オブジェクトで設定されます。
WebLogic Server では、データ ソースにおけるデータベース接続の作成時に、自動的に SQL コードを実行して、データベース接続を初期化できます。この機能を有効にするには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページの [初期化 SQL] 属性に「SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。この属性を空白のままにしておくと (デフォルト)、データベース接続を初期化するコードは実行されません。
サーバの起動時、接続プールの拡張時、接続の更新時など、データ ソースにおけるデータベース接続の作成時には常にここで指定したコードが実行されます。
この機能を使って、接続ごとの DBMS 固有の動作を設定したり、要求されたアクションを実行できるメモリやパーミッションを接続が備えているかを確認したりできます。
コードは、「SQL」で開始し、その後にスペースを入れます。次に例を示します。
SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
SQL SET LOCK MODE TO WAIT
InitSQL によって設定できるオプションは、DBMS ごとに異なります。
| 注意 : | Init SQL は、動的な属性ではありません。Init SQL の値を変更する際には、データ ソースをアンデプロイしてから再デプロイするか、またはサーバを再起動する必要があります。 |
以下の節では、セキュリティ資格を DBMS に渡す方法についての情報を提供します。
Weblogic Server では、セキュリティ権限に基づいて、次の 2 種類のデータ ソース プールが提供されます。
ここでは、セキュリティ資格を DBMS に渡す方法を比較します。
資格を渡すための最も単純な方法は、DBMS のユーザ アカウント名とパスワードを接続プールに提供する方法です。この場合、プール内のすべての接続で同じ資格を使用して DBMS にアクセスします。詳細については、Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。
| 注意 : | パスワードは [プロパティ] フィールド (プロダクション環境では不可) に名前と値の組み合わせとして入力することも、[パスワード] フィールドに入力することも可能です。[パスワード] フィールドの値は、物理的なデータベース接続を作成するときに JDBC ドライバに渡される Properties で定義されている、いかなる password 値をもオーバーライドします。プロパティ文字列でパスワード プロパティの代わりに Password 属性を使用することをお勧めします。なぜなら、Password 値はコンフィグレーション ファイル内で暗号化 (モジュール ファイルの jdbc-driver-params タグで password-encrypted 属性として保存) され、Administration Console では表示されなくなるからです。 |
データ ソースで [接続時にクライアント ID を設定] 属性が有効になっている場合は、アプリケーションによってデータ ソースのデータベース接続が要求されたときに、WebLogic Server インスタンスが現在の WebLogic ユーザ ID を判別し、マップされているデータベース ID を軽量なクライアント ID として設定します。この場合も、プール内のすべての接続で同じ資格を使用して DBMS にアクセスします。基本的なコンフィグレーション手順は次のとおりです。
この機能は、JDBC ドライバおよび DBMS の機能に依存します。Oracle および DB2 データベースで、ベンダ提供の拡張メソッドを使用する場合にのみサポートされます。
| 注意 : | [接続時にクライアント ID を設定] と [ID ベースの接続プールを有効化] は相互に排他的です。アプリケーション環境でセキュリティ資格を渡すために両方のメカニズムが必要な場合は、別々のデータ ソースを作成して、一方は [接続時にクライアント ID を設定] を指定し、もう一方は [ID ベースの接続プールを有効化] を指定してください。 |
ID ベースの接続プールを使用すると、アプリケーションごとに異なる DBMS 資格で物理的な接続をプールすることによって、特定の DBMS 資格で JDBC 接続を使用できます。
データ ソースで [ID ベースの接続プールを有効化] 属性が有効になっている場合は、アプリケーションによってデータ ソースのデータベース接続が要求されたときに、WebLogic Server インスタンスは既存の物理的接続を選択するか、または WebLogic ユーザの資格および DBMS 資格のマップに基づき、要求された DBMS ID との新しい物理的接続を作成します。基本的なコンフィグレーション手順は次のとおりです。
| 注意 : | [接続時にクライアント ID を設定] と [ID ベースの接続プールを有効化] は相互に排他的です。アプリケーション環境でセキュリティ資格を渡すために両方のメカニズムが必要な場合は、別々のデータ ソースを作成して、一方は [接続時にクライアント ID を設定] を指定し、もう一方は [ID ベースの接続プールを有効化] を指定してください。 |
物理的な接続がどのように作成されるかに関係なく、プール内の物理的な各接続は、プールによって維持される独自の DBMS 資格情報を持ちます。物理的な接続がプールによっていったん予約されると、現在のスレッドが WebLogic ユーザの資格を変更しても、その DBMS 資格は変更されず、同じ接続が使い続けられます。
グローバル トランザクションの中で実行される場合、アプリケーションは現在のスレッド上の資格を変更して、別の資格に基づき複数の JDBC 接続を取得することができます。ただし、ID ベースのプール機能では、グローバル トランザクションの中での WebLogic JDBC データ ソースの複数の論理 JDBC 接続を、単一の物理 JDBC 接続にマップします。つまり、WebLogic サーバ インスタンスに対する 1 つの WebLogic JDBC データ ソースにつき、ただ 1 つの DBMS 資格のみが、グローバル トランザクションについて尊重されるということです。
ID ベースのプールにおいてロギング ラスト リソース (LLR) トランザクションの最適化を利用するには、以下の変更を行う必要があります。
WebLogic Server ドメインの JDBC データ ソース内の接続プール属性を正しくコンフィグレーションすることで、アプリケーションおよびシステムのパフォーマンスを向上させることができます。以下の節では、JDBC データ ソースの接続プールのチューニング オプションについて説明します。
アプリケーションまたは EJB でプリペアド ステートメントや呼び出し可能ステートメントを使用すると、アプリケーション サーバとデータベース サーバの間の通信およびデータベース サーバ自体においてかなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Server ではアプリケーションで使用するプリペアド ステートメントおよび呼び出し可能ステートメントをキャッシュできます。アプリケーションまたは EJB が、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Server はキャッシュ内に格納されている文を再利用します。プリペアド ステートメントや呼び出し可能ステートメントを再利用することで、データベース サーバの CPU の使用率が下がり、現在のステートメントのパフォーマンスが向上するため、CPU サイクルを他のタスクに割り当てることができます。
データ ソースの各接続には、接続に使用するプリペアド ステートメントおよび呼び出し可能ステートメントのキャッシュが個別に備わっています。しかし、ステートメント キャッシュのコンフィグレーションは、データ ソースごとに行います。つまり、データ ソース内の各接続のステートメント キャッシュは、そのデータ ソースについて指定されたステートメント キャッシュ オプションを使用しますが、各接続は、独自に文をキャッシュします。ステートメント キャッシュのコンフィグレーション オプションには、次のようなものがあります。
10 です。「ステートメント キャッシュのサイズ」を参照してください。
データ ソースのステートメント キャッシュ オプションの設定には、Administration Console を使用できます。Administration Console オンライン ヘルプの「JDBC 接続プールのステートメント キャッシュのコンフィグレーション」を参照してください。
ステートメント キャッシュのタイプ (つまりアルゴリズム) は、データ ソースの各接続のキャッシュに格納するプリペアド ステートメントと呼び出し可能ステートメントを決定します。次のオプションから選択できます。
[LRU] (最長時間未使用。デフォルト) をステートメント キャッシュのタイプとして選択すると、WebLogic Server は接続で使用されるプリペアド ステートメントおよび呼び出し可能ステートメントを、ステートメント キャッシュのサイズに到達するまでキャッシュします。アプリケーションが Connection.prepareStatement() を呼び出すと、WebLogic Server はその文がステートメント キャッシュに格納されているかどうかを確認します。格納されていた場合、WebLogic Server はキャッシュされていた文を (それがすでに使用されていなければ) 返します。文がキャッシュ内に存在せず、キャッシュがいっぱい (キャッシュ内の文の数 = ステートメント キャッシュのサイズ) であった場合、WebLogic Server はキャッシュ内の既存の文のうち未使用時間の最も長いものを判断し、キャッシュ内のその文と新しい文を入れ替えます。
WebLogic Server の LRU ステートメント キャッシュ アルゴリズムは、近似 LRU 方式を使用します。
[固定] をステートメント キャッシュのタイプとして選択すると、WebLogic Server は接続で使用されるプリペアド ステートメントおよび呼び出し可能ステートメントを、ステートメント キャッシュのサイズに到達するまでキャッシュします。追加の文が使用された場合、これらはキャッシュされません。
このステートメント キャッシュ アルゴリズムでは、ほとんど使われない文を意図せずキャッシュしてしまうことがあります。多くの場合、LRU アルゴリズムが使用されます。ほとんど使われない文が、キャッシュ内で最終的には頻繁に使われる文に置き換えられるからです。
[ステートメント キャッシュ サイズ] 属性は、データ ソースの各インスタンスの各接続にキャッシュするプリペアド ステートメントと呼び出し可能ステートメントの総数を決定します。文をキャッシュすることで、システムのパフォーマンスが向上します。ただし、DBMS でオープンなプリペアド ステートメントと呼び出し可能ステートメントがどのように処理されるかを考慮する必要があります。多くの場合、DBMS は開いている各文について、カーソルを保持します。これは、ステートメント キャッシュ内のプリペアド ステートメントおよび呼び出し可能ステートメントに対して適用されます。キャッシュされた文の数が多すぎると、データベース サーバ上のオープン カーソル数の上限を超えてしまうことがあります。
たとえば、10 個の接続があるデータ ソースが 2 つのサーバにデプロイされている場合、[ステートメント キャッシュ サイズ] を 10 (デフォルト値) に設定すると、キャッシュされた文に対してデータベース サーバ上で 200 個 (10 x 2 x 10) のカーソルを開く可能性があります。
ステートメント キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。ステートメント キャッシュを使用する場合は、以下の制限に留意してください。
ここに示す以外にも、文のキャッシングに関連した問題が存在する可能性があります。プリペアド ステートメントまたは呼び出し可能ステートメントに関連するシステムでエラーが見つかった場合は、ステートメント キャッシュのサイズを 0 に設定して文のキャッシングをオフにし、問題がプリペアド ステートメントのキャッシングに起因するものかどうかをテストする必要があります。
キャッシュ内に格納されたプリペアド ステートメントは、プリペアド ステートメントのキャッシュ時に特定のデータベース オブジェクトを参照します。キャッシュに格納されたプリペアド ステートメントで参照されるデータベース オブジェクトに対して、何らかの DDL (データ定義言語) 処理を実行すると、それらの文は次に実行したときに失敗する可能性があります。たとえば、select * from emp などの文をキャッシュしてから、emp テーブルを削除して再作成した場合、その文が準備されたときに存在した emp テーブルはなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、プリペアド ステートメントは、キャッシュされた時点でデータベース内のテーブルの各カラムのデータ型にバインドされます。テーブルのカラムを追加、削除、または再配列すると、キャッシュに格納されているプリペアド ステートメントは、再び実行されたときに失敗するおそれがあります。
setNull バインド変数を使用するプリペアド ステートメントをキャッシュする場合、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、null 以外の値で実行したときにデータが切り捨てられたり、文が失敗したりするおそれがあります。
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//これは正しくない
else
setLong(2,sal)
if (sal == null)
setNull(2,long)//これは正しい
else
setLong(2,sal)
WebLogic Server でキャッシュされたプリペアド ステートメントまたは呼び出し可能ステートメントは、データベースのカーソルを開くことができます。キャッシュされた文の数が多すぎると、接続のためのオープン カーソル数の上限を超えてしまうことがあります。接続のためのオープン カーソル数の上限を超えないようにするには、データベース管理システムの上限を変更するか、またはデータ ソースのステートメント キャッシュのサイズを低減します。
データ ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Server には、2 種類の基本的なテスト方法があります。
次の節では、自動接続テストのオプションについて説明します。手動接続テストの詳細については、「データ ソースおよびデータベース接続のテスト」を参照してください。
データ ソースの自動テスト オプションをコンフィグレーションするには、JDBCConnectionPoolParamsBean を使用して、Administration Console または WLST から以下のオプションを設定します。
SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。[テスト対象のテーブル名] は、データベース接続のテストを有効にするための必須の属性です。
これらのオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『WebLogic Server MBean リファレンス』の「JDBCConnectionPoolParamsBean」を参照してください。
接続テスト オプションを設定する手順については、Administration Console オンライン ヘルプの「JDBC データ ソースのテスト オプションのコンフィグレーション」を参照してください。
WebLogic Server はデータ ソースのデータベース接続をテストする際、データ ソースからの接続を予約し、接続に対して小さなクエリを実行し、その後データ ソースのプールに接続を戻します。サーバ インスタンスは、プールの状態に関する統計情報 (接続テストの所要時間、接続を待機している接続数、テストされた接続数など) を追跡します。最近実施された接続動作テストの履歴は、接続テストが失敗したとサーバ インスタンスが判断するまでの待機時間を計算するために使用されます。サーバ インスタンスは、スレッドの接続に通常よりも時間がかかっていると判断すると、以下のいずれかの時点まで他のスレッドのテストを遅延させます。
テストで使用するクエリは、[テスト対象のテーブル名] の値によって決定されます。値がテーブル名の場合、クエリは select 1 from table_name となります。[テスト対象のテーブル名] に、先頭が SQL で直後にスペースとクエリが続く完全なクエリが含まれていれば、WebLogic Server はデータベース接続のテスト時に、そのクエリを使用します。
接続がテストに失敗すると、WebLogic Server は接続を閉じて再作成し、その後、新しい接続をテストします。
接続テストのセマンティクスの詳細については、以下の節で説明しています。
データ ソース内に接続が作成されると、WebLogic Server は [テスト対象のテーブル名] の値で定義されたクエリを使用して、各接続をテストします。接続の作成は、サーバ起動時かデータ ソース作成時にデータ ソースがデプロイされる場合、接続の要求を満たすために容量を増大させる場合、または接続テストに失敗した接続を再作成する場合に、行われます。
このテストの目的は、アプリケーションが接続を要求したときに、必ず新しい有効な接続がすぐに使用できるようにしておくことです。
[テスト頻度] が 0 より多い場合、WebLogic Server はデータ ソース内の使用されていないデータベース接続を定期的にテストします。テストは、[テスト対象のテーブル名] で定義されたクエリに基づいています。接続がテストに失敗した場合、WebLogic Server は接続を閉じ、接続を再作成し、新しい接続をテストしてから、その接続をプールに戻します。
[予約時に接続をテスト] が有効化されている場合、アプリケーションがデータ ソースからの接続を要求すると、WebLogic Server はアプリケーションに渡す前に、その接続を [テスト対象のテーブル名] で指定されたクエリを使用してテストします。
予約済みの接続のテストは、接続リクエストに応じるにあたり遅延を生じさせる可能性がありますが、アプリケーションが接続を取得した時点で、その接続は確実に有効です。[アイドル プール接続を信頼する秒数] をチューニングすることで、予約済みの接続のテストの影響を最小限に抑えることができます。「アイドル プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
DBMS への接続がたとえ一瞬でも失われると、通常、データ ソースにおける JDBC 接続の一部またはすべてが切断されます。データ ソースが予約時の接続テストを行うようにコンフィグレーションされている場合、あるアプリケーションによってデータベース接続がリクエストされると、WebLogic Server はその接続をテストし、その接続が切断されていることが分かると、リクエストに応えるため、新しい接続と置き換えようとします。通常、DBMS がオンラインに復帰すると更新プロセスは成功しますが、場合によって (障害の一部のモードにおいては)、切断された接続のテストによって、長時間の遅延を強いられる可能性があります。
この遅延を最小限に抑えるため、WebLogic データ ソースには、何度か連続してテストが失敗すると、データ ソース内のすべての接続を切断されているものと見なして閉じるロジックが含まれています。すべての接続が閉じられた後に、アプリケーションが接続を要求すると、データ ソースは先に切断された接続のテストを行うことなく、接続を作成します。この動作によって、データ ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小化されます。
WebLogic Server は、データ ソースの [テスト頻度] の設定に基づいてすべての接続を閉じるまでのテストの失敗回数を決定します。
DBMS が使用できなくなると、データ ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ ソースが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。
この遅延を最小限に抑えるため、WebLogic データ ソースには、2 回連続して失敗が生じたらデータ ソースを無効化して、切断されている接続を置き換えるロジックが含まれています。アプリケーションが、無効化されたデータ ソースから接続をリクエストすると、即座に ConnectDisabledException が送出され、接続が使用できないことがクライアントに知らされます。
この方法で無効化されたデータ ソースについては、定期的に更新プロセスが実行されます。更新プロセスでは、次のことが実行されます。
また、Administration Console を使用して手動でデータ ソースを有効化することもできます。
大量のトラフィックが発生しているなかでデータベース接続テストを行うと、アプリケーションのパフォーマンスが悪化します。接続テストの影響を最小化するには、JDBC データ ソース コンフィグレーションの [アイドル プール接続を信頼する秒数] 属性を設定して、最近使用またはテストしたデータベース接続を信頼して接続テストをスキップします。
データ ソース上で [予約時に接続をテスト] が有効化されている場合、アプリケーションがデータベース接続をリクエストすると、WebLogic Server はアプリケーションに渡す前にその接続をテストします。接続が正常に使用またはテストされてデータ ソースに戻された後、[アイドル プール接続を信頼する秒数] に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。
データ ソースに対する [テスト頻度] が 0 より多い (定期テストが有効化されている) 場合も、WebLogic Server は接続が正常に使用されて、[アイドル プール接続を信頼する秒数] で指定した時間内にデータ ソースに戻されていれば、接続テストをスキップします。
[アイドル プール接続を信頼する秒数] を設定する手順については、Administration Console オンライン ヘルプの「JDBC データ ソースのテスト オプションのコンフィグレーション」を参照してください。
[アイドル プール接続を信頼する秒数] は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などには、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。
接続テストの属性は、環境に最もよく適合するように設定する必要があります。たとえば、アプリケーションがデータベース接続の失敗を許容できない場合は、[アイドル プール接続を信頼する秒数] を 0 に設定して確実に [予約時に接続をテスト] を有効化しておき、WebLogic Server が接続をアプリケーションに渡す前に、毎回その接続のテストを行うようにします。アプリケーションがデータ ソースから接続を取得する際の遅延に影響を受けやすく、時折の接続失敗は許容できるのであれば、[アイドル プール接続を信頼する秒数] をより高い数値に、[テスト頻度] を低い数値に設定し、[予約時に接続をテスト] を有効化する必要があります。これらの設定によりアプリケーションは、アプリケーションが接続を要求したときよりも、プール内の接続が使用されていないときの接続テストに依存するようになります。
Administration Console を使用してデータ ソースを作成する場合、Administration Console は、選択した DBMS に基づき、データ ソースの [テスト対象のテーブル名] 属性を自動的に設定します。[テスト対象のテーブル名] 属性は接続テストで使用されます。接続テストは必要に応じて、テスト オプションのコンフィグレーションにより定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、データ ソースのデータベース接続を作成するユーザが、該当するデータベース テーブルにアクセスできる必要があります。アクセスできない場合には、DBMS を使用してそのユーザにアクセスを付与するか、WebLogic Server Administration Console を使用して [テスト対象のテーブル名] 属性をユーザがアクセスを持つテーブルの名前に変更する必要があります。
WebLogic JDBC データ ソースには、データベースへの接続確立を試行する間隔の秒数を指定するのに使用できる、[接続作成の再試行間隔] オプション (JDBCConnectionPoolParamsBean の ConnectionCreationRetryFrequencySeconds) があります。この値を設定して、データ ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで続行します。このオプションは、サーバ起動時にデータ ソースが作成されたとき、データ ソースがデプロイされたとき、または初期容量が増大されたときに作成される、接続に適用されます。プールを拡張したり、プール内の切断された接続を置き換えたりする場合に作成される接続には適用されません。
デフォルトでは、[接続作成の再試行間隔 (秒)] は 0 秒です。この値を 0 に設定すると、接続作成の再試行は無効化され、データベースが使用できなければデータ ソースの作成は失敗します。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『WebLogic Server MBean リファレンス』の「JDBCConnectionPoolParamsBean」を参照してください。
JDBC データ ソースには、データ ソースからの接続を待機する接続リクエストを有効化するために設定できる、2 つの属性があります。[接続予約のタイムアウト] (ConnectionReserveTimeoutSeconds) および [接続の最大待機数] (HighestNumWaiters) です。これら 2 つの属性を一緒に使うと、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。
これらのオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『WebLogic Server MBean リファレンス』の「JDBCConnectionPoolParamsBean」を参照してください。
また、Administration Console オンライン ヘルプの「接続要求における接続待機の有効化」も参照してください。
アプリケーションがデータ ソースからの接続を要求したときにデータ ソース内の接続がすべて使用中であり、かつデータ ソースが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可 SQL 例外を受け取ります。これを避けるために、接続が利用できるようになるまで接続リクエストが待機するよう、[接続予約のタイムアウト] 値 (秒単位) をコンフィグレーションすることができます。[接続予約のタイムアウト] の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションは PoolLimitSQLException 例外を受け取ります。
[接続予約のタイムアウト] を -1 に設定すると、利用できる接続がなかった場合、接続リクエストは直ちにタイムアウトします。[接続予約のタイムアウト] を 0 に設定すると、接続リクエストは無期限に待機します。デフォルト値は、10 秒です。
Administration Console オンライン ヘルプの「接続要求における接続待機の有効化」を参照してください。
接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを回避するには、[接続の最大待機数] (HighestNumWaiters) 属性を設定して、同時に接続を待機できる接続リクエスト数を制限します。
[接続の最大待機数] (HighestNumWaiters) を MAX-INT (デフォルト) に設定すると、事実上、接続を待機できる接続リクエストに制限はなくなります。[接続の最大待機数] を 0 に設定すると、接続リクエストは接続を待機できなくなります。最大リクエスト数に到達した場合、アプリケーションが接続を要求すると SQLException が送出されます。
リークされた接続とは、適切にデータ ソースの接続プールに返されなかった接続のことです。リークされた接続を自動的に回復するには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページで [非アクティブ接続タイムアウト] の値を指定します。[非アクティブ接続タイムアウト] に値を指定すると、予約された接続が指定した秒数の間、非アクティブになっている場合、接続が強制的にデータ ソースに返されます。0 (デフォルト値) に設定すると、この機能は無効になります。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『WebLogic Server MBean リファレンス』の「JDBCConnectionPoolParamsBean」を参照してください。
実際のタイムアウト時間は、[非アクティブ接続タイムアウト] にコンフィグレーションした値より長くなります。内部のデータ ソース保守スレッドは 5 秒ごとに実行されます。[非アクティブ接続タイムアウト] 値 (たとえば 30 秒) が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は 2 回チェックを受けることになっています。2 回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的にデータ ソースに返されます。タイムアウト時間は、コンフィグレーションした値より、平均して約 50% 遅延します。
アプリケーションで、データ ソースから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外が送出されます。このエラーを避けるには、データ ソースのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。データ ソース内の使用できる接続の最大数を増やすには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページでデータ ソースの [最大容量] の値を増大させます。
JDBC データ ソースで [ステートメント タイムアウト] オプションを使用すると、データ ソースからの予約されたデータベース接続に対する文の実行にかかる時間を制限できます。[ステートメント タイムアウト] に値を設定すると、WebLogic Server では、java.sql.Statement.setQueryTimeout() メソッドを使用して、指定された時間を JDBC ドライバに渡します。使用している JDBC ドライバでこのメソッドがサポートされていないと、例外が送出される場合があり、タイムアウト値が無視されます。
[ステートメント タイムアウト] を -1 (デフォルト値) に設定した場合には、文はタイム アウトしません。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『WebLogic Server MBean リファレンス』の「JDBCConnectionPoolParamsBean」を参照してください。
アプリケーションがデータ ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ ソースの接続プロパティ リストに Pinned-To-Thread プロパティを追加し、その値を true に設定します。
Pinned-To-Thread が有効化されている場合、WebLogic Server では、データ ソースから実行スレッドまでのデータベース接続が固定されます。これは、アプリケーションでそのスレッドが接続の予約のために最初に使用されるときに実行されます。また、アプリケーションでその接続を利用し終えて connection.close() が呼び出されたときに、実行スレッドとの接続が保持され、接続はデータ ソースに返されません (この設定が有効でない場合、メソッドは接続をデータ ソースに返します)。そして、アプリケーションが引き続き同じ実行スレッドを使用して接続を要求したときに、すでにそのスレッドで予約されている接続が提供されます。このような方法を取ると、複数のスレッドが同時に接続の予約を試行したときに起こる、データ ソースでのロックの競合が発生しなくなります。また、限られた数のデータベース接続から同じ接続を予約しようとするスレッド間に競合が発生することもありません。
| 注意 : | このリリースでは、Pinned-To-Thread 機能はマルチ データ ソース、Oracle RAC、および ID プールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続 ID が一致しなかった場合に、その接続を再取得する機能に依存しています。 |
Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」を参照してください。
接続プール動作の性質は、PinnedToThread を有効にすると変更されるため、そうした動作の変更に適合するため、次のように一部の接続プールの属性または機能の動作が通常と異なったり、無効化されます。
PinnedToThread が有効化されている場合、縮小は接続プールに適用されない。接続は、効率上、常に予約されます。
PinnedToThread を有効にすると、接続プールの最大容量 (接続プールに作成されるデータベース接続の最大数) は、接続の要求に使われる実行スレッドの数に、各スレッドによって予約される同時接続の数を乗じた数になります。この数は、接続プールに指定された [最大容量] を超える場合があります。システム設計では接続のこの大きな数を考慮し、オープン カーソルなど、追加の関連リソースについてデータベースで許容されるようにすべき場合があります。
また、接続が接続プールに返されない点にも注意する必要があります。これは、接続プールを縮小して、使用される関連リソースおよび接続の数を減らすことができないことを意味します。このコストは、追加のドライバ パラメータ onePinnedConnectionOnly を設定することによって最小限に抑えることができます。onePinnedConnectionOnly=true の場合、要求された最初の接続のみがスレッドに固定されます。スレッドで必要なその他の接続はすべて、必要に応じて接続プールから取得されたり、接続プールに返されます。次に示すように、Properties 属性を使用して onePinnedConnectionOnly を設定します。
Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"
システムで追加のリソース要件を処理できる場合、PinnedToThread オプションを使ってパフォーマンスを向上させることをお勧めします。
現在のシステムでは追加のリソース要件を処理できない、または PinnedToThread を有効化するとデータベース リソースでエラーが発生する場合は、PinnedToThread は使用しないでください。
データ ソースをクラスタまたはサーバにデプロイするには、サーバまたはクラスタをデプロイメント対象として選択します。データ ソースがサーバにデプロイされると、WebLogic Server はデータ ソース内のデータベース接続のプールを含む、サーバ上のデータ ソースのインスタンスを作成します。クラスタにデータ ソースをデプロイする場合、クラスタ内の各サーバ上にデータ ソースのインスタンスが作成されます。
手順については、Administration Console オンライン ヘルプの「JDBC データ ソースの対象指定」を参照してください。
サーバ起動時に、WebLogic Server はサーバにデプロイされたデータ ソース内にデータベース接続を作成しようとします。データベースにアクセスできない場合、サーバの起動は、長時間に渡って STANDBY 状態でハングする可能性があります。これは WebLogic Server スレッドが、データベース サーバからの応答を待機している JDBC ドライバ コード内部でハングすることに起因しています。ハングの継続時間は、WebLogic Server マシン上の JDBC ドライバおよび TCP/IP タイムアウトの設定に左右されます。
この問題を回避するため、WebLogic Server では ServerMBean 上の JDBCLoginTimeoutSeconds 属性を用意しています。この属性の値を指定すると、値は java.sql.DriverManager.setLoginTimeout() に渡されます。データベース接続の作成に使用されている JDBC ドライバが setLoginTimeout メソッドを実装している場合、データベース接続作成が試行されるまでの待機時間は、指定されたタイムアウトの長さのみとなります。
以下の節では、JDBC データ ソースを保護するために WebLogic Server でロールおよびポリシーがどのように使用されているのかを説明します。
必要に応じて、JDBC データ ソースへのアクセスを制限することができます。WebLogic Server では、WebLogic リソースに対するアクセスの可否は、セキュリティ ポリシーによって決まります。セキュリティ ポリシーは、WebLogic リソースと、ユーザ、グループ、またはロールとの関連付けを定義する際に作成します。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。すべての WebLogic Server リソースのセキュリティを設定する手順については、Administration Console オンライン ヘルプの「ロールとポリシーを使用したリソースの保護」を参照してください。サーバ リソースの保護については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。
JDBC の操作は、管理者による JDBC データ ソースに対する操作を制限できる管理者用メソッドを割り当てることによって保護できます。『ロールおよびポリシーによる WebLogic リソースの保護』の「Java DataBase Connectivity (JDBC) リソース」を参照してください。
JDBC MBean で許容されるロールは Admin と Deployer のみです。以下の節では、JDBC MBean に定義されるセキュリティ ロールに関する情報が提供されます。
WebLogic Server のデフォルトのセキュリティ設定については、『WebLogic Server MBean リファレンス』の「Default Security Policies for MBeans」を参照してください。
次のドメイン コンフィグレーション JDBC MBean には、デフォルトのセキュリティ設定をオーバーライドする設定があります。
『WebLogic Server MBean リファレンス』の「Domain Configuration MBeans」を参照してください。
次のシステム モジュール JDBC MBean には、デフォルトのセキュリティ設定をオーバーライドする設定があります。
『WebLogic Server MBean リファレンス』の「System Module MBeans」を参照してください。
WebLogic Server のこれまでのリリースでは、アプリケーション スコープの JDBC 接続プールは、デフォルトの接続プールの値を提供するのに、JDBC データ ソース ファクトリを使用していました。JDBC データ ソース ファクトリは WebLogic Server 9.2 では非推奨となっており、本リリースでは下位互換性のみを目的としています。アプリケーション スコープの JDBC 接続プールの代わりとして、JDBC アプリケーション モジュールが使用されます。詳細については、「パッケージ化された JDBC モジュールのアプリケーション スコープ指定」を参照してください。
  
|
