|
|
|
|
|
|
| | | |
WebLogic JDBC 機能のコンフィグレーション
以下の節では、JDBC 接続コンポーネントのプログラミング方法について説明します。
接続プールとは、接続プールが登録されるとき（通常は WebLogic Server の起動時）に作成される、データベースへの同一 JDBC 接続のグループに名前を付けたものです。アプリケーションはプールから接続を「借り」、使用後に接続を閉じることでプールに接続を返します。 接続プールの概要も参照してください。
接続プールには、数多くの性能上およびアプリケーション設計上の利点があります。
接続プールのコンフィグレーションの属性は Administration Console オンライン ヘルプで定義されています。WebLogic Server の実行中に接続プールをプログラムで作成する場合に使用できる API もあります。 接続プールの動的作成を参照してください。コマンド ラインを使用することもできます。『管理者ガイド』の「WebLogic Server コマンドライン インタフェース リファレンス」を参照してください。
WebLogic Server は、アプリケーションによる使用中に障害が発生した接続をフェイルオーバすることはできません。接続を使用している間の障害に対しては、トランザクションを実行し直し、このような障害を処理するためのコードを用意する必要があります。
起動（静的）接続プールを作成するには、Administration Console で属性を設定します。WebLogic Server は、起動処理中にデータベースに対する JDBC 接続を開き、接続をプールに追加します。
次に、接続プールの属性および説明のリストを示します。詳細については、『管理者ガイド』の「JDBC 接続の管理」と『Administration Console オンライン ヘルプ』を参照してください。
接続プールの属性
このプロパティは、使用する 2 層 JDBC ドライバによって定義および処理されます。DBMS への接続に必要なプロパティについては、使用する JDBC ドライバのマニュアルを参照してください。
（省略可能） 物理的なデータベース接続作成時に、2 層 JDBC ドライバに渡されるデータベース パスワード。この値は、[プロパティ] 属性で（名前/値のペアとして）定義されているデータベース パスワードがあっても、それを上書きします。この値は、config.xml ファイルに暗号化された形で格納されます。
（省略可能） XA 物理データベース接続の作成のためのオープン文字列内で使われるパスワード。この値は、 [プロパティ] 属性で定義されているオープン文字列内のパスワードを上書きします。この値は、config.xml ファイルに暗号化された形で格納されます。
true の場合、[縮小間隔] を設定します。設定しない場合は、デフォルトで 15 分になります。[縮小可] は下位互換のため、デフォルトで false に設定されます。
注意: [縮小可] が false に設定されているときにこの属性の値を設定すると、WebLogic Server は false 設定を無視し、[縮小間隔] の値に従って縮小を許可します。
select count(*) from テスト テーブル名」がテストに使用されます。テスト テーブル名は、必ず実在し、その接続のデータベース ユーザがアクセスできるものでなければなりません。ほとんどのデータベース サーバはこの SQL を最適化して、テーブル スキャンを回避します。それでも、[テスト テーブル名] を、行が少ない（またはまったくない）テーブルの名前に設定することは有益です。
true に設定すると、WebLogic Server は、プールから削除した後に接続のテストを実行してから、クライアントに渡します。テストを実行すると、クライアントのリクエストに応じてプールから接続を提供するまでに若干時間が余分にかかりますが、クライアントは必ず有効な接続を受け取ることができます（DBMS が使用可能またはアクセス可能であることが前提）。この機能を使用するには、[テスト テーブル名] パラメータを設定する必要があります。
高可用性アルゴリズムと共にマルチプールで接続プールを使用するときは、この属性を true に設定し、リスト中の次の接続プールにいつフェイルオーバするかをマルチプールが決定できるようにする必要があります。
マルチプールのフェイルオーバに関する制限と要件を参照してください。
true に設定すると、WebLogic Server は、接続プールに戻す前に接続をテストします。プール内のすべての接続がすでに使用されており、クライアントが接続を待機している場合、クライアントの待機時間は接続がテストされている間だけ若干長くなります。この機能を使用するには、[テスト テーブル名] パラメータを設定する必要があります。
Administration Console で、動的接続プールの作成に対するパーミッションを設定します。動的接続プールを作成するときに、ACL がその接続プールに関連付けられます。ACL と接続プールは同じ名前である必要はなく、複数の接続プールが 1 つの ACL を使用することができます。ACL を指定しない場合は「system」ユーザがプールのデフォルトの管理ユーザとなり、またどのユーザもプールから提供される接続を使用できます。
接続プールに対して ACL を定義する場合、アクセスは ACL の定義内容に厳密に制限されます。たとえば、fileRealm.properties ファイルで接続プールの ACL を定義するまでは、ドメイン内のすべての接続プールに誰もが無制限にアクセスできます。一方、ファイルに次の行を追加すると、アクセスは非常に厳しく制限されます。
acl.reset.weblogic.jdbc.connectionPool=Administrators
この行では、すべての接続プールを対象として 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
表 4-1 は、接続プールのセキュリティを保護するために fileRealm.properties で使用できる ACL の一覧です。
ACL の変更方法については、『管理者ガイド』の「セキュリティの管理」にある「ACL の定義」を参照してください。
接続プールを使うとき、DBMS 固有の SQL コードを実行して、データベース接続のプロパティを、WebLogic Server や JDBC ドライバが認識できない値に変更することができます。このような接続を接続プールに返しても、接続の特性が有効な状態に戻らないことがあります。たとえば、Sybase DBMS では、set rowcount 3 select * from y のような文を実行すると、その接続は最大 3 行しか返さなくなります。接続プールに返された接続をクライアントが再使用すると、選択したテーブルが 500 行であっても、クライアントは依然として 3 行しか取得できません。ほとんどの場合、同じ結果を得ることができて、WebLogic Server または JDBC ドライバが接続をリセットするような、標準の (DBMS 固有ではない) SQL コードが存在します。先の例では、set rowcount の代わりに setMaxRows() を使用できます。
DBMS 固有の SQL コードを使って接続を変更する場合は、接続プールに返す前に、接続を許容できる状態に戻す必要があります。
JNDI ベースの API を使用すると、Java アプリケーションの内部から接続プールを作成できます。この API を使用すると、すでに実行されている WebLogic Server に接続プールを作成できます。接続プールへ動的にアクセスするには、JTS または Pool ドライバが必要です。
動的プールは一時的に無効にできます。無効にすると、プール内のどの接続でもデータベース サーバとの通信がサスペンドされます。無効にしたプールを有効にした場合、各接続の状態はプールを無効にしたときと同じなので、クライアントは中断されたところからデータベース操作を継続できます。
接続プールの特定のプロパティを定義するには、キーの綴りと大文字/小文字を正確に指定していることを確認してください。プールを作成するときに使用する java.utils.Properties オブジェクトで、以下の表のように、これらのタイプ（キー）とその値をペアにします。
次のサンプル コードでは、プログラムで接続プールを割り当てる方法を示します。
注意: 以下のサンプル コードはクラスタ環境では使用できません。そこで、『Administration Console オンライン ヘルプ』で説明しているとおりに Administration Console で接続プールとデータ ソースを作成し、それらの接続プールとデータ ソースのターゲットをクラスタにすれば、 その問題を回避することができます。
パッケージをインポートする
以下のパッケージをインポートします。
import java.util.Properties
import weblogic.common.*;
import weblogic.jdbc.common.JdbcServices;
import weblogic.jdbc.common.Pool;
JNDI を使用して JdbcServices オブジェクトを取得する
オブジェクト参照を使用すると、動的プールの作成に必要なすべてのメソッドにアクセスできます。最初に、初期 JNDI コンテキストを WebLogic JNDI プロバイダへ取得します。次に、「weblogic.jdbc.common.JdbcServices」をルックアップします。
Hashtable env = new Hashtable();env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
// WebLogic Server の URL
env.put(Context.SECURITY_PRINCIPAL, "Fred");
env.put(Context.SECURITY_CREDENTIALS, "secret");
Context ctx = new InitialContext(env);
// weblogic.jdbc.JdbcServices をルックアップ
weblogic.jdbc.common.JdbcServices jdbc =
(weblogic.jdbc.common.JdbcServices)
ctx.lookup("weblogic.jdbc.JdbcServices");
プールの属性を定義する java.utils.properties オブジェクトを設定します。 プロパティの 表 4-2「接続プールのプロパティ」を参照してください。
weblogic.jdbc.JdbcServices をロードしたら、weblogic.jdbc.common.JdbcServices.createPool() メソッドに、プールを記述する Properties オブジェクトを渡します。Properties オブジェクトには、Administration Console で接続プールを作成するために使うのと同じプロパティが含まれています。ただし、「aclName」プロパティは、動的接続プールに固有のものです。
以下の例では、Oracle データベース DEMO 用に「eng2」という接続プールを作成しています。これらの接続は、「tiger」というパスワードを持つユーザ「SCOTT」としてデータベースにログインします。プールが作成されると、データベース接続が 1 つ開きます。このプールには、接続を最大 10 個作成することができます。「aclName」プロパティには、この接続プールでは「dynapool」が使用されることが指定されています。
String thePoolName = "eng2";
Properties poolProps = null;
Pool myPool = null;
weblogic.jdbc.common.Pool pool = null
poolProps = new Properties();
// 接続プールのプロパティを設定する
poolProps.put("poolName", thePoolName);
poolProps.put("url", "jdbc:weblogic:oracle");
poolProps.put("driver", "weblogic.jdbc.oci.Driver");
poolProps.put("props", "user=scott;password=tiger;server=demo");
poolProps.put("password", "tiger");
poolProps.put("initialCapacity", "1");
poolProps.put("maxCapacity", "10");
poolProps.put("capacityIncrement", "1");
poolProps.put("aclName", "weblogic.jdbc.connectionPool.dynapool");
poolProps.put("allowShrinking", "true");
poolProps.put("shrinkPeriodMins", "5");
poolProps.put("refreshPeriod", "10");
poolProps.put("testConnectionsOnReserve", "true");
poolProps.put("testConnectionsOnRelease", "false");
poolProps.put("testTableName", "dual");
poolProps.put("loginDelaySecs", "1");
新しく定義された Properties オブジェクトを、JNDI から事前に取得した JdbcServices オブジェクトに渡すことにより、プールを作成します。新しいプールの名前が既存のプールと同じ場合など、プールの作成に問題がある場合は、例外が送出されます。
// プールを作成する
try {
myJdbc.createPool(poolProps);
} catch (Exception e) {
System.out.println(thePoolName
+ " can't be created ..");
System.exit(666);
}
新しく作成したプールからプール ハンドルを取得します。プール ハンドルを使用して、アプリケーションの処理中にプールを操作します。
weblogic.jdbc.common.Pool myPool = null;
// プールを取得。プールで何らかの処理を行う ...
try {
theNewPool = myJdbc.getPool(thePoolName);
} catch (Exception e) {
System.out.println("Cannot retrieve pool: "
+ thePoolName);
System.exit(666);
}
weblogic.jdbc.common.Pool インタフェースと weblogic.jdbc.common.JdbcServices インタフェースは、接続プールを管理し、それらに関する情報を取得するためのメソッドを提供します。メソッドの目的は以下のとおりです。
weblogic.jdbc.common.JdbcServices.poolExists()
weblogic.jdbc.common.Pool.getProperties()
poolExists() メソッドは、指定された名前の接続プールが WebLogic Server に存在するかどうかを調べます。このメソッドを使用すると、動的接続プールがすでに作成されているかどうかを調べ、作成する動的接続プールに固有の名前を付けることができます。
getProperties() メソッドは、接続プールのプロパティを取得します。
weblogic.jdbc.common.Pool.disableDroppingUsers()
weblogic.jdbc.common.Pool.disableFreezingUsers()
weblogic.jdbc.common.pool.enable()
接続プールを一時的に無効にして、クライアントがそのプールから接続を取得するのを防ぐことができます。接続プールを有効または無効にできるのは、「system」ユーザか、またはそのプールに関連付けられている ACL によって「admin」パーミッションが与えられたユーザだけです。
disableFreezingUsers() を呼び出すと、プールの接続を現在使っているクライアントは中断状態に置かれます。データベース サーバと通信しようとすると、例外が送出されます。ただし、クライアントは接続プールが無効になっている間に自分の接続をクローズできます。その場合、接続はプールに返され、プールが有効になるまでは別のクライアントから予約することはできません。
disableDroppingUsers() を使用すると、接続プールが無効になるだけでなく、そのプールに対するクライアントの JDBC 接続が破棄されます。その接続で行われるトランザクションはすべてロールバックされ、その接続が接続プールに返されます。クライアントの JDBC 接続コンテキストは無効になります。
disableFreezingUsers() で無効にしたプールを再び有効にした場合、使用中だった各接続の JDBC 接続状態はその接続プールが無効にされたときと同じなので、クライアントはちょうど中断したところから JDBC 操作を続行できます。
さらに、weblogic.Admin クラスの disable_pool コマンドと enable_pool コマンドを使用して、プールを無効にしたり有効にしたりできます。
weblogic.jdbc.common.Pool.shrink()
接続プールは、プール内の接続の初期数と最大数を定義する一連のプロパティ（initialCapacity と maxCapacity）と、接続がすべて使用中のときにプールに追加される接続の数を定義するプロパティ（capacityIncrement）を備えています。プールがその最大容量に達すると、最大数の接続が開くことになり、プールを縮小しない限りそれらの接続は開いたままになります。
接続の使用がピークを過ぎれば、接続プールから接続をいくつか削除して、WebLogic Server と DBMS 上のリソースを解放してもかまいません。
weblogic.jdbc.common.Pool.shutdownSoft()
weblogic.jdbc.common.Pool.shutdownHard()
これらのメソッドは、接続プールを破棄します。接続はクローズされてプールから削除され、プールに残っている接続がなくなればプールは消滅します。接続プールを破棄できるのは、「system」ユーザか、またはそのプールに関連付けられている ACL によって「admin」パーミッションが与えられたユーザだけです。
shutdownSoft() は、接続がプールに返されるのを待って、それらの接続をクローズします。
shutdownHard() メソッドは、すべての接続を即座に破棄します。プールから取得した接続を使っているクライアントは、shutdownHard() が呼び出された後で接続を使おうとすると、例外を受け取ることになります。
さらに、weblogic.Admin クラスの destroy_pool コマンドを使って、プールを破棄することもできます。
weblogic.jdbc.common.Pool.reset()
接続プールは、定期的に、あるいは接続が予約または解放されるたびに接続をテストするようにコンフィグレーションすることができます。WebLogic Server がプール接続の一貫性を自動的に保てるようにすることで、DBMS 接続に関する問題の大半は防げるはずです。さらに、WebLogic には、アプリケーションから呼び出してプール内のすべての接続、またはプールから予約した単一の接続をリフレッシュできるメソッドが用意されています。
weblogic.jdbc.common.Pool.reset() メソッドは、接続プール内に割り当てられている接続をすべてクローズしてから開き直します。これは、たとえば、DBMS が再起動されたあとに必要になることがあります。接続プール内の 1 つの接続が失敗した場合は、プール内のすべての接続が不良であることが往々にしてあります。
接続プールをリセットするには、以下のいずれかの方法を使用します。
weblogic.Admin コマンドを（管理特権を持ったユーザとして）使用して、管理者として接続プールをリセットします。次にそのパターンを示します。
$java weblogic.Admin WebLogicURL RESET_POOL poolName system passwd
コマンドラインからこの方法を使うことはめったにないかもしれません。ほかにも、次に説明するようにプログラムを使用したより効率的な方法があります。
JdbcServicesDef インターフェイスに属する reset() メソッドを使用します。
最後のケースは、行うべき作業が最も多くなりますが、その反面、最初の 2 つの方法よりも柔軟性があります。次に、reset() メソッドを使用してプールをリセットする方法を示します。
マルチプールは「プールのプール」です。マルチプールには、アプリケーションに接続を返す接続プールを決定するためのコンフィグレーション可能なアルゴリズムとして、高可用性と接続プール ロードバランシングが含まれています。
マルチプールと接続プールは、次のような点が異なります。つまり、特定の「接続プール」に含まれる接続はすべて、同じデータベース、同じユーザ、同じ接続属性を使って、まったく等しく作成されます。一方、「マルチプール」内の接続プールは、異なるユーザまたは DBMS と関連付けることができます。
図4-1 マルチプールのアーキテクチャ
マルチプールは、複数のデータベースからの接続、またはユーザが異なる複数の接続を返すことができますが、WebLogic Server には異なるデータベースの内容を統合または処理するための手段が用意されていないことに注意してください。アプリケーションまたは DBMS 環境で同期またはデータ統合の処理を行って、基になっているどの接続プールから接続を受け取ったときでも、アプリケーションが透過的に正しく動作するようにしなければなりません。
マルチプールを設定する前に、その主要な目的、つまり高可用性またはロード バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズに合わせて選択できます。
高可用性アルゴリズムでは、接続プールの順序付けされたリストを提供します。通常、このタイプのマルチプールへのすべての接続リクエストは、リストの最初のプールによって処理されます。最初のプールがデータベースへの接続を失うと、そのリストの次のプールから順番に接続が選択されます。
注意: マルチプール内の接続プールに対しては TestConnsOnReserve=true を設定し、いつリスト内の次の接続プールにフェイルオーバするかをマルチプールが決定できるようにする必要があります。
ある接続プール内のすべての接続が使用されている場合、高可用性アルゴリズムを使用するマルチプールは、リストの次のプールから接続を提供しません。これは、接続プールの容量を設定できるようにするためのもので、マルチプール本来の動作です。マルチプールのフェイルオーバは、データベース接続が失われた場合にだけ行われます。このような状況を防ぐには、接続プールの接続の最大数を増やす必要があります。
ロード バランシング
ロード バランシング マルチプールへの接続リクエストは、リスト内の任意の接続プールから処理されます。プールは順序付けされずに追加され、ラウンドロビン方式でアクセスされます。接続を切り替えると、最後にアクセスされたプールの直後の接続プールが選択されます。
WebLogic Server ではマルチプール用に高可用性アルゴリズムが提供されており、接続プールで障害が発生した場合（データベース管理システムがクラッシュした場合など）でも、システムは動作を続けることができます。
接続プールは、TestConnsOnReserve の機能を利用して、データベース接続が失われたことを認識します。接続のテストが自動的に行われるのは、アプリケーションが接続を予約してからです。接続プールに対する TestConnsOnReserve=true の設定は、マルチプール内で行う必要があります。この機能を有効にすると、WebLogic Server はアプリケーションに返す前に接続を個別にテストします。これは、高可用性アルゴリズムにおいて必要不可欠の動作です。高可用性アルゴリズムでは、マルチプールは、予約時に行う接続テストの結果を使って、マルチプール内の次の接続プールにフェイルオーバするタイミングを決定します。テストが不合格になると、接続プールは接続の再作成を試みます。この試みが失敗した場合、マルチプールは次の接続プールにフェイルオーバします。
予約された後の接続で障害が発生する可能性があります。このような場合は、アプリケーションで障害に対処する必要があります。WebLogic Server は、アプリケーションの使用中に障害が発生した接続をフェイルオーバすることはできません。使用中の接続の障害に対しては、トランザクションを再度実行すると共に、障害を処理するためのコードを用意する必要があります。
接続待ち時間の設定は、接続試行のプロパティです。プール接続の待ち時間の設定に慣れている場合、接続待ち時間のプロパティを特定の接続試行で行われるすべての接続に適用します。
マルチプールには任意の接続プールを追加できます。しかし、リソースの最適化は、接続プールをコンフィグレーションするときに接続待ち時間をどのように設定したかに応じて行います。
ユーザは、接続を提供する接続プールに関する情報を要求する場合があります。
例外は、以下の状態のときに JDBC ログに記録されます。
高可用性のシナリオでは、リスト内の最初のプールが使用中であっても、リスト内の次のプールから接続が取得されるわけではありません。
接続プールやマルチプールの場合と同様に、DataSource オブジェクトは、Administration Console で、あるいは WebLogic 管理 API を使って作成することができます。トランザクション サービスに対応する DataSource オブジェクトを定義することも、対応しない DataSource オブジェクトを定義することもできます。DataSource のプール名属性を定義する前に、接続プールとマルチプールをコンフィグレーションします。
DataSource オブジェクトを JNDI と組み合わせると、データベースへの接続を提供する接続プールにアクセスすることができます。各 DataSource では、1 つの接続プールまたはマルチプールを参照できます。ただし、単一の接続プールを使用する複数の DataSource を定義することができます。これによって、同じデータベースを共有するトランザクション対応 DataSource オブジェクトとトランザクション非対応 DataSource オブジェクトの両方を定義できるようになります。
WebLogic Server では、以下の 2 種類の DataSource オブジェクトをサポートしています。
アプリケーションが以下の条件のいずれかを満たす場合には、TxDataSource を WebLogic Server で使用すべきです。
TxDataSource を使用すべき場合とそのコンフィグレーション方法の詳細については、「接続プール、マルチプール、およびデータソースの JDBC コンフィグレーションガイドライン」を参照してください。
アプリケーションで DataSource を使用して接続プールからデータベース接続を取得するようにしたい場合には (この方法を推奨)、アプリケーションを実行する前に、Administration Console で DataSource を定義しておかなければなりません。DataSource の作成方法については、『Administration Console オンライン ヘルプ』を参照してください。また、TxDataSource の作成方法については、『Administration Console オンライン ヘルプ』を参照してください。
DataSource オブジェクトにアクセスするためのパッケージのインポート
DataSource オブジェクトを使用するには、以下のクラスをクライアント コードにインポートします。
import java.sql.*;
import java.util.*;
import javax.naming.*;
JDBC クライアントから接続を取得するには、以下のコードに示すように、Java Naming and Directory Interface （JDNI）ルックアップを使用して DataSource オブジェクトを見つけます。
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL,
"t3://hostname:port");
try {
ctx = new InitialContext(ht);
javax.sql.DataSource ds
= (javax.sql.DataSource) ctx.lookup ("myJtsDataSource");
java.sql.Connection conn = ds.getConnection();
// これで conn オブジェクトを使用して
// 文を作成し、結果セットを検索できる
Statement stmt = conn.createStatement();
stmt.execute("select * from someTable");
ResultSet rs = stmt.getResultSet();
// 終了したら文と接続オブジェクトをクローズする
stmt.close();
conn.close();
}
catch (NamingException e) {
// エラー発生
}
finally {
try {ctx.close();}
catch (Exception e) {
// エラー発生
}
}
（WebLogic Server は適切な hostname と port 番号に置き換えられます。）
注意: 上のコードでは、JNDI コンテキストを取得するためにいくつかの使用可能なプロシージャが使用されています。JNDI の詳細については、『WebLogic JNDI プログラマーズ ガイド』を参照してください。
WebLogic Server の samples\examples\jdbc\datasource ディレクトリに収められている DataSource コード例を参照してください。
|
|
|
