| Oracle® Fusion Middleware Oracle WebLogic Server JDBCの構成と管理 11gリリース1 (10.3.3) B60997-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCの構成と管理 11gリリース1 (10.3.3) B60997-01 |
|
前 |
次 |
この項の内容は、以下のとおりです。
WebLogic Serverでデータベース接続を構成するには、データ・ソースをWebLogicドメインに追加します。WebLogic JDBCデータ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。各データ・ソースには、データ・ソース作成時およびサーバー起動時に作成される、データベース接続のプールが含まれています。アプリケーションは、JNDIツリーまたはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップし、次にgetConnection()を呼び出すことで、データ・ソースからのデータベース接続を予約します。接続の使用が終わったら、アプリケーションはできるだけ早くconnection.close()を呼び出して、データベース接続をプールに戻し、他のアプリケーションが使用できるようにする必要があります。
データ・ソースおよびその接続プールは、システムの安定稼働を維持するための接続管理プロセスを備えています。データ・ソースのこれらのオプションは、アプリケーションや環境にあわせて設定できます。次の項では、それらのオプションと、それらを有効にする方法について説明します。
WebLogicドメインにJDBCデータ・ソースを作成するには、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用できます。詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの作成に関する項。
サンプルWLSTスクリプトSAMPLES_HOME\server\examples\src\examples\wlst\online\jdbc_data_source_creation.py(SAMPLES_HOMEはWebLogic Serverインストールの主要なサンプル・ディレクトリを示します)。『Oracle WebLogic Scripting Tool』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。
JDBCデータ・ソース属性の詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceBeanおよびそのすべての子MBeanに関する項を参照してください。
Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソース参照ページ
「JDBCデータ・ソース:セキュリティ:資格証明マッピング」
|
注意: 管理コンソールのJDBCデータ・ソースの作成ページにリストされているJDBCドライバは、必ずしもWebLogic Serverでの使用が認証されているわけではありません。JDBCデータ・ソース・ページの主旨に沿って、使用可能な多くのデータベース管理システムへの接続を簡単に作成できるようにJDBCドライバの一覧が表示されます。データ・ソースでJDBCドライバを使用してデータベース接続を作成するには、データ・ソースをデプロイする各サーバーにJDBCドライバをインストールする必要があります。ドライバは、管理コンソールのJDBCデータ・ソースの作成ページに、データ・ソースの構成に役立つ、既知の必要な構成オプションと一緒に一覧表示されています。一覧にあるJDBCドライバが必ずしもインストールされているとは限りません。ドライバのインストールでは、システム・パス、クラス・パス、その他の環境変数の設定を行う場合もあります。「タイプ4サード・パーティJDBCドライバに対する環境設定」を参照してください。 JDBCドライバを更新すると、構成の要件が変わる場合があります。管理コンソールのJDBCデータ・ソースの作成ページでは、WebLogic Serverソフトウェアがリリースされた時点で知られていた構成要件を使用します。JDBCドライバの構成オプションが変更されている場合、データ・ソースの作成時、または作成後(データ・ソースのプロパティのページで)、構成オプションを手動でオーバーライドする必要がある場合があります。 |
JDBCデータ・ソースには、データ・ソースのアイデンティティ、データベース接続上のデータの処理方法、およびデータ・ソースからの接続をグロバール・トランザクションで使用したときのトランザクションの処理方法を判別するオプションが含まれます。JDBCデータ・ソースの一般的なオプションは、Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 一般」ページで確認できます。JDBCDataSourceBeanの子であるJDBCDataSourceParamsBeanからもこれらのオプションにアクセスできます。
データベースへの接続に使用するJDBCドライバを決定する際には、環境内で様々なベンダーのドライバを試してみることが必要です。通常、JDBCドライバのパフォーマンスは、アプリケーションで使用するSQLコード、JDBCドライバの実装など、様々な要因によって左右されます。
サポートされるJDBCドライバの詳細は、「System Requirements and Supported Platforms for Oracle WebLogic Server」の「Supported Database Configurations」(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照してください。
JDBCデータ・ソース名は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、名前はデータ・ソースやマルチ・データ・ソースを含む他のすべてのJDBCシステム・リソースを通じて一意であることが必要です。名前の競合を避けるため、データ・ソース名はサーバー、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど、他の構成オブジェクト名の間でも一意であることが必要です。アプリケーションをスコープとするJDBCアプリケーション・モジュールの場合、データ・ソース名は同様のスコープを持つJDBCデータ・ソースとマルチ・データ・ソースを通じて一意であることが必要です。
WebLogic Server 9.0以降のリリースでは、データ・ソースを構成できます。そのため、データ・ソースは複数の名前でJNDIツリーにバインドされることになります。1つのJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数のJNDI名を持つデータ・ソースを使用できます。
管理コンソールを使用してJNDI名を既存のデータ・ソースに追加するには、各JNDI名を別々の行に入れてJNDI名属性に名前を追加します。変更を行った後にシステムを再起動するか、変更を行う前にデータ・ソースをアンデプロイし、変更を行った後に再デプロイする必要があります。次の手順に従います。
管理コンソールの「JDBCデータ・ソース」>「構成」>「全般」ページの「JNDI名」に、データ・ソースをJNDIツリーにバインドするのに使用する名前を、名前ごとに改行して入力します。例:
name1 name2 name3
「保存」をクリックします。
変更をアクティブ化した後、データ・ソースを再デプロイするかサーバーを再起動して、変更を有効にする必要があります。
管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に基づき、自動的に特定のトランザクション・オプションを選択します。
XAドライバの場合、システムは自動的に、グローバル・トランザクション処理のための2フェーズ・コミット・プロトコルを選択します。
XA以外のドライバの場合、ローカル・トランザクションは定義によってサポートされており、WebLogic Serverは以下のオプションを提供します。
グローバル・トランザクションのサポート : (デフォルトで選択済み) XAドライバを選択していなくても、グローバル・トランザクションでデータ・ソースからの接続を使用する場合には、このオプションを選択します。詳細は、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。
「グローバル・トランザクションのサポート」を選択した場合は、グローバル・トランザクションを処理するときに、WebLogic Serverがトランザクション・ブランチに使用するプロトコルも選択する必要があります。
ロギング・ラスト・リソース: このオプションを使用すると、接続が使用されているトランザクション・ブランチが、トランザクションの最後のリソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によって、グローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションでは、「2フェーズ・コミットのエミュレート」よりもパフォーマンス上のメリットとデータの安全性が得られますが、いくつかの制限事項もあります。「ロギング・ラスト・リソース・トランザクション・オプションについて」を参照してください。
|
注意: ロギング・ラスト・リソースは、マルチ・データ・ソースで使用されるデータ・ソースについてはサポートされていません。ただし、「LLRデータ・ソースに関する管理上の考慮事項と制限事項」で説明するように、Oracle RACバージョン10Gリリース2 (10GR2)以降と一緒に使用する場合を除きます。 |
2フェーズ・コミットのエミュレート: このオプションを使用すると、接続が使用されているトランザクション・ブランチは、トランザクションの準備フェーズに対して常に成功を戻します。パフォーマンス上のメリットはありますが、いくつかの失敗の状況ではデータにリスクがあります。このオプションは、アプリケーションがヒューリスティックな状況を許容できる場合にのみ選択します。「2フェーズ・コミットのエミュレート・トランザクション・オプションについて」を参照してください。
1フェーズ・コミット: (デフォルトで選択済み)このオプションを使用すると、データ・ソースからの接続がグローバル・トランザクションの唯一の参加者となることができ、トランザクションは1フェーズ・コミットの最適化を使用して完了します。トランザクションに複数のリソースが参加している場合、トランザクション・マネージャが1PCリソースに対してXAResource.prepareを呼び出すと、例外がスローされます。
アプリケーションでグローバル・トランザクションを使用する場合、JDBCデータ・ソース内にデータベース接続を作成するのにXA JDBCドライバを使用する必要があります。XAドライバが使用できないデータベースの場合、またはXAドライバを使用しないことを選択した場合は、データ・ソース内でグローバル・トランザクションのサポートを有効化する必要があります。また、アプリケーションが、以下の条件に適合する場合も、グローバル・トランザクションのサポートを有効化する必要があります。
トランザクションの管理にWebLogic ServerのEJBコンテナを使用します。
1回のトランザクション中に複数のデータベース更新を含みます。
トランザクション中にデータベース、Java Messaging Service (JMS)など複数のリソースにアクセスします。
複数のサーバー(クラスタリング・サーバーとクラスタリングされていないサーバー)上で同一のデータ・ソースを使用します。
EJBアーキテクチャでは、データベース処理を行っている複数のEJBが単一のトランザクションの一部として呼び出されるのは、よくあることです。XAがない場合、これを行う唯一の方法は、すべてのトランザクション参加者がまったく同じデータベース接続を使用することです。グローバル・トランザクションを有効化して、「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」のどちらかを選択すると、WebLogic Serverは内部的にJTSドライバを使用して、EJB間で接続を明示的に渡さなくても、すべてのEJBが同じトランザクション・コンテキスト内で確実に同じデータベース接続を使用するようにします。
複数のEJBが1つのトランザクションに参加しており、かつ、データベース接続にXA JDBCドライバを使用しない場合は、次のオプションを使用してデータ・ソースを構成します。
「グローバル・トランザクションのサポート」を選択
「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」が選択されています
このように構成することによって、同じトランザクション内のすべてのデータベース作業で同じデータベース接続を内部的に使用することがJTSドライバに強制されます。
XA (XAドライバが必須)では、EJBはトランザクションの各部分に対して、別々のデータベース接続を使用できます。WebLogic Serverは、2フェーズ・コミット・プロトコルを使用してトランザクションを調整します。それにより、トランザクションがすべて完了するか、まったく完了しないかであることが保証されます。
WebLogic Serverは、JDBCデータ・ソースを通してロギング・ラスト・リソース(LLR)トランザクション最適化をサポートしています。LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のオプションです。LLRは、「ラスト・エージェント最適化」の改良版です。ラスト・エージェント最適化との相違は、トランザクションとして安全である点です。LLRリソースは、トランザクション作業にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。
LLR最適化により、次のようにしてパフォーマンスが向上します。
XA JDBCドライバがデータベースに接続する必要がなくなります。XA JDBCドライバは、一般的に、非XA JDBCドライバに比べて効率が低くなります。
トランザクションを完了させるまでの処理手順の数が少なくなり、それによりネットワーク・トラフィックとディスクI/O数も減少します。
データベース・レベルでのXA処理の必要性がなくなります。
LLR用に構成されたデータ・ソースからの接続が、2フェーズ・コミット(2PC)グローバル・トランザクションに参加している場合、WebLogic Serverトランザクション・マネージャは、次によりトランザクションを完了させます。
他のすべての(XA対応の)トランザクション参加リソースに対するprepareの呼出し。
(ファイル・ベースのトランザクション・ログではなく) LLR参加リソースの表へのコミット・レコードの挿入。
LLR参加リソースのローカル・トランザクション(トランザクション・コミット・レコードの挿入とアプリケーションのSQL処理の双方を含む)のコミット。
その他すべてのトランザクション参加リソースに対するコミットの呼出し。
1フェーズ・コミット(1PC)のグローバル・トランザクションの場合、LLRはローカル・トランザクションを使用してデータベース操作を完了することによって、XAオーバーヘッドを除去しますが、2PCトランザクション・レコードはデータベースに書き込まれません。
ロギング・ラスト・リソース最適化は、LLR参加リソースにコミット・レコードを書き込むことにより、データの整合性を維持します。ローカル・トランザクション・コミットの最中にトランザクションが失敗した場合、WebLogic Serverトランザクション・マネージャは、他のすべてのトランザクション参加リソースに対してトランザクションをロールバックします。失敗からリカバリするため、WebLogic Serverトランザクション・マネージャはデフォルトのストアにある他のトランザクション・ログ・ファイルと一緒にLLRリソース上のトランザクション・ログを読み取り、必要なすべてのトランザクション処理を完了します。XA参加リソースと関連付けられた処理は、コミット・レコードが存在すればコミットされます。そうでなければ、処理はロールバックされます。
LLR対応のJDBCデータ・ソースを作成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。ロギング・ラスト・リソース・トランザクション処理の詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
使用している環境によっては、パフォーマンス上の利点を得るために、トランザクション処理用として、2フェーズ・コミット・プロトコルのかわりにLLRトランザクション・プロトコルを検討する必要があります。LLRトランザクション・プロトコルには、次の利点があります。
非XA JDBCドライバ、およびXA非対応のデータベースも、2フェーズ・コミット・トランザクションに安全に参加できるようになります。
XAプロトコルがデータベースで使用されなくなります。
JDBC XA接続よりもパフォーマンスが向上します。
データベースの行ロックが保持される時間が短縮されます。
他のXA作業より常に先に、データベース作業がコミットされます。XAトランザクションでは、これらの操作は並列にコミットされます。したがって、たとえばJMS送信がトランザクションに参加している場合、JMSメッセージはデータベース処理のコミット前に配信されます。LLRでは、ローカル・トランザクションにおけるデータベース処理は、他のすべてのトランザクション処理より前に完了されます。
JDBCデータ・ソースの「2フェーズ・コミットのエミュレート」オプションと異なり、ヒューリスティック障害のリスクが増大しません。
|
注意: LLR最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLRでの読取り操作では、XAでの読取り操作と比べて、若干パフォーマンスが低下します。LLRパフォーマンス・チューニングの詳細は、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。 |
LLRトランザクション最適化を有効化するには、JDBCデータ・ソースをロギング・ラスト・リソース・トランザクション・プロトコルで作成して、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。
Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。
他のデータ・ソースからのJDBC接続と同じように、アプリケーション内のLLR対応データ・ソースからJDBC接続を使用できます。トランザクションの開始後、JNDIツリー上でデータ・ソースを検索してからデータ・ソースからの接続をリクエストします。ただし、LLR最適化を行うと、WebLogic Serverが内部的に接続のリクエストを管理し、XAトランザクションとは異なるやり方でトランザクションを処理します。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
次に注意してください:
LLRデータ・ソースでプログラミングを行う場合は、LLRデータ・ソースに対してgetConnectionを呼び出す前に、グローバル・トランザクションを開始する必要があります。グローバル・トランザクションを開始する前にgetConnectionを呼び出した場合、接続は独立したものとなり、その後で開始されるグローバル・トランザクションに関連付けされません。接続はautoCommit(true)モードで動作します。このモードでは、すべての更新がそのまま自動的にコミットされます。アプリケーション・コードでautoCommitの状態を明示的にfalseに設定して、独自のローカル・トランザクションを明示的に管理しない限り、更新をロールバックする方法はありません。
1つのトランザクションには、1つの内部JDBC LLR接続しか予約されません。その接続が、トランザクション処理全体を通して使用されます。
予約済みの接続は、常にトランザクションのコーディネータ・サーバーにホストされています。データ・ソースのターゲットには、必ずコーディネートしているサーバーまたはクラスタを指定してください。また、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。
同一名のデータ・ソースからのトランザクションでの追加のJDBC接続リクエストについては、後続の接続リクエストが、データ・ソースの別のインスタンス(つまり、最初のリクエストに対する接続を供給した元のデータ・ソースとは異なるサーバー上にデプロイされているデータ・ソース)に対して行われていたとしても、操作は予約された接続から元の接続リクエストにルーティングされます。次に注意してください。
ルーティングされたLLR接続は、ローカルでホストされているXA接続よりも、機能やパフォーマンスの点で劣ります。(「複数サーバー構成における非XAリソースのパフォーマンス低下の可能性」を参照してください。)
接続リクエストをルーティングすると、同時トランザクションの数が制限されます。同時LLRトランザクションの最大数は、コーディネータのJDBC LLRデータ・ソースの構成されたサイズ(MaxCapacity)と同じです。
ルーティングされた接続は、ローカル接続より機能が劣っており、その結果、失敗する可能性があります。特に、問合せResultSet内のシリアライズできない「カスタム」データ型で、失敗する可能性があります。
単一LLRデータ・ソースのインスタンスのみが、特定のトランザクションに参加できます。単一LLRデータ・ソースは、複数のWebLogicサーバーに対してインスタンスを持つ場合があり、2つのデータ・ソースは、構成された名前が同じ場合、同一とみなされます。複数のLLRデータ・ソース・インスタンスが検出され、それらが同じデータ・ソースのインスタンスでない場合、トランザクション・マネージャはトランザクションをロールバックします。
weblogic.transaction.nonxa.NonXAResourceインタフェースを実装するリソース・アダプタ(コネクタ)は、LLRリソースも参加しているグローバル・トランザクションには参加できません。どちらも、トランザクションの最後のリソースである必要があるからです。双方のリソース・タイプが同じトランザクションに参加している場合、競合が検出されると、トランザクションのcommit()メソッドが、javax.transaction.RollbackExceptionをスローします。
LLR接続では、データベース処理に別個のローカル・トランザクションを使用するため、XA接続を使用して同じデータベースに加えられた変更(および保持されるロック)はすべて、全処理が同じグローバル・トランザクション内で発生するとしても、LLR処理の最中には認識されません。場合によっては、これによりデータベースにデッドロックが発生します。単一のグローバル・トランザクションにおいて、同一データベース内でXA処理とLLR処理を組み合わせることはできません。
LLRデータ・ソースからの接続は、リモート・オブジェクト・リクエスト・ブローカやTuxedoによって開始されたトランザクションなど、外部トランザクション・マネージャが調整するトランザクションには参加できません。
グローバル・トランザクションは、LLRデータ・ソースと同じ名前のデータ・ソースを含む別の従来ドメインまで及ぶようにはできません。
JDBC LLR 2PCトランザクションでは、トランザクション・データが大きすぎてLLR表に合わない場合、そのトランザクションは、コミット時に例外をスローし失敗します。これは、トランザクションの処理中にアプリケーションに多くのトランザクション・プロパティを追加した場合に発生します。(『Oracle WebLogic Server JTAのプログラミング』のOracle WebLogic JTAの拡張に関する項を参照してください。)これが起こった場合、データベース管理者はより多くの列を含む表を手動で作成できます。
LLR対応のJDBCデータ・ソースを構成する際は、次の要件と制限を考慮してください。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
1つのサーバーにつき、LLR表は1つです。
複数のLLRデータ・ソースが1つの表を共有することがあります。
表が見つからない場合、WebLogic Serverは自動的に表を作成します。
デフォルト名はWL_LLR_SERVERNAMEです。表名を構成するには、管理コンソールの詳細オプションの「サーバー」>「構成」>「一般」を選択してください。Oracle WebLogic Server管理コンソール・ヘルプの「サーバー」:「構成」:「一般」を参照してください。
データベースが停止している場合や、起動中にLLR表にアクセスできない場合、サーバーは起動しません。
複数のサーバーが同じLLR表を共有することは許されません。起動の際には、ドメインおよびサーバーの名前が、作成された時点の表に格納されたドメインおよびサーバーの名前と一致するかどうかが確認されます。WebLogic Serverは、複数のサーバーが同じLLR表を共有していることを検出すると、1つまたは複数のサーバーを停止します。
LLRでは、サーバー移行およびトランザクション・リカバリ・サービス移行がサポートされます。トランザクション・リカバリ・サービス移行を使用するには、各LLRリソースが、クラスタまたはクラスタ内の候補サーバーのセットに対してターゲット指定されている必要があります。『Oracle WebLogic Server JTAのプログラミング』の失敗したクラスタ化サーバーのトランザクションのリカバリに関する項を参照してください。
LLRトランザクション・オプションは、JDBCアプリケーション・モジュールでは使用できません。
マルチ・データ・ソースを使用する場合は、LLRトランザクション・オプションはOracle RACバージョン10Gリリース2 (10GR2)以降で、次の設定でのみ使用できます。
すべてのWebLogicアプリケーション・データベースのJDBCインタラクションが、READ_COMMITTEDトランザクション分離レベル(デフォルト)を使用する必要があります。
Oracle RACのMAX_COMMIT_PROPAGATION_DELAYの値は0 (デフォルト)に設定する必要があります。
マルチ・データ・ソースでのLLRの使用はOracle RACでのみサポートされます。それ以外のマルチ・データ・ソース構成ではLLRはサポートされません。
LLRデータ・ソース上で資格証明マッピングを使用する場合、マップされるユーザーはすべて、LLR表への書込み権限を持っている必要があります。
JDBC XAドライバを使用して、JDBC LLRデータ・ソース内にデータベース接続を作成することはできません。JDBC LLRデータ・ソースで使用されるJDBCドライバがXAをサポートしている場合、警告メッセージがログに記録され、データ・ソースはLLRリソースではなく、完全なXAリソースとして、トランザクションに参加します。
LLRリソース用トランザクション統計は、「NonXAResource」の下に記録されます。Oracle WebLogic Server管理コンソール・ヘルプの非XAリソース用トランザクション統計の表示に関する項を参照してください。
JDBCデータ・ソースで分散トランザクションのサポートが必要であるにもかかわらず、DBMSで利用できるXA対応のドライバがない場合は、データ・ソースに対して非XAドライバ用の2フェーズ・コミットのエミュレートオプションを選択することにより、データ・ソースからの接続が参加しているトランザクションについて、データ・ソースが2フェーズ・コミットをエミュレートするようになります。このオプションは、「JDBCデータ・ソース」>「構成」>「全般」タブの詳細オプションです。
「非XAドライバ用の2フェーズ・コミットのエミュレート」が選択されている(EnableTwoPhaseCommitがtrueに設定されている)場合、非XA JDBCリソースはXAResource.prepare()メソッド呼出し中に常にXA_OKを戻します。リソースは、その後のXAResource.commit()またはXAResource.rollback()の呼出しに応じて、ローカル・トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック・エラーの結果、アプリケーション・データは矛盾した状態のまま残される場合があります。
「非XAドライバ用の2フェーズ・コミットのエミュレート」オプションが管理コンソールで選択されていない(EnableTwoPhaseCommitがfalseに設定されている)場合、非XA JDBCリソースは、XAResource.prepare()の失敗を引き起こします。トランザクションに参加するリソースが1つだけである場合、1フェーズ最適化がXAResource.prepare()をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットします。
|
注意: 「非XAドライバ用の2フェーズ・コミットのエミュレート」オプションを使用していると、データの整合性が損なわれるおそれがあります。「2フェーズ・コミットのエミュレート」オプションを使用するかわりに、XA対応のJDBCドライバ、または「ロギング・ラスト・リソース」オプションを使用することをお薦めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。 |
この非XAのJDBCドライバのサポートは、WebLogic Serverがその機能をサポートするために内部的にWebLogic JTSドライバを使用するので、多くの場合、「JTSドライバ」と呼ばれます。WebLogic JTSドライバの詳細は、『Oracle WebLogic Server 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データ・ソースの接続プールのオプションについて説明します。
これらのオプションおよびその他の関連オプションの詳細は、次で参照し、設定できます。
管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。
JDBCDataSourceBeanの子MBeanである、JDBCConnectionPoolParamsBean
管理コンソールを使用してJDBCデータ・ソースを作成する際、JDBCドライバ・クラスを選択するよう求められます。管理コンソールでは大部分の一般的なドライバ・クラス名が表示され、ほとんどの場合、ドライバに必要なURLの作成も支援されます。ただし、コンソールにURLのテストをリクエストする前に、URLが適切であることを確認してください。選択したドライバは、データ・ソースをデプロイするすべてのサーバーのクラス・パスに存在する必要があります。管理コンソールで一覧表示されるいくつかのJDBCドライバ(すべてではありません)は、WebLogic Serverに付属しています(および/または、クラス・パスにすでに存在します)。
Oracle Thin Driver
Oracle Thin Driver XA
Oracle Thin Driver非XA
サード・パーティのJDBCドライバ(第5章「WebLogic ServerでのJDBCドライバの使い方」を参照) :
Sybase jConnect
MySQL (非XA)
次のデータベース管理システム用のDataDirectからのWebLogicタイプ4 JDBCドライバ(『Oracle WebLogic Serverタイプ4 JDBCドライバ』を参照)。
DB2
Informix
Microsoft SQL Server
Sybase
これらのドライバはすべて、weblogic.jarマニフェスト・ファイルによって参照され、サーバーのクラス・パスで明示的に定義される必要はありません。
WebLogic JDBCデータ・ソースは、JDBCドライバで実装されるjavax.sql.ConnectionPoolDataSourceインタフェースをサポートしています。JDBCデータ・ソース内のProperties属性にプロパティおよびその値を追加して、ドライバ・レベルの機能を有効化できます。Properties属性におけるドライバ・レベルのプロパティは、ドライバのConnectionPoolDataSourceオブジェクトで設定されます。
WebLogic Serverでは、データ・ソースにおけるデータベース接続の作成時に、自動的にSQLコードを実行して、データベース接続を初期化できます。この機能を有効にするには、管理コンソールの「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ごとに異なります。
|
注意: 初期化SQLは、動的な属性ではありません。初期化SQLの値を変更する際には、データ・ソースをアンデプロイしてから再デプロイするか、またはサーバーを再起動する必要があります。 |
次の項では、セキュリティ資格証明をDBMSに渡す方法についての情報を提供します。
Weblogic Serverでは、セキュリティ権限に基づいて、次の2種類のデータ・ソース・プールが提供されます。
同種 - アプリケーションのエンド・ユーザーに関係なく、プール内のすべての接続で同じセキュリティ資格証明を使用してDBMSにアクセスします。
異種 - アプリケーションは、様々なDBMS資格証明で物理的な接続をプールすることによって、特定のDBMS資格証明でJDBC接続を使用できます。
ここでは、セキュリティ資格証明をDBMSに渡す方法を比較します。
資格証明の最も簡単なタイプの認証情報は、接続プールにDBMSのユーザー・アカウント名およびパスワードを提供することです。そうすると、プール内のすべての接続は、同じ認証情報を使用してDBMSにアクセスします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの作成に関する項を参照してください。
|
注意: パスワードは「プロパティ」フィールドに名前/値ペアとして入力するか(本番環境では不許可)、「パスワード」フィールドに入力することができます。「パスワード」フィールドの値は、物理的なデータベース接続を作成するときにJDBCドライバに渡されるプロパティで定義されている、いかなるパスワード値もオーバーライドします。「パスワード」の値は構成ファイル内で暗号化(モジュール・ファイルのjdbc-driver-paramsタグでpassword-encrypted属性として保存)され、管理コンソールには表示されないため、「プロパティ」文字列のパスワード・プロパティのかわりに「パスワード」属性を使用することをお薦めします。なぜなら、 |
データ・ソースで「接続時にクライアントIDを設定」属性が有効になっている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたときに、WebLogic Serverインスタンスが現在のWebLogicユーザーIDを判別し、マップされているデータベースIDを軽量なクライアントIDとして設定します。この場合も、プール内のすべての接続で同じ資格証明を使用してDBMSにアクセスします。基本的な構成手順は次のとおりです。
「接続時にクライアントIDを設定」を選択し、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースに対する接続時に「クライアントIDの設定」の有効化に関する項を参照してください。
WebLogicユーザーIDおよびデータベースIDをマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項を参照してください。
この機能は、JDBCドライバおよびDBMSの機能に依存します。OracleおよびDB2データベースで、ベンダー提供の拡張メソッドを使用する場合にのみサポートされます。
oracle.jdbc.OracleConnection.setClientIdentifier(String id)
com.ibm.db2.jcc.DB2Connection.setDB2ClientUser(String user)
|
注意: 「接続時にクライアントIDを設定」と「IDベースの接続プールを有効化」は相互に排他的です。アプリケーション環境でセキュリティ資格証明を渡すために両方のメカニズムが必要な場合は、別々のデータ・ソースを作成して、一方は「接続時にクライアントIDを設定」を指定し、もう一方は「IDベースの接続プールを有効化」を指定してください。 |
IDベースの接続プーリングを使用すると、アプリケーションは、様々なDBMS資格証明で物理的な接続をプールすることによって、特定のDBMS資格証明でJDBC接続を使用できます。
データ・ソースで「IDベースの接続プールを有効化」属性が有効になっている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたとき、WebLogic Serverインスタンスは既存の物理的接続を選択するか、またはWebLogicユーザー資格証明とDBMS資格証明のマップに基づき、リクエストされたDBMS IDで新しい物理的接続を作成します。基本的な構成手順は次のとおりです。
「IDベースの接続プールを有効化」を選択し、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのIDベースの接続プールの有効化に関する項を参照してください。
WebLogicユーザー資格証明とDBMS資格証明をマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項を参照してください。
|
注意: 「接続時にクライアントIDを設定」と「IDベースの接続プールを有効化」は相互に排他的です。アプリケーション環境でセキュリティ資格証明を渡すために両方のメカニズムが必要な場合は、別々のデータ・ソースを作成して、一方は「接続時にクライアントIDを設定」を指定し、もう一方は「IDベースの接続プールを有効化」を指定してください。 |
次の項では、異種接続が作成されるプロセスについて説明します。
接続プールの初期化時に、データ・ソースのデフォルトDBMS資格証明で物理的なJDBC接続が作成されます。
アプリケーションは、データ・ソースからの接続の取得を試行します。
現在のサーバー・インスタンス資格証明はDBMS資格証明にマップされています。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成を参照してください。
一致する資格証明が見つからない場合、デフォルトのDBMS資格証明が使用されます。
|
注意: デフォルトのDBMS資格証明は、XAトランザクションを実行したり、接続テスト操作を実行できる最低限のDBMS権限を持つ必要があります。 |
一致する資格証明が見つかった場合、DBMS資格証明に一致する物理的な接続の検出にその資格証明が使用されます。
一致する接続が見つかった場合、その接続が予約されてアプリケーションに戻されます。
一致する接続が見つからない場合、プールの最大容量に基づいて1つの接続が作成されるか、再利用されます。
最大容量にまだ達していない場合、DBMS資格証明で新しい接続が作成され、予約されてから、アプリケーションに戻されます。
プールが最大容量に達している場合、LRU (Least Recently Used)アルゴリズムに基づいて、物理的な接続がプールから選択され、破棄されます。DBMS資格証明で新しい接続が作成され、予約されてから、アプリケーションに戻されます。
物理的な接続がどのように作成されるかに関係なく、プール内の物理的な各接続は、プールによって維持される独自のDBMS資格証明情報を持ちます。物理的な接続がプールによっていったん予約されると、現在のスレッドがWebLogicユーザーの資格証明を変更しても、そのDBMS資格は変更されず、引き続き同じ接続が使用されます。
グローバル・トランザクションの中で実行される場合、アプリケーションは現在のスレッド上の資格証明を変更して、別の資格証明に基づき複数のJDBC接続を取得することができます。ただし、IDベースのプール機能では、グローバル・トランザクションの中でのWebLogic JDBCデータ・ソースの複数の論理JDBC接続を、単一の物理JDBC接続にマップします。つまり、WebLogicサーバー・インスタンスに対する1つのWebLogic JDBCデータ・ソースにつき、ただ1つのDBMS資格証明のみが、グローバル・トランザクションについて尊重されるということです。
IDベースのプーリングにおいてロギング・ラスト・リソース(LLR)トランザクション最適化を利用するには、次の変更を行う必要があります。
完全修飾LLR表名を使用して、LLRのカスタム・スキーマを構成する必要があります。そうすると、すべてのLLR接続が、LLRトランザクション表へのアクセス時に、デフォルトのスキーマではなく指定されたスキーマを使用するようになります。
データベース固有の管理ツールを使用して、指定されたLLR表へのアクセス許可を、すべてのユーザーに付与します。デフォルトでは、LLR表はデータ・ソース内で接続に対して構成されたユーザーによって、起動の際に作成されます。ほとんどの場合、データベースはこのユーザーに対してのみアクセスを許可し、マップされたユーザーには許可しません。
WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を正しく構成することで、アプリケーションおよびシステムのパフォーマンスを向上させることができます。次の項では、JDBCデータ・ソースの接続プールのチューニング・オプションについて説明します。
アプリケーションまたはEJBでプリペアド文や呼出し可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信およびデータベース・サーバー自体においてかなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Serverではアプリケーションで使用するプリペアド文と呼出し可能文をキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリペアド文と呼出し可能文を再利用することで、データベース・サーバーのCPUの使用率が下がり、現在の文のパフォーマンスが向上するため、CPUサイクルを他のタスクに割り当てることができます。
データ・ソースの各接続は、接続時に使用されるプリペアド文と呼出し可能文のキャッシュが個別に持っています。しかし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソース内の各接続の文キャッシュは、そのデータ・ソースに指定された文キャッシュ・オプションを使用しますが、各接続は、それぞれに固有の文をキャッシュします。文キャッシュの構成オプションには、次のようなものがあります。
文キャッシュのタイプ - 文キャッシュ内に格納する文を決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください。
文キャッシュ・サイズ - 各接続のキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください。
管理コンソールを使用してデータ・ソース用の文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの文キャッシュの構成を参照してください。
文キャッシュのタイプ(つまりアルゴリズム)は、データ・ソースの各接続のキャッシュに格納するプリペアド文と呼出し可能文を決定します。次のオプションから選択できます。
「LRU」 (Least Recently Used、デフォルト)を文キャッシュのタイプとして選択すると、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表はなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、プリペアド文は、キャッシュされた時点でデータベース内の表の各列のデータ型にバインドされます。表の列を追加、削除、または再配列すると、キャッシュに格納されているプリペアド文は、再び実行されたときに失敗するおそれがあります。
これらの制限は、DBMSの動作に依存します。
setNullバインド変数を使用するプリペアド文をキャッシュする場合、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、null以外の値で実行したときにデータが切り捨てられたり、文が失敗したりするおそれがあります。
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
かわりに、次を使用します。
if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)
データ・ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Serverには、2種類の基本的なテスト方法があります。
WebLogic Serverがデータベース接続の正常な状態を確認できるよう、データ・ソースのオプションで構成する、自動テスト。
データ・ソースのトラブルシューティング用に行える、手動テスト。
次の項では、自動接続テストのオプションについて説明します。手動接続テストの詳細は、「データ・ソースおよびデータベース接続のテスト」を参照してください。
データ・ソースの自動テスト・オプションを構成するには、JDBCConnectionPoolParamsBeanを使用して、管理コンソールまたはWLSTから以下のオプションを設定します。
テスト頻度 - (JDBCConnectionPoolParamsBeanのTestFrequencySeconds) この属性では、未使用の接続をテストする間隔を秒数で指定します。WebLogic Serverは未使用の接続をテストし、フォルトのある接続を閉じて置き換えます。「表名のテスト」も設定する必要があります。
予約された接続のテスト - (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve) このオプションを有効にすると、クライアントに与える前に各接続をテストすることができます。これにより、リクエストが少し遅くなる場合がありますが、接続が正常であることを保証します。「表名のテスト」も設定する必要があります。
表名のテスト - (JDBCConnectionPoolParamsBeanのTestTableName) この属性では、接続テストで使用される表名を指定します。標準的なテストのかわりに、テストとして実行するSQLコードを指定することもできます。「SQL」と入力し、その直後にスペース、次に実行するSQLコードを入力します。「表名のテスト」は、データベース接続のテストを有効にするための必須の属性です。
アイドル・プール接続を信頼する秒数 - (JDBCConnectionPoolParamsBeanのSecondsToTrustAnIdlePoolConnection) このオプションでは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であるとWebLogic Serverが信頼してよいことが証明されて接続テストをスキップする間隔を秒数で指定します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
接続のテスト・オプションの設定に関する指示については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
WebLogic Serverはデータ・ソースのデータベース接続をテストする際、データ・ソースからの接続を予約し、接続に対して小さな問合せを実行し、その後データ・ソースのプールに接続を戻します。サーバー・インスタンスは、プールのステータスに関する統計情報(接続テストの所要時間、接続を待機する接続数、テストされた接続数など)を追跡します。最近実施された接続動作テストの履歴は、接続テストが失敗したとサーバー・インスタンスが判断するまでの待機時間を計算するために使用されます。
スレッドの接続に通常よりも時間がかかっている場合、サーバー・インスタンスはそのテストが完了するまで、他のスレッドのテストを遅延させる場合があります。接続テスト中(デフォルトでは10秒)のスレッドのハングが長すぎる場合、プールはDBMSの接続エラーを宣言して自身を無効にし、予約されてない接続も、アプリケーションが使用中の接続も、すべての接続を強制終了します。
これは非常にまれなケースですが、ネットワーク・ケーブルの切断によって引き起こされる無限のハング状態や、ソケット読取りでJDBC呼出しを行っているJVMスレッドがロックされ、OSのTCP制限(通常は10分間)に達するまでJVMが解除されなくなるような問題を解決することを意図しています。この方法でプールが自身を無効化した場合、プールは定期的に(デフォルトでは5秒おきに)DBMSに再接続しようとします。新しい接続を作成できた場合、プールは自身を再び有効化して、以降の接続リクエストをは通常どおりに処理します(プールは負荷の必要性に応じて再び接続を格納します)。
テストで使用する問合せは、「表名のテスト」の値によって決定されます。値が表名の場合、問合せは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は、データ・ソースの「テスト頻度」の設定に基づいてすべての接続を閉じるまでのテストの失敗回数を決定します。
「テスト頻度」が0より大きければ、すべての接続を閉じるまでのテスト失敗回数は2に設定されます。
「テスト頻度」が0に設定されている(定期テストが無効化されている)場合、すべての接続を閉じるまでのテスト失敗回数は、データ・ソースの「最大容量」の25%に設定されます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。
この遅延を最小限に抑えるため、WebLogicデータ・ソースには、2回連続して失敗が生じたらデータ・ソースを無効化して、切断されている接続を置き換えるロジックが含まれています。アプリケーションが、無効化されたデータ・ソースから接続をリクエストすると、即座にPoolDisabledSQLExceptionがスローされ、接続が使用できないことがクライアントに知らされます。
この方法で無効化されたデータ・ソースについては、定期的に更新プロセスが実行されます。更新プロセスは、次を実行します。
サーバー・インスタンスは、データベース・サーバーに対して5秒おきにヘルス・チェックを行います。この設定は構成可能ではありません。
サーバー・インスタンスは、データベースが回復されたことを認識すると、新しいデータベース接続を作成してデータ・ソースを有効化します。
また、管理コンソールを使用して手動でデータ・ソースを有効化することもできます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断された接続をテストして、無駄に置き換えようとすると、OSネットワーク・タイムアウト(数分間)の時間がかかり、予期されるエラー・メッセージを取得するまでにクライアントで長時間の遅延を引き起こす可能性があります。
|
注意: データ・ソースをマルチ・データ・ソースに追加している場合は、マルチ・データ・ソースがデータ・ソースの無効化と再有効化を引き継ぎます。デフォルトでは、マルチ・データ・ソースは2分おきにチェックして(この時間は構成可能)、接続を再確立できるデータ・ソースがあれば再有効化します。 |
DBMS接続を非常に短いサイクルで使用するアプリケーションの場合(例:reserve-do_one_query-close)、データ・ソースの接続のテストは各使用サイクルに大量のオーバーヘッドをもたらす可能性があります。接続テストの影響を最小化するには、JDBCデータ・ソース構成の「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用またはテストしたデータベース接続を信頼して接続テストをスキップします。
データ・ソース上で「予約時に接続をテスト」が有効化されている場合、アプリケーションがデータベース接続をリクエストすると、WebLogic Serverはアプリケーションに渡す前にその接続をテストします。接続がテストされるかアプリケーションで正常に使用されてから、「アイドル・プール接続を信頼する秒数」に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。
データ・ソースに対する「テスト頻度」が0より多い(定期テストが有効化されている)場合も、WebLogic Serverは接続が正常に使用されて、「アイドル・プール接続を信頼する秒数」で指定した時間内にデータ・ソースに戻されていれば、接続テストをスキップします。
アイドル・プール接続を信頼する秒数の設定方法については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
「アイドル・プール接続を信頼する秒数」は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などには、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。
接続テストの属性は、環境に最もよく適合するように設定する必要があります。たとえば、アプリケーションがデータベース接続の失敗を許容できない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して確実に「予約時に接続をテスト」を有効化しておき、WebLogic Serverが接続をアプリケーションに渡す前に、毎回その接続のテストを行うようにします。アプリケーションがデータ・ソースから接続を取得する際の遅延に影響を受けやすく、切断された接続の使用によるアプリケーション・エラーの可能性を許容できるのであれば、「アイドル・プール接続を信頼する秒数」をより高い数値に、「テスト頻度」を低い数値に設定し、「予約時に接続をテスト」を有効化する必要があります。
これらの設定によりアプリケーションは、アプリケーションが接続をリクエストしたときよりも、プール内の接続が使用されていないときのデータ・ソースの接続テストに依存するようになります。
|
注意: 結局は、WebLogicが最善を尽くした場合でも、WebLogicが接続を正常にテストした後で、アプリケーションがその接続を使用する前に、接続が失敗する可能性はあります。したがって、どのアプリケーションも、切断された接続から予期しない例外が発生した場合に適切に対応するように記述しておく必要があります。 |
管理コンソールを使用してデータ・ソースを作成する場合、管理コンソールは、選択したDBMSに基づき、データ・ソースの「表名のテスト」属性を自動的に設定します。「表名のテスト」属性は接続テストで使用されます。接続テストは必要に応じて、テスト・オプションの構成により定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、データ・ソースのデータベース接続を作成するユーザーが、該当するデータベース表にアクセスできる必要があります。アクセスできない場合には、DBMSを使用してそのユーザーにアクセスを付与するか、WebLogic Server 管理コンソールを使用して「表名のテスト」属性をユーザーがアクセスを持つ表の名前に変更する必要があります。
「テスト表名」はオーバーロードされるパラメータです。最も単純な形式は、WLSが接続のテストをリクエストする表を指定することです。Oracleの場合の「DUAL」など、任意の表に設定すると、データ・ソースは「select count(*) from DUAL」のような問合せを実行することになります。このモードで使用する場合は、小さく、頻繁には更新されない表(DUALのような擬似表が望ましい)を選ぶことをお薦めします。
このパラメータを定義するときの2番目の方法は、特定のSQL文字列に接続のテストを実行させることです。この方法を使用するには、パラメータとして、「SQL」 に必要なSQL文字列を加えたもの設定します。たとえば、SQLServerの場合は「SQL select 1」が使用できます(定数を選択する問合せに表を含める必要はありません)。この方法は、WLSのプール接続テストにDBMS側の制御を加えて、テストをできる限り速く行うには便利です。
表3-2 DBMS別のデフォルト・テスト表名
| DBMS | デフォルト・テスト表名(問合せ) |
|---|---|
|
Adabas for z/OS |
SQL call shadow_adabas('select * from employees') |
|
Cloudscape |
SQL SELECT 1 |
|
DB2 |
SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
|
FirstSQL |
SQL SELECT 1 |
|
IMS/TM for z/OS |
SQL call shadow_ims('otm','/dis','cctl') |
|
Informix |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Microsoft SQL Server |
SQL SELECT 1 |
|
MySQL |
SQL SELECT 1 |
|
Oracle |
SQL SELECT 1 FROM DUAL |
|
PostgreSQL |
SQL SELECT 1 |
|
Progress |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Sybase |
SQL SELECT 1 |
WebLogic JDBCデータ・ソースには、データベースへの接続確立を試行する間隔の秒数を指定するのに使用できる、「接続作成の再試行間隔」オプション(JDBCConnectionPoolParamsBeanのConnectionCreationRetryFrequencySeconds)があります。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで続行します。このオプションは、サーバー起動時にデータ・ソースが作成されたとき、データ・ソースがデプロイされたとき、または初期容量が増大されたときに作成される、接続に適用されます。プールを拡張したり、プール内の切断された接続を置き換えたりする場合に作成される接続には適用されません。
デフォルトでは、「接続作成の再試行間隔(秒)」は0秒です。この値を0に設定すると、接続作成の再試行は無効化され、データベースが使用できなければデータ・ソースの作成は失敗します。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
JDBCデータ・ソースには、データ・ソースからの接続を待機する接続リクエストを有効化するために設定できる、2つの属性があります。[接続予約のタイムアウト] (ConnectionReserveTimeoutSeconds)および[接続の最大待機数] (HighestNumWaiters)です。これら2つの属性を一緒に使用すると、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
また、管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化に関する項も参照してください。
アプリケーションがデータ・ソースからの接続をリクエストしたときにデータ・ソース内の接続がすべて使用中であり、かつデータ・ソースが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可SQL例外を受け取ります。これを避けるために、接続が利用できるようになるまで接続リクエストが待機するよう、「接続予約のタイムアウト」の値(秒単位)を構成することができます。「接続予約のタイムアウト」の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションはPoolLimitSQLException例外を受け取ります。
「接続予約のタイムアウト」を-1に設定すると、利用できる接続がなかった場合、接続リクエストは直ちにタイムアウトします。「接続予約のタイムアウト」を0に設定すると、接続リクエストは無期限に待機します。デフォルト値は、10秒です。
Oracle WebLogic Server管理コンソール・ヘルプの接続を待機する接続リクエストの有効化に関する項を参照してください。
接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを回避するには、「接続の最大待機数」 (HighestNumWaiters)属性を設定して、同時に接続を待機できる接続リクエスト数を制限します。
「接続の最大待機数」 (HighestNumWaiters)をMAX-INT (デフォルト)に設定すると、事実上、接続を待機できる接続リクエストに制限はなくなります。「接続の最大待機数」を0に設定すると、接続リクエストは接続を待機できなくなります。最大リクエスト数に到達した場合、アプリケーションが接続をリクエストするとSQLExceptionがスローされます。
リークされた接続とは、適切にデータ・ソースの接続プールに返されなかった接続のことです。リークされた接続を自動的に回復するには、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページで「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」に値を指定すると、予約された接続が指定した秒数の間、非アクティブになっている場合、接続が強制的にデータ・ソースに返されます。0 (デフォルト値)に設定すると、この機能は無効になります。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
実際のタイムアウト時間は、「非アクティブ接続タイムアウト」に構成した値より長くなります。内部のデータ・ソース保守スレッドは5秒ごとに実行されます。「非アクティブ接続タイムアウト」値(たとえば30秒)が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は2回チェックを受けることになっています。2回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的にデータ・ソースに返されます。タイムアウト時間は、構成した値より、平均して約50%遅延します。
アプリケーションで、データ・ソースから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外がスローされます。このエラーを避けるには、データ・ソースのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。データ・ソース内の使用できる接続の最大数を増やすには、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページでデータ・ソースの「最大容量」の値を増やします。
JDBCデータ・ソースで「文タイムアウト」オプションを使用すると、データ・ソースからの予約されたデータベース接続に対する文の実行にかかる時間を制限できます。「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間をJDBCドライバに渡します。WebLogic Serverが呼出しを行い、ドライバが例外をスローした場合は、この値は無視されます。場合によっては、ドライバは暗黙的にこの呼出しをサポートしていないか、制限されたサポートがドキュメントに記載されていることがあります。ドライバのドキュメントを確認して、予期しないエラーを検証することをお薦めします。
「文タイムアウト」を -1 (デフォルト値)に設定した場合には、文はタイムアウトしません。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。
Pinned-To-Threadが有効化されている場合、WebLogic Serverでは、データ・ソースから実行スレッドまでのデータベース接続が固定されます。これは、アプリケーションでそのスレッドが接続の予約のために最初に使用されるときに実行されます。また、アプリケーションでその接続を利用し終えてconnection.close()が呼び出されたときに、実行スレッドとの接続が保持され、接続はデータ・ソースに返されません(この設定が有効でない場合、メソッドは接続をデータ・ソースに返します)。そして、アプリケーションが引続き同じ実行スレッドを使用して接続をリクエストしたときに、すでにそのスレッドで予約されている接続が提供されます。このような方法を取ると、複数のスレッドが同時に接続の予約を試行したときに起こる、データ・ソースでのロックの競合が発生しなくなります。また、限られた数のデータベース接続から同じ接続を予約しようとするスレッド間に競合が発生することもありません。
|
注意: このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。 |
Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。
PinnedToThreadを有効にすると接続プーリングの動作の性質が変更されるため、一部の接続プールの属性や機能は、動作の変更に適合するように、通常と異なる動作をしたり、無効化されたりします。
最大容量が無視されます。接続プール内の接続の数は、接続プールから予約されている接続の数または初期容量のいずれか大きな方の値に等しくなります。
接続が接続プールに返されないため、PinnedToThreadが有効化されている場合、縮小は接続プールに適用されません。接続は、効率上、常に予約されます。
接続プールをリセットすると、接続プールからリセットされた接続は、「テストが必要」とマークされます。次に各接続が予約されるときに、その接続は必要に応じてテストおよび再作成されます。接続は、接続プールのリセット時に同期的にテストされません。この機能は、「予約時に接続のテスト」を有効化し、「表名のテスト」または問合せを指定しておく必要があります。
PinnedToThreadを有効にすると、接続プールの最大容量(接続プールに作成されるデータベース接続の最大数)は、接続のリクエストに使われる実行スレッドの数に、各スレッドによって予約される同時接続の数を乗じた数になります。この数は、接続プールに指定された[最大容量]を超える場合があります。システム設計では接続のこの大きな数を考慮し、オープン・カーソルなど、追加の関連リソースについてデータベースで許容されるようにすべき場合があります。
また、接続が接続プールに返されない点にも注意する必要があります - これは、接続プールを縮小して、使用される関連リソースおよび接続の数を減らすことができないことを意味します。このコストは、追加のドライバ・パラメータonePinnedConnectionOnlyを設定することによって最小限に抑えることができます。onePinnedConnectionOnly=trueの場合、リクエストされた最初の接続のみがスレッドに固定されます。スレッドで必要なその他の接続はすべて、必要に応じて接続プールから取得されたり、接続プールに返されます。次に示すように、Properties属性を使用してonePinnedConnectionOnlyを設定します。
Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"
システムで追加のリソース要件を処理できる場合、PinnedToThreadオプションを使ってパフォーマンスを向上させることをお薦めします。
現在のシステムでは追加のリソース要件を処理できない、またはPinnedToThreadを有効化するとデータベース・リソースでエラーが発生する場合は、PinnedToThreadは使用しないでください。
データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイメント対象として選択します。データ・ソースがサーバーにデプロイされると、WebLogic Serverはデータ・ソース内のデータベース接続のプールを含む、サーバー上のデータ・ソースのインスタンスを作成します。クラスタにデータ・ソースをデプロイする場合、クラスタ内の各サーバー上にデータ・ソースのインスタンスが作成されます。
手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのターゲット指定に関する項を参照してください。
サーバー起動時に、WebLogic Serverはサーバーにデプロイされたデータ・ソース内にデータベース接続を作成しようとします。データベースにアクセスできない場合、サーバーの起動は、長時間にわたってスタンバイ状態でハングする可能性があります。これは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リソースのセキュリティの設定方法については、Oracle WebLogic Server管理コンソール・ヘルプの「ロールとポリシーを使用したリソースの保護」に関する項を参照してください。サーバー・リソースのセキュリティについては、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースのセキュリティ」に関する項を参照してください。
管理者がJDBCデータ・ソース上に行う可能性があるアクションを制限できる管理者用メソッドを割り当てることによって、JDBC操作を保護できます。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のJavaデータベースの接続性(JDBC)リソースに関する項を参照してください。
JDBC MBeanで許容されるロールはAdminとDeployerのみです。次の項では、JDBC MBeanに定義されるセキュリティ・ロールに関する情報が提供されます。
WebLogic Serverのデフォルトのセキュリティ設定の詳細は、Oracle WebLogic Server MBeanリファレンスのMBeanのデフォルトのセキュリティ・ポリシーに関する項を参照してください。
次のドメイン構成JDBC MBeanには、デフォルトのセキュリティ設定をオーバーライドする設定があります。
JDBCConnectionPoolMBean (非推奨)
JDBCDataSourceFactoryMBean (非推奨)
JDBCDataSourceMBean (非推奨)
JDBCMultiPoolMBean (非推奨)
JDBCSystemResourceMBean
JDBCTxDataSourceMBean (非推奨)
Oracle WebLogic Server MBeanリファレンスのドメイン構成MBeanに関する項を参照してください。
次のシステム・モジュールJDBC MBeanには、デフォルトのセキュリティ設定をオーバーライドする設定があります。
JDBCConnectionPoolParamsBean
JDBCDataSourceBean
JDBCDataSourceParamsBean
JDBCDriverParamsBean
JDBCPropertiesBean
JDBCPropertyBean
JDBCXAParamsBean
Oracle WebLogic Server MBeanリファレンスのシステム・モジュールMBeanに関する項を参照してください。
WebLogic Serverのこれまでのリリースでは、アプリケーション・スコープのJDBC接続プールは、デフォルトの接続プールの値を提供するのに、JDBCデータ・ソース・ファクトリを使用していました。JDBCデータ・ソース・ファクトリはWebLogic Server 9.2では非推奨となっており、本リリースでは下位互換性のみを目的としています。アプリケーション・スコープのJDBC接続プールの代わりとして、JDBCアプリケーション・モジュールが使用されます。詳細は、「パッケージ化されたJDBCモジュールのアプリケーション・スコープ指定」を参照してください。
