ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 8.1 ドキュメント > WebLogic JDBC プログラマーズ ガイド > WebLogic JDBC のコンフィグレーションと使い方

WebLogic JDBC プログラマーズ ガイド

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

WebLogic JDBC のコンフィグレーションと使い方

WebLogic Server Administration Console を使用して、JDBC 接続プール、データ ソース、マルチプールなどの WebLogic Server の機能を有効化したり、コンフィグレーションやモニタを行ったりできます。また、JMX API と weblogic.Admin コマンドライン ユーティリティを使用して、同じタスクをプログラム的に行うこともできます。コンフィグレーション後の JDBC 接続コンポーネントは、アプリケーション内で使用できます。

以下の節では、JDBC 接続コンポーネントのプログラミング方法について説明します。

詳細については、以下を参照してください。

 

接続プールのコンフィグレーションと使い方

接続プールとは、データベースへの同一の JDBC 接続の集まりです。データベースへの接続は、接続プールをデプロイすると実行されます。この実行は、WebLogic Server の起動時または実行時に動的に行われます。アプリケーションはプールから接続を「借り」、使用後に接続を閉じることでプールに接続を返します。「接続プールの概要」も参照してください。

接続プールを使用するメリット

接続プールには、数多くの性能およびアプリケーション設計上の利点があります。

接続プールのコンフィグレーションの属性は Administration Console オンライン ヘルプで定義されています。WebLogic Server の実行中に接続プールをプログラムで作成する場合に使用できる API もあります。「接続プールの動的作成」を参照してください。コマンドラインを使用することもできます。『WebLogic Server コマンドライン リファレンス』を参照してください。

起動時の接続プールの作成

起動 (静的) 接続プールを作成するには、Administration Console で属性とパーミッションを定義します。WebLogic Server は、起動処理中にデータベースに対する JDBC 接続を開き、接続をプールに追加します。

Administration Console で接続プールを設定するには、左ペインに表示されるナビゲーション ツリーでサービスと JDBC ノードを展開し、接続プールを選択します。右ペインには、既存の接続プールのリストが表示されます。[新しい JDBC Connection Pool のコンフィグレーション] テキスト リンクをクリックして、接続プールを作成します。

手順説明、および接続プール属性の説明については、Administration Console オンライン ヘルプ (Administration Console の右上の疑問符をクリックしたときに表示される) を参照してください。

正しい接続数でサーバ ロックを回避する

アプリケーションで、接続プールから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外が送出されます。このエラーを避けるには、接続プールのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。

Administration Console で接続プールの最大接続数を設定するには、左ペインのナビゲーション ツリーを展開し、[サービス｜JDBC｜接続プール] ノードを表示して、接続プールを選択します。次に右ペインで、[コンフィグレーション｜接続] タブを選択して、[最大容量] の値を指定します。

接続プール コンフィグレーションのデータベース パスワード

接続プールを作成する場合、一般にはデータベースへの接続用として、1 つ以上のパスワードを組み込みます。オープン文字列を使用して、XA を有効にする場合は、パスワードを 2 つ使用できます。これらのパスワードは [プロパティ] フィールドに名前と値の組み合わせとして入力することも、それぞれのフィールドに入力することも可能です。

接続プールを初めてコンフィグレーションするときに [プロパティ] フィールドにパスワードを指定した場合、次の起動時に WebLogic Server は、パスワードを Properties 文字列から取り除き、その値を暗号化して Password の値として設定します。接続プールの Password 属性に値が指定されている場合、WebLogic Server は値を変更しません。ただし、Password 属性の値は Properties 文字列内のパスワード値をオーバーライドします。この動作は、オープン文字列の一部として定義するすべてのパスワードに対して同じように適用されます。たとえば、接続プールを初めてコンフィグレーションするときに次のプロパティを指定したとします。

user=scott;
password=tiger;
openString=Oracle_XA+Acc=p/scott/tiger+SesTm=177+db=jtaXaPool+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=lcs817

次に起動したときには、WebLogic Server はデータベース パスワードおよびオープン文字列に含まれるパスワードをそれぞれ [パスワード] 属性および [オープン文字列のパスワード] 属性に移動します。[プロパティ] フィールドには、次の値が残されます。

user=scott;
openString=Oracle_XA+Acc=p/scott/+SesTm=177+db=jtaXaPool+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=lcs817

[パスワード] または [オープン文字列のパスワード] 属性の値が確定したら、これらの属性の値は [プロパティ] フィールドのそれぞれの値をオーバーライドします。前述の例で説明すると、tiger2 をデータベース パスワードとして [プロパティ] 属性に指定した場合、WebLogic Server はこの値を無視し、暗号化された [パスワード] 属性の現在の値である tiger をデータベース パスワードとして使い続けます。データベース パスワードを変更するには、[パスワード] 属性を変更しなければなりません。

注意 : [パスワード] と [オープン文字列のパスワード] の値は、同じでなくてもかまいません。

プールされた JDBC 接続に対する SQL 文のタイムアウト機能の拡張

WebLogic Server 8.1 SP3 では、JDBC 接続プールに対して次のような属性が追加され、JDBC 接続プールからのデータベース接続において 1 つの文を実行できる時間を制限できるようになりました。

これらの属性は、基底の JDBC ドライバ サポートに依存します。WebLogic Server は、java.sql.Statement.setQueryTimeout() メソッドを使用して JDBC ドライバに指定された時間を渡します。使用している JDBC ドライバでこのメソッドがサポートされていないと、例外が送出される場合があり、タイムアウト値が無視されます。

注意 : これらの機能を使用すると、パフォーマンスが低下する場合があります。これらの機能は、プロダクション環境で使用する前に、ステージング環境またはテスト環境でテストしてください。

また、これらの属性は Administration Console では設定できません。これらの機能を有効化するには、手動で config.xml を編集する必要があります。

JDBC 接続プールのテスト機能の拡張

WebLogic Server 8.1 SP3 では、JDBC 接続プールに次に示す属性が追加されました。これにより、プールされた接続に対するデータベース接続テストの機能が向上しました。

データベース接続が失われた後の接続テストによる遅延を最小化する

DBMS への接続がたとえ一瞬でも失われると、通常、接続プールにおける JDBC 接続の一部またはすべてが切断されます。接続プールが予約時の接続テストを行うようにコンフィグレーションされている場合 (推奨)、あるアプリケーションによってデータベース接続がリクエストされると、WebLogic Server はその接続をテストし、その接続が切断されていることが分かると、リクエストに応えるため、新しい接続と置き換えようとします。通常、DBMS がオンラインに復帰すると更新プロセスは成功しますが、場合によって (障害の一部のモードにおいては)、切断された接続のテストによって、長時間の遅延を強いられるおそれがあります。この遅延は、接続プールの切断された各接続について発生し、すべての接続が置き換えられるまで続きます。

切断されたデータベース接続のテスト中に発生する遅延を最小限にするには、接続プールの CountOfTestFailuresTillFlush 属性を設定します。この属性を設定すると、指定したテストの失敗回数を超えたときに、接続プール内のすべての接続が切断されていると見なされ、接続プール内のすべての接続が閉じられます。

アプリケーションが接続をリクエストすると、切断された接続が最初にテストされずに、接続プールによって接続が作成されます。この動作によって、接続プールのフラッシュに続く接続リクエストの遅延が最小化されます。

CountOfTestFailuresTillFlush 属性は、config.xml の JDBCConnectionPool エントリで指定します。TestConnectionsOnReserve も true に設定する必要があります。例 :

<JDBCConnectionPool 
  CapacityIncrement="1" 
  DriverName="com.pointbase.xa.xaDataSource" 
  InitialCapacity="2" MaxCapacity="10" 
  Name="demoXAPool" Password="password"
  Properties="user=examples;
    DatabaseName=jdbc:pointbase:server://localhost/demo" 
  Targets="examplesServer" 
  TestConnectionsOnReserve="true"
  CountOfTestFailuresTillFlush="1"
  TestTableName="SYSTABLES"
  URL="jdbc:pointbase:server://localhost/demo" 
/>

注意 : CountOfTestFailuresTillFlush 属性は、Administration Console では設定できません。

傾向として、ネットワークの小さな不具合が見られたり、ファイアウォールで 1 つのソケットまたは接続のみが時々切断される場合は、テストの失敗回数を 2 か 3 に設定したほうがよい場合があります。ただし、データベースの可用性の問題が解消された後、1 に設定した場合は、最高のパフォーマンスが提供されます。

接続テスト失敗後の接続リクエストによる遅延を最小化する

DBMS が使用できなくなると、接続プールは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、接続プールが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。

データベースが使用できない間、クライアント アプリケーションに発生する遅延を最小限にするには、接続プールの CountOfRefreshFailuresTillDisable 属性を設定します。この属性を設定すると、失敗回数を超えたときに、接続プールは、切断された接続を置き換えることができなくなります。アプリケーションが、無効化された接続プールから接続をリクエストすると、即座に ConnectDisabledException が送出され、接続が使用できないことがクライアントに知らされます。

