| Oracle Containers for J2EEサービス・ガイド 10g（10.1.3.5.0） B56027-01 |
|
 戻る |
 次へ |
この章では、Oracle Containers for J2EE（OC4J）のデータソースについて説明します。この章には、次の項目が含まれます。
タスク
この章では、次のOC4Jデータソース・タスクについて説明します。
新機能
次のOC4Jデータソースの機能および動作は、今回のリリースの新機能です。
Oracle Enterprise Manager 10g Application Server Controlコンソールで、すべてのデータソース構成を実行できます。
エミュレート、非エミュレートおよびネイティブの各OC4Jデータソース・タイプは、マネージド・データソースとネイティブ・データソースに置き換えられました。
OC4Jでは、デフォルトでローカル・トランザクションを追跡します。これにより、異なるデータベース・ドライバおよびベンダー間で一貫性を維持できます。さらに、この追跡によってインターリーブを原因とするトランザクションの破損を防止できます。
Oracleデータソース全体で統一化された新しい接続キャッシュ・メカニズムにより、Real Application Clusters（RAC）フェイルオーバーの統合サポートが提供されます。詳細は、「接続プール」および表5-3「接続プールの属性」を参照してください。
非推奨
次の項目は、今回のリリースでは非推奨です。
OracleConnectionCacheImplクラスは非推奨です。このクラスでは、複数のスキーマはサポートされず、1人のユーザーのみがキャッシュされます。
stmt-cache-size属性。データソースにJDBC文のキャッシング機能を構成するために、stmt-cache-size属性ではなくnum-cached-statements属性を使用してキャッシュ・サイズを設定します。
追加ドキュメント
追加のデータソース情報は、次のドキュメントを参照してください。
『Oracle Database JDBC開発者ガイドおよびリファレンス』
コード例付きのHow-To概要ドキュメント（http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlで入手可能）
追加の資料（http://www.oracle.com/technology/tech/java/oc4j/index.htmlで入手可能）
データソースは、javax.sql.DataSourceインタフェースを実装するJavaオブジェクトです。データソースにより、ベンダーに依存しない移植可能なメソッドを使用して、データベースへの接続を作成できます。特定のデータベースを指定するために、データソース・オブジェクトのプロパティを設定します。アプリケーションでは、データソースのプロパティを変更することで様々なデータベースを使用できるため、アプリケーション・コードは変更せずに済みます。
OC4Jのデータソースには、マネージド・データソースとネイティブ・データソースという2つのタイプがあります。
マネージド・データソースは、OC4Jによって管理されます。つまり、グローバル・トランザクション管理、接続プーリング、エラー処理などの重要なシステム・インフラストラクチャは、OC4Jによって提供されます。マネージド・データソースは、JDBCドライバまたはデータソースのラッパーとして機能するjavax.sql.DataSourceインタフェースのOC4Jによる実装です。J2EEコンポーネントでは、データソース実装がラッパーであると認識することなく、JNDIを使用してマネージド・データソースにアクセスできます。
マネージド・データソースとネイティブ・データソースの相違点は、次のとおりです。
マネージド・データソースから取得された接続は、グローバル・トランザクションに参加できます。
マネージド・データソースは、OC4Jの接続プールおよび文キャッシュを使用します。
マネージド・データソースから戻される接続は、OC4Jの接続プロキシでラップされます。
ネイティブ・データソースは、javax.sql.DataSourceインタフェースを実装しており、JDBCドライバ・ベンダー（オラクル社やDataDirect社など）により提供されます。ネイティブ・データソースとマネージド・データソースの相違点は、次のとおりです。
ネイティブ・データソースから取得された接続は、グローバル・トランザクションに参加できません。
ネイティブ・データソースは、OC4Jの接続プールまたは文キャッシュを使用しません。
ネイティブ・データソースから戻される接続は、OC4Jの接続プロキシでラップされません。
ネイティブ・データソースを構成する方法の詳細は、「ネイティブ・データソースの定義」を参照してください。
Application Server Controlコンソールは、データソースを管理するための主要ツールであり、データソースと接続プールの作成、データソースと接続プールの削除、既存のデータソースと接続プールの変更などの操作を実行できます。
データソースの設定に関する有用な情報は、Application Server Controlコンソールのオンライン・ヘルプを参照してください。
Application Server Controlコンソールでデータソースを変更すると、データソースの設定は、即座にそのアプリケーションのdata-sources.xmlファイルに永続化されます。
デフォルト・アプリケーションのデータソース構成ファイルは、$J2EE_HOME/config/data-sources.xmlです。
このファイルの各<data-source>タグは、JNDIにバインドされていてクライアント・コンポーネント（サーブレットやEJBなど）からアクセスできる1つのデータソースを示しています。
この項では、data-sources.xml構成ファイルのデータソース定義の例を示します。
データソースを定義する方法の詳細は、「データソース・オブジェクトの構成」を参照してください。
data-sources.xmlファイルの例は、「構成例」の項を参照してください。
構成に関する注意事項
データソースの追加、編集または削除を直接data-sources.xmlファイルで行った場合、その変更を実装するためにOC4Jを再起動する必要があります。
データソースの追加、編集または削除をApplication Server Controlコンソールで行った場合、その変更を実装するためにOC4Jを再起動する必要はありません。Application Server Controlコンソールでデータソース設定を保存するたびに、新規のdata-sources.xmlファイルが生成され、コメントは失われます。
data-sources.xmlファイルには、サンプルのデータソース・エントリおよび接続プール・エントリが含まれます。これらのエントリはサンプルとしてのみ使用され、削除できません。「サンプル・データソースの削除」を参照してください。
データソースのjndi-nameは、アプリケーションに対して一意である必要があります。同じdata-sources.xmlファイルに重複するJNDI名を含めることはできません。JNDIロケーションがdata-sources.xmlファイル内で重複していると、OC4Jによって例外がスローされます。グローバルなdata-sources.xmlファイルですでに指定済のアプリケーションのdata-sources.xmlファイルに、jndi-nameを指定することも可能です。この場合、そのアプリケーションのdata-sources.xmlに指定されたJNDIロケーションにより、アプリケーション・コンテキストのJNDIロケーションが上書きされます。
データソースを定義するには、<data-source>タグを使用します。class属性には、javax.sql.DataSourceインタフェースを実装するオブジェクトのフルパスのクラス名を設定できます。
一部の明確なプロパティ（user、password、urlなど）もこのタグで指定します。
OC4Jによって認識されないプロパティは、<property>タグで定義します。
OC4J固有の実装には、設定可能な追加のプロパティはありません。つまり、OC4Jのすべてのプロパティは、<data-source>タグの値を通じて設定します。
Oracle固有の実装（oracle.jdbc.pool.OracleDataSourceなど）には、<data-source>タグの<property>サブタグを通じて設定可能なプロパティがあります。
Oracle JDBCドライバの詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。
通常は、Oracle以外のベンダー固有の実装（DB2、Sybase、SQLServerなど）にも、<data-source>タグで定義するプロパティ以外に、<property>タグを使用して定義できるプロパティがあります。ユーザーは、Oracle以外のデータソース実装のプロパティを決定できます。
マネージド・データソースでは、接続を効率的に管理するため、接続プールを使用します。マネージド・データソースを作成する場合、少なくとも1つの接続プールと、そのコネクション・ファクトリを定義する必要があります。
OC4Jには、再利用可能な物理接続のキャッシュを保持することで効率性を高める接続プール機能があります。クライアントによって接続がクローズされると、その接続は、別のクライアントで使用できるようプールに戻されます。接続プールにより、複数のクライアントで少数の物理接続を共有できるため、パフォーマンスとスケーラビリティが向上します。
|
注意: 接続プールという語と接続キャッシュという語は、同じ意味です。 |
接続プールの性質および用途の詳細は、「マネージド・データソースでの接続プールの使用方法」を参照してください。
Application Server Controlコンソールでのコネクション・ファクトリおよび接続プールの設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→目的の設定にドリルダウン。
次の例で、Application Server Controlコンソールではなくdata-sources.xmlファイルで接続プールを定義する方法を示します。
<connection-pool name="myConnectionPool">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com"/>
<property name="foo" value="bar"/>
</connection-factory>
</connection-pool>
<connection-pool>要素には、接続プールを一意に識別するname属性が含まれます。他の属性では、接続プールで保持する接続の最大数など、接続プールのパラメータを定義します。接続プールは、<connection-factory>要素で定義されたコネクション・ファクトリを使用してデータベースから物理接続を取得します。
<connection-factory>要素には、JDBCドライバがデータベースに接続するためのURLと、データベースから接続を取得するためのオプションのデフォルト・ユーザーおよびパスワードが含まれます。factory-class属性では、接続を取得するJDBCドライバにより提供される実装クラスを定義します。実装クラスは、次のいずれかのインタフェースを実装する必要があります。
java.sql.Driver
javax.sql.DataSource
javax.sql.XADataSource
javax.sql.ConnectionPoolDataSource
接続プールおよびコネクション・ファクトリの設定の詳細は、表5-3「接続プールの属性」を参照してください。
1つ以上の接続プールを定義したら、マネージド・データソースを定義できます。
マネージド・データソース設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→「データソース」→「作成」→「アプリケーションの選択」→「データ・ソースのタイプを選択」→「管理対象」
次の例で、前に定義した接続プールを使用して、data-sources.xmlファイルでマネージド・データソースを定義する方法を示します。
<managed-data-source
jndi-name="jdbc/ManagedDS"
name="Managed DataSource Name"
connection-pool-name="myConnectionPool" />
name属性では、一意のマネージド・データソースを指定します。jndi-name属性では、このデータソースを配置するJNDIロケーションを定義します。connection-pool-name属性では、このマネージド・データソースが接続を取得するために通信する接続プールを指定します。この接続プール名は、前項の「接続プールの定義」の例に記載されている<connection-pool>要素のname属性の値に対応します。
ネイティブ・データソースは、接続プールに依存しません。そのため、ネイティブ・データソースの定義には、基礎となるデータベースと通信するのに必要なデータが含まれます。
ネイティブ・データソース設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→「データソース」→「作成」→「アプリケーションの選択」→「データ・ソースのタイプを選択」→「ネイティブ」
次の例で、data-sources.xmlファイルでネイティブ・データソースを定義する方法を示します。
<native-data-source
name="nativeDataSource"
jndi-name="jdbc/nativeDS"
data-source-class="com.acme.DataSourceImpl"
user="frank"
password="frankpw"
url="jdbc:acme:@localhost:5500:acme" />
データソース構成の追加の例は、http://www.oracle.com/technology/tech/java/newsletter/articles/oc4j_datasource_config.htmlにある資料「Data Source Configuration in Oracle Application Server 10g」を参照してください。
name属性では、一意のネイティブ・データソースを指定します。jndi-name属性では、このデータソースを配置するJNDIロケーションを定義します。data-source-class属性では、ネイティブ・データソースの実装クラスを定義します。このクラスは、javax.sql.DataSourceを実装している必要があります。userおよびpassword属性では、デフォルトのユーザーとパスワードを定義します。url属性では、データソースがデータベースと通信するためのURLを定義します。
data-sources.xmlで定義したデータソースごとに、そのデータソースの通信対象であるバックエンド・データベースにアクセスできないことを示す致命的エラー・コードを定義できます。OC4Jでこれらのエラー・コードのいずれかが検出されると（JDBCドライバによってSQLExceptionがスローされた場合）、その接続プールは削除されます。つまり、接続プールのすべての接続がクローズされます。Oracleで事前定義されている致命的エラー・コードは、3113、3114、1033、1034、1089および1090です。
Oracle以外のデータベースに致命的エラー・コードを定義する場合や、Oracleデータベースに別の致命的エラー・コードを追加する場合は、次の手順を使用します。
<connection-factory>要素のサブタグである<fatal-error-codes>要素を使用します。<fatal-error-codes>要素で、子要素の<error-code>を使用して1個の致命的エラー・コードを定義します。1つの<fatal-error-codes>要素に対して、0〜n個の<error-code>要素を定義できます。たとえば、致命的エラー・コードとして10、20、30を設定する場合、データソース定義は次のようになります。
<connection-pool name="myConnectionPool">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com">
<fatal-error-codes>
<error-code code='10'/>
<error-code code='20'/>
<error-code code='30'/>
</fatal-error-codes>
</connection-factory>
</connection-pool>
data-sources.xmlファイルには、認証用のパスワードが必要です。これらのパスワードをなんらかの形式で不明瞭化することなく埋め込むと、セキュリティ上のリスクが生じます。この問題を回避するため、OC4Jでは、パスワードの間接化をサポートしています。
間接パスワードは、特殊な間接化記号（->）とユーザー名（またはユーザー名とレルム）で構成されます。OC4Jは、間接パスワードを検出すると、ユーザー・マネージャが提供するセキュリティ・ストアから、指定のユーザーに関連付けられているパスワードを取得します。
ユーザーとパスワードの作成およびユーザー・マネージャの操作の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』のパスワード管理に関する項を参照してください。
たとえば、次のようなネイティブ・データソースのエントリがあるとします。
<native-data-source name="nativeDataSource" jndi-name="jdbc/nativeDS" data-source-class="com.acme.DataSourceImpl" user="frank" password="frankpw" url="jdbc:acme:@localhost:5500:acme" />
この場合、パスワードfrankpwは、間接化記号（->）とユーザー名（frank）を使用して、password="->frank"のように置き換えることができます。この操作は、ユーザー名frankとそのパスワードfrankpwがユーザー・マネージャに作成されていることを前提とします。
パスワードの間接化は、Application Server Controlコンソールで構成できます。
データソースの間接パスワードをdata-sources.xmlファイルに直接構成するには、password属性の値を->で始め、続けてユーザー名（またはスラッシュ（/）で区切ったレルムとユーザー名）を指定します。例:
<native-data-source name="nativeDataSource" jndi-name="jdbc/nativeDS" data-source-class="com.acme.DataSourceImpl" user="frank" password="->frank" url="jdbc:acme:@localhost:5500:acme" />
<managed-data-source>および<connection-factory>要素には、password属性もあります。
data-sources.xmlファイルには、サンプルの接続プール、およびデフォルトのデータソースとして使用されるマネージド・データソースのエントリが含まれます。これらの例は説明を目的として使用され、データソースを理解するために用意されています。
接続プールおよびデータソースの削除は、Application Server Controlコンソール（「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース: タスクに移動」）を使用するか、data-sources.xmlファイルから手動でエントリを削除することで実行できます。コンソールを使用する場合は、データソースを削除してから接続プールを削除します。
サンプルのデータソースを削除したら、default-data-source属性を使用して、新しいデフォルトのデータソースをJ2EE_HOME/application.xmlファイルに割り当てます。実行時に適切なデータソース構成が検出されない場合、このOC4Jインスタンスにデプロイされたすべてのアプリケーションは、デフォルトでこのデータソースに設定されます。ただし、OC4Jインスタンスを実行するためにはデフォルトのデータソースは不要です。
|
注意: 個々のアプリケーション・レベル（独自のapplication.xml）に定義されているデフォルトのデータソースは、このグローバルのデフォルトのデータソースより優先されます。 |
OC4Jのデータソースは、次の2つのタイプの接続を戻します。
マネージド接続: マネージド・データソースから戻される接続は、接続プールから取得され、プロキシ・クラスでラップされます。そのため、OC4Jでは、SQLエラーを処理することや、これらの接続をグローバル・トランザクションに登録することができます。「マネージド・データソースでの接続プロキシの使用方法」を参照してください。
ネイティブ接続: ネイティブ・データソースから戻された接続は、OC4Jでは操作できません。つまり、この接続はラップされていない状態であり、関連付けられたプロキシもなく、グローバル・トランザクションにも参加できません。
データソースでは、データベースと通信することで接続を生成します。通常、データソースでは、データベースとの通信に使用するマシン、ポート、データベース名などの識別にURLを使用します。
マネージド・データソースのURLは、そのマネージド・データソースの接続プールのコネクション・ファクトリで定義します。コネクション・ファクトリのurl属性により、データベースとの通信に使用するURLを定義します。JDBCドライバでは、URLの書式を定義しています。このドキュメント全体を通じて、いくつかのURLの例が記載されています。
ネイティブ・データソースのURLは、<native-data-source>要素のurl属性で定義します。
基本的なデータソース実装では、クライアントの接続オブジェクトと物理接続の間に1対1の対応関係があります。通常、クライアントが接続をクローズすると、物理接続は削除されます。この場合、クライアントがデータソースから接続を取得するたびに、多くのオーバーヘッドが生じます。
OC4Jのマネージド・データソースでは、接続プールを頻繁に使用します。
接続プールは、複数のマネージド・データソースによって使用できます。つまり、複数のマネージド・データソースで同じ接続プールを共有できます。
Oracle10g JDBCドライバを使用するようデータソースを定義すると、OC4Jでは、このドライバに付属するImplicit Connection Cache（ICC）により提供される高機能な接続プールが使用されます。OC4Jデータソースでは、自動的にICCが使用されます。ICCを無効化する方法は、「ICCの無効化」を参照してください。特に指定のないかぎり、表5-3「接続プールの属性」に記載されたすべての接続プール属性がICCに適用されます。一部の属性は、Implicit Connection Cache対応のデータソース（OracleDataSourceおよびOracleXADataSource）にのみ適用されます。ICCを使用するために追加の構成を実行する必要はありません。
接続プール構成設定の詳細は、表5-3「接続プールの属性」を参照してください。
接続プールは、Oracle以外のJDBCドライバや旧リリースのOracle JDBCドライバでも使用できます。接続プール構成の例は、「構成例」の項を参照してください。
マネージド・データソースを使用する場合、接続プールから取得される各接続は、OC4Jによりプロキシ・オブジェクトでラップされます。このプロキシにより、OC4Jでは、トランザクション登録、例外処理およびロギングが可能になります。
ベンダー固有の拡張
クライアントでは、java.sqlインタフェースのベンダー実装により提供される拡張インタフェースも使用できます。たとえば、java.sql.ConnectionインタフェースのOracle拡張は、oracle.jdbc.OracleConnectionです。このインタフェースにより、java.sql.Connectionインタフェースには含まれないOracle固有のAPIが提供されます。OC4Jには、プロキシが実装するインタフェースを制限するための構成要素があり、クライアントのアクセス先をこれらのAPIに限定できます。この構成要素は、任意のjava.sql.*インタフェースの追加インタフェースを指定するために使用できます。デフォルトでは、プロキシは、基礎となるオブジェクトにより実装されている任意のpublicインタフェースを実装します。
プロキシの設定方法の詳細は、表5-3「接続プールの属性」を参照してください。
次の例で、Application Server Controlコンソールではなくdata-sources.xmlファイルで接続プールの接続プロキシと文プロキシを定義する方法を示します。
<connection-pool name="myConnectionPool">
<connection-factory
factory-class="com.acme.AcmeDataSource"
user="scott"
password="tiger"
url="jdbc:acme:@localhost:1234:acme">
<property name="foo" value="bar"/>
<proxy-interface sql-object="Connection"
interface="com.acme.AcmeConnection"/>
<proxy-interface sql-object="CallableStatement"
interface="com.acme.AcmeCallableStatement"/>
</connection-factory>
</connection-pool>
この例において、Connectionオブジェクト用に生成されるプロキシは、基礎となる接続オブジェクトによって実装されるインタフェースにかかわらず、com.acme.AcmeConnectionインタフェースのみを公開します。同様に、Statementオブジェクト用に生成されるプロキシは、com.acme.AcmeStatementインタフェースのみを公開します。データソースのデプロイヤは、この方法により、プロキシ・オブジェクトによって公開されるインタフェースを制限できます。
この項では、データソースから接続を取得して文を実行するためのサンプル・コードを示します。
|
注意: 例外がスローされる場合でも、データソースから取得した接続は必ずクローズしてください。 ルックアップの実行に使用する文字列は、マネージド・データソースまたはネイティブ・データソースのJNDIロケーションを示す |
Connection connection = null;
try {
InitialContext context = new InitialContext();
DataSource ds = (DataSource) context.lookup( "jdbc/ManagedDS" );
connection = ds.getConnection();
Statement statement = connection.createStatement();
statement.execute( "select * from dual" );
statement.close();
}
catch( Exception exception ) {
// process exception
}
finally {
if ( connection != null )
{
try {
connection.close();
}
catch( SQLException sqlException ){}
}
}
|
注意: ユーザーとパスワードを渡さずに コネクション・ファクトリでユーザーとパスワードを指定する方法は、表5-4「コネクション・ファクトリの属性」を参照してください。 コネクション・ファクトリのプロパティの詳細は、「コネクション・ファクトリのプロパティ」を参照してください。 |
一定の状況下では、データソースにより接続を戻すことができない場合があります。この最も一般的な原因は、接続プールのすべての接続が使用中であることです。データソースを一定時間待機させた後に接続プールをチェックして、接続を戻す前に使用可能な接続があるかどうかを確認できます。
接続プールの構成設定には、プールの接続が使用できない場合の待機時間を制御する設定と、接続プールに接続が存在するかどうかを問い合せる試行の回数を制御する設定の2つがあります。
max-connect-attempts設定では、（接続プールのすべての接続が使用中の場合に）マネージド・データソースで接続プールから接続を取得する操作を再試行する回数を定義します。connection-retry-interval設定では、接続プールからの接続の取得に最後に失敗した後、次の取得操作を再試行するまでに待機する間隔を秒単位で指定します。これらの設定の詳細は、「接続プールの属性」を参照してください。
次の例で、Application Server Controlコンソールではなくdata-sources.xmlで再試行を構成する方法を示します。この例では、max-connect-attemptsを5回に、connection-retry-intervalを3秒に設定します。
<connection-pool name="myConnectionPool"
max-connect-attempts="5"
connection-retry-interval="3">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com"/>
</connection-pool>
OC4Jでは、処理と格納用にOracleデータベースを使用するアプリケーションや中間層のセキュリティおよびパフォーマンス向上のために使用する、次の2つのタイプのOracleデータベース接続セッションがサポートされます。
プロキシ・セッション: プロキシ・セッションを使用すると、クライアント・ユーザーはアプリケーション・サーバーを介して、プロキシ・ユーザーとしてデータベースに接続できます。アプリケーション・サーバーはOracleデータベースを使用して、プロキシ・ユーザーとして自身を認証しますが、クライアント・ユーザーは、アプリケーション・サーバーを使用して自身を認証します。この方法で確立されたプロキシ接続では、データベースに接続するまで同じクライアント・ユーザー名が使用されます。
軽量セッション: 軽量セッションを使用すると、クライアント・ユーザーは、アプリケーションだけに関連する情報を含むセッションを作成できます。このセッションは、トランザクションやカーソルなどのリソースに関連付けられないため、軽量であるとみなされます。軽量ユーザー・セッションが消費するサーバー・リソースは従来のデータベース・セッションに比べてはるかに少ないため、軽量ユーザー・セッションを各ユーザー専用にし、アプリケーションで必要とみなされるかぎり、ユーザーがデータベース・サーバー上で永続化することが可能です。
これらの機能の詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。
プロキシ・セッションは、使用されているのがマネージド・データソースであるかネイティブ・データソースであるかによって、異なる方式で有効化されます。マネージド・データソースの場合、プロキシは、接続プールの構成時に、宣言的に有効化されます。ネイティブ・データソースの場合、プロキシ・セッションは、Oracleの接続APIを介してプログラムによって有効化する必要があります。
プロキシ・セッションでは、アプリケーション・ユーザーがデータベースに存在し、適切なCONNECT THROUGH権限を付与されている必要があります。例:
ALTER USER admin_user GRANT CONNECT THROUGH user
プロキシ・セッションは、proxy-sessions属性を使用して、接続プール内部で有効化されます。プロキシ・セッションはデフォルトでは無効です。プロキシ・セッションが有効化されると、OC4Jは、プールで接続リクエストが作成されるたびに、アプリケーションで認証されたユーザーの接続上でプロキシ・セッションを開きます。その後プロキシ・セッションは、接続がプールに返されるときにクローズされます。
次の例は、マネージド・データソースの場合のプロキシ・セッションの有効化を示しています。簡単にするために、例では、Application Server Controlでなくdata-sources.xmlファイルを使用しています。
<managed-data-source name="OracleDS"
connection-pool-name="Example Connection Pool"
jndi-name="jdbc/OracleDS"/>
<connection-pool name="Example Connection Pool"
max-connections="100"
min-connections="20"
num-cached-statements="10"
proxy-sessions="true">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="user"
password="password"
url="jdbc:oracle:thin:@localhost:5521:main">
</connection-factory>
</connection-pool>
JDBC/OC4Jでは、プロキシ・セッションの作成を可能にする、OracleConnectionインタフェースのopenProxySessionメソッドが公開されています。このメソッドが既存の信頼できるユーザー接続/セッションで起動されると、2つ目のプロキシ・セッションが作成され、その信頼できるユーザーのセッションが一時停止されます。中間層のサブシステムの多くで大規模な変更が必要なため、OC4Jまたはトランザクション・マネージャでXAおよび2セッション・アーキテクチャのプロキシ・セッションをサポートすることはできません。これらの変更は間違いやすく、リスクも伴います。
次の例は、OracleConnectionインタフェースを使用した、プログラムによるプロキシ・セッションの構成を示します。
InitialContext ic = new InitialContext();
DataSource nativeDS = (DataSource) ic.lookup(NATIVE_DS_NAME);
OracleConnection oconn = (OracleConnection)
nativeDS.getConnection(PROXY_USER_NAME, PROXY_USER_PWD);
strBuf.append("Obtained a connection using getConnection(" +
PROXY_USER_NAME + ", " + PROXY_USER_PWD + ")\n");
strBuf.append("isProxySession: " + oconn.isProxySession() + "\n");
strBuf.append("Check user name before opening the proxy session\n");
strBuf.append(checkUser(oconn));
// Specify the user that connects through the proxy user and its roles
Properties prop = new Properties();
prop.put(OracleConnection.PROXY_USER_NAME, USER_NAME);
prop.put(OracleConnection.PROXY_ROLES, roles);
// Open the proxy session (DB-authenticated users)
oconn.openProxySession(OracleConnection.PROXYTYPE_USER_NAME, prop);
strBuf.append("Opened a proxy session for " + USER_NAME + " through " +
PROXY_USER_NAME + " using openProxySession()\n");
strBuf.append("isProxySession: " + oconn.isProxySession() + "\n");
// Now test using the proxy-connection
strBuf.append("### Testings using the proxy session ###\n");
String resultStr = testAndGetResultString(oconn);
strBuf.append(resultStr);
strBuf.append("Closing the proxy session ...\n");
oconn.close(OracleConnection.PROXY_SESSION);
strBuf.append("isProxySession: " + oconn.isProxySession() + "\n");
strBuf.append("Check user name after closing the proxy session\n");
strBuf.append(checkUser(oconn));
strBuf.append("Closing the original connection ...\n");
oconn.close();
軽量セッションは、light-weight-sessions属性を使用して、接続プール内部で有効化されます。軽量セッションはデフォルトでは無効です。軽量セッションが有効化されると、OC4Jは、プールで接続リクエストが作成されるたびに、アプリケーションで認証されたユーザーの接続上で軽量セッションをアタッチします。その後軽量セッションは、接続がプールに返されるときに接続からデタッチされます。
次の例は、マネージド・データソースの場合の軽量セッションの有効化を示しています。簡単にするために、例では、Application Server Controlでなくdata-sources.xmlファイルを使用しています。
<managed-data-source name="OracleDS"
connection-pool-name="Example Connection Pool"
jndi-name="jdbc/OracleDS"/>
<connection-pool name="Example Connection Pool"
max-connections="100"
min-connections="20"
num-cached-statements="10"
light-weight-sessions ="true">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="user"
password="password"
url="jdbc:oracle:thin:@localhost:5521:main">
</connection-factory>
</connection-pool>
マネージド・データソースには、文の操作をより効率的に実行するためのキャッシング機能とプロキシ機能があります。
文キャッシュにより、繰り返し使用される実行可能文がキャッシュされるため、パフォーマンスが向上します。また、プログラマは、プリコンパイルされた文を明示的に再利用する必要がなくなります。文キャッシュを使用することで、カーソル作成の繰返しや文の解析と作成の繰返しに起因するオーバーヘッドを排除できると同時に、アプリケーション・サーバーとデータベース・サーバー間の通信により発生するオーバーヘッドも削減できます。文キャッシュの特徴は、次のとおりです。
文のキャッシュと再利用は、アプリケーションには透過的に動作します。
各文キャッシュは、物理接続に関連付けられます。つまり、物理接続ごとに独自の文キャッシュを保持します。
文の一致条件は、次のとおりです。
文のSQL文字列は、キャッシュ内の文字列と同一である必要があります（大/小文字も区別されます）。
文のタイプ（preparedまたはcallable）は、同一である必要があります。
文により生成される結果セットのスクロール可能タイプ（forward-onlyまたはscrollable）は、同一である必要があります。
キャッシュする文の最大数
カーソル作成の繰返しや文の解析と作成の繰返しによるオーバーヘッドを削減するため、データベース文で文キャッシュを使用できます。JDBC文のキャッシング機能を有効化して繰り返し使用される実行可能文をキャッシュするには、文キャッシュを使用するようデータソースを構成します。JDBC文のキャッシュは、データソースで管理されている特定の物理接続と関連付けられます。文キャッシュは、データソースに関連付けられていないため、すべての物理接続で共有することはできません。JDBC文のキャッシュは、データベース・サーバーではなく中間層で管理されます。
文キャッシュの有効化と無効化をプログラムで動的に切り替えるには、接続オブジェクトのsetStmtCacheSize()メソッドを使用します。
データソースでJDBC文のキャッシング機能を構成するには、num-cached-statements属性を使用してキャッシュのサイズを設定します。この属性では、キャッシュに配置する文の最大数を設定します。num-cached-statements属性を指定しないか、0に設定した場合、文キャッシュは無効化されます。
次のXMLでは、文のキャッシュ・サイズを200文に設定します。
<data-source> ... num-cached-statements="200" </data-source>
num-cached-statements属性を設定するには、まずアプリケーションがデータベースに発行する個別の文の数を決定します。次に、キャッシュのサイズをその数に設定します。アプリケーションがデータベースに発行する文の数がわからない場合は、JDBCのパフォーマンス・メトリックを使用すると文のキャッシュ・サイズの決定に役立ちます。文メトリックを使用するには、OC4JでJavaプロパティのoracle.jdbc.DMSStatementMetricsをtrueに設定する必要があります。
|
注意: データソースでJDBC文のキャッシング機能を構成するには、num-cached-statements属性を使用してキャッシュのサイズを設定します。stmt-cache-size属性は非推奨です。 |
文のキャッシュ・サイズのリソース問題
データソースにnum-cached-statementsを指定しても、文はデータソースや接続プールごとにではなく、接続ごとにキャッシュされます。つまり、特定のデータソースのnum-cached-statementsが0より大きい場合、そのデータソースから取得されたマネージド接続ごとに独自の文キャッシュが保持されます。
接続の文キャッシュに保持されている文は、データベース・リソースを解放しない可能性があることに注意してください。オープンしている接続の数と、接続ごとにキャッシュされている文の数の合計が、データベースに許可されたオープン・カーソルの制限を超える可能性があります。num-cached-statementsの値を減らすか、データベースに許可されたオープン・カーソルの制限を増やすことで、この問題を回避できる場合があります。
java.sql.*インタフェース（マネージド・データソース）のすべての実装は、OC4Jによりプロキシ・オブジェクトでラップされます。これには、文オブジェクト（java.sql.Statement、java.sql.PreparedStatementおよびjava.sql.CallableStatement）も含まれます。
プロキシの設定方法の詳細は、表5-3「接続プールの属性」に記載されているコネクション・ファクトリの「プロキシ・インタフェース」タブの説明を参照してください。
一定の状況下では、接続プロキシが新しい物理接続にリバインドされる場合があります。これは、接続プロキシが1つのトランザクション全体で使用される場合などに発生します。リバインドが発生すると、接続プロキシを通じて取得された文オブジェクトは、古い物理接続を使用して作成されているため、すべて無効になります。このため、物理接続から取得される文オブジェクトに対しても、プロキシが配置されます。これらの文プロキシは、基礎となる物理接続との関連を監視できるように、取得元の接続プロキシと関連付けられます。文プロキシにより、接続プロキシに関連付けられた物理接続が変化したと判断されると、接続プロキシから新しい物理文が取得されます。
java.sql.Statement、java.sql.PreparedStatementおよびjava.sql.CallableStatementインタフェースのベンダー固有の拡張も、接続と同じ方法によりクライアントで使用できます。
J2EEでは、次の2種類のトランザクションがサポートされます。
ローカル・トランザクション: ローカル・トランザクションは、単一のリソースの内部で実行されます。
グローバル・トランザクション: グローバル・トランザクションは、外部のトランザクション・マネージャによって作成され、複数のリソースを操作対象として実行されます。
ローカル・トランザクションとグローバル・トランザクションを含むトランザクション・サポートの詳細は、第5章「データソース」を参照してください。
ローカル・トランザクション用に構成されたマネージド・データソースは、ローカル・トランザクションに参加できるがグローバル・トランザクションには参加できない接続を戻します。つまり、その接続は、グローバル・トランザクションに登録されません。データソースは、取得した接続の自動コミットをtrueに設定します。ただし、ローカル・トランザクションでその接続をどのように使用するかを決定するのは、クライアントです。クライアントは、接続に対してsetAutoCommit()を使用することで、自動コミット・モードを変更できます。
マネージド・データソースをローカル・トランザクション用に設定する方法は、表5-1「マネージド・データソースの設定」に記載されている「トランザクション・レベル」の設定を参照してください。
Application Server Controlコンソールではなくdata-sources.xmlファイルでデータソースをローカル・トランザクション用に構成するには、tx-level属性をlocalに設定します（デフォルト値はglobalです）。例:
<managed-data-source jndi-name="jdbc/ManagedDS" name="Managed DataSource Name" connection-pool-name="myConnectionPool" tx-level="local" />
ネイティブ・データソースは、ローカル・トランザクションにのみ参加できるため、ネイティブ・データソース用のトランザクション・サポートの設定はありません。
localとしてマーク付けされた接続を、グローバル・トランザクションの内部で使用することも可能です。このケースは、JDBC仕様で具体的に言及されているわけではありませんが、仕様には、接続が分散トランザクションに参加しない場合、その接続はローカル接続のように振る舞うという意味の記載があります。接続がグローバル・トランザクションに登録されない場合、その接続はグローバル・トランザクションに参加しません。したがって、local transactionで構成されたデータソースにより生成される接続は、たとえグローバル・トランザクションの内部でその作業が実行される場合でも、ローカル・トランザクションの内部に存在するかのように扱われます。つまり、自動コミットがfalseに設定されている場合、このような接続で実行される作業は、その接続でcommitやrollbackがコールされるまでコミットまたはロールバックされません。この動作は、分散トランザクションでコミットまたはロールバックが実行される場合でも同様です。このケースでは、接続は、構文的にトランザクション境界を伴って出現するだけで、意味的にはそのトランザクションに参加しません（つまり、この接続は登録されません）。
例:
ローカル・トランザクション用に構成されたデータソースから接続lcを取得します。
グローバル・トランザクションを開始します。
グローバル・トランザクション用に使用できるデータソースから接続gcを取得します。
両方の接続上で作業を実行します。
lc上で処理される作業は、その作業が実行されるか（自動コミットがtrueの場合）、lc上でcommitやrollbackがコールされると（自動コミットがfalseの場合）コミットされます。
グローバル・トランザクションをコミットまたはロールバックします。
gc上の作業は、この時点でコミットまたはロールバックされます。lc上の作業は、コミットされません。
lc上の作業は、その接続でcommitまたはrollbackをコールすることでコミットまたはロールバックできます（自動コミットがfalseに設定されている場合）。
次のコード例では、前述の手順を実装します。
Connection lc = localTxDataSource.getConnection(); userTransaction.begin(); Connection gc = globalTxDataSource.getConnection(); lc.doWork(); gc.doWork(); userTransaction.commit(); // At this point work done on gc is now committed. //The work done on lc is NOT yet committed. lc.commit(); // At this point work done on lc is now committed.
通常、ローカル・トランザクションは、クライアントが接続上でautoCommitをfalseに設定すると開始し、クライアントが同じ接続上でcommit()またはrollback()をコールすると終了します。autoCommitがfalseで、トランザクション作業が実行されていない場合、接続で明示的にcommit()またはrollback()をコールする必要はありません（トランザクション作業が実行されていないためにコミットやロールバックが不要であることは、ドライバにより正しく認識されます）。
OC4Jは、autoCommitがfalseであり、かつcommit()、rollback()、setAutoCommit(true)またはclose()以外の任意のメソッドが接続上でコールされると、アクティブなローカル・トランザクションがその接続に存在すると判断します（ただし、OC4Jは、接続上で処理される作業が実際にトランザクション形式の作業であるかどうかは判断できません）。commit()やrollback()のコール、またはautoCommitの値の変更が発生すると、現在のローカル・トランザクションは終了します。autoCommitがfalseであり、かつcommit()、rollback()、setAutoCommit(true)またはclose以外のメソッドが引き続き接続上でコールされると、OC4Jは、それを新しいローカル・トランザクションの開始と判断します。
クライアントが接続で（commit()、rollback()またはsetAutoCommit(true)をコールして）明示的にローカル・トランザクションを終了しない場合については、次の2つのケースを検討する必要があります。
第1のケース: アクティブなローカル・トランザクションが存在し、接続がユーザーによってクローズされる場合。
第2のケース: アクティブなローカル・トランザクションが存在し、接続がグローバル・トランザクションで使用される場合。
OC4Jでは、次の2つの方法でこれらのケースを処理できます。
接続がクローズされるか、グローバル・トランザクションで使用される場合に、OC4Jでローカル・トランザクションを管理および調整します。具体的には、OC4Jは、commit()またはrollback()をコールして暗黙的にローカル・トランザクションを終了します。また、OC4Jでは、接続がクローズされるか、グローバル・トランザクションで使用される場合に例外をスローできます。
OC4Jでローカル・トランザクションを管理せず、これらのケースを調整しません。具体的には、接続がクローズされるか、グローバル・トランザクションで使用される場合に、リソース側でローカル・トランザクションを終了する方法（または終了しない方法）を決定する必要があります。ローカル・トランザクションを管理しないようOC4Jを構成している場合、接続が接続プールに戻されたときに、コミットされていないローカル・トランザクションがアクティブになっている可能性があることに注意してください。
グローバル・トランザクション用に構成されたマネージド・データソースは、グローバル・トランザクションに参加できる接続を戻します。グローバル・トランザクション（分散トランザクション）では、トランザクションに複数のリソースが登録されます。
未処理のJ2CAローカル・トランザクションが存在する場合に、トランザクション・マネージャでグローバル・トランザクションを処理する方法の詳細は、「ローカル・トランザクション管理」を参照してください。
トランザクションの詳細は、第3章「OC4Jトランザクション・サポート」を参照してください。
マネージド・データソースをグローバル・トランザクション用に設定する方法は、表5-1「マネージド・データソースの設定」に記載されている「トランザクション・レベル」の設定を参照してください。
Application Server Controlコンソールではなくdata-sources.xmlファイルでデータソースをローカル・トランザクション用に構成するには、tx-level属性を含めないか（デフォルト値はglobalです）、tx-level属性をglobalに設定します。例:
<managed-data-source jndi-name="jdbc/ManagedDS" name="Managed DataSource Name" connection-pool-name="myConnectionPool" tx-level="global" />
グローバル・トランザクションが失敗した場合、トランザクション・マネージャでXAリカバリを実行する必要があります。この場合、リカバリするリソースごとにいくつかの情報を定義しておく必要があります。データソースでは、factory-classにjavax.sql.XADataSourceを使用するコネクション・ファクトリごとに、リカバリ用のusernameとpasswordを定義します。
表5-3「接続プールの属性」に記載されている「ユーザー」および「パスワード」の設定を参照してください。
次の例で、Application Server Controlコンソールではなくdata-sources.xmlファイルでXAリカバリを構成する方法を示します。xa-recovery-configノードに注意してください。
<connection-pool name="myConnectionPool">
<connection-factory
factory-class="oracle.jdbc.xa.client.OracleXADataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com">
<xa-recovery-config>
<password-credential>
<username>system</username>
<password>manager</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
|
注意:
|
エミュレートされたXAResourceは、XAプロトコルのセマンティックをエミュレートするjavax.sql.XAResourceの実装です。グローバル・トランザクション中、エミュレートされたXAResourceに関連付けられた接続は、グローバル作業ユニットのサブセットとして明示的に制御されるトランザクション・ブランチではなく、ローカル・トランザクションを使用してXAのセマンティックに準拠します。
javax.sql.XADataSourceの実装を提供しないJDBCドライバをサポートする場合は、XAResourceをエミュレートする必要があります。エミュレートされたXAResourceは、実際の2フェーズ・コミットに関連するオーバーヘッドによるパフォーマンス上の影響を受けないため、本物のXAResourceより高速に動作します。
エミュレートされたXAResourceを使用する場合、複数のXAResourceを登録し、少なくともその1つをエミュレートすると、一貫性のない状態やリカバリ不可能な状態が発生することがあります。エミュレートされたXAResourceは、準備フェーズ中にローカル・トランザクションを使用するため、正しい準備を実行できないのがその理由です。これが問題となる1つの例としては、エミュレートされたXAResourceでcommitがコールされたときに、そのローカル・トランザクションがすでにタイムアウトしており、結果としてローカル・トランザクションのコミットに失敗し、トランザクション全体が一貫性のない状態に陥ることがあります。
OC4Jでは、XA動作をエミュレートする状況が自動的に判別されます。これは、コネクション・ファクトリのfactory-classオブジェクトを内部監視することで実行されます（factory-class属性では、接続プール用の接続を作成するためのコネクション・ファクトリで使用するオブジェクトを指定します）。このオブジェクトがjavax.sql.XADataSourceのインスタンスであれば、XAはエミュレートされません。このオブジェクトがjava.sql.Driver、javax.sql.DataSourceまたはjavax.sql.ConnectionPoolDataSourceのインスタンスである場合、このデータソースでXA動作がエミュレートされます。
この項では、Application Server Controlコンソールで設定するか、data-sources.xmlファイルで直接設定するかを問わず、様々なデータソース関連オブジェクトの構成設定とその説明を示します。
各設定は、次の表に記載されています。
データソース・オブジェクトを構成する方法の詳細は、「データソースの定義」を参照してください。
マネージド・データソースを定義するには、1つ以上の接続プールを定義する必要があります。
マネージド・データソース設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→「データソース」→「作成」→「アプリケーションの選択」→「データ・ソースのタイプを選択」→「管理対象」
1つの<managed-data-source>タグで、1つのマネージド・データソースを定義します。
各属性の詳細は、表5-1「マネージド・データソースの設定」を参照してください。
次の例で、data-sources.xmlのマネージド・データソースの定義を示します。
<managed-data-source jndi-name="jdbc/ManagedDS" name="Managed DataSource Name" connection-pool-name="myConnectionPool"/>
表5-1「マネージド・データソースの設定」
| Application Server Controlコンソールのプロパティ | <managed-data-source>の属性 | 説明 |
|---|---|---|
|
名前 |
|
必須。データソースの名前。この値は、一意である必要があります。 この名前は、 |
|
JNDIロケーション |
|
必須。データソース・オブジェクトのJNDI論理名。OC4Jでは、データソースのインスタンスが、この値を持つアプリケーションJNDIネームスペースにバインドされます。 |
|
接続プール |
|
必須。このマネージド・データソースで接続を取得するのに使用する接続プールの名前。 |
|
スキーマ |
|
EJBのOrion CMP実装の使用時における、このデータソースのデータベース・スキーマへのパス。これは、下位互換性を目的として提供されています。 |
|
トランザクション・レベル |
|
このマネージド・データソースでサポートされるトランザクション・レベル。 値 値 オプション。デフォルトは、 |
|
ローカル・トランザクション管理 |
|
OC4Jでローカル・トランザクションを管理するかどうかを指定します。
オプション。デフォルトは、 |
|
SQLオブジェクト管理 |
|
OC4Jで 値 値 値 オプション。デフォルトは、 |
|
ログイン・タイムアウト |
|
データベースへの接続試行時にこのデータソースが待機する最大時間（秒単位）。値 オプション。デフォルトは、 |
|
ユーザー |
|
データベースへの接続に使用するデフォルト・ユーザー。 オプション。デフォルトはありません。 |
|
パスワード |
|
データベースへの接続に使用するデフォルト・パスワード。 オプション。デフォルトはありません。 |
ネイティブ・データソース設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→「データソース」→「作成」→「アプリケーションの選択」→「データ・ソースのタイプを選択」→「ネイティブ」
ネイティブ・データソースは、接続プールに依存しません。そのため、ネイティブ・データソースの定義には、基礎となるデータベースと通信するのに必要なデータが含まれます。
1つの<native-data-source>タグで、1つのネイティブ・データソースを定義します。
ネイティブ・データソースの設定は、表5-2「ネイティブ・データソースの設定」を参照してください。
1つのnative-data-sourceタグには、0個以上のpropertyタグを指定できます。各propertyタグでは、ネイティブ・データソース・インスタンスのプロパティを定義します。ネイティブ・データソース・オブジェクトでは、プロパティ値の設定にリフレクションが使用されます。プロパティ名は、そのプロパティを設定するためのsetterメソッドの名前と一致する必要があります（大/小文字も区別されます）。たとえば、コネクション・ファクトリ・オブジェクトにMyPropというプロパティが存在する場合、そのプロパティを設定するためにsetMyProp()というメソッドがコールされます。したがって、プロパティを正しく設定するためには、propertyタグの名前がMyPropである必要があります。
<native-data-source name='My Native DataSource' jndi-name='jdbc/nativeDs' data-source-class='com.acme.DataSourceImpl' user='frank' password='frankpw' url='jdbc:acme:@localhost:5500:acme'> <property name="foo" value="bar" /> </native-data-source>
データソース構成の追加の例は、http://www.oracle.com/technology/tech/java/newsletter/articles/oc4j_datasource_config.htmlにある資料「Data Source Configuration in Oracle Application Server 10g」を参照してください。
表5-2 ネイティブ・データソースの設定
| Application Server Controlコンソールのプロパティ | <managed-data-source>の属性 | 説明 |
|---|---|---|
|
名前 |
|
必須。データソースの名前。この値は、一意である必要があります。 |
|
JNDIロケーション |
|
必須。データソース・オブジェクトのJNDI論理名。OC4Jでは、データソースのインスタンスが、この値を持つアプリケーションJNDIネームスペースにバインドされます。 |
|
データ・ソース・クラス |
|
必須。データソース・クラス実装の名前とパス。このクラスは、 |
|
URL |
|
必須。データベースに接続するためにJDBCドライバにより使用されるURL。URLでは、通常、データベース・ホスト・マシン、ポートおよびデータベース名を指定します。たとえば、 |
|
ログイン・タイムアウト |
|
データベースへの接続試行時にこのデータソースが待機する最大時間（秒単位）。値 オプション。デフォルトは、 |
|
ユーザー |
|
データソースへの接続に使用するデフォルト・ユーザー。 オプション。デフォルトはありません。 |
|
パスワード |
|
データソースへの接続に使用するデフォルト・パスワード。 オプション。デフォルトはありません。 |
コネクション・ファクトリおよび接続プールの設定へのパス
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JDBCリソース」→「タスクに移動」→「接続プール」→目的の設定にドリルダウン。
connection-factoryタグでは、データソースの接続を作成するためのコネクション・ファクトリを定義します。
factory-classがjavax.sql.XADataSourceの実装である場合、コネクション・ファクトリから取得された接続は、グローバル・トランザクションに参加できます。この接続は、XA機能をエミュレートしません。factory-classがjavax.sql.XADatatSourceの実装ではない場合、コネクション・ファクトリから取得された接続は、グローバル・トランザクションへの参加時にXA動作をエミュレートします。
1つの<connection-factory>タグには、0個以上の<property>タグを指定できます。各<property>タグでは、コネクション・ファクトリ・インスタンスのプロパティを定義します。
コネクション・ファクトリがjava.sql.Driverの実装である場合、これらの各ドライバ・プロパティは、データベースからの接続の取得時にドライバによって使用されるjava.util.Propertiesオブジェクトに配置されます。
コネクション・ファクトリがjavax.sql.DataSource、javax.sql.ConnectionPoolDataSourceまたはjavax.sql.XADataSourceの実装である場合、プロパティ値を設定するためにコネクション・ファクトリ・オブジェクトでリフレクションが使用されます。
プロパティ名は、そのプロパティを設定するためのsetterメソッドの名前と一致する必要があります（大/小文字も区別されます）。たとえば、コネクション・ファクトリ・オブジェクトにMyPropというプロパティが存在する場合、そのプロパティを設定するためにsetMyProp()というメソッドがコールされます。したがって、プロパティを正しく設定するためには、propertyタグの名前がMyPropである必要があります。
|
注意: コネクション・ファクトリでは、次の例のように、属性とプロパティに2つの異なるユーザーとパスワードの組合せを指定できます。この例の場合、
<connection-factory user="scott1" password="tiger1" ...>
<property name="user" value="scott2" />
<property name="password" value="tiger2" />
</connection-factory>
|
1つの<connection-factory>タグには、0個以上の<proxy-interface>タグを指定できます。
各プロキシ・インタフェースは、コネクション・ファクトリから戻される接続オブジェクトと、それらの接続オブジェクトにより作成されるjava.sql.*オブジェクトをラップするプロキシによって実装されます。
SQLオブジェクト設定で、プロキシ・インタフェースの定義対象となるjava.sql.*オブジェクトを指定します。これは、次のいずれかである必要があります。
Array
Blob
CallableStatement
Connection
DatabaseMetaData
ParameterMetaData
PreparedStatement
Ref
resultSet
ResultSetMetaData
Savepoint
SQLData
SQLInput
SQLOutput
Struct
Statement
インタフェース属性で、このオブジェクトのプロキシが実装するインタフェースの完全修飾パスを定義します。
各SQLオブジェクトに対して複数のプロキシ・インタフェースを定義できます。
<xa-recover-config>タグでは、グローバル・トランザクションの失敗時にトランザクション・マネージャでリカバリを実行するために必要な情報を定義します。<username>サブタグでは、リカバリの実行時に使用するユーザー名を定義します。<password>サブタグでは、リカバリの実行時に使用するパスワードを定義します。
<connection-properties>タグでは、コネクション・ファクトリがoracle.jdbc.pool.OracleDataSourceのインスタンス（oracle.jdbc.pool.OracleDataSourceから導出されるインスタンスを含む）である場合にコネクション・ファクトリに設定する接続プロパティを定義します。各接続プロパティは、<property>サブタグで定義します。<connection-properties>タグには、0〜N個の<property>サブタグを定義できます。
マネージド・データソースでは、接続を効率的に管理するため、接続プールを使用します。マネージド・データソースを作成する場合、少なくとも1つの接続プールと、そのコネクション・ファクトリを定義する必要があります。
<connection-pool>タグで、1つの接続プールを定義します。
各<connection-pool>タグには、<connection-factory>タグが1つ含まれる必要があります。
表5-3 接続プールの属性
| Application Server Controlコンソールの設定 | <connection-pool>の属性 | 説明 |
|---|---|---|
|
名前 |
|
必須。接続プールの名前。この値は、一意である必要があります。 |
|
最小接続数 |
|
接続プールで保持する接続の最小数。 オプション。デフォルトは、
たとえば、 |
|
最大接続数 |
|
接続プールで保持する接続の最大数。 値
負の値を指定すると、接続プールは有効になり、最大数の制限がなくなります。 オプション。デフォルトは、無制限です。 セッションの開始時に、 |
|
接続キャッシュの初期サイズ |
|
キャッシュが最初に作成される場合、またはキャッシュが再初期化される場合の接続キャッシュのサイズ。このプロパティに オプション。デフォルトは、 接続プールの セッションの開始時に、 セッションの開始時に、 |
|
使用接続タイムアウトの待機時間 |
|
使用中の接続がクライアントから解放されるまで待機する時間（秒単位）。 このパラメータは、データソースから最大数の接続が取得されて使用中となっている場合にのみ適用されます。クライアントがプールから接続を取得しようとして、すべての接続が使用中の場合、接続プールでは、接続がプールに戻されるのを待機します。 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
非アクティブのタイムアウト |
|
プールから削除する前に、使用されていない接続を非アクティブにして待機する時間（秒単位）。 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
接続再試行間隔 |
|
失敗した接続試行を再実行するまでの待機間隔（秒単位）。 このパラメータは、 オプション。デフォルトは、 |
|
最大接続試行回数 |
|
接続の再試行回数。 このパラメータは、 オプション。デフォルトは、 |
|
接続の妥当性チェック |
|
Oracle Implicit Connection Cache専用。 プールから取得した接続をデータベースに対して検証するかどうかを指定します。この検証は、 値 オプション。デフォルトは、 |
|
検証用のSQL文 |
|
Oracle Implicit Connection Cache専用。
オプション。デフォルトはありません。 |
|
キャッシュする文の最大数 |
|
各接続でキャッシュするSQL文の最大数。 オプション。デフォルトは、 詳細は、「データソースでのJDBC文のキャッシュ・サイズの設定」を参照してください。 |
|
使用接続の最大アクティブ時間 |
|
Oracle Implicit Connection Cache専用。 使用中の接続をアクティブにする最大時間（秒単位）。 このタイムアウト時間を超えると、使用中の接続は無条件にクローズされ、関連する文ハンドルは取り消され、接続は接続プールに戻されます。 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
中止接続タイムアウト |
|
Oracleデータベース専用。 プールから削除する前に、使用されていない論理接続を非アクティブにして待機する時間（秒単位）。 このパラメータは、 たとえば、この接続で 接続が非アクティブの状態が指定した時間続くと、基礎となるPooledConnectionは回収され、再利用のためにキャッシュに戻されます。 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
タイムアウト制限の強制間隔 |
|
Oracleデータベース専用。 常にOracleデータベースと組み合せて使用します。キャッシュ・デーモン・スレッドでタイムアウト制限を強制する時間間隔（秒単位）です。 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
プールの下限しきい値 |
|
Oracleデータベース専用。 常にOracleデータベースと組み合せて使用します。 オプション。デフォルトは、 |
表5-4に、コネクション・ファクトリの属性とその説明を示します。
表5-4 コネクション・ファクトリの属性
| Application Server Controlコンソールの設定 | <connection-factory>の属性 | 説明 |
|---|---|---|
|
コネクション・ファクトリ・クラス |
|
必須。データソースの接続の作成に使用するコネクション・ファクトリ・クラスの名前とパス。このクラスは、JDBCドライバにより提供されます。たとえば、 このクラスは、
|
|
URL |
|
必須。データベースに接続するためにJDBCドライバにより使用されるURL。URLでは、通常、データベース・ホスト・マシン、ポートおよびデータベース名を指定します。たとえば、 |
|
ユーザー |
|
データベースへの接続に使用するデフォルト・ユーザー。 オプション。デフォルトはありません。 接続プールのinitial-limitが |
|
パスワード |
|
データベースへの接続に使用するデフォルト・パスワード。 オプション。デフォルトはありません。 |
|
ログイン・タイムアウト |
|
データベースへの接続試行時にこのデータソースが待機する最大時間（秒単位）。 値 オプション。デフォルトは、 タイムアウト設定を適用するには、 |
|
注意: 接続プールのinitial-limitが1より大きいが、connection-factoryでuser/passwordが指定されていない場合、OC4Jは起動に失敗し、エラーをスローします。
重大: コネクタの初期化中にエラーが発生しました。例外: データソースの接続プールの作成中にエラーが発生しました。例外: oracle.oc4j.sql.DataSourceException: ConnectionCacheManagerのインスタンスを取得/作成できませんでした。例外: ユーザー資格証明がcom.evermind.server.ApplicationStateRunning initConnectorの既存の資格証明と一致しません。 このエラーは、プールの接続を初期化するためのユーザーとパスワードが存在しない場合に発生します。 |
oracle.jdbc.pool.OracleDataSourceがdata-sources.xmlファイルにconnection-factoryのfactory-classとして指定されている場合、OracleDataSourceによって提供されるICCはOC4Jにより有効化されます。ICCが不要な場合には、connection-factoryのconnectionCachingEnabledプロパティをfalseに設定することで無効化できます。例:
<connection-pool name="myConnectionPool"
min-connections="10"
max-connections="100"
max-connect-attempts="5"
connection-retry-interval="3">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com">
<property name="connectionCachingEnabled" value="false"/>
</connection-factory>
</connection-pool>
この項では、data-sources.xml構成ファイルのデータソース定義の例を示します。
デフォルト・アプリケーションのデータソース構成ファイルは、$J2EE_HOME/config/data-sources.xmlです。
各アプリケーションには、それぞれ独自のdata-sources.xmlファイルを割り当てることができます。アプリケーションに独自ファイルを割り当てると、そのファイルは、アプリケーションのルート・ディレクトリに配置されます。
この項には、次の項目が含まれます。
グローバル
ローカル
例: Fast Connection Failoverの構成
シン
OCI
データソース設定は、エンタープライズ・アプリケーションのdata-sources.xmlファイルで永続化されます。このファイルの各<data-source>タグは、JNDIにバインドされていてクライアント・コンポーネント（サーブレットやEJBなど）からアクセスできる1つのデータソースを示しています。
次の例は、data-sources.xmlファイルの構文を示しています。詳細は、スキーマを参照してください。
<managed-data-source
attr1="val1"
attr2="val2"
… />
<native-data-source
attr1="val1"
attr2="val2"
… >
<property name="propertyName" value="propertyValue" />
…
</native-data-source>
<connection-pool
attr1="val1"
attr2="val2"
… >
<connection-factory
attr1="val1"
attr2="val2"
… >
<proxy-interface sql-object="javaSQLObject" interface=""/>
…
<property name="propertyName" value="propertyValue"/>
…
<xa-recover-config>
<password-credential>
<username></username>
<password></password>
</password-credential>
</xa-recovery-config>
<fatal-error-codes>
<error-code code="integerCode"/>
…
</fatal-error-codes>
<connection-properties>
<property name="propertyName value="propertyValue"/>
…
</connection-properties>
</connection-factory>
</connection-pool
移入例
次に、data-sources.xmlの定義の移入例を示します。
<?xml version="1.0" standalone="yes"?>
<data-sources>
<connection-pool name="myConnectionPool" max-connections="30">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com" />
</connection-pool>
<managed-data-source
jndi-name="jdbc/ManagedDS"
name="Managed DataSource Name"
connection-pool-name="myConnectionPool" />
<native-data-source
name="nativeDataSource"
jndi-name="jdbc/nativeDS"
data-source-class="com.acme.DataSourceImpl"
user="frank"
password="frankpw"
url="jdbc:acme:@localhost:5500:acme" />
</data-sources>
この項では、データソースの構成例を示します。
データソース構成の追加の例は、http://www.oracle.com/technology/tech/java/newsletter/articles/oc4j_datasource_config.htmlにある資料「Data Source Configuration in Oracle Application Server 10g」を参照してください。
<native-data-source name='My Native DataSource' jndi-name='jdbc/nativeDs' data-source-class='com.acme.DataSourceImpl' user='frank' password='frankpw' url='jdbc:acme:@localhost:5500:acme'> <property name="foo" value="bar"/> </native-data-source>
このデータソースは、XA動作をエミュレートしません。XA動作のエミュレートの詳細は、「XAのエミュレート」を参照してください。
<managed-data-source
name='My Managed DataSource'
jndi-name='jdbc/managedDs_1'
connection-pool-name='myConnectionPool'/>
<connection-pool
name='myConnectionPool'
min-connections='5'
max-connections='25'>
<connection-factory
factory-class='oracle.jdbc.xa.client.OracleXADataSource'
user='scott'
password='tiger'
url='jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com' />
</connection-pool>
このデータソースは、XA動作をエミュレートします。XA動作のエミュレートの詳細は、「XAのエミュレート」を参照してください。
<managed-data-source
name='My Managed DataSource'
jndi-name='jdbc/managedDs_1'
connection-pool-name='myConnectionPool'/>
<connection-pool
name='myConnectionPool'
min-connections='5'
max-connections='25'>
<connection-factory
factory-class='oracle.jdbc.pool.OracleDataSource'
user='scott'
password='tiger'
url='jdbc:oracle:thin:@//localhost:1521/
Oracle.regress.rdbms.dev.us.oracle.com' />
</connection-pool>
このデータソースは、XA動作をエミュレートします。XA動作のエミュレートの詳細は、「XAのエミュレート」を参照してください。
<managed-data-source
name='My Managed DataSource'
jndi-name='jdbc/managedDs_1'
connection-pool-name='myConnectionPool'/>
<connection-pool
name='myConnectionPool'
min-connections='5'
max-connections='25'>
<connection-factory
factory-class='oracle.jdbc.OracleDriver'
user='scott'
password='tiger'
url='jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com' />
</connection-pool>
<connection-pool
name='myConnectionPool'
min-connections='5'
max-connections='25'>
<connection-factory
factory-class='oracle.jdbc.pool.OracleDataSource'
user='scott'
password='tiger'
url='jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com'>
<proxy-interface sql-object="Connection"
interface="oracle.jdbc.internal.OracleConnection"/>
<proxy-interface sql-object="Statement"
interface="oracle.jdbc.OracleStatement"/>
<proxy-interface sql-object="CallableStatement"
interface="oracle.jdbc.OracleCallableStatement"/>
<proxy-interface sql-object="ResultSet"
interface="oracle.jdbc.OracleResultSet"/>
<proxy-interface sql-object="PreparedStatement"
interface="oracle.jdbc.OraclePreparedStatement"/>
</connection-factory>
</connection-pool>
<connection-pool
name='myConnectionPool'
min-connections='5'
max-connections='25'>
<connection-factory
factory-class='oracle.jdbc.xa.client.OracleXADataSource'
user='scott'
password='tiger'
url='jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com'>
<xa-recovery-config>
<password-credential>
<username>system</username>
<password>manager</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
<managed-data-source
jndi-name="jdbc/managedDs_1"
name="Managed DataSource"
connection-pool-name="myConnectionPool" />
<connection-pool
name="myConnectionPool">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url='jdbc:oracle:thin:@//localhost:1521/
oracle.regress.rdbms.dev.us.oracle.com'>
<connection-properties>
<property name="oracle.jdbc.RetainV9LongBindBehavior"
value="true"/>
</connection-properties>
</connection-factory>
</connection-pool>
接続プロパティの詳細は、「接続プロパティ」を参照してください。
グローバル
次の例では、data-sources.xmlファイルのtx-level属性をglobalに設定して、マネージド・データソースをグローバル・トランザクション用に構成する方法を示します。
<managed-data-source jndi-name="jdbc/ManagedDS" name="Managed DataSource Name" connection-pool-name="myConnectionPool" tx-level="global" />
ローカル
次の例では、data-sources.xmlファイルのtx-level属性をlocalに設定して、マネージド・データソースをローカル・トランザクション用に構成する方法を示します。デフォルト値は、globalです。
<managed-data-source jndi-name="jdbc/ManagedDS" name="Managed DataSource Name" connection-pool-name="myConnectionPool" tx-level="local" />
次に、Fast Connection Failoverのコネクション・ファクトリを構成する例を示します。
シン
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"
<property name="connectionCachingEnabled" value="true"/>
<property name="fastConnectionFailoverEnabled" value="true" />
</connection-factory>
OCI
次に、OCIを使用するコネクション・ファクトリ定義の例を示します。
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource" user="scott" password="tiger" url="jdbc:oracle:oci:@myAlias" />
OC4Jのデータソースは、Oracle10gのJDBCドライバと完全に統合されているため、自動的に高可用性（HA）およびFast Connection Failover（FCF）機能を使用できます。
高可用性とFast Connection Failoverの詳細は、次のドキュメントを参照してください。
『Oracle Database高可用性概要』
『Oracle Database JDBC開発者ガイドおよびリファレンス』の第VI部「高可用性」
追加情報: http://www.oracle.com/technology/tech/java/oc4j/index.html
Fast Connection Failoverは、JDBC Implicit Connection Cacheに実装されたRAC/FaNクライアントです。この機能の主な目的は、接続の有効性と可用性を保証することです。クライアント・サイドのFast Connection Failoverにより、次の機能が提供されます。
Implicit Connection Cache内の無効接続の高速検出（DCD）
失効または無効接続のキャッシュからの削除
上位レイヤーでの再試行を容易にする、コール元へのエラーの伝播
新規RACインスタンス追加時の接続の再配布
Fast Connection Failoverメカニズムを有効化するには、OracleDataSourceオブジェクトの<connection-factory>タグで次のプロパティおよび属性を設定する必要があります。
表5-5 Fast Connection Failoverの設定
| 設定 | 説明 |
|---|---|
|
|
これは、ブール型プロパティであり、 |
|
|
このプロパティを |
|
|
これは、<connection-factory>タグの属性です。Fast Connection Failoverを有効化する場合、サービス名の構文を使用してURLを設定する必要があります。接続URLに指定されたサービス名は、接続キャッシュをサービスにマップするために使用されます。Fast Connection Failoverが有効な場合にSIDをURLに指定すると、例外がスローされます。 |
次の例では、Fast Connection Failover用の接続キャッシュ設定におけるURLの用例として、有効な構文と無効な構文を示します。
有効なURLの用例
url="jdbc:oracle:oci:@TNS_ALIAS" url="jdbc:oracle:oci:@(DESCRIPTION= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))" url="jdbc:oracle:oci:@(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))" url = "jdbc:oracle:thin@//host:port/service_name" url = "jdbc:oracle:thin@//cluster-alias:port/service_name" url="jdbc:oracle:thin:@(DESCRIPTION= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))" url = "jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))"
無効なURLの用例
url = "jdbc:oracle:thin@host:port:SID"
data-sources.xmlファイルでのFast Connection Failoverの有効化
次に、data-sources.xmlファイルでネイティブ・データソース用にFast Connection Failoverを有効化する例を示します。
<native-data-source
name="nativeDataSource"
jndi-name="jdbc/nativeDS"
description="Native DataSource"
data-source-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))">
<property name="connectionCacheName" value="ICC1"/>
<property name="connectionCachingEnabled" value="true"/>
<property name="fastConnectionFailoverEnabled" value="true"/>
</native-data-source>
マネージド・データ・ソースは、Oracleデータベースとの通信を保護するためにTCP over SSL（TCPS）を使用するように構成できます。TCPSを使用する場合、次の要件があります。
トラストストア（この場合はPKCS12ウォレット）で構成されたデータベース。データベース・サーバーでのセキュリティのセットアップにサポートが必要な場合は、DBAに連絡してください。
10.2.0.3（またはそれ以上）のJDBCドライバ（アプリケーション・サーバーは、デフォルト・ドライバとして10.1.0.5 JDBCドライバを使用します）。ドライバは、コンテナまたは個別アプリケーションのための共有ライブラリとして構成できます。『Oracle Containers for J2EE開発者ガイド』の「OC4Jクラス・ローディング・フレームワーク」を参照してください。
アプリケーション・サーバーのJREセキュリティ・ファイルのOracle PKIセキュリティ・プロバイダ・エントリ（JAVA_HOME/jre/lib/security/java.security）。例:
security.provider.3=oracle.security.pki.OraclePKIProvider
|
注意: TCPSを使用したJDBC/SSLの詳細は、次のドキュメントを参照してください。http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/wp-oracle-jdbc_thin_ssl.pdf |
マネージド・データソースの定義には、次の内容が含まれる必要があります。
oracle.jdbc.driver.OracleDriverファクトリ・クラス。
次に示すようにTCPSプロトコルを定義する接続URL:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps) \
(HOST=host)(PORT=2484)) \
(CONNECT_DATA=(SERVICE_NAME=orcl)))
データベースのユーザー名/パスワードと、トラストストア資格証明
サーバー上のクライアント・ウォレットへのパス。ファイル・システム上の任意の場所にできます。例:
/home/wallets/client/ewallet.p12
次の例は、TCPSを使用してOracleデータベースに接続するマネージド・データソース定義を示しています。この例ではSSLを暗号化にのみ使用しており、一連の暗号スイートを渡しています。
<managed-data-source
connection-pool-name="ConnPoolTCPS"
jndi-name="jdbc/sslDS"
name="jdbc/sslDS"/>
<connection-pool name="ConnPoolTCPS">
<connection-factory
factory-class="oracle.jdbc.driver.OracleDriver"
user="user"
password="password"
URL="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps) \
(HOST=host)(PORT=2484)) \
(CONNECT_DATA=(SERVICE_NAME=orcl)))"
commit-record-table-name="">
<property name="truststore"
value="/path/ewallet.p12"/>
<property name="truststore-password" value="password"/>
<property name="truststore-type" value="PKCS12"/>
<property name="oracle.net.ssl_cipher_suites"
value="SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, \
SSL_DH_anon_WITH_DES_CBC_SHA"/>
</connection-factory>
</connection-pool>
この項には、次の項目が含まれます。
この項では、Oracle JDBC OCIドライバとOracle JDBCシン・ドライバについて説明します。
Oracle JDBCドライバの詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。
この章のOracleデータソース定義の例では、Oracle JDBCシン・ドライバが使用されています。ただし、Oracle JDBC OCIドライバを使用することもできます。OC4Jサーバーを起動する前に、次の作業を実行します。
OC4JがインストールされているシステムにOracle Clientをインストールします。
OLE_HOME変数を設定します。
LD_LIBRARY_PATH（または使用中のオペレーティング・システムの対応する環境変数）に$OLE_HOME/libを設定します。
TNS_ADMINに、適切なtnsnames.oraファイルを含む有効なOracle管理ディレクトリを設定します。
<connection-factory>要素定義のurl属性で使用するURLは、次のいずれかの形式です。
jdbc:oracle:oci:@ - このTNSエントリは、クライアントと同じシステム上にあるデータベース用で、クライアントはIPCモードでデータベースに接続します。
jdbc:oracle:oci:@TNS_service_name - TNSサービス名は、インスタンスのtnsnames.oraファイルのエントリです。
jdbc:oracle:oci:@full_TNS_listener_description - TNSの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
次の例では、OCIを使用するコネクション・ファクトリの定義を示します。
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:oci:@myAlias" />
クライアント・ライブラリの互換性に制限があることから、任意のバージョンのOracle JDBC-OCIドライバにアップグレードすることはできません。サポートされるのは、Oracle Application Server 10gリリース2（10.1.2）内にインストールされているOracle Clientライブラリと一致するOCIドライバ・バージョンへのアップグレードです。たとえば、Oracle JDBC 10.1.xドライバはサポートされますが、Oracle JDBC 9.2.xドライバはサポートされません。
Oracle Application ServerでJDBC-OCIの使用をサポートする場合、ORACLE_HOMEおよびライブラリ・パスの適切な値を起動環境に伝播するため、各OC4Jインスタンス用のopmn.xmlエントリも必要です。
環境変数ORACLE_HOMEは、すべてのプラットフォームに共通ですが、ライブラリ・パスを指定する環境変数の名前は、次のようにオペレーティング・システムごとに異なります。
LD_LIBRARY_PATH（Solaris）
SLIB_PATH（AIX）
SHLIB_PATH（HP-UX）
PATH（Windows）
opmn.xmlでライブラリ・パスを指定する一般的な構文は、次のとおりです。
<prop name="<LIB_PATH_VARIABLE>" value="<LIB_PATH_VARIABLE_VALUE>"/>
ここで、<LIB_PATH_VARIABLE>は、ライブラリ・パスを指定するプラットフォーム固有の適切な変数名で置き換えます。また、<LIB_PATH_VARIABLE_VALUE>は、その変数の値で置き換えます。
次の例では、Solarisオペレーティング・システムの場合を示します。
<process-type id="OC4J_SECURITY" module-id="OC4J">
<environment>
<variable id="ORACLE_HOME" value="/u01/app/oracle/product/inf10120"/>
<variable id="LD_LIBRARY_PATH"
value="/u01/app/oracle/product/inf10120/lib"/>
</environment>
Instant Client 10.2.0.3をダウンロードしてインストールします。この手順説明では、インストール先ディレクトリをIC_INSTALL_DIRと表記します。
次の環境変数を設定します。
set PATH=IC_INSTALL_DIR;%PATH%
set TNS_ADMIN=IC_INSTALL_DIR
set LD_LIBRARY_PATH=IC_INSTALL_DIR
|
注意: IC_INSTALL_DIRにあるtnsnames.oraファイルには、スタンドアロンOC4J接続文字列に使用される接続エントリが含まれています。 |
スタンドアロンOC4Jインスタンスを起動します。
OC4J 10.1.3.xで使用するJDBCドライバのバージョンは10.1.0.5で、10.2.0.3クライアントとの互換性がありません。ojdbc14.jarを使用するようにOC4Jをアップグレードします。OC4Jに含まれるJDBCドライバを変更する手順は、次のOTNページにあります。
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-swapjdbclib/doc/readme.html
Application Server Controlを使用して、OCI URLを使用してデータベースに接続する接続プールを作成します。例:
<connection-pool name="ocitest-pool">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="user" password="password" url="jdbc:oracle:oci:@LINUX10G"/>
</connection-pool>
異種データベースに接続する必要のあるアプリケーションでは、DataDirect JDBCドライバを使用できます。DataDirect JDBCドライバは、Oracleデータベース用ではありませんが、DB2、Sybase、Informix、SQLServerなどのOracle以外のデータベースに接続する場合に使用できます。
『DataDirect Connect for JDBC User's Guide and Reference』の説明に従ってDataDirect JDBCドライバをインストールします。
DataDirect JDBCドライバを使用するには、次のようにします。
DataDirect JDBCドライバの内容をディレクトリに解凍します。このディレクトリは、DDJD_INSTALLと呼ばれます。
Oracle Enterprise Manager 10gコンソールから、共有ライブラリ（「管理」→「共有ライブラリ」）を作成し、DDJD_INSTALL/libにあるDataDirect JDBCライブラリを共有ライブラリにアップロードします。DataDirectドライバを使用するには、YMbase.jarおよびYMutil.jarライブラリが必要です。
「データソース・エントリの例」で説明されているように、データベースのデータソース定義をORACLE_HOME/config/data-sources.xmlファイルに追加します。
手順2で作成した共有ライブラリをインポートしたことを確認し、Oracle Enterprise Manager 10gコンソールから、アプリケーションをデプロイ（「アプリケーション」→「デプロイ」）します。
|
注意: 共有ライブラリの作成の詳細は、『Oracle Containers for J2EE開発者ガイド』の第3章を参照してください。 |
この項では、次のOracle以外の各データベースについてデータソース・エントリの例を示します。
ベンダー固有のデータソースをクラス属性で直接使用することもできます。つまり、クラス属性でOC4J固有のデータソースを使用する必要はありません。
詳細は、『DataDirect Connect for JDBC User's Guide and Reference』を参照してください。
データソース構成の追加の例は、http://www.oracle.com/technology/tech/java/newsletter/articles/oc4j_datasource_config.htmlにある資料「Data Source Configuration in Oracle Application Server 10g」を参照してください。
DataDirect DB2
|
注意: DataDirect JDBCドライバを使用してDB2に接続する場合、次の制限事項があります。
|
<managed-data-source
name="db2"
jndi-name="jdbc/db2"
connection-pool-name="db2 Connection Pool"/>
<connection-pool name="db2 Connection Pool">
<connection-factory
factory-class="com.oracle.ias.jdbcx.db2.DB2DataSource"
user="user"
password="password"
url="jdbc:oracle:db2://host:50008;DatabaseName=sample">
<property name="databaseName" value="sample"/>
<property name="serverName" value="host"/>
<property name="portNumber" value="50008"/>
<xa-recovery-config>
<password-credential>
<username>system</username>
<password>manager</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
DataDirectを使用するときに、ネイティブ・データソースとしてDB2を構成する手順:
<native-data-source user="user" password="password" login-timeout="0" name="db2native" jndi-name="jdbc/db2native" url="jdbc:oracle:db2://host:50008;DatabaseName=sample" data-source-class="com.oracle.ias.jdbcx.db2.DB2DataSource"> <property name="databaseName" value="sample/> <property name="serverName" value="host"/> <property name="portNumber" value="50008"/> </native-data-source>
DataDirect Sybase
<managed-data-source
name="Sybase"
jndi-name="jdbc/Sybase"
connection-pool-name="Sybase Connection Pool"/>
<connection-pool name=" Sybase Connection Pool">
<connection-factory
factory-class="com.oracle.ias.jdbcx.sybase.SybaseDataSource"
user="user"
password="password"
url="jdbc:oracle:sybase://host:5000:jdbctest">
<property name="serverName" value="host"/>
<property name="portNumber" value="5000"/>
<xa-recovery-config>
<password-credential>
<username>system</username>
<password>manager</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
DataDirectを使用するときに、ネイティブ・データソースとしてSybaseを構成する手順:
<native-data-source user="user" password="password" login-timeout="0" name="sybasenative" jndi-name="jdbc/sybasenative" url="jdbc:oracle:sybase://host:5000:jdbctest" data-source-class="com.oracle.ias.jdbcx.sybase.SybaseDataSource"> <property name="serverName" value="host"/> <property name="portNumber" value="5000"/> </native-data-source>
DataDirect Informix
<managed-data-source
name="Informix"
jndi-name="jdbc/Informix"
connection-pool-name="Informix Connection Pool"/>
<connection-pool name=" Informix Connection Pool">
<connection-factory
factory-class="com.oracle.ias.jdbc.informix.InformixDriver"
user="user"
password="password"
url="jdbc:oracle:informix://host:3900;
informixServer=gtw93;DatabaseName=gatewaydb">
<xa-recovery-config>
<password-credential>
<username>userid</username>
<password>pword</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
DataDirectを使用するときに、ネイティブ・データソースとしてInformixを構成する手順:
<native-data-source user="user" password="password" login-timeout="0" name="informixnative" jndi-name="jdbc/informixnative" url="jdbc:oracle:informix://host:3900" data-source-class="com.oracle.ias.jdbcx.informix.InformixDataSource"> <property name="informixServer" value="ifmx10"/> <property name="portNumber" value="3900"/> <property name="serverName" value="host"/> </native-data-source>
DataDirect SQLServer
<managed-data-source connection-pool-name="ConnectionSqlserver"
jndi-name="jdbc/mysqlserver"
name="mysqlserver" />
<connection-pool name="ConnectionSqlserver" max-connections="20"
min-connections="1">
<connection-factory
factory-class="com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource"
user="user"
password="password"
url="jdbc:oracle:sqlserver://host\sqldb">
<property name="serverName" value="host\sqldb"/>
<xa-recovery-config>
<password-credential>
<username>msuser</username>
<password>mspass</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
DataDirectを使用するときに、ネイティブ・データソースとしてSQLServerを構成する手順:
<native-data-source user="user" password="password" jndi-name="jdbc/mysqlserver" name="mysqlserver" url="jdbc:oracle:sqlserver://host\sqldb" data-source-class="com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource"> <property name="serverName" value="host\sqldb" /> </native-data-source>
MySQL
次の例ではConnector/Jを使用しています。
<managed-data-source connection-pool-name="mysqlCP" name="mysql"
jndi-name="jdbc/mysql" />
<connection-pool name="mysqlCP">
<connection-factory
factory-class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
user="user"
password="password"
url="jdbc:mysql://host/test">
<xa-recovery-config>
<password-credential>
<username/>
<password/>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
ネイティブ・データソースとしてMySQLを構成する手順:
<native-data-source user="root" password="mysql" name="mysqlnative"
jndi-name="jdbc/mysqlnative"
url="jdbc:mysql://host/test"
data-source-class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource"/>
次の追加のデータソース構成例では、データソース・タイプ、コネクション・ファクトリ・タイプ、および他の変数の様々な組合せを示します。これらの例は、http://www.oracle.com/technology/tech/java/newsletter/articles/oc4j_datasource_config.htmlにある資料「Data Source Configuration in Oracle Application Server 10g」からの抜粋です。
ネイティブ・データソース: Oracle JDBCからOracleデータベースへ
<native-data-source name="nativeDataSource" jndi-name="jdbc/nativeDS" description="Native DataSource" data-source-class="oracle.jdbc.pool.OracleDataSource" user="scott" password="tiger" url="jdbc:oracle:thin:@//dbhost:1521/dbservicename"> </native-data-source>
ネイティブ・データソース: DataDirect JDBCからDB2 UDBへ
<native-data-source name="nativeDataSource" jndi-name="jdbc/nativeDS" description="Native DataSource" data-source-class="com.ddtek.jdbcx.db2.DB2DataSource" user="frank" password="frankpw" url="jdbc:datadirect:db2://server_name:50000;DatabaseName=your_database"> </native-data-source>
ネイティブ・データソース: DB2 Universal JDBCからDB2 UDBへ
<native-data-source
name="nativeDataSource"
jndi-name="jdbc/nativeDS"
description="Native DataSource"
data-source-class="com.ibm.db2.jcc.DB2DataSource"
user="db2adm"
password="db2admpwd"
url="jdbc:db2://sysmvs1.stl.ibm.com:5021/
dbname:user=db2adm;password=db2admpwd;" />
マネージド・データソース: XADataSourceコネクション・ファクトリを使用
<managed-data-source
jndi-name="jdbc/ManagedDS"
description="Managed DataSource"
connection-pool-name="myConnectionPool"/>
<connection-pool
name="myConnectionPool"
min-connections="10"
max-connections="30"
inactivity-timeout="30">
<connection-factory
factory-class="oracle.jdbc.xa.client.OracleXADataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//dbhost:1521/dbservicename" />
</connection-pool>
マネージド・データソース: DataSourceコネクション・ファクトリを使用
<managed-data-source
jndi-name="jdbc/ManagedDS"
description="Managed DataSource">
connection-pool-name="myConnectionPool"/>
<connection-pool
name="myConnectionPool"
min-connections="10"
max-connections="30"
inactivity-timeout="30">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//dbhost:1521/dbservicename" />
</connection-pool>
マネージド・データソース: Driverコネクション・ファクトリを使用
<managed-data-source
jndi-name="jdbc/ManagedDS"
description="Managed DataSource">
connection-pool-name="myConnectionPool"/>
<connection-pool
name="myConnectionPool"
min-connections="10"
max-connections="30"
inactivity-timeout="30">
<connection-factory
factory-class="oracle.jdbc.OracleDriver"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//dbhost:1521/dbservicename" />
</connection-pool>
レガシー・データソース構成を使用する際には、次の事項を考慮する必要があります。
data-sources.xmlには、次の2つの構文があります。
現行の構文は、http://xmlns.oracle.com/oracleas/schema/data-sources-10_1.xsdスキーマに準拠します。
レガシー構文は、http://xmlns.oracle.com/ias/dtds/data-sources-9_04.dtdスキーマに準拠します。
どちらの構文も有効ですが、新規構文を使用することをお薦めします。
Application Server Controlコンソールで追加した変更内容がdata-sources.xmlに永続化される場合、その構文は、常に新規形式で記述されます。
data-sources.xmlファイルの内容は、admin.jarユーティリティを使用することで、レガシーの旧構文から新規構文に明示的に変換できます。-convertDataSourceConfigurationオプションを使用します。詳細は、次の「既存のデータソースの変換」の項で説明されています。
OC4Jでは、data-sources.xmlファイルのレガシー形式を解釈できます。既存のデータソースの変更やデータソースの作成または削除など、data-sources.xmlファイルの変更にApplication Server Controlコンソールが使用されている場合、古い形式のdata-sources.xmlファイルが含まれるアプリケーションでは、OC4Jによりそのdata-sources.xmlファイルが自動的に最新の形式に変換されます。
スタンドアロン環境でアクティブなOC4Jインスタンスを使用すると、次の構文でadmin.jarを使用し、レガシーのdata-sources.xmlファイルを現行の形式に手動で変換することもできます。詳細は『Oracle Containers for J2EE構成および管理ガイド』を参照してください。このマニュアルでは、ORMI URLを指定できるのはOC4Jの稼働中のみであること、またはORMI URLがオプションであることは説明されていません。
java -jar admin.jar ormi://oc4jHost:oc4jOrmiPort adminId adminPassword -convertDataSourceConfiguration old-data-sources.xml new-data-sources.xml
OC4Jインスタンスが稼働していなくても、デプロイ前にdata-sources.xmlファイルを変換することも可能です。このオフライン変換の構文は次のとおりです。
java -jar admin.jar -convertDataSourceConfiguration old-data-sources.xml new-data-sources.xml
|
注意:
|
アプリケーションと新しいdata-sources.xmlファイル間の整合性の確認
手動または自動での変換後、新しいdata-sources.xmlファイルを開いて調査し、アプリケーションと新しいファイルとの間に、データソースの参照に使用されるJNDIロケーションの整合性があることを確認します。新しいファイルには使用されないデータソース定義が含まれている場合があるので、この確認を行うことをお薦めします。
これは、古い形式で複数のロケーション属性（location、ejb-location、xa-locationなど）が使用されていることが原因です。新しい形式への変換により、古いdata-sources.xmlファイルに指定されているそれぞれのロケーション属性に対応する別のデータソースが、新しいdata-sources.xmlファイルに作成されます。多くの場合、クライアント・アプリケーションでは、locationまたはejb-location属性で定義されたデータソースのみが使用されます。ただし、これは保証されているわけではありません。そのため、変換されたdata-sources.xmlにはアプリケーションで使用されない定義が含まれますが、ファイルから削除できます。
