| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > 管理者ガイド > JDBC 接続の管理 |
|
管理者ガイド
|
以下の節では、ローカル トランザクションと分散トランザクションの両方における、JDBC コンポーネント (データ ソース、接続プール、およびマルチプール) を介したデータベース接続のコンフィグレーションと管理のガイドラインを紹介します。
Administration Console には、JDBC (Java Database Connectivity) などの WebLogic Server 機能のコンフィグレーションと管理を可能にするツールへのインタフェースが用意されています。接続の作成、管理、およびモニタを含むほとんどの JDBC 管理機能において、システム管理者は Administration Console またはコマンドライン インタフェースを使用します。アプリケーション開発者は、JDBC API を使用することも WebLogic 管理 API を使用することもできます。
以下に、接続を設定および管理するためによく行われるタスクを示します。
JDBC 接続の設定と管理は、おもに Administration Console で行います。Administratin Console を使用して、永続的な接続、つまりサーバを停止して再起動した後も利用できる接続プール、データ ソース、トランザクション データ ソース、およびマルチプールを設定します。これらの JDBC オブジェクトは、静的オブジェクトと呼ばれます。動的オブジェクト、つまり使用後に削除することが想定されているオブジェクトは、管理コマンドラインまたはアプリケーション コードで作成できます。
接続を設定するだけでなく、Administration Console では確立された接続を管理およびモニタすることもできます。
コマンドライン インタフェースでは、接続プールおよびデータ ソースを動的に作成および管理できます。コマンドライン インタフェースの使い方については、WebLogic Server コマンドライン インタフェース リファレンスを参照してください。
プログラミングによる接続の設定と管理については、『WebLogic JDBC プログラマーズ ガイド』を参照してください。
ローカルおよび分散トランザクションで使用される JDBC ドライバは多くの WebLogic Server コンポーネントと連係して機能し、情報はさまざまなドキュメントに掲載されています。たとえば、JDBC ドライバについての情報は、JDBC、JTA、および WebLogic jDrivers のマニュアルで参照できます。
JDBC、JTA、および管理の追加リソースのリストを以下に示します。
以下のドキュメントは、おもにアプリケーション開発者向けに書かれています。システム管理者は、このドキュメントの内容を理解するための補助資料として、必要に応じて以下の初歩的な情報を参照してください。
以下のドキュメントは、おもにアプリケーション開発者向けに書かれています。システム管理者は、この章の内容を理解するための補助資料として、必要に応じて以下の情報を参照してください。
JDBC コンポーネント (接続プール、データ ソース、およびマルチプール)
以降の節では、JDBC 接続コンポーネント (接続プール、マルチプール、およびデータ ソース) の概要を説明します。
図8-1 WebLogic Server の JDBC コンポーネント
接続プールとは、接続プールが登録されるとき (WebLogic Server の起動時、または対象となるサーバやクラスタに接続プールを割り当てるとき) に作成される JDBC 接続のグループです。接続プールでは、物理的なデータベース接続の作成に、Type 2 または Type 4 の JDBC ドライバを使用します。アプリケーションはプールから接続を「借り」、使用後は接続をクローズしてプールに返します。詳細については、『WebLogic JDBC プログラマーズ ガイド』の「接続プール」を参照してください。
Administration Console で行う設定はすべて静的なものです。つまり、すべての設定は WebLogic Server を停止して再起動した後も持続します。動的な接続プール、つまりサーバの実行中に使用および削除することが想定されている接続プールは、コマンドラインを使用して (WebLogic Server コマンドライン インタフェース リファレンスを参照)、または API を使用してプログラムで (『WebLogic JDBC プログラマーズ ガイド』の「接続プールの動的作成」を参照) 動的に作成できます。
接続プールの設定は config.xml ファイルに保持されます。動的に作成された接続プールの設定も、プログラムによって接続プールが削除されるまではこのファイルに保持されます。config.xml ファイル内のエントリについては、『コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
エンタープライズ アプリケーションをパッケージ化するときに、weblogic-application.xml 補足デプロイメント記述子を含めることができます。この記述子を使用して、アプリケーション スコーピングをコンフィグレーションします。weblogic-application.xmlファイルでは、エンタープライズ アプリケーションをデプロイするときに作成される JDBC 接続プールをコンフィグレーションできます。
接続プールのインスタンスは、アプリケーションのインスタンスごとに作成されます。つまり、プールのインスタンスは、アプリケーションの対象となっている各ノード上のアプリケーションで作成されます。プールのサイズを検討する場合は、この点に留意してください。
この方法で作成された接続プールは「アプリケーション スコープの接続プール」(アプリケーション スコープ プール、アプリケーション ローカル プール、または ローカル プール) と呼ばれ、そのエンタープライズ アプリケーションに対してだけスコーピングされます。つまり、各接続プールがエンタープライズ アプリケーションごとに分離されます。
アプリケーション スコーピング、およびアプリケーション スコープ リソースの詳細については、以下を参照してください。
マルチプールとは、接続プールのプールです。単一または複数の WebLogic Server コンフィグレーションのローカル (非分散) トランザクションで使用します。マルチプールは、以下の機能に役立ちます。
データ ソース オブジェクトによって、JDBC アプリケーションは接続プールから DBMS 接続を取得できるようになります。各データ ソース オブジェクトは、JNDI ツリーにバインドし、接続プールまたはマルチプールを指します。アプリケーションは、データ ソースをルックアップして接続を取得します。データ ソース オブジェクトは、JTA を使用して定義することも (Administration Console の [トランザクション データ ソース])、使用せずに定義することもできます (Administration Console の [データ ソース])。分散トランザクションには、[トランザクション データ ソース] を使用します。データ ソースおよびトランザクション データ ソースの使い方の詳細については、接続プール、マルチプール、およびデータソースの JDBC コンフィグレーション ガイドラインを参照してください。
WebLogic Server では、JDBC データ ソース リソースを、リソース ファクトリとして WebLogic Server JNDI ツリーにバインドできます。その後、EJB デプロイメント記述子のリソース ファクトリ参照を、実行中の WebLogic Server の利用可能なリソース ファクトリにマップすると、接続プールから接続を取得できます。
JDBC データ ソース ファクトリの作成と使用方法の詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「リソース ファクトリ」を参照してください。
オプションとして、JDBC 接続プールへのアクセスを制限できます。以前のバージョンの WebLogic Server では、ACL を使って WebLogic リソースを保護していました。WebLogic Server バージョン 7.0 では、WebLogic リソースへの「アクセス権は誰が持つか」という問いに、セキュリティ ポリシーが答えます。セキュリティ ポリシーは、WebLogic リソースとユーザ、グループ、またはロールの間の関連付けを定義するときに作成します。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。すべての WebLogic Server リソースのセキュリティを設定する手順については、Administration Console オンライン ヘルプの「WebLogic リソースの保護の設定」を参照してください。
WebLogic Server 7.0 では、下位互換性のためにバージョン 6.1 のセキュリティ モデルを引き続きサポートしています。バージョン 6.1 のセキュリティを使用するには、互換性モードで実行する必要があります。互換性モードでの実行の詳細については、以下のドキュメントを参照してください。
WebLogic Server 6.1 では、デフォルトのセキュリティ レルムはファイル レルムでした。ファイル レルムは、認証と認可に fileRealm.properties ファイルの ACL を使用します。接続プールは、(リソース タイプとして) 接続プール群または個々の接続プールに対し ACL を定義するまでは、保護されません。接続プールに対して ACL を定義すると、その ACL に定義されているものだけにアクセスが制限されます。たとえば、fileRealm.properties ファイル内で接続プールの ACL が定義されるまでは、ドメイン内のすべての接続プールに誰でも無制限にアクセスできます。しかし、ファイルに次の行を追加すると、アクセス権は大幅に制限されます。
acl.reset.weblogic.jdbc.connectionPool=Administrators
この行により、すべての接続プールの管理者にリセット特権が付与され、他のすべてのユーザによる他のアクションはすべて禁止されます。ACL を追加することで、接続プールのファイル レルム保護がアクティブになります。WebLogic Server では、fileRealm.properties で定義された ACL を強制し、ファイル内で明確に付与されたアクセスのみを許可します。接続プールのリセットだけを制限する目的で ACL を追加するのであれば、他のアクションに対する特権を、全員または特定のロールやユーザに、明確に付与する必要があります。次に例を示します。
acl.reserve.weblogic.jdbc.connectionPool=everyone
acl.shrink.weblogic.jdbc.connectionPool=everyone
acl.admin.weblogic.jdbc.connectionPool=everyone
表 8-1 には、fileRealm.properties で接続プールのセキュリティ保護を行うために使用できる ACL を示します。
Administration Console による JDBC 接続プール、マルチプール、およびデータソースのコンフィグレーションと管理
以降の節では、JDBC コンポーネント (接続プール、データ ソース、およびマルチプール) をコンフィグレーションしてデータベース接続を設定する方法について説明します。接続がいったん確立されたら、Administration Console またはコマンドライン インタフェースを使用して接続を管理およびモニタできます。コンフィグレーション タスクの説明および Administration Console オンライン ヘルプのリンクについては、表 8-3を参照してください。
Administration Console で行う JDBC の設定は、接続プール、マルチプール、DataSource、および TxDataSource のコンフィグレーション設定も含め、そのドメインの config.xml ファイルに保持されます。このファイル内のエントリについては、『コンフィグレーション リファレンス』の以下の節を参照してください。
ここでは、コンフィグレーションとは以下のプロセスのことです。
Administration Console を使用し、属性とデータベース プロパティを指定して JDBC コンポーネント (接続プール、データ ソース、およびマルチプール) を作成します。Administration Console を使用した JDBC 接続のコンフィグレーションを参照してください。
まず接続プールおよびオプションでマルチプールを作成してから、データ ソースを作成します。データ ソース オブジェクトを作成する場合、データ ソースの属性の 1 つとして接続プールまたはマルチプールを作成します。これにより、そのデータ ソースは特定の 1 つの接続プールまたはマルチプール (「プール」) と関連付けられます。
データ ソースと接続プール (またはマルチプール) のコンフィグレーションと関連付けを行ったら、各オブジェクトを同じサーバまたはクラスタに割り当てます。 一般的なシナリオをいくつか以下に示します。
クラスタ内の接続プール、データ ソース、およびマルチプールの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「JDBC 接続」を参照してください。実行するタスクの説明については、Administration Console を使用した JDBC 接続のコンフィグレーションを参照してください。
コンフィグレーション プロセスの関連付けと割り当ての詳細については、次の表を参照してください。
これらのデータ ソースと接続プールの組み合わせを複数のサーバまたはクラスタに割り当てることはできますが、それらは組み合わせとして割り当てなければなりません。たとえば、関連付けられている接続プールがサーバ B にのみ割り当てられている場合は、データ ソースを管理対象サーバ A に割り当てることはできません。
動的な接続プールは、(サーバの起動後に) WebLogic API を使用しても (『WebLogic JDBC プログラマーズ ガイド』の「動的接続プールの作成」を参照)、コマンドライン インタフェースを使用しても (コマンドライン インタフェースを使用した JDBC コンフィグレーション タスクを参照)、コンフィグレーションできます。また WebLogic Server では、インストールの際にサンプルのインストールを選択した場合、サーバ サンプル内に動的なデータ ソースおよび接続プールを作成およびコンフィグレーションするためのサンプル コードが入っています。SAMPLES_HOME¥server¥src¥examples¥jdbc を参照してください。ここで SAMPLES_HOME は、WebLogic プラットフォーム用のすべてのサンプルおよび例の格納先の最上位ディレクトリです (デフォルトでは c:¥bea¥weblogic700¥samples)。
Administration Console を使用した JDBC 接続のコンフィグレーション
Administration Console では、JDBC 接続をコンフィグレーション、管理、およびモニタできます。タスクに使用するタブを表示するには、以下の手順を実行します。
次の表では、接続タスクを一般的な実行順序で示します。これらのタスクは異なった順序で実行してもかまいませんが、オブジェクトは関連付けや割り当てを行う前にコンフィグレーションする必要があります。
|
このタスクでは接続プールをコピーする。[コンフィグレーション] タブで、プールの名前をユニークな名前に変更し、それ以外の属性をそのまま使用するか変更する。この機能は、別々の名前で複数の同じプール コンフィグレーションが必要な場合に便利。たとえば、各データベース管理者に、特定のプールを使用してデータベースへの個々の変更をトラッキングさせることができる。 |
|
|
[対象] タブを使用して、接続プールを 1 つまたは複数のサーバまたはクラスタに割り当てる。表 8-2「関連付けと割り当てのシナリオ」を参照。 また、複数の接続プールをサーバに割り当てる方法については、オンライン ヘルプの「サーバへの JDBC 接続プールの割り当て」を参照。 |
|
|
[コンフィグレーション] タブで、名前およびアルゴリズム (高可用性またはロードバランシング) の属性を設定する。[プール] タブで、接続プールをこのマルチプールに割り当てる。 |
|
|
[コンフィグレーション] タブを使用して、名前、JNDI 名、およびプール名 (これでデータ ソースが特定の接続プールまたはマルチプールと関連付けられる) といったデータ ソースの属性を設定する。 |
|
|
[コンフィグレーション] タブを使用して、名前、JNDI 名、および接続プール名 (これでデータ ソースが特定のプールと関連付けられる) といったトランザクション データ ソースの属性を設定する。 注意: トランザクション データ ソースはマルチプールとは関連付けない。マルチプールは分散トランザクションでサポートされていない。 |
|
接続プールのコンフィグレーションにおけるデータベース パスワード
接続プールを作成する場合、一般にはデータベースへの接続用として、1 つ以上のパスワードを組み込みます。オープン文字列を使用して、XA を有効にする場合は、パスワードを 2 つ使用できます。パスワードは、名前と値のペアとして [プロパティ] フィールドに入力するか、名前と値をそれぞれ対応するフィールドに入力します。
openString=Oracle_XA+Acc=P/userName/+SesTm=177+DB=dbHost+Threads=true=Sqlnet=dvi0+logDir=.
接続プールを初めてコンフィグレーションするときに [プロパティ] フィールドにパスワードを指定した場合、次の起動時に WebLogic Server は、パスワードを Properties 文字列から取り除き、その値を暗号化して Password の値として設定します。既に接続プールの [パスワード] 属性に値が設定されている場合は、どの値も変更されません。ただし、[プロパティ] の文字列の値は、[パスワード] 属性の値によってオーバーライドされます。この動作は、オープン文字列の一部として定義するすべてのパスワードに対して同じように適用されます。たとえば、接続プールを初めてコンフィグレーションするときに次のプロパティを指定したとします。
user=scott;
password=tiger;
openString=Oracle_XA+Acc=p/scott/tiger+SesTm=177+db=dbHost+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=dbHost
次回の WebLogic Server の起動時には、データベース パスワードが [パスワード] 属性に、オープン文字列に含まれているパスワードが [オープン文字列のパスワード] 属性にそれぞれ移され、[プロパティ] フィールドには次の値が残ります。
user=scott;
openString=Oracle_XA+Acc=p/scott/+SesTm=177+db=dbHost+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=dbHost
[パスワード] 属性または [オープン文字列のパスワード] 属性の値が確定すると、これらの値によって [プロパティ] 属性のそれぞれの値がオーバーライドされます。これを先の例で説明すると、[パスワード] 属性に暗号化されたデータベース パスワードとして tiger が設定されているため、[プロパティ] 属性内のデータベース パスワードとして tiger2 を指定しても無視されます。データベース パスワードを変更するには、[パスワード] 属性を変更する必要があります。
注意: [パスワード] と [オープン文字列のパスワード] の値は、同じでなくてもかまいません。
コマンドライン インタフェースを使用した JDBC コンフィグレーション タスク
|
|
詳細については、WebLogic Server コマンドライン インタフェース リファレンス、および『WebLogic JDBC プログラマーズ ガイド』の「接続プールの動的作成」を参照してください。
接続の管理では、確立された JDBC コンポーネントを有効化、無効化、および削除します。
Administration Console を使用した JDBC の管理
JDBC 接続を管理およびモニタするには、次の表を参照してください。
|
「接続プールのサーバ/クラスタへの割り当て」の手順に従って、[対象] タブで対象を選択解除 ([選択済み] から [選択可] に移動) し、新しい対象に割り当てる。 複数の接続プールをサーバに割り当てる方法については、オンライン ヘルプの「サーバへの JDBC 接続プールの割り当て」を参照。 |
|
|
「マルチプールのサーバまたはクラスタへの割り当て」の手順に従って、[対象] タブで対象を選択解除 ([選択済み] から [使用可能] に移動) し、新しい対象に割り当てる。 |
|
|
オンライン ヘルプの「JDBC 接続プールの削除」を参照。 |
|
|
オンライン ヘルプの「JDBC マルチプールの削除」を参照。 |
|
|
オンライン ヘルプの「JDBC 接続プールの削除」を参照。 |
|
|
1 つの接続プールの接続をモニタする方法については、オンライン ヘルプの「JDBC 接続プールのモニタ」を参照。 サーバのすべてのアクティブな接続プールをモニタする方法については、オンライン ヘルプの「すべてのアクティブな JDBC 接続プールのモニタ」を参照。 |
|
次の表では、コマンドライン インタフェースを使用した接続プールの管理について説明します。詳細情報が必要な場合は、目的のコマンドを選択してください。
接続プールのコマンドの使い方については、WebLogic Server コマンドライン インタフェース リファレンスを参照してください。
接続プール、マルチプール、およびデータソースの JDBC コンフィグレーション ガイドライン
この節では、ローカル トランザクションおよび分散トランザクションで使用される接続プール、マルチプール、およびデータ ソースの JDBC コンフィグレーションのガイドラインについて説明します。
JDBC 接続を設定するには、Administration Console (動的接続プールの場合はアプリケーション コードまたはコマンドライン) で属性を定義して、接続プール、データ ソース オブジェクト (常に設定することが望ましいが、省略可能な場合もある)、およびマルチプール (省略可能) をコンフィグレーションします。
システム内でトランザクションが処理される方法に応じて、データ ソース オブジェクト (DataSources および TxDataSources)、接続プール、およびマルチプールをコンフィグレーションします。次の表に、3 つのトランザクション シナリオ用にこれらのオブジェクトをコンフィグレーションする方法を示します。
|
複数のリソースが関与している場合は、[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] を選択する (enable two-phase commit=true を設定)。 分散トランザクション用の XA 非対応 JDBC ドライバのコンフィグレーションを参照。 |
|||
注意: 分散トランザクションの場合は、XA 対応ドライバ (WebLogic jDriver for Oracle の XA 対応バージョンである WebLogic jDriver for Oracle/XA など) を使用します。
アプリケーションまたは環境が以下の条件のいずれかに合てはまる場合は、データ ソースではなくトランザクション データ ソースを使用してください。
EJB アーキテクチャでは、データベース処理中の複数の EJB が単一のトランザクションの一部として呼び出されることがよくあります。XA を使用しない場合、すべてのトランザクション参加コンポーネントが同一のデータベース接続を使用しないと、このトランザクションは機能しません。WebLogic Server は、JTS ドライバおよび TxDataSource ([非 XA ドライバ用に 2 フェーズ コミットをエミュレート] を選択) を背後で使用して、JDBC 接続を EJB 間で明示的に受け渡さないでもこの処理が行われるようにします。XA を使用すると (XA 対応ドライバが必要)、2 フェーズ コミットによる分散トランザクションに対して WebLogic Server のトランザクション データ ソースを使用できるので、EJB ではトランザクションの各部分に異なったデータベース接続を使用できます。いずれの場合でも (XA の有無にかかわらず)、トランザクション データ ソースは使用してください。
詳細については、『WebLogic JDBC プログラマーズ ガイド』の「データ ソース」を参照してください。
注意: 同じ接続プールを指す 2 つのトランザクション データ ソースを作成することはできません。1 つのトランザクションで、同じ接続プールを指す 2 つの異なるトランザクション データ ソースを使用していると、2 度目の接続へのアクセス試行時に XA_PROTO エラーが発生します。
JDBC コア 2.0 API (java.sql) をサポートする JDBC 2.0 ドライバ。WebLogic jDrivers for Oracle、および WebLogic jDrivers for Microsoft SQL Server など。この API を使用すると、データ ソースへの接続を確立し、クエリを送信し、その結果を処理するのに必要なクラス オブジェクトを作成できます。
JDBC 2.0 分散トランザクション標準拡張インタフェース (javax.sql.XADataSource、javax.sql.XAConnection、javax.transaction.xa.XAResource) をサポートする JDBC 2.0 ドライバ。WebLogic jDriver for Oracle/XA など。
XA を使用しない分散トランザクションをサポートするドライバ
JDBC 2.0 コア API はサポートするが、JDBC 2.0 分散トランザクション標準拡張インタフェースはサポートしない JDBC ドライバ (XA 非対応)。XA 非対応の JDBC ドライバは、1 つしか分散トランザクションに参加できません。 分散トランザクション用の XA 非対応 JDBC ドライバのコンフィグレーションを参照してください。
アプリケーションで、接続プールから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外が送出されます。接続プールでは、接続要求のキューは作成されません。このエラーを避けるには、接続プールのサイズを接続要求の最大負荷に対応できるサイズに拡大するようにしてください。
Administration Console で接続プールの最大接続数を設定するには、左ペインのナビゲーション ツリーを展開して [サービス｜JDBC｜接続プール] ノードを表示し、接続プールを選択します。次に右ペインで、[コンフィグレーション｜接続] タブを選択し、[最大容量] の値を指定します。
ローカル トランザクション用の JDBC ドライバのコンフィグレーション
ローカル トランザクションに対応する JDBC ドライバをコンフィグレーションするには、次の手順に従って JDBC 接続プールを設定します。
WebLogic 2 層 JDBC ドライバの詳細については、使用しているドライバに関する BEA のマニュアル、『WebLogic jDriver for Oracle のインストールと使い方』および『WebLogic jDriver for Microsoft SQL Server のインストールと使い方』を参照してください。サードパーティ ドライバを使用する場合は、『WebLogic JTA プログラマーズ ガイド』の「WebLogic Server でのサードパーティ JDBC XA ドライバの使い方」およびベンダ提供のマニュアルを参照してください。以下の表では、WebLogic jDriver を使用した JDBC 接続プールおよびデータ ソースのサンプル コンフィグレーションを示します。
次の表では、WebLogic jDriver for Oracle を使用した接続プールのサンプル コンフィグレーションを示します。
注意: 以下のコンフィグレーション例では、[パスワード] 属性を使用します。[パスワード] 属性の値は、名前と値のペアで定義されたプロパティ内のパスワードをオーバーライドします。この属性は、物理的なデータベース接続の作成時に 2 層 JDBC ドライバに渡されます。値は、暗号化されて config.xml ファイルに格納され、そのファイルにクリア テキストのパスワードが格納されるのを防止するために使用できます。
|
tiger (入力時には「*****」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
次の表では、WebLogic jDriver for Oracle または WebLogic jDriver for Microsoft SQL Server を使用したデータ ソースのサンプル コンフィグレーションを示します。
次の表では、WebLogic jDriver for Microsoft SQL Server を使用した接続プールのサンプル コンフィグレーションを示します。
次の表では、IBM Informix JDBC Driver を使用した接続プールのサンプル コンフィグレーションを示します。
|
informix (入力時には「******」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
分散トランザクション用の XA 対応 JDBC ドライバのコンフィグレーション
XA 対応 JDBC ドライバを分散トランザクションに参加させるには、以下のように JDBC 接続プールをコンフィグレーションします。
以下の表で、XA モードで WebLogic jDriver for Oracle を使用する場合の JDBC 接続プールのコンフィグレーションの例を示します。
|
tiger (入力時には「*****」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
以下の表は、XA モードで WebLogic jDriver for Oracle を使用する場合のトランザクション データ ソースのコンフィグレーションの例を示します。
また、JDBC 接続プールをコンフィグレーションして、XA モードでサード パーティ ベンダ製ドライバを使用することもできます。この場合、データ ソース プロパティは、JavaBeans 設計パターンを使用し、XADataSource インスタンスに反映して設定します。つまり、abc というプロパティの場合、XADataSource インスタンスは、getAbc という名前の取得メソッドと、setAbc という名前の設定メソッドをサポートする必要があります。
以下の属性は、Oracle Thin Driver を使用する場合の JDBC 接続プールのコンフィグレーションの例です。
|
tiger (入力時には「*****」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
以下の表は、Oracle Thin Driver を使用する場合のトランザクション データ ソースのコンフィグレーションの例を示します。
以下の表は、Pointbase JDBC ドライバ を使用して、分散トランザクション用に JDBC 接続プールをコンフィグレーションする場合の例を示します。
注意: PointBase Server は WebLogic Server 配布キットに含まれている all-Java の DMBS 製品で、WebLogic Server の評価のみをサポートしてます。カスタムの試用版アプリケーションまたは WebLogic Server に付属するパッケージ化されたサンプル アプリケーションの形式です。 PointBase Server を評価以外の開発やプロダクション環境で使用する場合、エンド ユーザは別個のライセンスを PointBase から直接入手する必要があります。
|
public (入力時には「******」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
Pointbase ドライバで使用するトランザクション データ ソースは、以下のようにコンフィグレーションします。
WebLogic jDriver for Oracle/XA のデータ ソース プロパティ
表 8-18 に、WebLogic jDriver for Oracle でサポートされているデータ ソース プロパティを示します。「JDBC 2.0」カラムは、特定のデータ ソース プロパティが JDBC 2.0 の標準データ ソース プロパティ (S) か、または JDBC に対する WebLogic Server の拡張 (E) かを示します。
「省略可能」カラムは、特定のデータ ソース プロパティが省略可能かどうかを示します。「Y*」マークが付いたプロパティは、表 8-18 に示された、Oracle の xa_open 文字列 (openString プロパティの値) の対応するフィールドにマップされます。それらのプロパティが指定されない場合、デフォルト値は openString プロパティから取得されます。それらのプロパティが指定される場合、その値は openString プロパティで指定された値と一致する必要があります。プロパティが一致しない場合、XA 接続を確立しようとすると SQLException が送出されます。
「N*」マークが付いた必須プロパティも、Oracle の xa_open 文字列の対応するフィールドにマップされます。これらのプロパティは、Oracle の xa_open 文字列を指定するときに指定します。プロパティが指定されない場合や、指定されていても一致しない場合は、XA 接続を確立しようとすると SQLException が送出されます。
「**」マークが付いたプロパティ名はサポートされていますが、WebLogic Server では使用されません。
|
XA トレース出力が有効かどうかを示す。有効 (true) の場合、xa_poolnamedate.trc 形式の名前を持つファイルがサーバの起動ディレクトリに配置される。 |
表 8-19 に、Oracle の xa_open 文字列フィールドとデータ ソース プロパティの間のマッピングを示します。
注意: Oracle の xa_open 文字列で「Threads=true」と指定する必要があります。
Oracle の xa_open 文字列フィールドの詳細については、Oracle のドキュメントを参照してください。
分散トランザクションで接続プール内の接続を使用する場合、接続プールのプロパティを追加設定して、接続プールがトランザクションのコンテキストにおいて WebLogic Server 内で適切に接続を処理できるようにする必要があります。これらのプロパティは、JDBCConnectionPool タグ内のコンフィグレーション ファイル (config.xml) に設定します。デフォルトでは、すべての追加プロパティは false に設定されています。true に設定すると、これらのプロパティが有効になります。
多くの場合、これらのプロパティの適切な値は自動的に設定されるので、ユーザが手動で設定する必要はありません。
DBMS によっては、同じ物理データベース接続でトランザクションを開始および終了する必要があります。しかし、ある物理データベース接続で開始した WebLogic Server トランザクションが別のデータベース接続で終了する場合もあります。トランザクションが完了するまで接続プールが物理接続を保持し、同じアプリケーション接続を提供するようにするには、KeepXAConnTillTxComplete="true" に設定します。次に例を示します。
<JDBCConnectionPool KeepXAConnTillTxComplete="true" DriverName="com.sybase.jdbc2.jdbc.SybXADataSource" CapacityIncrement="5" InitialCapacity="10" MaxCapacity="25" Name="demoXAPool" Password="{3DES}vIF8diu4H0QmdfOipd4dWA==" Properties="User=dbuser;DatabaseName=dbname;ServerName=server_name_or_IP_address;PortNumber=serverPortNumber;NetworkProtocol=Tds;resourceManagerName=Lrm_name_in_xa_config;resourceManagerType=2" />注意: このプロパティは、DB2 と Sybase との分散トランザクションをサポートするために必要です。
分散トランザクション用の XA 非対応 JDBC ドライバのコンフィグレーション
XA 非対応のドライバが分散トランザクションの他のリソースに関与できるように JDBC 接続プールをコンフィグレーションする場合は、[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] 属性 (JDBCTxDataSource MBean の EnableTwoPhaseCommit) を選択します。このパラメータは、XAResource インタフェースをサポートしているリソースでは無視されます。XA 非対応の接続プールは、1 つしか分散トランザクションに参加できません。
XA 非対応ドライバを 1 つだけ使用し、それがトランザクションで唯一のリソースである場合は、Console において [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションを選択されていないままにします (デフォルトの EnableTwoPhaseCommit = false を受け入れる)。 この場合は、WebLogic Server は設定を無視し、トランザクション マネージャが 1 フェーズの最適化を実行します。
他の XA リソースとともに XA 非対応 JDBC ドライバを 1 つ使用する場合は、Administration Console で [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] を選択します (EnableTwoPhaseCommit = true)。
[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] が選択されている (EnableTwoPhaseCommit が true に設定されている) 場合、XA 非対応の JDBC リソースは XAResource.prepare() メソッド呼び出し中に必ず XA_OK を返します。リソースは、以降の XAResource.commit() 呼び出しまたは XAResource.rollback() 呼び出しに応答して、そのローカル トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗すると、ヒューリスティック エラーが発生します。ヒューリスティック エラーの結果、アプリケーション データは矛盾した状態のまま残される場合があります。
Console で [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションが選択されていない (EnableTwoPhaseCommit が false に設定されている) 場合、XA 非対応の JDBC リソースによって XAResource.prepare() が失敗します。この場合、commit() が SystemException を送出するので、トランザクションには参加コンポーネントが 1 つしか存在しないことになります。トランザクションの参加コンポーネントが 1 つしか存在しない場合、1 つのフェーズ最適化は XAResource.prepare() を無視し、トランザクションはほとんどのインスタンスで正常にコミットします。
この XA 非対応の JDBC ドライバを「JTS ドライバ」と呼ぶこともあります。これは、WebLogic Server で XA をサポートするために WebLogic JTS ドライバを内部的に使用しているからです。 WebLogic JTS ドライバの詳細については、『WebLogic JDBC プログラマーズ ガイド』の「WebLogic JTS ドライバの使い方」を参照してください。
グローバル トランザクションで XA 非対応のドライバを使用する場合の制限とリスク
WebLogic Server では、XA 非対応の JDBC リソースをグローバル トランザクションに参加させることができますが、こうしたリソースを使用するアプリケーションを設計する際に考慮すべき制限事項があります。 XA 非対応のドライバは XA/2PC 規約に準拠しておらず、1 フェーズのコミットおよびロールバック操作しかサポートしていません。このため、WebLogic Server では JTS ドライバを使用して、トランザクションに参加するリソースをトランザクション マネージャで管理できるようにする必要があります。
XA 非対応のリソース用に [Emulate Two-Phase Commit] を選択した場合 (enableTwoPhaseCommit = true)、XA 非対応リソース用のトランザクションの準備フェーズは必ず問題なく完了します。 したがって、XA 非対応リソースは、実際には 2 フェーズ コミット (2PC) プロトコルには参加しないため、障害が発生しても構いません。 準備フェーズの後で XA 非対応リソースに障害が発生した場合は、XA トランザクションの参加者がトランザクションをコミットする間に XA 非対応リソースがトランザクションにロールバックされ、結果としてヒューリスティックな終了とデータの矛盾が発生します。
データの整合性が失われるリスクがあるため、[Emulate Two-Phase Commit] オプションはヒューリスティックな状態を許容できるアプリケーションでのみ使用してください。
XA 非対応ドライバではローカル データベース トランザクションのみを操作するため、外部のトランザクション マネージャに関しては、データベース内のトランザクションが保留状態になることは想定されていません。 XA 非対応リソース上で XAResource.recover() が呼び出されると、コミットまたはロールバックする必要のあるトランザクションがあったとしても、常に空の Xid (トランザクション ID) のセットが返されます。 したがって、グローバル トランザクションで XA 非対応リソースを使用するアプリケーションでは、システム障害から回復したりデータの整合性を維持したりすることはできません。
マルチ サーバ コンフィグレーションで XA 非対応リソースを使用することによるパフォーマンスの低下
WebLogic Server は、XA 非対応リソースのグローバル トランザクションへの参加をサポートする上で、特定の JDBC に関連付けられたデータベース ローカル トランザクションに依存しています。このため、複数の WebLogic Server インスタンスのグローバル トランザクション コンテキストを持つアプリケーションが同じ JDBC データ ソースにアクセスした場合、JTS ドライバはトランザクション内で最初に確立された接続に JDBC 操作をルーティングします。 たとえば、あるアプリケーションがサーバ上のトランザクションを開始して XA 非対応リソースにアクセスし、続いて RMI (remote method invocation) 呼び出しを別のサーバに対して実行して同じ基底の JDBC ドライバを使用するデータ ソースにアクセスした場合、JTS ドライバは別のサーバ上のトランザクションに関連付けられた接続を持つリソースを認識し、1 番目のサーバ上の実際の接続への RMI のリダイレクトを設定します。 接続におけるすべての操作は、1 番目のサーバで確立された 1 つの接続を使用して実行されます。 この動作により、リモート接続の設定と物理接続に対する RMI 呼び出しが原因でパフォーマンスが低下するおそれがあります。
WebLogic Server トランザクション マネージャに [Emulate Two-Phase Commit] を選択した XA 非対応リソースを登録すると、そのリソースは XAResource インタフェースを実装するクラスの名前で登録されます。 [Emulate Two-Phase Commit] を選択したすべての XA 非対応リソースは XAResource インタフェース用の JTS ドライバを使用するため、グローバル トランザクションに参加するこれらの XA 非対応リソースはすべて同じ名前で登録されます。 1 つのグローバル トランザクションで複数の XA 非対応リソースを使用すると、名前の衝突やヒューリスティック エラーが発生します。
XA 非対応接続プールと Tx データ ソースのコンフィグレーション例
次の表では、XA 非対応 JDBC ドライバを使用するサンプル JDBC 接続プールのコンフィグレーション属性を示します。
|
tiger (入力時には「*****」と表示され、以後は非表示。この値は [プロパティ] で名前と値の組み合わせとして定義されているすべてのパスワードをオーバーライドする) |
|
次の表では、XA 非対応 JDBC ドライバを使用するサンプル トランザクション データ ソースのコンフィグレーション属性を示します。
Prepared Statement キャッシュのパフォーマンスの向上
WebLogic Server 内に作成した各接続プールで Prepared Statement または XA Prepared Statement のキャッシュ サイズを設定することで、Prepared Statement のキャッシングが有効になります。 Prepared Statement のキャッシングを有効にすると、アプリケーションおよび EJB で使用した Prepared Statement と Callable Statement が設定した数だけキャッシュされます。 アプリケーションまたは EJB で、キャッシュに格納されている Prepared Statement または Callable Statement のいずれかが呼び出されると、WebLogic Server はキャッシュに格納されている Prepared Statement を再利用します。 Statement を再利用すると、データベース内の文を解析する必要がなくなることでデータベース マシンの CPU 使用率が低減され、現在の文に対するパフォーマンスが向上するとともに、CPU サイクルを他のタスク用に残しておけます。
Prepared Statement は、接続プールではなく接続ごとにキャッシュされます。 たとえば、Prepared Statement のキャッシュ サイズを 10 に設定すると、WebLogic Server はアプリケーションまたは EJB がその特定の接続を使用して呼び出した 10 個の Prepared Statement を格納します。
WebLogic Server 7.0 サービス パック 3 では、Prepared Statement のキャッシュ機能が変更され、XA (トランザクション対応) JDBC ドライバを使用する接続プールに対しては、XA 非対応の JDBC ドライバの代わりにデータベース接続が作成されるようになりました。 JDBC 接続プール内でデータベース接続の作成に使用する JDBC ドライバのタイプに応じて、適切なキャッシュ サイズ属性を設定する必要があります。XA 非対応 JDBC ドライバを使用する接続プールの場合は PreparedStatementCacheSize を、XA 対応 JDBC ドライバを使用する接続プールの場合は XAPreparedStatementCacheSize を設定します。 詳細については、次の節XA 非対応の Prepared Statement キャッシュおよびXA 対応の Prepared Statement キャッシュを参照してください。
XA 非対応の Prepared Statement キャッシュ
XA 非対応の Prepared Statement キャッシュの場合、接続プール内の接続ごとのキャッシュにどの文を格納するかが、固定アルゴリズムに基づいて判別されます。接続で使用された Prepared Statement および Callable Statement は、Prepared Statement キャッシュが一杯になるまでキャッシュされます。 キャッシュが一杯になると、それ以降に使用された文はキャッシュされません。
注意: Statement キャッシュは、JMX API を使用してクリアできます。 詳細については、WebLogic クラスの Javadoc のclearStatementCache() メソッドを参照してください。
この Statement キャッシュは、XA 非対応 JDBC ドライバを使用してデータベース接続を作成する接続プールにのみ使用します。 このキャッシュ設定は、データベース接続に XA 対応 JDBC ドライバを使用する接続プールでは無視されます。
XA 非対応 Prepared Statement のキャッシュ サイズのデフォルト値は、5 です。以下の方法で、接続プールの Prepared Statement キャッシュのサイズを設定できます。
コンフィグレーション ファイルを使用して接続プール用に XA 非対応の Prepared Statement のキャッシュ サイズを設定するには、サーバを起動する前にエディタで config.xml ファイルを開き、JDBCConnectionPool タグの PreparedStatementCacheSize 属性のエントリを追加します。次に例を示します。
<JDBCConnectionPool CapacityIncrement="5"
DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
InitialCapacity="5" MaxCapacity="20" Name="demoPool"
Password="{3DES}ANfMduXgaaGMeS8+CR1xoA=="
PreparedStatementCacheSize="20" Properties="user=examples"
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="examplesServer"
TestConnectionsOnRelease="false"
TestConnectionsOnReserve="false"
URL="jdbc:pointbase:server://localhost/demo"/>
XA 対応の Prepared Statement キャッシュ
XA 対応の Prepared Statement キャッシュの場合、最長時間未使用 (LRU : Least Recently Used) アルゴリズムに基づいて、接続プール内の接続ごとのキャッシュにどの文を格納するかを判別します。接続で使用された Prepared Statement および Callable Statement は、Statement キャッシュが一杯になるまでキャッシュされます。 アプリケーションが Connection.prepareStatement() を呼び出すと、Prepared Statement キャッシュにその文が格納されているかどうかがチェックされます。 格納されている場合は、キャッシュされている文が返されます (まだ使用されていない場合)。 文がキャッシュに格納されておらず、キャッシュが一杯 (キャッシュ内の文の数が XAPreparedStatementCacheSize に等しい状態) になっている場合は、キャッシュ内で最長時間未使用になっている文が識別され、この文が新しい文によって置換されます。
注意: Statement キャッシュは、JMX API を使用してクリアできます。 詳細については、WebLogic クラスの Javadoc のclearStatementCache() メソッドを参照してください。
XA 対応の Statement キャッシュは、XA 対応 JDBC ドライバを使用してデータベース接続を作成する接続プールにのみ使用します。 このキャッシュ設定は、データベース接続に XA 非対応 JDBC ドライバを使用する接続プールでは無視されます。
XA 対応 Prepared Statement のキャッシュ サイズのデフォルト値は、5 です。 以下の方法で、接続プールの XA 対応 Prepared Statement キャッシュのサイズを設定できます。
コンフィグレーション ファイルを使用して接続プール用に XA 対応 Prepared Statement のキャッシュ サイズを設定するには、サーバを起動する前にエディタで config.xml ファイルを開き、JDBCConnectionPool タグの PreparedStatementCacheSize 属性のエントリを追加します。次に例を示します。
<JDBCConnectionPool CapacityIncrement="5"
DriverName="com.pointbase.xa.xaDataSource"
InitialCapacity="5" MaxCapacity="20" Name="demoXAPool"
Password="{3DES}ANfMduXgaaGMeS8+CR1xoA=="
XAPreparedStatementCacheSize="20"
Properties="user=examples;
DatabaseName=jdbc:pointbase:server://localhost/demo"
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="examplesServer"
TestConnectionsOnRelease="false"
TestConnectionsOnReserve="false"
URL="jdbc:pointbase:server://localhost/demo"/>
Prepared Statement キャッシュに関する制限
Prepared Statement キャッシュを使用することでパフォーマンスを向上させることができますが、制限があることも考慮に入れる必要があります。Prepared Statement のキャッシュを使用する場合は、以下の制限に留意してください。 これらの制限は、XA 対応および XA 非対応の両方の Prepared Statement キャッシュに適用されます。
ここに示す以外にも、Prepared Statement に関連した問題が存在する可能性があります。Prepared Statement に関連するシステムでエラーが見つかった場合は、Prepared Statement キャッシュのサイズを 0 に設定して Prepared Statement のキャッシングをオフにし、問題が Prepared Statement のキャッシングに起因するものかどうかをテストする必要があります。
データベース変更後の Prepared Statement 呼び出しはエラーの原因となる可能性がある
キャッシュ内に格納された Prepared Statement は、Prepared Statement のキャッシュ時に特定のデータベース オブジェクトを参照します。キャッシュに格納された Prepared Statement で参照されるデータベース オブジェクトに対して、何らかの DLL (データ定義言語) 処理を実行すると、それらの文は次に実行したときに失敗します。たとえば、select * from emp などの文をキャッシュしてから、emp テーブルを削除して再作成した場合、その文が準備されたときに存在した emp テーブルはなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、Prepared Statement は、キャッシュされた時点でデータベース内のテーブルの各カラムのデータ型にバインドされます。テーブルのカラムを追加、削除、または再配列すると、キャッシュに格納されている Prepared Statement は、再び実行されたときに失敗するおそれがあります。
Prepared Statement における setNull の使用
データベースへの接続に WebLogic jDriver for Oracle を使用する場合、setNull バインド変数を使用する Prepared Statement をキャッシュするのであれば、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、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 jDriver for Oracle を使用する場合には常に発生します。他の JDBC ドライバでも生じる可能性があります。
キャッシュ内の Prepared Statement はデータベース カーソルを予約可能
WebLogic Server でキャッシュされた Prepared Statement は、データベースのカーソルをオープンすることができます。キャッシュされた文の数が多すぎると、接続のためのオープン カーソル数の上限を超えてしまうことがあります。接続のためのオープン カーソル数の上限を超えないようにするには、データベース管理システムの上限を変更するか、または接続プールの Prepared Statement キャッシュのサイズを低減します。
Prepared Statement キャッシュの適切なサイズの決定
Prepared Statement キャッシュの適切なサイズ設定を決定するには、開発環境におけるサーバ負荷をエミュレートし、次に Oracle の statspack スクリプトを実行します。スクリプトの出力で、1 秒当たりの解析数を確認します。Prepared Statement キャッシュのサイズを増やすにつれ、1 秒当たりの解析数は少なくなります。1 秒当たりの解析数の減少が止まるまで、Prepared Statement キャッシュのサイズを徐々に増やしていきます。
注意: プロダクション環境で Prepared Statement キャッシュを使用すると決定する前に、その制限について考慮してください。 詳細については、Prepared Statement キャッシュに関する制限を参照してください。
起動クラスを使用した XA 非対応の Prepared Statement キャッシュのロード
XA 非対応の Prepared Statement キャッシュを有効に活用し、最大限のパフォーマンスを得るために、Prepared Statement キャッシュに格納する Prepared Statement のそれぞれを呼び出す起動クラスを作成できます。WebLogic Server では、Prepared Statement を使用順にキャッシュし、Prepared Statement キャッシュ サイズの上限に到達すると、キャッシングを停止します。キャッシュする Prepared Statement を呼び出すための起動クラスを作成すると、数回しか呼び出されない文ではなく、アプリケーションで再利用される文でキャッシュを埋めることができます。したがって、キャッシュする文の数は最小限にとどめながら、パフォーマンスを最大限向上させることができます。 Prepared Statement キャッシュに関する制限で説明したような、問題になる可能性のある Prepared Statement のキャッシングを回避することもできます。
起動クラスが失敗しても、WebLogic Server は後で使用するために、文をロードし、キャッシングします。
各接続には、独自の Prepared Statement キャッシュが割り当てられます。起動クラスを使用して Prepared Statement をキャッシュする場合、接続プールから各接続を取得し、キャッシュする各 Prepared Statement を呼び出すように起動クラスを作成します。
接続要求の増加に応じて接続プールのサイズが拡大するよう設定した場合、新しい接続は使用された Prepared Statement をキャッシュします。起動クラスは、新しい接続用の Prepared Statement をロードできません。接続プールのサイズを縮小できるよう設定した場合、接続プールは縮小間隔の経過後に接続が利用可能であれば接続を閉じます。どの接続を最初に閉じるかを指定する方法はありません。このため、ロードした Prepared Statement キャッシュを持つ接続がそうでない接続の前に閉じる場合があります。
また、サーバ起動時には、起動クラスの実行前に EJB がデプロイされます。CMP エンティティ Bean 内の Prepared Statement およびデプロイ中に EJB が使用する Prepared Statement は、起動クラス内の Prepared Statement よりも前にキャッシュ内に格納されます。この問題を回避するため、すべての EJB およびアプリケーションのデプロイ後に Prepared Statement キャッシュをクリアし、その後キャッシュプライミング コードを実行できます。 weblogic.jdbc.extensions パッケージ内の clearStatementCache メソッドについては、Javadoc を参照してください。
XA 対応 Prepared Statement キャッシュでは、キャッシュ内の文の置換に最長時間未使用アルゴリズムを使用するため、起動クラスでキャッシュをあらかじめロードしても意味がありません。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||