この方法で無効化された接続プールについては、定期的に更新プロセスが実行されます。更新プロセスにおいて、新しいデータベース接続の作成が成功すると、その接続プールが再有効化されます。Administration Console または weblogic.Admin ENABLE_POOL コマンドを使用して、接続プールを手動で再有効化することもできます。

CountOfRefreshFailuresTillDisable 属性は、config.xml の JDBCConnectionPool エントリで指定します。TestConnectionsOnReserve も true に設定する必要があります。例 :

<JDBCConnectionPool 
  CapacityIncrement="1" 
  DriverName="com.pointbase.xa.xaDataSource" 
  InitialCapacity="2" MaxCapacity="10" 
  Name="demoXAPool" Password="password"
  Properties="user=examples;
    DatabaseName=jdbc:pointbase:server://localhost/demo" 
  Targets="examplesServer" 
  TestConnectionsOnReserve="true"
  CountOfRefreshFailuresTillDisable="1"
  TestTableName="SYSTABLES"
  URL="jdbc:pointbase:server://localhost/demo" 
/>

注意 : CountOfRefreshFailuresTillDisable 属性は、Administration Console では設定できません。

傾向として、ネットワークの小さな不具合が見られたり、ファイアウォールで 1 つのソケットまたは接続のみが時々切断される場合は、更新の失敗回数を 2 か 3 に設定したほうがよい場合があります。ただし、1 に設定すると、通常最高のパフォーマンスが提供されます。

アイドル プール接続を信頼する秒数の設定により接続リクエスト遅延を最小化する

大量のトラフィックが発生しているなかでデータベース接続テストを行うと、アプリケーションのパフォーマンスが悪化します。接続テストの影響を最小化するには、JDBC 接続プール コンフィグレーションの [アイドル プール接続を信頼する秒数] 属性を設定して、最近使用またはテストしたデータベース接続が有効であると信頼して接続テストをスキップします。

接続プールが予約時の接続テストを行うようにコンフィグレーションされている場合 (推奨)、アプリケーションがデータベース接続をリクエストすると、WebLogic Server はアプリケーションに渡す前にその接続をテストします。接続が正常に使用またはテストされて接続プールに戻された後、[アイドル プール接続を信頼する秒数] に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。

接続プールがプール内の使用可能な接続を定期的にテストするようにコンフィグレーションされている ([テスト頻度] が指定されている) 場合にも、[アイドル プール接続を信頼する秒数] に指定した時間内に接続が正常に使用されて接続プールに戻されていれば、接続テストはスキップされます。

[アイドル プール接続を信頼する秒数] を設定するには、Administration Console の [JDBC 接続プール｜コンフィグレーション｜接続] タブで値を指定します。Administration Console オンライン ヘルプの「[JDBC 接続プール] --> [コンフィグレーション] --> [接続]」を参照してください。また、config.xml ファイルで設定することもできます。次に例を示します。

<JDBCConnectionPool 
  CapacityIncrement="1" 
  DriverName="com.pointbase.xa.xaDataSource" 
  InitialCapacity="2" MaxCapacity="10" 
  Name="demoXAPool" Password="password"
  Properties="user=examples;
    DatabaseName=jdbc:pointbase:server://localhost/demo" 
  Targets="examplesServer" 
  SecondsToTrustAnIdlePoolConnection="15"
  TestConnectionsOnreserve="true"
  TestTableName="SYSTABLES"
  URL="jdbc:pointbase:server://localhost/demo" 
/>

[アイドル プール接続を信頼する秒数] は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などは、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。

接続プールの動的作成

JDBCConnectionPool 管理 MBean は WebLogic Server 管理アーキテクチャ (JMX) の一部として提供されます。JMX API を使用して、Java アプリケーションの内部から、接続プールを動的に作成、およびコンフィグレーションできます。すなわち、クライアント、またはサーバ アプリケーション コードを使用して、すでに実行中の WebLogic Server インスタンスで接続プールを作成できます。

WebLogic Server コマンドライン インタフェースで CREATE_POOL コマンドを使用しても、接続プールを動的に作成できます。「CREATE_POOL」を参照してください。

JMX API を使用して接続プールを動的に作成するには、次の手順に従います。

  1. 必要なパッケージをインポートします。
  2. JNDI ツリーで、管理 MBeanHome をルックアップします。
  3. サーバ MBean を取得します。
  4. 接続プール MBean を作成します。
  5. 接続プールのプロパティを設定します。
  6. 対象を追加します。
  7. DataSource オブジェクトを作成します。

注意 : 動的に作成した接続プールでは必ず、動的に作成した DataSource オブジェクトを使用します。DataSource を終了するには、これが特定の接続プールに関連付けられている必要があります。また、WebLogic Server 中の DataSource オブジェクトと接続プールの間は、1 対 1 の関係になっています。したがって、接続プールに対応して使用する DataSource の作成が必要です。

JMX API を使用して接続プールを作成すると、サーバ コンフィグレーションに接続プールが追加され、サーバを起動/停止した後も、引き続き有効になります。接続プールを持続させる必要がない場合は、プログラムで削除します。

MBean を使用して WebLogic Server を管理する方法については、『WebLogic JMX Service プログラマーズ ガイド』を参照してください。JDBCConnectionPool MBean の詳細については、「Javadoc」を参照してください。

動的接続プールのサンプル コード

接続プールを動的に作成するときの各手順を実行するコード サンプルを以下の節で示します。

パッケージをインポートする

import java.sql.*;
import java.util.*;
import javax.naming.Context;
import javax.sql.DataSource;
import weblogic.jndi.Environment;
import weblogic.management.configuration.JDBCConnectionPoolMBean;
import weblogic.management.runtime.JDBCConnectionPoolRuntimeMBean;
import weblogic.management.configuration.JDBCTxDataSourceMBean;
import weblogic.management.configuration.ServerMBean;
import weblogic.management.MBeanHome;
import weblogic.management.WebLogicObjectName;
String cpName = null;
String cpJNDIName = null;

管理 MBeanHome をルックアップする

mbeanHome = (MBeanHome)ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);

サーバ MBean を取得する

svrAdminMBean = (ServerMBean)mbeanHome.getAdminMBean("myserver",
 "Server");

接続プール MBean を作成する

  // Create ConnectionPool MBean
  cpMBean = (JDBCConnectionPoolMBean)mbeanHome.createAdminMBean(
    cpName, "JDBCConnectionPool", 
    mbeanHome.getDomainName());

接続プール プロパティを設定する

  Properties pros = new Properties();
  pros.put("user", "scott");
    pros.put("server", "dbserver1t1");
  // DataSource 属性の設定
  cpMBean.setURL("jdbc:weblogic:oracle");
  cpMBean.setDriverName("weblogic.jdbc.oci.xa.XADataSource");
  cpMBean.setProperties(pros);
  cpMBean.setPassword("tiger");

注意 : この例では、[プロパティ] にユーザ名とサーバ名で指定する代わりに、setPassword(String) メソッドを使ってデータベース パスワードを設定します。setPassword(String) メソッドを使用すると、WebLogic Server は config.xml ファイル中のパスワード、および管理コンソールに表示されるパスワードを暗号化します。このメソッドを使用して、config.xml ファイル中でデータベース パスワードをクリア テキストで格納するのを避けるようにお勧めします。

対象を追加する

デプロイメント対象を追加すると、接続プールがデプロイされ、接続プールのデータベース接続が作成されます。

  cpMBean.addTarget(serverMBean);

DataSource を作成する

public void createDataSource() throws SQLException {
  try {
    // コンテキストの取得
    Environment env = new Environment();
    env.setProviderUrl(url);
    env.setSecurityPrincipal(userName);
    env.setSecurityCredentials(password);
    ctx = env.getInitialContext();
      // TxDataSource  MBean の作成
      dsMBean = (JDBCTxDataSourceMBean)mbeanHome.createAdminMBean(
        cpName, "JDBCTxDataSource",
        mbeanHome.getDomainName());
      // TxDataSource 属性の設定
      dsMBean.setJNDIName(cpJNDIName);
      dsMBean.setPoolName(cpName);
      // DataSource の起動
      dsMBean.addTarget(serverMBean);
    } catch (Exception ex) {
      ex.printStackTrace();
      throw new SQLException(ex.toString());
    }
  }

注意 : JDBCDataSourceMBean は WebLogic Server 8.1 で非推奨になりました。代わりに JDBCTxDataSourceMBean を使用してください。JDBCTxDataSourceMBean で使用できない属性 (WaitForConnectionEnabled および ConnectionWaitPeriod) は非推奨になり、JDBCConnectionPoolMBean の ConnectionReserveTimeoutSeconds 属性で置き換えられました。「接続を待機する接続リクエストの有効化」を参照してください。

動的接続プールと DataSource を削除する

