|
|
|
|
|
|
| | | |
JDBC 接続の管理
以下の節では、ローカル トランザクションと分散トランザクションの両方における、JDBC コンポーネント（データ ソース、接続プール、およびマルチプール）を介したデータベース接続のコンフィグレーションと管理のガイドラインを紹介します。
Administration Console には、JDBC（Java Database Connectivity）などの WebLogic Server 機能のコンフィグレーションと管理を可能にするツールへのインタフェースが用意されています。接続の作成、管理、およびモニタを含むほとんどの JDBC 管理機能において、システム管理者は Administrative Console またはコマンドライン インタフェースを使用します。アプリケーション開発者は JDBC API を使用することもできます。
以下に、接続を設定および管理するためによく行われるタスクを示します。
JDBC 接続の設定と管理は、おもに Administration Console で行います。Administration Console を使用して、サーバを起動する前に接続を静的に設定します。詳細については、 Administration Consoleを参照してください。
接続を設定するだけでなく、Administration Console では確立された接続を管理およびモニタすることもできます。
コマンドライン インタフェースについて
コマンドライン インタフェースでは、接続プールを動的に作成および管理できます。コマンドライン インタフェースの使い方については、 WebLogic Server コマンドライン インタフェース リファレンスを参照してください。
JDBC API について
プログラミングによる接続の設定と管理については、『WebLogic JDBC プログラミング ガイド』を参照してください。
関連情報
ローカルおよび分散トランザクションで使用される JDBC ドライバは多くの WebLogic Server コンポーネントと連係して機能し、情報はさまざまなドキュメントに掲載されています。たとえば、JDBC ドライバについての情報は、JDBC、JTA、および WebLogic jDrivers のマニュアルで参照できます。
JDBC、JTA、および管理の追加リソースのリストを以下に示します。
管理
JDBC と WebLogic jDrivers
以下のドキュメントは、おもにアプリケーション開発者向けに書かれています。システム管理者は、このドキュメントの内容を理解するための補助資料として、必要に応じて以下の初歩的な情報を参照してください。
トランザクション（JTA）
以下のドキュメントは、おもにアプリケーション開発者向けに書かれています。システム管理者は、この章の内容を理解するための補助資料として、必要に応じて以下の情報を参照してください。
JDBC コンポーネント（接続プール、データ ソース、およびマルチプール）
以降の節では、JDBC 接続コンポーネント（接続プール、マルチプール、およびデータ ソース）の概要を説明します。
図16-1 WebLogic Server における JDBC コンポーネント
接続プール
接続プールとは、接続プールが登録されるとき（通常は WebLogic Server の起動時）に作成される JDBC 接続のグループに名前を付けたものです。アプリケーションはプールから接続を「借り」、使用後は接続をクローズしてプールに返します。詳細については、『WebLogic JDBC プログラミング ガイド』の「接続プール」を参照してください。
Administration Console で行う設定はすべて静的なものです。つまり、すべての設定は WebLogic Server の起動前に行います。動的な接続プールは、コマンドライン（ WebLogic Server コマンドライン インタフェース リファレンスを参照）または API（『WebLogic JDBC プログラミング ガイド』の「動的接続プールの作成」を参照）を使用することで（サーバの起動後に）作成できます。
マルチプール
マルチプールは、以下の機能で役立ちます。
特定の接続プール内のすべての接続は同じです。つまり、それらは 1 つのデータベースにアタッチされています。ただし、マルチプール内の接続プールにはそれぞれ異なる DBMS を関連付けることができます。詳細については、『WebLogic JDBC プログラミング ガイド』の「マルチプール」を参照してください。
データ ソース
データ ソース オブジェクトを使用することで、JDBC アプリケーションは接続プールから DBMS 接続を取得できるようになります。各データ ソース オブジェクトは、JNDI ツリーにバインドされ、接続プールまたはマルチプールを指します。アプリケーション側では、データ ソースをルックアップして接続を取得します。JTA に対応するデータ ソース オブジェクト (Administration Console における [トランザクション データ ソース]) を定義することも、JTA に対応しないデータ ソース オブジェクト (Administration Console における [データ ソース]) を定義することもできます。分散トランザクションには、トランザクション データ ソースを使用します。データ ソースとトランザクション データ ソースの使用に関する詳細については、 接続プール、マルチプール、およびデータソースの JDBC コンフィグレーション ガイドライン を参照してください。
注意: トランザクション データ ソースで指すことができるのは接続プールだけで、マルチプールを指すことはできません。マルチプールは分散トランザクションではサポートされていないからです。
接続プール、マルチプール、およびデータソースの JDBC コンフィグレーション ガイドライン
この節では、ローカル トランザクションおよび分散トランザクションに対応する JDBC コンフィグレーションのガイドラインについて説明します。
JDBC 接続を設定するには、Administration Console（動的接続プールの場合はコマンドライン）で属性を定義して、接続プール、データ ソース オブジェクト（常に設定することが望ましいが、省略可能な場合もある）、およびマルチプール（省略可能）をコンフィグレーションします。トランザクションのタイプは以下の 3 つです。
次の表にローカルおよび分散トランザクションでのこれらのオブジェクトの使い方を示します。
|
説明/オブジェクト |
ローカル トランザクション |
分散トランザクション XA 対応ドライバ |
分散トランザクション XA 非対応ドライバ |
|---|---|---|---|
|
JDBC ドライバ |
|||
|
データ ソース |
データ ソース オブジェクト推奨（データ ソースがない場合は JDBC API を使用）。 |
トランザクション データ ソースが必須。 |
トランザクション データ ソース必須。 複数のリソースの場合は |
|
接続プール |
Administration Console でコンフィグレーションするときにはデータ ソース オブジェクトが必須。 |
トランザクション データ ソースが必須。 |
トランザクション データ ソースが必須。 |
|
マルチプール |
接続プールとデータ ソースが必須。 |
トランザクション データ ソースが必須。 |
トランザクション データ ソースが必須。 |
注意: 分散トランザクションの場合には、WebLogic jDriver for Oracle/XA (WebLogic jDriver for Oracle の XA 準拠バージョン) などの XA 準拠ドライバを使用します。
アプリケーションや環境が以下の条件のいずれかを満たす場合には、データソースではなくトランザクション データ ソースを使用すべきです。
EJB アーキテクチャでは、 データベース処理を実行する複数の EJB が単一トランザクションの一部として呼び出されることがよくあります。XA を使用しない場合、これがうまく機能するには、トランザクションに参加するすべてのコンポーネントがまったく同じデータベース接続を使用する必要があります。WebLogic Server では、JTS ドライバと TxDataSource ([2 フェーズ コミットを有効化] を選択する場合) を使用してこの処理を裏で実行するので、EJB 間で JDBC 接続を明示的に受け渡す必要はありません。XA (XA ドライバが必要) の場合には、WebLogic Server のトランザクション データ ソースを使用して 2 フェーズ コミットで分散トランザクションを行えるため、複数の EJB がトランザクションの各部分で別個のデータベース接続を使用できるようになります。いずれの場合も (XA を使用する場合も使用しない場合も)、トランザクション データ ソースを使用しなければなりません。
データ ソースの詳細については、『WebLogic JDBC プログラミング ガイド』を参照してください。
注意: 同じ接続プールを指す 2 つのトランザクション データ ソースを作成してはいけません。同じ接続プールを指す 2 つの異なるトランザクション データ ソースを 1 つのトランザクションで使用する場合、2 番目の接続にアクセスしようとすると、XA_PROTO エラーが発生します。
java.sql）をサポートする JDBC 2.0 ドライバ。WebLogic jDrivers for Oracle、WebLogic jDrivers for Microsoft SQL Server、および WebLogic jDrivers for Informix など。この API を使用すると、データ ソースへの接続を確立し、クエリを送信し、その結果を処理するのに必要なクラス オブジェクトを作成できます。
javax.sql.XADataSource、javax.sql.XAConnection、javax.transaction.xa.XAResource）をサポートする JDBC 2.0 ドライバ。WebLogic jDriver for Oracle/XA など。
ローカル トランザクション用の JDBC ドライバのコンフィグレーション
ローカル トランザクションに対応する JDBC ドライバをコンフィグレーションするには、次の手順に従って JDBC 接続プールを設定します。
java.sql.driver インタフェースをサポートしているクラスの名前を指定します。
Administration Console で、接続プロパティの各プロパティについて、それぞれの行で名前=値の組を指定します。 コンフィグレーション ファイル(config.xml) では、接続プロパティがセミコロンで区切られた文字列の形式で一覧されています。 例:
Properties="user=SCOTT;server=DEMO"
WebLogic 2 層 JDBC ドライバの詳細については、使用するドライバについての BEA のマニュアル（『WebLogic jDriver for Oracle のインストールと使い方』、『WebLogic jDriver for Microsoft SQL Server のインストールと使い方』、または『WebLogic jDriver for Informix のインストールと使い方』）を参照してください。サードパーティ ドライバを使用する場合は、『WebLogic JTA プログラマーズ ガイド』の「分散トランザクションでの WebLogic jDriver for Oracle/XA の使い方」およびベンダ提供のマニュアルを参照してください。以下の表では、WebLogic jDrivers を使用した JDBC 接続プールおよびデータ ソースのサンプル コンフィグレーションを示します。
次の表では、WebLogic jDriver for Oracle を使用した接続プールのサンプル コンフィグレーションを示します。
注意: 新しいプロパティ「Password」があります。この値は、名前と値のペアで定義されたプロパティ内のパスワードをオーバーライドします。この属性は、物理データベース接続の作成時に 2 層 JDBC ドライバに渡されます。値は、暗号化されて config.xml に格納され、そのファイルにクリアテキスト パスワードが格納されるのを防止するために使用できます。
次の表では、WebLogic jDriver for Oracle を使用したデータ ソースのサンプル コンフィグレーションを示します。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
次の表では、WebLogic jDriver for Microsoft SQL Server を使用した接続プールのサンプル コンフィグレーションを示します。
次の表では、WebLogic jDriver for Microsoft SQL Server を使用したデータ ソースのサンプル コンフィグレーションを示します。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
次の表では、WebLogic jDriver for Informix を使用した接続プールのサンプル コンフィグレーションを示します。
次の表では、WebLogic jDriver for Informix を使用したデータ ソースのサンプル コンフィグレーションを示します。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
分散トランザクション用の XA 対応 JDBC ドライバのコンフィグレーション
XA 対応 JDBC ドライバを分散トランザクションに参加させるには、以下のように JDBC 接続プールをコンフィグレーションします。
Driver Classname 属性に、javax.sql.XADataSource インタフェースをサポートしているクラスの名前を指定します。
XADataSource にデータ ソース プロパティとして渡されます。WebLogic jDriver for Oracle のデータ ソース プロパティについては、
WebLogic jDriver for Oracle/XA のデータ ソース プロパティを参照してください。サード パーティ製ドライバのデータ ソース プロパティについては、ベンダが提供するマニュアルを参照してください。
以下の属性は、XA モードで WebLogic jDriver for Oracle を使用する場合の JDBC 接続プールのコンフィグレーションの例です。
以下の属性は、XA モードで WebLogic jDriver for Oracle を使用する場合のトランザクション データ ソースのコンフィグレーションの例です。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
また、JDBC 接続プールをコンフィグレーションして、XA モードでサード パーティ ベンダ製ドライバを使用することもできます。この場合、データ ソース プロパティは、JavaBeans 設計パターンを使用し、XADataSource インスタンスに反映して設定します。つまり、abc というプロパティの場合、XADataSource インスタンスは、getAbc という名前の取得メソッドと、setAbc という名前の設定メソッドをサポートする必要があります。
以下の属性は、Oracle Thin Driver を使用する場合の JDBC 接続プールのコンフィグレーションの例です。
以下の属性は、Oracle Thin Driver を使用する場合のトランザクション データ ソースのコンフィグレーションの例です。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
Cloudscape ドライバで使用する JDBC 接続プールは、以下のようにコンフィグレーションします。
Cloudscape ドライバで使用するトランザクション データ ソースは、以下のようにコンフィグレーションします。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
WebLogic jDriver for Oracle/XA のデータ ソース プロパティ
表 16-14 に、WebLogic jDriver for Oracle でサポートされているデータ ソース プロパティを示します。「JDBC 2.0」カラムは、特定のデータ ソース プロパティが JDBC 2.0 の標準データ ソース プロパティ（Y）か、または JDBC に対する WebLogic Server の拡張（N）かを示します。
「省略可能」カラムは、特定のデータ ソース プロパティが省略可能かどうかを示します。「Y*」マークが付いたプロパティは、
表 16-14 に示された、Oracle の xa_open 文字列（openString プロパティの値）の対応するフィールドにマップされます。それらのプロパティが指定されない場合、デフォルト値は openString プロパティから取得されます。それらのプロパティが指定される場合、その値は openString プロパティで指定された値と一致する必要があります。プロパティが一致しない場合、XA 接続を確立しようとすると SQLException が送出されます。
「N*」マークが付いた必須プロパティも、Oracle の xa_open 文字列の対応するフィールドにマップされます。これらのプロパティは、Oracle の xa_open 文字列を指定するときに指定します。プロパティが指定されない場合や、指定されていても一致しない場合は、XA 接続を確立しようとすると SQLException が送出されます。
「**」マークが付いたプロパティ名はサポートされていますが、WebLogic Server では使用されません。
表 16-15 に、Oracle の xa_open 文字列フィールドとデータ ソース プロパティの間のマッピングを示します。
|
Oracle xa_open 文字列フィールド名 |
JDBC 2.0 データ ソース プロパティ |
省略可能 |
|---|---|---|
|
acc |
user、password |
N |
|
sqlnet |
ServerName |
|
また、ユーザは Oracle の xa_open 文字列で「Threads=true」と指定する必要があります。Oracle の xa_open 文字列フィールドの詳細については、Oracle のドキュメントを参照してください。
分散トランザクションにおいて接続プールからの接続を使用している場合は、接続プールに対して追加プロパティを設定し、WebLogic Server 内のトランザクションの状況に合わせて、接続プールが接続を正しく処理できるようにすることが必要になる場合があります。そのようなプロパティは、 JDBCConnectionPool タグで、コンフィグレーション ファイル (config.xml) に指定します。デフォルトでは、追加プロパティはすべて、falseに設定されています。プロパティを true にセットすると、有効になります。
普通は、WebLogic Server が内部的にこれらのプロパティを適切な値に自動的に設定するので、ユーザが手動で設定する必要はありません。
KeepXAConnTillTxComplete
DBMS によっては、トランザクションの開始と終了を同じ物理データベース接続で行う必要があります。また場合によっては、WebLogic Server 内のトランザクションの開始と終了を、異なる物理データベース接続で行うこともできます。トランザクションが完了するまでのトランザクションの全期間を通して、接続プールが 1 つの物理接続を確保し、アプリケーションに対して「同じ」接続を割り当てるようにするには、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 ドライバのコンフィグレーション
JDBC 接続プールをコンフィグレーションして、XA 非対応の JDBC ドライバを別のリソースと共に分散トランザクションに参加させる場合は、JDBC Tx Data Source に [2 フェーズ コミットを有効化] 属性を指定します（このパラメータは、XAResource インタフェースををサポートしているリソースには無視されます）。非 XA 接続プールは、一度に 1 つしか分散トランザクションに参加できません。
XA 非対応ドライバ/単一リソース
XA 非対応ドライバを 1 つだけ使用し、それがトランザクションで唯一のリソースである場合は、Administration Console において [2 フェーズ コミットを有効化] オプションを選択されていないままにします（デフォルトの enableTwoPhaseCommit = false を受け入れる）。この場合、Weblogic Server ではその設定が無視され、トランザクション マネージャが 1 フェーズの最適化を実行します。
XA 非対応ドライバ/複数リソース
他の XA リソースとともに XA 非対応 JDBC ドライバを 1 つ使用する場合は、Console で [2 フェーズ コミットを有効化] を選択します（enableTwoPhaseCommit = true）。
enableTwoPhaseCommit が true に設定されている場合、XA 非対応の JDBC リソースは常に XAResource.prepare() メソッド呼び出し中に XA_OK を返します。リソースは、以降の XAResource.commit() 呼び出しまたは XAResource.rollback() 呼び出しに応答して、そのローカル トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗すると、ヒューリスティック エラーが発生します。ヒューリスティック エラーの結果、アプリケーション データは矛盾した状態のまま残される場合があります。
[2 フェーズ コミットを有効化] が選択されていない（enableTwoPhaseCommit が false に設定されている）場合、XA 非対応の JDBC リソースによって XAResource.prepare() が失敗します。この場合、commit() が SystemException を送出するので、トランザクションには参加コンポーネントが 1 つしか存在しないことになります。トランザクションの参加コンポーネントが 1 つしか存在しない場合、1 つのフェーズ最適化は XAResource.prepare() を無視し、トランザクションはほとんどのインスタンスで正常にコミットします。
こうした XA 非対応 JDBC ドライバのサポートは、しばしば「JTS ドライバ」と呼ばれることがあります。WebLogic Server では、WebLogic JTS ドライバを内部的に使用して、この機能をサポートしているからです。 WebLogic JTS ドライバの詳細については、『WebLogic JDBC プログラミング ガイド』の「WebLogic JTS ドライバの使い方」を参照してください。
XA 非対応ドライバをグローバル トランザクションで使用する際の制限事項と危険性
WebLogic Server では、グローバル トランザクションに XA 非対応 JDBC リソースを参加させることもできますが、そうしたリソースを使用するアプリケーションを設計する際には、いくつかの制限事項を考慮する必要があります。XA 非対応ドライバは XA/2PC 規約に従っておらず、1 フェーズ コミットとロールバックの操作しかサポートしていないため、WebLogic Server (内部的には JTS ドライバ) では、トランザクション マネージャで管理されるトランザクションにこうしたリソースが参加できるようにするために妥協が必要になります。
ヒューリスティックな終了とデータの不整合
XA 非対応リソースに対して [2 フェーズ コミットを有効化] が選択されると (enableTwoPhaseCommit = true)、XA 非対応リソースのトランザクションの準備フェーズは常に成功します。そのため、XA 非対応リソースは、2 フェーズ コミット (2PC) プロトコルに本当に参加するわけではなく、障害が発生しやくなります。準備フェーズのあとで XA 非対応リソースに障害が発生した場合、XA 非対応リソースはトランザクションをロールバックする可能性が高いのに対して、トランザクションに参加する XA 対応のコンポーネントはトランザクションをコミットするので、結果的に、ヒューリスティックな終了とデータの不整合が発生します。
データ整合性を損なう危険性があるので、[2 フェーズ コミットを有効化] のオプションを使用するのは、ヒューリスティックな状況に耐え得るアプリケーションの場合に限るべきです。
保留中のトランザクションを回復できない
XA非対応のドライバではローカル データベース トランザクションだけを操作するため、外部トランザクション マネージャに関しては、データベースにおけるトランザクションの保留状態という概念がありません。XA 非対応のリソースに対して XAResource.recover() が呼び出されると、コミットやロールバックの必要があるトランザクションが存在していても、常に Xid (トランザクション ID) の空集合が返されます。そのため、グローバル トランザクションで XA 非対応のリソースを使用するアプリケーションでは、システム障害から回復してデータの整合性を維持することはできません。
マルチサーバ コンフィグレーションでの XA 非対応リソースによるパフォーマンス低下のおそれ
WebLogic Server では、特定の JDBC 接続に関連付けられたデータベース ローカル トランザクションに基づいて、グローバル トランザクションに対する XA 非対応リソースの参加をサポートしているので、複数の WebLogic Server インスタンス上でグローバル トランザクション コンテキストのアプリケーションから同じ JDBC データ ソースがアクセスされると、JTS ドライバは常に、JDBC 操作を、そのトランザクション内のアプリケーションで最初に確立された接続にリダイレクトします。たとえば、一方のサーバ上でアプリケーションがトランザクションを開始し、XA 非対応の JDBC リソースにアクセスしたあと 、もう一方のサーバに対するリモート メソッド呼び出し (RMI) を行い、同じ基礎 JDBC ドライバを使用するデータ ソースにアクセスした場合、 JTS ドライバは、別のサーバ上のトランザクションに関連付けられている接続がそのリソースに対して確立されていることを認識し、最初のサーバ上にある実際の接続への RMI リダイレクトをセットアップします。接続に関するすべての操作は、最初のサーバ上で確立された 1 つの接続に対して行われます。こうした動作の結果、これらのリモート接続のセットアップと 1 つの物理接続に対する RMI 呼び出しによるオーバーヘッドのために、パフォーマンスが低下するおそれがあります。
XA 非対応の参加コンポーネントは 1 つのみ
XA 非対応のリソース (enableTwoPhaseCommit = true に設定) は、WebLogic Server のトランザクション マネージャに登録される際には、XAResource インタフェースを実装するクラスの名前で登録されます。enableTwoPhaseCommit = true に設定されたすべての XA 非対応リソースでは、XAResource インタフェースを実装する JTS ドライバを使用するので、グローバル トランザクションに参加する XA 非対応リソース (enableTwoPhaseCommit = true に設定) はすべて、同じ名前で登録されます。グローバル トランザクションで複数の XA 非対応リソースを使用した場合、名前の衝突や、場合によってはヒューリスティック障害が発生します。
XA 非対応の接続プールとトランザクション データ ソースのコンフィグレーション例
次の表では、XA 非対応 JDBC ドライバを使用するサンプル JDBC 接続プールのコンフィグレーション属性を示します。
次の表では、XA 非対応 JDBC ドライバを使用するサンプル トランザクション データ ソースのコンフィグレーション属性を示します。
|
属性値 |
|
|---|---|
|
Name |
|
|
Targets |
|
|
JNDIName |
|
|
PoolName |
|
|
EnableTwoPhaseCommit |
|
Administration Console による JDBC 接続プール、マルチプール、およびデータソースのコンフィグレーションと管理
以降の節では、JDBC コンポーネント（接続プール、データ ソース、およびマルチプール）をコンフィグレーションしてデータベース接続を設定する方法について説明します。接続がいったん確立されたら、Administration Console またはコマンドライン インタフェースを使用して接続を管理およびモニタできます。コンフィグレーション タスクの説明および Administration Console オンライン ヘルプのリンクについては、 表 16-19を参照してください。
ここでは、コンフィグレーションとは以下のプロセスのことです。
JDBC オブジェクトの作成
Administration Console を使用し、属性とデータベース プロパティを指定して JDBC コンポーネント（接続プール、データ ソース、およびマルチプール）を作成します。 Administration Console を使用した JDBC 接続のコンフィグレーションを参照してください。
まず接続プールまたはマルチプールを作成してから、データ ソースを作成します。データ ソース オブジェクトを作成する場合、データ ソースの属性の 1 つとして接続プールまたはマルチプールを作成します。これにより、データ ソースが特定の接続プールまたはマルチプール（「プール」）と永続的に関連付けられます。
JDBC オブジェクトの割り当て
データ ソースと接続プール（またはマルチプール）のコンフィグレーションと関連付けを行ったら、各オブジェクトを同じサーバまたはサーバまたはクラスタに割り当てます。一般的なシナリオをいくつか以下に示します。
実行するタスクの説明については、 Administration Console を使用した JDBC 接続のコンフィグレーションを参照してください。
コンフィグレーション プロセスの関連付けと割り当ての詳細については、次の表を参照してください。
（プールには複数のデータ ソースを割り当てることができますが、実際の効果はありません。）これらのデータ ソースとプールの組み合わせを複数のサーバまたはクラスタに割り当てることができますが、それらは組み合わせとして割り当てなければなりません。たとえば、関連付けられている接続プールがサーバ B にのみ割り当てられている場合は、データ ソースを管理対象サーバ A に割り当てることはできません。
コマンドライン インタフェースを使用すると、動的な接続プールを（サーバの起動後に）コンフィグレーションできます。 コマンドライン インタフェースを使用した JDBC コンフィグレーション タスクを参照してください。動的な接続プールは、API を使用してプログラミングによってコンフィグレーションすることもできます（『WebLogic JDBC プログラミング ガイド』の「動的接続プールの作成」を参照）。
Administration Console を使用した JDBC 接続のコンフィグレーション
Administration Console では、JDBC 接続をコンフィグレーション、管理、およびモニタできます。タスクに使用するタブを表示するには、次の操作を行います。
次の表では、接続タスクを一般的な実行順序で示します。この順序は変更してもかまいません。ただし、オブジェクトは関連付けおよび割り当ての前にコンフィグレーションする必要があります。
|
タスク番号 |
JDBC コンポーネント/タスク |
説明 |
|---|---|---|
|
1 |
[コンフィグレーション] タブで、名前、URL、データベース プロパティなどの接続プールの属性を設定する。 |
|
|
2 |
接続プールのクローンの作成（省略可能） |
このタスクでは接続プールをコピーする。[コンフィグレーション] タブで、プールの名前をユニークな名前に変更し、それ以外の属性をそのまま使用するか変更する。この機能は、別々の名前で複数の同じプール コンフィグレーションが必要な場合に便利。たとえば、各データベース管理者に、特定のプールを使用してデータベースへの個々の変更をトラッキングさせることができる。 |
|
3 |
[コンフィグレーション] タブで、名前およびアルゴリズム（高可用性またはロードバランシング）の属性を設定する。[プール] タブで、接続プールをこのマルチプールに割り当てる。 |
|
|
4 |
[コンフィグレーション] タブを使用して、名前、JNDI 名、およびプール名（これでデータ ソースが特定の接続プールまたはマルチプールと関連付けられる）といったデータ ソースの属性を設定する。 |
|
|
5 |
トランザクション データ ソースのコンフィグレーション（および接続プールとの関連付け） |
[コンフィグレーション] タブを使用して、名前、JNDI 名、および接続プール名（これでデータ ソースが特定のプールと関連付けられる）といったトランザクション データ ソースの属性を設定する。 |
|
6 |
[対象] タブを使用して、接続プールを 1 つまたは複数のサーバまたはクラスタに割り当てる。 表 16-18「関連付けと割り当てのシナリオ」を参照。 |
|
|
7 |
[対象] タブを使用して、コンフィグレーションされたマルチプールをサーバまたはクラスタに割り当てる。 |
接続プールのコンフィグレーションにおけるデータベース パスワード
接続プールを作成する際には、そのデータベースに接続するためのパスワードを少なくとも 1 つ作成するのが普通です。オープン文字列を使用して XA を有効にする場合、2 種類のパスワードを使用するとよいでしょう。WebLogic Server の [JDBC接続プール｜コンフィグレーション｜一般] タブには、以下のフィールドがあります。
− このフィールドは、データベース パスワードを設定するのに使用します。物理データベース接続を作成する際に 2 層 JDBC ドライバに渡される Properties の中で定義されている password があっても、ここで設定した値がそれを上書きします。この値は、config.xml ファイルの中では暗号化され（JDBCConnectionPool タグの中のPassword 属性として保管されます）、Administration Console 上では表示されません。
− このフィールドは、WebLogic Server のトランザクション マネージャがデータベース接続を開くのに使用するオープン文字列に、パスワードを設定するのに使用します。[プロパティ] フィールドに定義されているパスワードがあっても、オープン文字列の一部としてここで設定した値がそれを上書きします。この値は、config.xml ファイルの中では暗号化され（JDBCConnectionPool タグの中の XAPassword 属性として保管されます )、 Administration Console 上では表示されません。実行時には、WebLogic Server はこのフィールドに指定されたパスワードを使ってオープン文字列を再構築します。[プロパティ]フィールドにあるオープン文字列のフォーマットは次のとおりです。
openString=Oracle_XA+Acc=P/userName/+SesTm=177+DB=demoPool+Threads=true=Sqlnet=dvi0+logDir=.
userName の後ろにはパスワードがないことに注意してください。
[JDBC接続プール｜コンフィグレーション｜一般] タブの [プロパティ] フィールドに上記のパスワードを指定してもかまいません。しかし、WebLogic Server は、 Administration Console およびコンフィグレーション ファイル（通常は config.xml）でこれらのパスワードをクリア テキストで表示します。これらのパスワードをクリア テキストで表示したり保管するのを回避するには、パスワードはそれぞれのフィールドで指定します。
[パスワード] および [文字列のオープン パスワード]の値は、 同一である必要はありません。また、これらのフィールドを使用する場合、[プロパティ] フィールドでそれらに相当する値は省略しなければなりません。たとえば、[パスワード] フィールドに値を指定する場合には、[プロパティ] フィールドにはpassword=password 指定しないでください。
注意: [パスワード] および [文字列のオープン パスワード] フィールドに入力した値は、[プロパティ] フィールドのそれに相当する値を上書きします。たとえば、[パスワード] フィールドに tiger と入力し、[プロパティ] フィールドに password=smith と入力すると、WebLogic Server ではこのデータベースへの接続を作成するためのパスワードとして tiger を使用します。
コマンドライン インタフェースを使用した JDBC コンフィグレーション タスク
次の表では、動的な接続プールを作成する方法を示します。
|
目的とする作業 |
使用するツール |
|---|---|
|
動的接続プールの作成 |
|
詳細については、 WebLogic Server コマンドライン インタフェース リファレンス、および『WebLogic JDBC プログラミング ガイド』の「動的接続プールの作成」を参照してください。
接続の管理では、確立された JDBC コンポーネントを有効化、無効化、および削除します。
Administration Console を使用した JDBC の管理
JDBC 接続を管理およびモニタするには、次の表を参照してください。
|
目的とする作業 |
Administration Console での操作 |
|---|---|
|
接続プールの割り当て先サーバまたはクラスタの変更 |
「接続プールのサーバ/クラスタへの割り当て」の手順に従って、[対象] タブで対象を選択解除（[選択済み] から [使用可能] に移動）し、新しい対象に割り当てる。 |
|
マルチプールの割り当て先クラスタの変更 |
「マルチプールのサーバまたはクラスタへの割り当て」の手順に従って、[対象] タブで対象を選択解除（[選択済み] から [使用可能] に移動）し、新しい対象に割り当てる。 |
|
JDBC 接続プールの削除 |
オンライン ヘルプの「JDBC 接続プールの削除」を参照。 |
|
マルチプールの削除 |
|
|
データ ソースの削除 |
|
|
接続プールのモニタ |
|
|
接続プール、マルチプール、またはデータ ソースの属性の修正 |
|
コマンドライン インタフェースを使用した JDBC の管理
次の表では、コマンドライン インタフェースを使用した接続プールの管理について説明します。詳細情報が必要な場合は、目的のコマンドを選択してください。
接続プールのコマンドの使い方については、 WebLogic Server コマンドライン インタフェース リファレンスを参照してください。
|
目的とする作業 |
使用するコマンド |
|---|---|
|
接続プールの無効化 |
|
|
無効な接続プールの有効化 |
|
|
JDBC 接続プールの削除 |
|
|
接続プールが作成されたかどうかの確認 |
|
|
接続プールのリセット |
|
prepared statement キャッシュによるパフォーマンスの向上
WebLogic Server で作成する各接続プールに対し、prepared statement キャッシュのサイズを指定できます。prepared statement キャッシュ サイズを設定すると、WebLogic Server は、prepared statement が指定された数に達するまで、アプリケーションと EJB で使用される各 prepared statement を保管します。statement は、接続プール単位ではなく、「接続ごとに」キャッシュされます。たとえば、prepared statement キャッシュ サイズを 10 に設定すると、WebLogic Server は、その特定の接続を使ってアプリケーションまたは EJB によって呼び出された最初の 10 個の prepared statement を保存します。
アプリケーションまたは EJB がキャッシュに保管されている prepared statement のいずれかを呼び出すと、WebLogic Server はキャッシュに保存されている statement を再使用します。prepared statement を再使用することで、データベース中の statement を解析する必要がなくなり、データベース マシンの CPU 使用量が減るので、現在の statement に対するパフォーマンスが向上し、他のタスクが利用できる CPU サイクルが増えます。
prepared statement キャッシュ サイズのデフォルト値は 0 です。接続プールに対して prepared statement キャッシュ サイズを設定するには、以下の方法を使用できます。
config.xml）で直接指定する。
コンフィグレーション ファイルを使って接続プールの prepared statement キャッシュ サイズを設定するには、サーバを起動する前に、エディタで config.xml を開き、PreparedStatementCacheSize 属性に対するエントリを JDBCConnectionPool タグに追加します。次に例を示します。
<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"/>
prepared statement キャッシュの使用に関する制限
prepared statement キャッシュを使用するとパフォーマンスが劇的に向上しますが、使用するかどうかを決定する前に、制限事項について検討する必要があります。prepared statement キャッシュを使用するときは、以下の制限事項に注意してください。
prepared statement のキャッシングに関しては、ここで示されていない問題がほかにも存在する可能性があります。prepared statement に関係してシステムでエラーが発生する場合は、prepared statement のキャッシュ サイズを 0 に設定してみてください。このように設定すると、prepared statement のキャッシングはオフになり、問題の原因が prepared statement のキャッシングかどうかを確認できます。
データベースを変更してから保存されている prepared statement を呼び出すと発生する可能性のあるエラー
キャッシュに保存されている prepared statement は、キャッシュされる時点で特定のデータベース オブジェクトを参照しています。キャッシュに格納されている prepared statement で参照されているデータベース オブジェクトに対して DDL（データ定義言語）操作を実行した場合、次に prepared statement を実行したときに障害が発生します。たとえば、select * from emp のような statement をキャッシュした後、emp テーブルを削除して作成し直した場合、キャッシュされている statement を次に実行したときには、statement を準備したときに存在していたものとまったく同じ emp テーブルがもはや存在しないため、statement は失敗します。
同様に、prepared statement がキャッシュされる時点で、prepared statement はデータベースのテーブルの各カラムに対するデータ型にバインドされています。テーブル内のカラムを追加、削除、または再配置した場合、キャッシュに格納されている prepared statement を再び実行すると障害が発生します。
prepared statement での setNull の使用
WebLogic jDriver for Oracle を使用してデータベースに接続している場合、setNull バインド変数を使用する prepared statement をキャッシュするときには、変数に適切なデータ型を設定する必要があります。汎用データ型を使用する場合は、次の例で示すように、null 以外の値で実行すると statement は失敗します。
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 がデータベースのカーソルを開いている場合があります。あまり多くの statement をキャッシュした場合、接続に対するオープン カーソルの制限を越える可能性があります。接続に対するオープン カーソルの制限を超えないようにするには、データベース管理システムで限度を変更するか、または接続プールに対する prepared statement のキャッシュ サイズを小さくします。
適切な prepared statement キャッシュ サイズの決定
prepared statement キャッシュ サイズの最適な設定を決定するには、開発環境でサーバの負荷をエミュレートしてから、Oracle statspack スクリプトを実行します。スクリプトからの出力で、1 秒あたりの解析数を確認します。prepared statement のキャッシュ サイズを増やすと、1 秒あたりの解析数は減ります。1 秒あたりの解析数がそれ以上減少しなくなるまで、prepared statement キャッシュ サイズを段階的に増やします。
注意: プロダクション環境で prepared statement キャッシュの使用を決定する前に、使用上の制限について検討してください。詳細については、 prepared statement キャッシュの使用に関する制限を参照してください。
スタートアップ クラスを使用した prepared statement キャッシュのロード
prepared statement キャッシュを最大限に活用し、最善のパフォーマンスを実現するには、prepared statement キャッシュに格納しようとする各 prepared statement を呼び出すスタートアップ クラスを作成します。WebLogic Server は、使用されている順序で prepared statement をキャッシュし、prepared statement キャッシュ サイズ制限に達した時点で statement のキャッシュを停止します。キャッシュする prepared statement を呼び出すスタートアップ クラスを作成することで、わずかな回数しか呼び出されない statement ではなく、アプリケーションで再利用される statement をキャッシュに格納でき、最低限の数の statement をキャッシュに収めることで最善のパフォーマンスが向上します。また、 prepared statement キャッシュの使用に関する制限で説明されているような問題のある prepared statement がキャッシュされるのを防ぐことができます。
スタートアップ クラスで問題が発生した場合でも、WebLogic Server は後で使用できるように statement をロードしてキャッシュします。
確立されている接続ごとに、statement のキャッシュが個別にあることに注意してください。スタートアップ クラスを使用して statement をキャッシュする場合は、プールから各接続を取得し、その接続でキャッシュする prepared statement を呼び出すという方法で、クラスを作成する必要があります。
接続の需要が増加するのに合わせて接続プールが拡大するようになっている場合は、statement が使用されると新しい接続が statement をキャッシュします。スタートアップ クラスは、新しい接続に対する prepared statement キャッシュをロードすることはできません。接続プールが縮小できるようにしてある場合は、縮小期間が経過して接続が利用できる状態になっていると、接続プールは接続を閉じます。その際、最初に閉じられる接続を指定する手段はありません。したがって、prepared statement キャッシュをロードした接続が、ロードしていない接続より前に閉じられる場合があります。
|
|
|