動的に作成した接続プールを削除する方法を以下のコード サンプルで示します。動的に作成した接続プールは削除しない限り、サーバを停止/再起動した後も、有効です。

public void deleteConnectionPool() throws SQLException {
  try {
    // 動的に作成した接続プールをサーバから削除
    cpMBean.removeTarget(serverMBean);
    // 動的に作成した接続プールをコンフィグレーションから削除
    mbeanHome.deleteMBean(cpMBean);
  } catch (Exception ex) {
    throw new SQLException(ex.toString());
  }
}
public void deleteDataSource() throws SQLException {
    try {
      // 動的に作成した TxDataSource をサーバから削除
      dsMBean.removeTarget(serverMBean);
      // 動的に作成した TxDataSource をコンフィグレーションから削除
      mbeanHome.deleteMBean(dsMBean);
    } catch (Exception ex) {
      throw new SQLException(ex.toString());
    }
  }

 

DataSource のコンフィグレーションと使い方

接続プールやマルチプールと同様に、DataSource オブジェクトは Administration Console または WebLogic 管理 API を使用して作成できます。DataSource オブジェクトを定義して、トランザクション サービスを有効または無効にできます。DataSource のプール名属性を定義する前に、接続プールとマルチプールをコンフィグレーションします。

DataSource オブジェクトを JNDI と組み合わせると、データベースへの接続を提供する接続プールにアクセスできます。個々の DataSource は、1 つの接続プール、またはマルチプールを参照できます。ただし、単一の接続プールを使用する複数の DataSource を定義できます。これにより、同じデータベースを共有するトランザクション対応 DataSource オブジェクトとトランザクション非対応 DataSource オブジェクトの両方を定義できます。

WebLogic Server では、2 種類の DataSource オブジェクトがサポートされます。

注意 : Administration Console では、データ ソースとトランザクション データ ソースはデータソース作成時に選択する [グローバル トランザクションを受け付ける] の設定によって区別されます。

true - トランザクション データ ソース

false - データ ソース (トランザクション以外)

トランザクション データ ソースは、Administration Console でデータ ソースを作成するときにデフォルトで作成されます。

アプリケーションで次のいずれかの基準が該当する場合は、WebLogic Server で TxDataSource を使用してください。

非トランザクション データ ソースを使用するのは、現在のトランザクションに含めたくないデータベースで作業を行う場合のみです。

アプリケーションで DataSource (Tx または非 Tx) を使用して、接続プールからデータベース接続を取得する (推奨) 場合は、アプリケーションを実行する前に、Administration Console で DataSource を定義します。DataSource のコンフィグレーション方法と、TxDataSource を使用する場合については、「JDBC データソース」を参照してください。

注意 : JDBCDataSourceMBean は WebLogic Server 8.1 で非推奨になりました。代わりに JDBCTxDataSourceMBean を使用してください。JDBCTxDataSourceMBean で使用できない属性 (WaitForConnectionEnabled および ConnectionWaitPeriod) は非推奨になり、JDBCConnectionPoolMBean の ConnectionReserveTimeoutSeconds 属性で置き換えられました。「接続を待機する接続リクエストの有効化」を参照してください。

DataSource オブジェクトにアクセスするパッケージのインポート

アプリケーションで DataSource オブジェクトを使用するには、以下のクラスをクライアント コードにインポートします。

import java.sql.*;
import java.util.*;
import javax.naming.*;

DataSource を使用したクライアント接続の取得

JDBC クライアントに対する接続を取得するには、以下のコードに示すように、Java Naming and Directory Interface (JDNI) ルックアップを使用して DataSource オブジェクトを見つけます。

注意 : クライアントサイド アプリケーションで JDBC 接続を使用する際、サーバとクライアントの両方の CLASSPATH に、同一の JDBC ドライバ クラスを指定する必要があります。ドライバ クラスが一致していないと、java.rmi.UnmarshalException 例外が送出される場合があります。

Context ctx = null;
  Hashtable ht = new Hashtable();
  ht.put(Context.INITIAL_CONTEXT_FACTORY,
         "weblogic.jndi.WLInitialContextFactory");
  ht.put(Context.PROVIDER_URL,
         "t3://hostname:port");
  Connection conn = null;
  Statement stmt = null;
  ResultSet rs = null;
  try {
    ctx = new InitialContext(ht);
    javax.sql.DataSource ds 
      = (javax.sql.DataSource) ctx.lookup ("myDataSource");
    conn = ds.getConnection();
   // これで conn オブジェクトを使用して
   //  文を作成し、結果セットを検索できる
    stmt = conn.createStatement();
    stmt.execute("select * from someTable");
    rs = stmt.getResultSet(); 
...
//できる限り速やかに JDBC オブジェクトを閉じる
    stmt.close();
    stmt=null;
    conn.close();
    conn=null;
 }
  catch (Exception e) {
    // エラー発生
    log message;
  }
finally {    
  try { 
    ctx.close(); 
  } catch (Exception e) {
     log message; }
  try { 
    if (rs != null) rs.close(); 
  } catch (Exception e) {  
     log message; }
  try { 
    if (stmt != null) stmt.close(); 
  } catch (Exception e) {  
     log message; }
  try { 
    if (conn != null) conn.close(); 
  } catch (Exception e) {  
     log message; }
}
(使用する WebLogic Server に合わせて適切な hostname と port 番号に置き換えます。)

注意 : 上のコードでは、JNDI コンテキストを取得するためにいくつかの使用可能なプロシージャが使用されています。JNDI の詳細については、『WebLogic JNDI プログラマーズ ガイド』参照してください。

接続リクエスト失敗時に生じる可能性のある例外

weblogic.jdbc.extensions パッケージには、アプリケーション リクエストの失敗時に送出され得る以下の例外が含まれています。各例外は、java.sql.SQLException の拡張です。

接続プールの制約

接続プールを使用中に、DBMS 固有の SQL コードが実行されることがあります。これはデータベース接続プロパティを変更するものであり、WebLogic Server および JDBC ドライバからは認識されません。接続が接続プールに返されたときに、その接続の特性の設定が有効な状態に戻らない可能性があります。たとえば Sybase DBMS で、set rowcount 3 select * from y などの文を使用すると、接続は続くクエリで最大で 3 行までしか返しません。接続が接続プールに返されてから再利用される場合、たとえ選択対象のテーブルに 500 の行があっても、クライアントにはやはり 3 行だけが返されます。

ほとんどの場合、同じ結果をもたらすことができる標準の JDBC コードが存在します。この例では、set rowcount の代わりに setMaxRows() を使用できます。DBMS 固有の SQL コードの代わりに標準の JDBC コードを使用することをお勧めします。標準の JDBC 呼び出しを使用して接続を変更すると、Weblogic Server は接続が接続プールに返された時点で接続を標準の状態に戻します。

接続を変更する DBMS 固有の SQL コードを使用する場合は、接続を接続プールに返す前に、その設定を受け入れ可能な状態に戻す必要があります。

 

接続プールの管理

JDBCConnectionPool と JDBCConnectionPoolRuntime の MBean には、接続プールを管理し、これに関する情報を収集するためのメソッドがあります。これらの管理オプションはすべて、Administration Console で利用できます。しかし、JMX API を使って接続プールを管理するために提供されているメソッドを使用することもできます。メソッドは、これらの処理およびその他の処理のために提供されています。

利用できるすべてのメソッドと、この節で説明しているメソッドに関する詳細情報については、以下の MBean の Javadoc を参照してください。

接続プールのステータスと統計の取得

JDBCConnectionPoolRuntimeMBean.getState()
JDBCConnectionPoolRuntimeMBean.getActiveConnectionsAverageCount() 
JDBCConnectionPoolRuntimeMBean.getActiveConnectionsCurrentCount() 
JDBCConnectionPoolRuntimeMBean.getActiveConnectionsHighCount() 
JDBCConnectionPoolRuntimeMBean.getConnectionLeakProfileCount() 
JDBCConnectionPoolRuntimeMBean.getConnectionsTotalCount() 
JDBCConnectionPoolRuntimeMBean.getCurrCapacity() 
JDBCConnectionPoolRuntimeMBean.getFailuresToReconnectCount() 
JDBCConnectionPoolRuntimeMBean.getHighestNumAvailable() 
JDBCConnectionPoolRuntimeMBean.getHighestNumUnavailable() 
JDBCConnectionPoolRuntimeMBean.getLeakedConnectionCount() 
JDBCConnectionPoolRuntimeMBean.getMaxCapacity() 
JDBCConnectionPoolRuntimeMBean.getNumAvailable() 
JDBCConnectionPoolRuntimeMBean.getNumUnavailable() 
JDBCConnectionPoolRuntimeMBean.getStatementProfileCount() 
JDBCConnectionPoolRuntimeMBean.getVersionJDBCDriver() 
JDBCConnectionPoolRuntimeMBean.getWaitingForConnectionCurrentCount() 
JDBCConnectionPoolRuntimeMBean.getWaitingForConnectionHighCount() 
JDBCConnectionPoolRuntimeMBean.getWaitSecondsHighCount()

JDBCConnectionPoolRuntimeMBean は、接続プールの現在の状態を取得したり、アクティブな接続の平均数、現在のアクティブな接続数、アクティブな接続の最大数など接続プールに関する統計を取得したりするためのメソッドを提供します。

getState() メソッドは、接続プールの現在の状態を返します。現在の状態には以下のものがあります。

接続プールの統計を取得する方法の詳細については、JDBCConnectionPoolRuntimeMBean の Javadoc を参照してください。「接続プールおよびデータベース接続のテスト」も参照してください。

接続作成の再試行の有効化

JDBCConnectionPoolMBean.setConnectionCreationRetryFrequencySeconds(int seconds)

setConnectionCreationRetryFrequencySeconds() メソッドは、接続プール作成時に、データベース接続の作成を試行する間隔を秒単位で設定します。この値を設定しないと、データベースが利用できなかった場合に接続プールの作成は失敗します。接続プールの作成時に設定されており、かつデータベースが利用不可の場合、WebLogic Server は指定した秒数の経過後にプール内に再度接続を作成しようとし、さらに成功するまでその試行を繰り返します。

デフォルトでは、この属性は 0 に設定されており、接続作成の再試行は無効です。

注意 : 接続作成の再試行は、高可用性マルチプール内の接続プールでは使用しないでください。リスト内の接続プールからの応答がなく、接続リクエストの数が 1 番目の接続プール内の接続数と同じ場合、マルチプール内の以降の接続プールで接続が使用できたとしても、マルチプールへの接続リクエストは失敗します (フェイルオーバではありません)。

SQL クエリによる接続の初期化

JDBCConnectionPoolMBean.setInitSQL(java.lang.String string)

setInitSQL() メソッドを使うと、initSQL MBean 属性の値を設定できます。WebLogic Server は、接続プールのデータベース接続を作成する際には必ずこの SQL コードを実行します。これには、サーバ起動時、接続プール拡張時、サーバ上での接続プールのデプロイ時、および接続更新時が含まれます。基本的に、WebLogic Server はアプリケーションが接続を使用できるようになる前に、この SQL コードによって接続を「プライミング」します。この機能を使って、接続ごとの DBMS 固有動作を設定したり、要求されたアクションを実行できるメモリやパーミッションを接続が備えているか確認したりできます。

コードは、「SQL」で開始し、その後にスペースを入れます。次に例を示します。

SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

または 

SQL SET LOCK MODE TO WAIT

InitSQL によって設定できるオプションは、DBMS ごとに異なります。

Administration Console でこの属性を設定することに関する詳細は、Administration Console オンライン ヘルプの「SQL コードを使用したデータベース接続の初期化」および「初期化 SQL」を参照してください。

注意 : InitSQL は、動的な属性ではありません。InitSQL の値を変更する際には、接続プールをアンデプロイしてから再デプロイするか、またはサーバを再起動する必要があります。

接続プールおよびデータベース接続のテスト

JDBCConnectionPoolRuntimeMBean.testPool()
JDBCConnectionPoolMBean.setTestConnectionsOnCreate(boolean enable) 
JDBCConnectionPoolMBean.setTestConnectionsOnRelease(boolean enable) 
JDBCConnectionPoolMBean.setTestConnectionsOnReserve(boolean enable) 
JDBCConnectionPoolMBean.setTestFrequencySeconds(int seconds) 
JDBCConnectionPoolMBean.setTestTableName(java.lang.String table)
JDBCConnectionPoolMBean.setHighestNumUnavailable(int count)

接続プール内のデータベース接続が正常な状態を保っていることを確認するため、定期的に接続をテストする必要があります。WebLogic Server には、2 つの基本的なテスト タイプが用意されています。JDBCConnectionPoolMBean (コンフィグレーション MBean) 上の属性でコンフィグレーションする自動テスト、および JDBCConnectionPoolRuntimeMBean (実行時 MBean) 上の testPool() メソッドを使って接続プールのトラブルシューティングを行える手動テストです。

WebLogic Server がプール接続の一貫性を自動的に保てるようにすることで、DBMS 接続に関する問題の大半は防げるはずです。自動接続テストをコンフィグレーションするには、JDBCConnectionPoolMBean 上で次のメソッドを使用します。

Administration Console でこの属性を設定することに関する詳細は、Administration Console オンライン ヘルプの「接続テストのオプション」および「[JDBC 接続プール] --> [コンフィグレーション] --> [接続]」を参照してください。

接続を待機する接続リクエストの有効化

JDBCConnectionPoolMBean には、接続プールからの接続を待機する接続リクエストを有効化するように設定できる、2 つの属性があります。ConnectionReserveTimeoutSeconds と HighestNumWaiters です。これら 2 つの属性を一緒に使うと、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。

[接続予約のタイムアウト]

JDBCConnectionPoolMBean.setConnectionReserveTimeoutSeconds(int seconds)

アプリケーションが接続プールからの接続を要求したときに接続プール内の接続がすべて使用中であり、かつ接続プールが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可 SQL 例外を受け取ります。これを避けるためには、接続が利用できるようになるまで接続リクエストが待機するよう、[接続予約のタイムアウト] 値 (秒単位) をコンフィグレーションすることができます。[接続予約のタイムアウト] の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションは PoolLimitSQLException 例外を受け取ります。

待機する接続リクエスト数を制限する

JDBCConnectionPoolMBean.setHighestNumWaiters(int count)

接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを避けるため、同時に接続を待機できる接続リクエスト数を制限する、HighestNumWaiters 属性を設定できます。

HighestNumWaiters を MAX-INT (デフォルト) に設定すると、事実上、接続を待機できる接続リクエスト数に制限はなくなります。HighestNumWaiters を 0 に設定すると、接続リクエストは接続を待機できなくなります。

接続プールの Statement キャッシュのコンフィグレーションと管理

システム内の接続プールにおける各接続について、WebLogic Server は statement キャッシュを作成します。接続で prepared statement または callable statement が使用されると、WebLogic Server はその文をキャッシュして、再利用できるようにします。文のキャッシングは StatementCacheSize および StatementCacheType によって制御されます。Statement キャッシュの仕組みとコンフィグレーション オプションの詳細については、WebLogic Server Administration Console オンライン ヘルプの「Statement キャッシュによるパフォーマンス向上」を参照してください。

接続プールの各接続には、独自の statement キャッシュがありますが、コンフィグレーションの設定は接続プール内のすべての接続に対して行われます。

Statement キャッシュをコンフィグレーションする

JDBCConnectionPoolMBean.setStatementCacheSize(int cacheSize)
JDBCConnectionPoolMBean.setStatementCacheType(java.lang.String type)

WebLogic Server は、各接続プールについて statement キャッシュのサイズ (StatementCacheSize) とアルゴリズム (StatementCacheType) を設定するメソッドを提供します。

StatementCacheSize を設定すると、その数の文 (prepared statement と callable statement) が接続プールの各接続についてキャッシュされます。

デフォルトでは、StatementCacheType は最長未使用時間 (Least Recently Used) の LRU に設定されています。このアルゴリズムにより、接続プールは新しい prepared statement または callable statement の使用時に、キャッシュ内の最も古い文を置き換えます。ほとんどの場合、このオプションを使うと最大限のパフォーマンスが得られます。また、StatementCacheType を Fixed に設定することもできます。固定アルゴリズムを使うと、prepared statement および callable statement は StatementCacheSize 値の要件が満たされるまでキャッシュされます。各文は、キャッシュが手動でクリアされるか、接続が閉じられるまでは、キャッシュ内に残っています。

注意 : StatementCacheType は、動的な属性ではありません。StatementCacheType の値を変更する際には、接続プールをアンデプロイしてから再デプロイするか、またはサーバを再起動する必要があります。

Statement キャッシュの非推奨コンフィグレーション オプション

WebLogic Server 8.1 以前のリリースでは、XA と非 XA の JDBC 接続プール (データベース接続の作成に XA JDBC ドライバを使用する接続プールと、非 XA JDBC ドライバを使用する接続プール) に対して、別々の statement キャッシュが実装されていました。WebLogic Server 8.1 では、statement キャッシュが書き換えられました。現在では、1 つの Statement キャッシュ実装で XA および非 XA の両方の接続プールに対応します。Statement キャッシュの修正によって、JDBCConnectionPoolMBean にある、Statement キャッシュをコンフィグレーションするための接続プール属性は非推奨になりました。表 2-1 に、非推奨になった以前のリリースの MBean 属性と WebLogic Server 8.1 でその属性に相当するオプションを示します。

表 2-1 非推奨の Statement キャッシュ属性とその属性に相当するオプション

非推奨の MBean 属性

WebLogic Server 8.1 で相当する機能

PreparedStatementCacheSize

StatementCacheSize

XAPreparedStatementCacheSize

StatementCacheSize


 

以前のリリースから 8.1 に WebLogic Server のコンフィグレーションを移行できるようにするために、Weblogic Server では上記の MBean 属性が以下の優先順位で適用されます。

  1. PreparedStatementCacheSize
  2. XAPreparedStatementCacheSize
  3. StatementCacheSize

たとえば、JDBC 接続プールの PreparedStatementCacheSize が 5 に、StatementCacheSize が 10 に設定されている場合、接続プール内の各接続に対応する実際の Statement キャッシュのサイズは 5 になります。PreparedStatementCacheSize が StatementCacheSize よりも優先されるためです。

接続プールの Statement キャッシュをクリアする

JDBCConnectionPoolRuntimeMBean.clearStatementCache()

clearStatementCache() メソッドを使うと、接続プール内のすべての接続の statement キャッシュを手動でクリアできます。

単一接続用の Statement キャッシュをクリアする

weblogic.jdbc.extensions.WLConnection.clearStatementCache()
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql,int resSetType,int resSetConcurrency)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql,int resSetType,int resSetConcurrency)

weblogic.jdbc.extensions.WLConnection インタフェースのメソッドを使用すると、単一の接続用の statement キャッシュをクリアするか、またはキャッシュから個別に文をクリアできます。これらのメソッドは、処理が正常に実行されると true を返し、文が見つからなかったために処理が失敗すると false を返します。

Prepared statement と callable statement がキャッシュに格納される場合、これらは正確な SQL 文と、必要に応じて結果セット パラメータ (タイプおよび同時実行性オプション) に基づいて格納 (キー化) されます。個々の prepared statement または callable statement をクリアする場合は、適切な結果セット パラメータを取るメソッドを使用する必要があります。たとえば、resSetType が ResultSet.TYPE_SCROLL_INSENSITIVE で resSetConcurrency が ResultSet.CONCUR_READ_ONLY のキャッシュ内に callable statement がある場合は、結果セット パラメータを取るメソッドを使用することが必要です。

clearCallableStatement(java.lang.String sql,int resSetType,int resSetConcurrency)

パラメータとして SQL 文字列のみを取るメソッドを使用する場合は、メソッドは文を見つけられず、キャッシュからクリアされるものはありません。メソッドは false を返します。

現在アプリケーションによって使用中の文をクリアする場合、WebLogic Server はその文をキャッシュから削除しますが、閉じはしません。現在使用中でない文をクリアする場合、WebLogic Server はキャッシュからその文を削除して閉じます。

これらのメソッドの詳細については、WLConnection の Javadoc を参照してください。

接続プールの縮小

JDBCConnectionPoolRuntimeMBean.shrink()

接続プールは、プール内の接続の初期数と最大数を定義する一連のプロパティ (initialCapacity と maxCapacity) と、接続がすべて使用中のときにプールに追加される接続の数を定義するプロパティ (capacityIncrement) を備えています。プールがその最大容量に達すると、最大数の接続が開くことになり、接続プールで自動縮小を有効化するか、shrink() メソッドを使って手動で接続プールを縮小しない限り、それらの接続は開いたままになります。

接続の使用がピークを過ぎれば、接続プールから接続をいくつか削除して、WebLogic Server と DBMS のリソースを解放してもかまいません。

接続プールのリセット

JDBCConnectionPoolRuntimeMBean.reset()

JDBCConnectionPoolRuntimeMBean.reset() メソッドは、接続プール内の接続をすべて閉じてから開き直します。これは、たとえば、DBMS が再起動されたあとに必要になることがあります。接続プール内の 1 つの接続が失敗した場合は、プール内のすべての接続が不良であることが往々にしてあります。

接続プールのサスペンド

JDBCConnectionPoolRuntimeMBean.suspend()
JDBCConnectionPoolRuntimeMBean.forceSuspend()

WebLogic Server では、JDBCConnectionPoolRuntimeMbean 内に接続プールをサスペンドする 2 つのメソッド、suspend() と forceSuspend() があります。このメソッドを使うと、接続プールを一時的に無効にして、クライアントがそのプールから接続を取得したり使用したりするのを防ぐことができます。適切なパーミッションを付与されたユーザのみが、接続プールをサスペンドできます。

suspend() メソッドで接続プールをサスペンドすると、接続プールは無効であるとマーク付けされ、アプリケーションはプールからの接続を使用できなくなります。サスペンド時にすでに接続プールからの接続を予約してあったアプリケーションは、接続を使用しようとすると例外を受け取ります。WebLogic Server は接続プール内の接続をすべて、接続プールがサスペンドされる前の状態のままで保持します。

forceSuspend() メソッドで接続プールをサスペンドすると、WebLogic Server は接続プールを無効なものとしてマーク付けし、現在接続を使用中のアプリケーションの接続を強制的に切断し、サスペンドしたときに使用中だった接続を再作成し (閉じて開き直し) ます。閉じた接続に対するトランザクションはすべてロールバックされます。WebLogic Server は、他の接続をすべて、接続プールがサスペンドされる前の状態のままで保持します。

suspend() および forceSuspend() メソッドは、非推奨となった disableFreezingUsers() および disableDroppingUsers() メソッドの代わりとなるものです。

接続プールの再開

JDBCConnectionPoolRuntimeMBean.resume()

suspend() または forceSuspend() メソッドで無効化した接続プールを再び有効化するには、resume() メソッドを使用できます。このメソッドは、接続プールを有効なものとしてマーク付けし、接続プールからの接続をアプリケーションが使用できるようにします。suspend() メソッドで接続プールをサスペンドした場合、接続はすべてサスペンド前の状態のままで保持されます。接続プールのサスペンド前に接続を予約してあったクライアントは、中断した箇所とまったく同じところから JDBC 処理を続行できます。forceSuspend() メソッドで接続プールをサスペンドした場合、サスペンド時に使用中でなかった接続は、サスペンド前とまったく同じ状態で保持されます。使用中だった接続は、閉じられ、再び開かれます。接続を予約してあったクライアントには、有効な JDBC コンテキストがなくなっています。

resume() メソッドは、非推奨となった enable() メソッドの代わりとなるものです。

注意 : たとえば、データベース サーバが利用できない場合に、正しく起動しなかった接続プールを起動するために resume() メソッドを使うことはできません。

 

アプリケーション スコープの JDBC 接続プールのコンフィグレーションと使い方

エンタープライズ アプリケーションをパッケージ化するときに weblogic-application.xml 補足デプロイメント記述子を組み込むことができます。この記述子は、アプリケーション スコーピングのコンフィグレーションに使用できます。weblogic-application.xml ファイルで、エンタープライズ アプリケーションのデプロイ時に作成される JDBC 接続プールをコンフィグレーションできます。

接続プールのインスタンスは、アプリケーションのインスタンスごとに作成されます。つまり、プールのインスタンスは、アプリケーションの対象となっている各ノード上のアプリケーションで作成されます。プールのサイズを検討する場合は、この点に留意してください。

この方法で作成された接続プールは、アプリケーション スコープの接続プール、アプリケーション スコープのプール、アプリケーション ローカル プール、ローカル プールなどと呼ばれ、そのエンタープライズ アプリケーション専用にスコープが設定されます。つまり、各接続プールがエンタープライズ アプリケーションごとに分離されます。

アプリケーション スコーピング、およびアプリケーション スコープ リソースの詳細については、以下を参照してください。

アプリケーション スコープの接続プールのコンフィグレーション

アプリケーション スコープの接続プールをコンフィグレーションするには、エンタープライズ アプリケーションの weblogic-application.xml ファイルに jdbc-connection-pool 要素を接続プール コンフィグレーション パラメータを指定して追加します。次に例を示します。

<jdbc-connection-pool>
      <data-source-name>XA_LocalDS1</data-source-name>
      <connection-factory>
        <factory-name>XA_LocalCF1</factory-name>
        <connection-properties>
          <user-name>SCOTT</user-name>
          <password>tiger</password>
          <url>jdbc:oracle:thin:@dbserver:1521:sid</url>
          <driver-class-name>oracle.jdbc.xa.client.OracleXADataSource
            </driver-class-name>
          <connection-params>
            <parameter>
              <param-name>foo</param-name>
              <param-value>xyz</param-value>
            </parameter>
            <parameter>
              <param-name>bar</param-name>
              <param-value>abc</param-value>
            </parameter>
          </connection-params>
        </connection-properties>
      </connection-factory>
      <pool-params>
        <size-params>
          <initial-capacity>5</initial-capacity>
          <max-capacity>10</max-capacity>
          <capacity-increment>2</capacity-increment>
          <shrinking-enabled>true</shrinking-enabled>
          <shrink-frequency-seconds>300</shrink-frequency-seconds>
          <highest-num-waiters>100</highest-num-waiters>
          <highest-num-unavailable>4</highest-num-unavailable>
        </size-params>
        <xa-params>
          <debug-level>3</debug-level>
          <local-transaction-supported>true</local-transaction-supported>
          <xa-set-transaction-timeout>true</xa-set-transaction-timeout>
          <xa-transaction-timeout>30</xa-transaction-timeout>
        </xa-params>
        <login-delay-seconds>1</login-delay-seconds>
        <leak-profiling-enabled>false</leak-profiling-enabled>
        <connection-check-params>
          <table-name>check_table</table-name>
          <check-on-create-enabled>true</check-on-create-enabled>
          <check-on-reserve-enabled>true</check-on-reserve-enabled>
          <check-on-release-enabled>false</check-on-release-enabled>
          <connection-reserve-timeout-seconds>30
            </connection-reserve-timeout-seconds>
          <test-frequency-seconds>600</test-frequency-seconds>
          <connection-creation-retry-frequency-seconds>360
            </connection-creation-retry-frequency-seconds>
          <inactive-connection-timeout-seconds>360
            </inactive-connection-timeout-seconds>
          <init-sql>SQL SET LOCK MODE TO WAIT</init-sql>
        </connection-check-params>
      </pool-params>
      <driver-params>
        <prepared-statement>
          <cache-size>10</cache-size>
          <cache-type>LRU</cache-type>
        </prepared-statement>
        <row-prefetch-enabled>true</row-prefetch-enabled>
        <row-prefetch-size>500</row-prefetch-size>
        <stream-chunk-size>1024</stream-chunk-size>
      </driver-params>
    </jdbc-connection-pool>

JDBC 接続プール要素エントリの詳細については、『WebLogic Server アプリケーションの開発』の「weblogic-application.xml デプロイメント記述子の要素」にある「jdbc-connection-pool」を参照してください。

エンタープライズ アプリケーションを展開アーカイブとしてデプロイする場合は、Administration Console を使ってコンフィグレーション オプションを変更することもできます。Administration Console オンライン ヘルプの「アプリケーション スコープの JDBC データ ソースと JDBC 接続プール」を参照してください。

jdbc-connection-pool 要素内の必須要素

weblogic-application.xml ファイル内でアプリケーション スコープの接続プールをコンフィグレーションする場合、以下のサブ要素を含める必要があります。

weblogic-application.xml 内のデータベース パスワードを暗号化する

データベース パスワードをクリア テキストで保存しなくてすむように、weblogic-application.xml ファイル内のデータベース パスワードを weblogic.j2ee.PasswordEncrypt ユーティリティで暗号化できます。このユーティリティは、次の場所でデータベース パスワードを探します。

ユーティリティはパスワードをハッシュ化し、weblogic-application.xml ファイル内のパスワードをハッシュ化されたバージョンに置き換え、ハッシュ化された値を WebLogic ドメインの SerializedSystemIni.dat に格納します。

注意 : パスワードの暗号化は、ドメインごとに固有です。つまり、暗号化ユーティリティを実行する場合、アプリケーションのデプロイ先とするドメインを指定する必要があります。別のドメインでアプリケーションをデプロイしようとしても、WebLogic Server は実行時に使用されるパスワードを解読できません。パスワードの暗号化の詳細については、『WebLogic Security の管理』の「パスワードの保護」を参照してください。

アプリケーション アーカイブの作成前にこのユーティリティを実行します。すでにアーカイブされているファイルに対しては実行できません。

このユーティリティを実行する前に、WebLogic Server がインストールされ、(ユーティリティが必要なクラスを見つけられるように) 環境がコンフィグレーションされている必要があります。パスワード暗号化ユーティリティを実行するときにサーバが実行されている必要はありません。

パスワード暗号化ユーティリティを実行するには、次のコマンドを入力します。

java weblogic.j2ee.PasswordEncrypt <descriptor file> <domain config dir>

各要素の説明は次のとおりです。

パスワード暗号化ユーティリティの実行後は、パスワードは次のように表示されます。

注意 : パスワードを変更する必要がある場合は、weblogic-application.xml ファイルで変更し、その後パスワード暗号化ユーティリティを再実行します。ユーティリティは、すでに暗号化されているパスワードの再暗号化は行いません。

次の場合は、記述子ファイル内のパスワードを再暗号化する必要があります。

アプリケーション スコープの接続プールの Statement キャッシュの非推奨コンフィグレーション オプション

WebLogic Server 8.1 より前のリリースでは、XA JDBC 接続プールと非 XA JDBC 接続プール用に別々の Statement キャッシュを実装していました。WebLogic Server 8.1 では、statement キャッシュが書き換えられました。現在では、1 つの Statement キャッシュ実装で XA および非 XA の両方の接続プールに対応します。Statement キャッシュの変更に伴って、非推奨のタグが 1 つ weblogic-application.xml 記述子ファイルで使用できるようになりました。表 2-2 に、非推奨の記述子タグ、代替タグ、アプリケーション スコープの接続プールをデプロイするときに作成される関連 MBean 属性を示します。

表 2-2 非推奨の Statement キャッシュ記述子タグと関連 MBean 属性

非推奨

WebLogic Server 8.1 で相当する機能

非推奨の記述子タグ :

<pool-params>
 <xa-params>
   <prepared-statement-cache-size>10
    </prepared-statement-cache-size>
 </xa-params>
</pool-params>

注意 : 太字のタグのみが非推奨で、その他のタグはコンテキストを示すためのもの。

代わりに使用するタグ :

<driver-params>
 <prepared-statement>
   <cache-size>10
    </cache-size>
 </prepared-statement>
</driver-params>

上記タグによって設定される MBean 属性 :

XaParamsMBean.PreparedStatementCacheSize

上記タグによって設定される MBean 属性 :

PreparedStatementMBean.CacheSize


 

以前のリリースから 8.1 に WebLogic Server またはエンタープライズ アプリケーションのコンフィグレーションを移行できるようにするために、Weblogic Server では上記の MBean 属性が以下の優先順位で適用されます。

  1. PreparedStatementMBean.CacheSize
  2. XAParamsMBean.PreparedStatementCacheSize

たとえば、weblogic-application.xml ファイルで JDBC 接続プールの <cache-size> が 5 に、<prepared-statement-cache-size> が 10 に設定されている場合、接続プール内の各接続に対応する実際の Statement キャッシュのサイズは 5 になります。PreparedStatementMBean.CacheSize が XaParamsMBean.PreparedStatementCacheSize よりも優先されるためです。

注意 : WebLogic Server 7.0 SP3 以降からアプリケーションを移行する場合に、XA statement キャッシュを無効にするには、weblogic-application.xml ファイルで JDBC 接続プールの <cache-size> を 0 に設定する必要があります。

アプリケーション スコープの接続プールからの接続の取得

アプリケーション スコープの接続プールから接続を取得するには、ローカル環境 (java:comp/env) の weblogic-application.xml 記述子ファイルで定義されたデータ ソースをルックアップし、データ ソースからの接続を要求します。次に例を示します。

javax.sql.DataSource ds = 
    (javax.sql.DataSource) ctx.lookup("java:app/jdbc/myDataSource");
java.sql.Connection conn = ds.getConnection();

接続を使い終わったら、必ずその接続を閉じて接続プールに返すようにしてください。

conn.close();

 

マルチプールのコンフィグレーションと使い方

マルチプールとは、接続プールのプールです。特定の接続プール内のすべての接続は、同じデータベース、同じユーザ、同じ接続プロパティを使って作成されます。つまり、それらは単一のデータベースに関連付けられます。しかし、マルチプール内の接続プールには、それぞれ異なる DBMS を関連付けることができます。

マルチプールのコンフィグレーション

マルチプールには、どの接続プールがクライアントに接続を返すかを選択するための、コンフィグレーション可能なアルゴリズムが含まれています。

以下の手順を使用してマルチプールを作成します。

  1. 必要な接続プールを作成します。
  2. マルチプールの主な目的を、高可用性とするかロード バランシングとするかを決定します。「マルチプール アルゴリズムの選択」を参照してください。
  3. Administration Console または WebLogic 管理 API を使用してマルチプールを作成し、接続プールをマルチプールに割り当てます。

マルチプールの詳細については、Administration Console オンライン ヘルプを参照してください。JDBCMultiPoolMBean については、WebLogic Server の Javadoc を参照してください。

マルチプール アルゴリズムの選択

マルチプールを設定する前に、その主要な目的、つまり高可用性またはロード バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズに合わせて選択できます。

高可用性

高可用性アルゴリズムでは、接続プールの順序付けされたリストを提供します。通常、このタイプのマルチプールへのすべての接続リクエストは、リストの最初のプールによって処理されます。このプールを通したデータベース接続が失敗し、かつその接続を置き換えられない場合、または接続プールがサスペンドされている場合、そのリストの次のプールから順番に接続が選択されます。

注意 : このアルゴリズムは、TestConnectionsOnReserve に依存して最初の接続プールの接続の状態が正常かどうかのテストを行います。接続テストが失敗であれば、マルチプールは次の接続プールからの接続を使用します。TestConnectionsOnReserve のコンフィグレーションについては、「接続プールおよびデータベース接続のテスト」を参照してください。

ロード バランシング

ロード バランシング マルチプールへの接続リクエストは、リスト内の任意の接続プールから処理されます。プールは、ラウンドロビン方式でアクセスされます。マルチプールは接続を提供する際、最後に使用されたプールの直後にリストされている接続プールからの接続を選択します。ロード バランシング アルゴリズムを使用するマルチプールも、データベース接続テストが失敗して接続を置き換えられない場合、または接続プールがサスペンドされている場合、リスト内の次の接続プールにフェイルオーバされます。

JDBC マルチプールにおけるトランザクションのサポート

WebLogic Server 8.1 SP5 では、グローバル トランザクションをサポートするようマルチプールが拡張されました。

注意 : WebLogic Server 8.1 SP5 では、Oracle RAC 上でのみ XA を使用したマルチプールのサポートを保証しています。Oracle RAC のサポートされているバージョンについては、「サポート対象のデータベース コンフィグレーション」を参照してください。

グローバル トランザクションをサポートするマルチプール コンフィグレーションの例については、「グローバル トランザクションを利用する場合のマルチプールの使用」を参照してください。

マルチプールのトランザクション フェイルオーバ処理

グローバル トランザクションの進行中にマルチプールからの接続が失敗した場合、そのトランザクションの結果は接続が失敗した時点でトランザクションがどの段階にあるかによって決まります。

最初に障害が発生する可能性のある段階は、アプリケーションでトランザクションをコミットする呼び出しを行う前です。データベース接続にこの段階で障害が発生すると、アプリケーションは例外を受け取ります。アプリケーションでは新しい接続を取得して、新たにトランザクションの処理を試行する必要があります。WebLogic Server では透過的なフェイルオーバはサポートされていません。

アプリケーションでトランザクションをコミットする呼び出しを行った後で障害が発生した場合、処理中の任意のトランザクション処理は PREPARE 操作が完了しているかどうかによって変わります。PREPARE 操作が完了していない場合、トランザクション マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外が送出されます。PREPARE 操作が完了している場合、トランザクション マネージャでは別の接続を使用して処理中のトランザクションを完了しようとします。

COMMIT 操作の間に障害が発生した場合、トランザクション マネージャでは XARetryDurationSeconds の設定に応じて、COMMIT 操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT 操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。トランザクション マネージャでは、再試行が成功するか、コンフィグレーション ファイルに定義された JTA 破棄タイムアウトに達するまで、定期的に COMMIT 操作の再試行が続けられ、破棄タイムアウトに達した後にはトランザクションが中止されます。

マルチプールのフェイルオーバ機能の拡張

WebLogic Server 8.1 SP3 では、マルチプールの機能が以下のように拡張されています。

接続プールの障害発生時における接続リクエストのルーティング機能を拡張する

マルチプール内の接続プールに障害が発生した場合のパフォーマンスを向上させるために、WebLogic Server ではプールされた接続で接続テストが失敗するとその接続プールが自動的に無効化されます。接続プールが無効化されると、アプリケーションからその接続プールに接続リクエストがルーティングされなくなります。その代わり、マルチプール内にリストされた次の利用可能な接続プールに接続リクエストがルーティングされます。

この機能では、マルチプール内のすべての接続プールに対して接続プールのテスト オプション (特に TestTableName と TestConnectionsOnReserve) をコンフィグレーションする必要があります。

マルチプールに対してコールバック ハンドラが登録されている場合、コールバック ハンドラが呼び出されてから、リスト内の次の接続プールにフェイルオーバされます。詳細については、「コールバックを使用してマルチプールのフェイルオーバを制御する」を参照してください。

マルチプール内の障害が発生した接続プールが回復した場合に自動的に再有効化する

接続が接続テストに失敗したために接続プールが自動的に無効化されると、WebLogic Server では、無効化された接続プールからの接続が定期的にテストされ、接続プール (または基底のデータベース) が再び利用可能になっているかどうかの確認が行われます。接続プールが利用可能になっている場合には、その接続プールが自動的に再有効化され、マルチプールのアルゴリズムとリスト内の接続プールの位置に応じてその接続プールに対する接続リクエストのルーティングが再開されます。

マルチプール内の自動的に無効化された接続プールに対して WebLogic Server が行うチェックの頻度を制御するには、config.xml ファイル内のマルチプールのコンフィグレーションに HealthCheckFrequencySeconds 属性の値を追加します。次に例を示します。

<JDBCMultiPool 
AlgorithmType="High-Availability" 
Name="demoMultiPool" 
PoolList="demoPool2,demoPool" 
HealthCheckFrequencySeconds="240" 
Targets="examplesServer" />

注意 : この属性は Administration Console では設定できません。この機能を実装するには、config.xml ファイル内のマルチプールのコンフィグレーションにこの属性を手動で追加する必要があります。

WebLogic Server では、無効化された各接続プールに対してこの属性で指定した間隔で接続テストが行われます。デフォルト値は、300 秒です。値を指定しない場合、300 秒ごとに自動的に無効化された接続プールがテストされます。

この機能では、マルチプール内のすべての接続プールに対して接続プールのテスト オプション (特に TestTableName と TestConnectionsOnReserve) をコンフィグレーションする必要があります。

手動で無効化した接続プールに対してはテストも自動的な再有効化も行われません。WebLogic Server によって自動的に無効化された接続プールに対してのみテストが行われます。

マルチプールに対してコールバック ハンドラが登録されている場合、コールバック ハンドラが呼び出されてから、接続プールの再有効化が行われます。詳細については、「コールバックを使用してマルチプールのフェイルバックを制御する」を参照してください。

マルチプール内の使用中の接続プールに対するフェイルオーバを有効化する

デフォルトでは、高可用性アルゴリズムを使用するマルチプールの場合、データベース接続に対するリクエスト数が、マルチプール内の現在の接続プールにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。

現在の接続プールにあるすべての接続が使用中の場合にマルチプールのフェイルオーバを有効にするには、config.xml ファイル内のマルチプールのコンフィグレーションに FailoverRequestIfBusy 属性の値を設定する必要があります。この属性を true に設定すると、現在の接続プールにあるすべての接続が使用中の場合に、マルチプール内の次の利用可能な接続プールにアプリケーションの接続リクエストがルーティングされます。false (デフォルト) に設定すると、接続リクエストはフェイルオーバされません。WebLogic Server によって weblogic.jdbc.extensions.PoolUnavailableSQLException が送出されます。

config.xml ファイルに FailoverRequestIfBusy 属性を追加すると、マルチプールのエントリは次のようになります。

<JDBCMultiPool 
AlgorithmType="High-Availability" 
Name="demoMultiPool" 
PoolList="demoPool2,demoPool" 
FailoverRequestIfBusy="true" 
Targets="examplesServer" />

注意 : FailoverRequestIfBusy 属性は、Administration Console では設定できません。この機能を実装するには、config.xml ファイル内のマルチプールのコンフィグレーションにこの属性を手動で追加する必要があります。

マルチプールのコンフィグレーションに ConnectionPoolFailoverCallbackHandler が含まれている場合、コールバック ハンドラが呼び出されてから、フェイルオーバが行われます。詳細については、「コールバックを使用してマルチプールのフェイルオーバを制御する」を参照してください。

コールバックを使用してマルチプールのフェイルオーバを制御する

高可用性アルゴリズムを使用するマルチプールでは、接続リクエストをマルチプール内のある JDBC 接続プールからリスト内の次の接続プールにフェイルオーバする時期を制御するコールバック ハンドラを WebLogic Server に登録できます。

コールバック ハンドラを使用すると、フェイルオーバを行うかどうか、またはフェイルオーバを行う時期を制御できるので、フェイルオーバの前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。

コールバック ハンドラは、config.xml ファイル内のマルチプールの属性を使用して、マルチプールごとに登録されます。そのため、コールバックの適用先となるマルチプールごとにコールバック ハンドラを登録する必要があります。また、マルチプールごとに異なるコールバック ハンドラを登録することもできます。

コールバック ハンドラの要件

マルチプール内のフェイルオーバおよびフェイルバックの制御に使用されるコールバック ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallback インタフェースの実装が含まれていなければなりません。マルチプールでリスト内の次の接続プールにフェイルオーバする必要がある場合や、以前に無効化された接続プールが利用可能になった場合、ConnectionPoolFailoverCallback インタフェースの allowPoolFailover() メソッドが呼び出され、以下に定義されている 3 つのパラメータ (currPool、nextPool、および opcode) の値が渡されます。コールバック ハンドラからの戻り値を待機してからタスクが完了されます。

アプリケーションは、以下に定義されている OK、RETRY_CURRENT、または DONOT_FAILOVER を返す必要があります。アプリケーションはフェイルオーバおよびフェイルバックの個々の状況を処理しなければなりません。

詳細については、weblogic.jdbc.extensions.ConnectionPoolFailoverCallback インタフェースの Javadoc を参照してください。

注意 : フェイルオーバのコールバック ハンドラは省略可能です。マルチプールのコンフィグレーションにコールバック ハンドラが指定されていない場合、WebLogic Server では処理 (フェイルオーバまたは無効化された接続プールの再有効化) が続行されます。

コールバック ハンドラのコンフィグレーション

フェイルオーバおよびフェイルバック機能に関連付けられたマルチプールのコンフィグレーション属性には、以下の 2 つがあります。

config.xml ファイルにこれらの属性を追加すると、マルチプールのエントリは次のようになります。

<JDBCMultiPool 
AlgorithmType="High-Availability" 
Name="demoMultiPool" 
ConnectionPoolFailoverCallbackHandler="com.bea.samples.wls.jdbc.MultiPoolFailoverCallbackApplication"
PoolList="demoPool2,demoPool" 
HealthCheckFrequencySeconds="120" 
Targets="examplesServer" />

注意 : これらの属性は Administration Console では設定できません。これらの機能を実装するには、config.xml ファイル内のマルチプールのコンフィグレーションにこれらの属性を手動で追加する必要があります。

フェイルオーバのしくみ

WebLogic Server は、現在の接続プールで接続テストが失敗した場合や、FailoverRequestIfBusy が有効化されているときに現在の接続プール内のすべての接続が使用中である場合に、接続リクエストをリスト内の次の接続プールにフェイルオーバしようとします。

コールバック機能を有効にするには、config.xml ファイル内のマルチプールのコンフィグレーションで ConnectionPoolFailoverCallbackHandler 属性を使用してコールバック ハンドラを WebLogic Server に登録します。

高可用性アルゴリズムを使用する場合、接続リクエストはリスト内の最初の接続プールから処理されます。接続プールからの接続が接続テストに失敗すると、WebLogic Server はその接続プールを「応答なし」としてマーク付けし、無効にします。コールバック ハンドラが登録されている場合、WebLogic Server は以下の情報を渡してコールバック ハンドラを呼び出し、戻り値を待機します。

フェイルオーバは接続リクエストと同期します。フェイルオーバは、WebLogic Server が接続リクエストに応じようとする場合にのみ発生します。

コールバック ハンドラからの戻り値は、以下の 3 種類のオプションのいずれかを示します。

WebLogic Server はコールバック ハンドラによって返された値に従って処理を行います。

2 番目の接続プールで障害が発生すると、先のフェイルオーバと同様、マルチプール内の次の利用可能な接続プールにフェイルオーバしようと再びコールバック ハンドラが呼び出されます (接続プールが存在している場合)。

注意 : 接続プールを手動で無効化した場合、WebLogic Server はコールバック ハンドラを呼び出しません。

ロード バランシング アルゴリズムを使用するマルチプールの場合、WebLogic Server では接続プールが無効化されても、コールバック ハンドラは呼び出されません。ただし、無効化された接続プールを再有効化しようとする場合にはコールバック ハンドラが呼び出されます。詳細については、次の節を参照してください。

コールバックを使用してマルチプールのフェイルバックを制御する

マルチプールに対してフェイルオーバのコールバック ハンドラが登録されている場合、WebLogic Server では、自動的に無効化された接続プールを再有効化するときに同じコールバック ハンドラが呼び出されます。コールバックを使用すると、無効化された接続プールを再有効化するかどうか、または再有効化を行う時期を制御できるので、接続プールを再有効化する前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。

コールバック ハンドラは、config.xml ファイル内のマルチプールの属性を使用して、マルチプールごとに登録されます。そのため、コールバックの適用先となるマルチプールごとにコールバック ハンドラを登録する必要があります。また、マルチプールごとに異なるコールバック ハンドラを登録することもできます。

コールバック ハンドラの詳細については、以下の節を参照してください。

フェイルバックのしくみ

WebLogic Server では、マルチプール内の自動的に無効化された接続プールのステータスが定期的にチェックされます (「マルチプール内の障害が発生した接続プールが回復した場合に自動的に再有効化する」を参照)。無効化された接続プールが利用可能になった場合、およびフェイルオーバのコールバック ハンドラが登録されている場合、WebLogic Server は以下の情報を持つコールバック ハンドラを呼び出して、戻り値を待機します。

フェイルバック (つまり、無効化された接続プールを自動的に再有効化すること) は、フェイルオーバが接続リクエストと同期しているものの、フェイルバックは接続リクエストと同期していないという点でフェイルオーバとは異なります。

コールバック ハンドラは、以下の値のいずれかを返すことができます。

WebLogic Server はコールバック ハンドラによって返された値に従って処理を行います。

コールバック ハンドラが DONOT_FAILOVER を返した場合、WebLogic Server はマルチプールのコンフィグレーションの HealthCheckFrequencySeconds 属性で決められている設定に従って次のテスト サイクル中に接続プールを再有効化しようとし、そのプロセスの一部としてコールバック ハンドラを呼び出します。

マルチプールにリストされている接続プールの順序は非常に重要です。高可用性アルゴリズムを使用するマルチプールは、常に、マルチプール内の接続プールのリストにある最初の利用可能な接続プールで接続リクエストを処理しようとします。以下のシナリオを検討してください。

高可用性アルゴリズムを使用する MultiPool_1 には、登録された ConnectionPoolFailoverCallbackHandler があり、CP1、CP2、および CP3 という順序でリストされている 3 つの接続プールが含まれています。

CP1 が無効化されると、MultiPool_1 では接続リクエストが CP2 にフェイルオーバされます。

続いて CP2 が無効化されると、MultiPool_1 では接続リクエストが CP3 にフェイルオーバされます。

しばらく経つと、CP1 が再び利用可能になり、コールバック ハンドラによって WebLogic Server による接続プールの再有効化が許可されます。CP1 はマルチプール内にリストされた最初の接続プールなので、以降の接続リクエストは、CP1 によって処理されます。

続いて CP2 が利用可能になり、コールバック ハンドラによって WebLogic Server による接続プールの再有効化が許可されても、接続プールのリストで CP1 は CP2 の前にリストされているので、接続リクエストは引き続き CP1 によって処理されます。

マルチプールのフェイルオーバの制限と要件

WebLogic Server はマルチプール用の高可用性アルゴリズムを備えており、接続プールで障害 (データベース管理システムのクラッシュなど) が発生しても、システムをそのまま稼働させることができます。ただし、システムをコンフィグレーションする際は、以下の制限と要件を考慮する必要があります。

予約時の接続テストによってフェイルオーバが有効になる

接続プールでは、いつデータベース接続が失なわれたかを識別するために TestConnectionsOnReserve 機能を使用します。接続は、アプリケーションによって予約されるまで、自動的にはテストされません。マルチプール内の接続プールに TestConnectionsOnReserve=true を設定する必要があります。この機能をオンにすると、各接続はアプリケーションに戻される前にテストされます。これは、高可用性アルゴリズムにおいて不可欠な処理です。高可用性アルゴリズムでは、マルチプール内の次の接続プールにフェイルオーバするタイミングが、予約時の接続テストの結果に基づいて決定されます。テストが失敗すると、接続プールによって接続が再作成されます。再作成が失敗すると、マルチプールの次の接続プールにフェイルオーバされます。

デフォルトではすべての接続が使用中の場合はフェイルオーバしない

デフォルトでは、プライマリ接続プール内のすべての接続が使用中の場合、高可用性アルゴリズムを備えたマルチプールでは、リスト内の次のプールから接続が提供されることはありません。マルチプールのフェイルオーバは、データベース接続が失われたとき (または接続プールが無効化されているとき) にだけ機能します。接続プール内のすべての接続が使用中の場合にマルチプールでフェイルオーバを有効化することについては、「マルチプール内の使用中の接続プールに対するフェイルオーバを有効化する」を参照してください。

接続作成の再試行は有効にしない

接続作成の再試行は、高可用性マルチプール内の接続プールでは有効にしないでください。リスト内の接続プールからの応答がなく、接続リクエストの数が 1 番目の接続プール内の接続数と同じ場合、マルチプール内の以降の接続プールで接続が使用できたとしても、マルチプールへの接続リクエストは失敗します (フェイルオーバではありません)。

データベースが利用できない場合、マルチプールおよび接続作成の再試行機能のいずれにおいても、データベース接続を正常に処理することで問題を解決しようとします。これら 2 つの機能を併用すると、相互の機能を干渉し合うことになります。

使用中の接続はフェイルオーバできない

予約後に接続が失敗する可能性もありますが、これについてはアプリケーションで処理する必要があります。WebLogic Server では、アプリケーションで使用中に失敗した接続をフェイルオーバさせることはできません。接続の使用中に障害が発生した場合は、トランザクションをやり直す必要があり、こうした障害が処理できるようにコーディングしておく必要があります。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次