この章では、WebLogic ServerからOracle Application Serverにデータベース・アクセス・コードを移行する場合に必要な情報について説明します。具体的には、JDBCドライバ、データソースおよび接続プーリングの移行について説明します。
ここで説明する内容は次のとおりです。
WebLogic Serverにデプロイされたアプリケーションのうち、JDBC(特にWebLogic JDBCドライバ)を使用するアプリケーションをOC4JおよびOracle JDBCドライバに移行する作業は簡単であり、移行するアプリケーションのコードを変更する必要はほとんどありません。まったくない場合もあります。JDBCの標準仕様に準拠して作成されたアプリケーションはすべて正常に動作し、最小限の作業で移行できます。主な作業は、新しい環境でのアプリケーションの構成およびデプロイです。独自の拡張機能が使用されている場合にのみ、移行作業が複雑になります。
WebLogic Server 8.1ではJ2EE 1.3(JDBC 2.0)、OC4JではJ2EE 1.4(JDBC 2.1)がサポートされています。BEAおよびOracleのJDBCドライバでは、同じバージョンのJDBC標準(バージョン2.0仕様)がサポートされています。したがって、2つのサーバー間の相違点は最小限で、それらの相違点は主に独自の拡張機能に見られます。相違点を分析する前に、JDBCドライバの概要を示します。
JDBCでは、指定したJDBCドライバへの標準APIコールが定義されます。JDBCドライバは、実際のデータ・インタフェース・コマンドを実行するソフトウェアです。このドライバは、低レベルのJDBC APIとみなされています。このドライバのインタフェースには、データベースのクライアント・コール、またはデータベース・サーバーから提供されるデータベースのネットワーク・プロトコル・コマンドが使用されます。
JDBC APIコールを変換するJDBCドライバには、インタフェースのタイプに応じて、次の4つのタイプがあります。
タイプ1、JDBC-ODBCブリッジ: JDBC APIコールをODBC APIコールに変換します。
タイプ2、ネイティブAPIドライバ: JDBC APIコールをデータベースのネイティブAPIコールに変換します。このドライバではネイティブAPIが使用されるため、このドライバはベンダーに依存します。このドライバは、変換が行われるJava言語の部分および一連のネイティブAPIライブラリの2つの部分で構成されています。
タイプ3、ネットプロトコル: JDBC APIコールをDBMSに依存しないネットワーク・プロトコル・コールに変換します。データベース・サーバーで、このネットワーク・プロトコル・コールが特定のDBMS操作に変換されます。
タイプ4、ネイティブプロトコル: JDBC APIコールをDBMS固有のネットワーク・プロトコル・コールに変換します。データベース・サーバーで、これらのコールがDBMS操作に変換されます。
BEA社では、JDBC API仕様を使用するデータベース・アクセス用に、様々なオプションが提供されています。これらのオプションには、Oracle用、Microsoft SQL Server用およびInformixデータベース管理システム(DBMS)用のWebLogic jDriverなどがあります。WebLogicでは、タイプ2のWebLogic jDriver for Oracleの他に、Oracle XA用のタイプ2ドライバが1つ、タイプ3ドライバが3つ(RMIドライバ、PoolドライバおよびJTSドライバ)提供されています。
同様に、Oracle Application Serverでも、データベース・アクセス用の様々なオプションが提供されています。主なものとしては、Oracleデータベースに最適なJDBCドライバやDB2などの他社製データベースにアクセスするためのMerant社(パートナ企業)製JDBCドライバがあります。
WebLogic jDriver for Oracle: WebLogic jDriver for Oracleでは、Oracleデータベースへの接続性が提供されています。WebLogic jDriver for Oracleは、OCI(Oracle Call Interface API)に基づいているため、Oracleクライアントのインストールが必要です。WebLogic jDriver for Oracleは、WebLogic jDriver for Oracle/XAドライバによって分散トランザクション用に拡張されます。
Oracle Thickドライバ(JDBC OCIドライバ)は、WebLogic jDriver for OracleおよびWebLogic jDriver for Oracle XAに相当します。このドライバには、XA機能が備わっているためです。
WebLogic Poolドライバ: WebLogic Poolドライバによって、HTTPサーブレットやEJBなどのサーバー・サイド・アプリケーションから接続プールを使用できます。
Oracle JDBC-OCIドライバ: Oracle JDBC-OCIドライバによって、J2EEアプリケーションで接続プールを使用できます。このドライバは、JDBC 2.0の接続プール機能を完全にサポートします。
WebLogic RMIドライバ: WebLogic RMIドライバは、タイプ3の多層Java Data Base Connectivity(JDBC)ドライバです。WebLogic Serverで実行され、任意の2層のJDBCドライバとともに使用してデータベース・アクセスを提供できます。また、WebLogic RMIドライバは、WebLogic Serverのクラスタ内に構成すると、クラスタリングされたJDBCに対して使用できます。これによって、WebLogic Clustersで提供されるロード・バランシングおよびフェイルオーバー機能をJDBCクライアントで使用できるようになります。
WebLogic JTSドライバ: WebLogic JTSドライバは、タイプ3の多層JDBCドライバです。1つのデータベース・インスタンスを使用する複数のサーバーにわたる分散トランザクションで使用されます。JTSドライバは、2フェーズ・コミットを行わないため、1つのデータベース・インスタンスのみを使用する場合はWebLogic jDriver for Oracle XAドライバより効率的です。
Oracle Thinドライバ: タイプ4の2層Oracle Thinドライバです。WebLogic ServerからOracle DBMSへの接続性を提供します。
すでにWebLogic ServerからOracle OCIドライバ(Oracle Thin JDBCドライバ)を使用している場合は、コードを変更する必要がないため、OC4Jでのデータソースの構成に関する項に進んでください。
JDBC 2.0仕様では、java.sql.Datasource
クラスが導入され、JDBCプログラムが100%移植可能になりました。このバージョンでは、ベンダー固有の接続URLおよびマシンとポートの依存性が削除されました。また、このバージョンでは、java.sql.DriverManager
、Driver
、およびDriverPropertyInfo
の各クラスの使用は推奨されていません。以前のJDBC DriverManager
機能は、データソース機能に完全に置き換えられています。ドライバ・マネージャ・クラスをクライアント・アプリケーション・ランタイムに明示的にロードするかわりに、集中化されたJNDIへのサービス・ルックアップによってjava.sql.Datasource
オブジェクトが取得されます。Datasource
オブジェクトを使用してデータベースに接続することもできます。データソースは、JDBC 2.0 API仕様に従って、JDBCサブコンテキストまたはその子コンテキストのいずれかの下に登録されます。JDBCコンテキスト自体は、ルート・コンテキストの下に登録されます。DataSource
オブジェクトは、データソースへのコネクション・ファクトリです。
JDBC 2.0データソースAPIは、WebLogicおよびOC4Jの両方でサポートされています。J2EEサーバーでは、JDBCドライバ構成に基づいてドライバが暗黙的にロードされるため、ドライバのロードにクライアント固有のコードは必要ありません。JNDI(Java Naming and Directory Interface)ツリーでDataSource
オブジェクトを参照できます。
DataSource
オブジェクトをJNDIと併用することによって、データベースに接続するための接続プールにアクセスできます。データソースごとに個別のDataSource
オブジェクトが必要です。DataSource
オブジェクトは、接続プーリングまたは分散トランザクションのいずれかをサポートするDataSource
クラスとして実装できます。
DataSource
オブジェクトを使用するには、クライアント・コードに次のクラスをインポートします。
import java.sql.*; import java.util.*; import javax.naming.*;
WebLogic Serverの場合はweblogic.jdbc.*
パッケージ、OC4Jの場合はoracle.jdbc.*
パッケージを使用します。
Oracle Application Server用にデータソースを構成するには、Application Server ControlコンソールのWebページを使用して、データソース名、データベース名およびJDBC URL文字列を指定します。単一の接続プールが使用されるように複数のデータソースを定義することもできます。これによって、同一データベースを共有するトランザクション対応およびトランザクション非対応の両方のDataSource
オブジェクトを定義できます。
データソースの構成および定義を行う最良の方法は、Application Server Controlコンソールを使用して行う方法です。ただし、このドキュメントでは、基礎となるインフラストラクチャを調べ、構成ファイルを直接操作する方法について主に説明します。OC4Jでは、フラット・ファイルを使用して、デプロイしたすべてのアプリケーション用のデータソースが構成されます。 データソースは、<ORACLE_HOME>/j2ee/home/config/data-sources.xml
ファイルに指定されています。次に、Oracleデータベースのデータソース構成の例を示します。data-sources.xml
に指定されているデータソース(xa-location
、ejb-location
およびpooled-location
)は、それぞれ一意である必要があります。
<data-source class="com.evermind.sql.DriverManagerDataSource" name="Oracle" url="jdbc:oracle:thin@<database host name><database listener port number>:<database SID>" pooled-location="jdbc/OraclePoolDS" xa-location="jdbc/xa/OracleXADS" ejb-location="jdbc/OracleDS" connection-driver="oracle.jdbc.driver.OracleDriver" username="scott" password="tiger" url="jdbc:oracle:thin@<database host name><database listener port number>:<database SID>" schema="database-schemas/oracle.xml" inactivity-timeout="30" max-connections="20" />
表6-1に、data-sources.xml
内のすべての構成パラメータを示します。(前述の例に示されていないパラメータもあります)。
表6-1 data-sources.xml
ファイルの構成パラメータ
パラメータ | 説明 |
---|---|
|
データソースのクラス名。 |
|
JDBCのクラス名。 |
|
失敗した接続を再試行するまでの待機時間(秒)。 デフォルト値は1秒です。 |
|
EJB対応のプーリングされたバージョンのデータベースをバインドするためのJNDIパス。このバージョンは、コンテナ管理のトランザクションで使用されます。このタイプのデータソースは、EJBおよび同様のオブジェクト内から使用されます。 このパラメータが適用されるのは、 |
|
使用されていない接続がクローズされるまでキャッシュされる時間(秒)。 |
|
データソースをバインドするためのJNDIパス。 |
|
失敗した接続を再試行する回数。 デフォルトは3回です。 |
|
データソースをプーリングするためにオープンしておく接続の最大数。 |
|
データソースをプーリングするためにオープンしておく接続の最小数。 デフォルトは0(ゼロ)です。 |
|
データソースの表示名。 |
|
データソースにアクセスするためのユーザー・パスワード(オプション)。 |
|
プーリングされたバージョンのデータソースをバインドするためのJNDIパス。 このパラメータが適用されるのは、 データベースに接続するためのdatabase-schemaファイルへの相対パスまたは絶対パス。 |
|
特殊なデータソースの基礎となるデータソース。 |
|
データソースのJDBC URL( |
|
データソースにアクセスするためのユーザー名(オプション)。 |
|
すべての接続が使用されている場合に接続が解放されるまでの待機時間(秒)。 デフォルトは60です。 |
|
トランザクション・バージョンのデータソースをバインドするためのJNDIパス。 このパラメータが適用されるのは、 |
|
特殊なデータソースの基礎となる |
JDBCクライアントから接続を取得するには、JNDIを使用してDataSource
オブジェクトのルックアップおよびロケーティングを行います。次に、WebLogic Serverで接続を取得するコード部分を示します。
try { java.util.Properties parms = new java.util.Properties(); parms.setProperty(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); javax.naming.Context ctx = new javax.naming.InitialContext(parms); javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/SampleDB"); java.sql.Connection conn = ds.getConnection(); // process the results ... }
前述のコードをWebLogic ServerからOC4Jに移行するには、JNDIツリーの初期コンテキスト・ファクトリ(Context.INITIAL_CONTEXT_FACTORY
)を実装するクラスをweblogic.jndi.WLInitialContextFactory
(WebLogic固有のクラス)からcom.evermind.server.ApplicationClientInitialContextFactory
(OC4J固有のクラス)に変更する必要があります。
この変更によって、コードはOC4Jにデプロイ可能となり、Oracle JDBCドライバを使用できるようになります。
ほとんどのWebベースのリソース(サーブレット、アプリケーション・サーバーなど)は、データベース内の情報にアクセスします。リソースは、データベースへのアクセスを試行するたびに、データベースへの接続を確立し、接続の作成および維持にシステム・リソースを使用する必要があります。また、接続が不要になった場合、その接続を解放するためにもシステム・リソースを使用する必要があります。リソースのオーバーヘッドは、Webベースのアプリケーションで特に大きくなります。これは、Webユーザーが頻繁かつ大量に接続および切断を行うためです。多くの場合、データのやり取り自体で消費されるリソースより、接続および切断で消費されるリソースの量のほうが多くなります。
接続プーリングを使用すると、接続のオーバーヘッドを多数のユーザー・リクエストに分散することによって、接続リソースの使用を制御できます。接続プールは、一連の接続オブジェクトをキャッシュしたもので、複数のクライアントがデータベースのリソースにアクセスする必要がある場合に、それらのクライアントによって共有されます。プール内の接続を作成するためのリソースは、指定した数の接続に対して一度のみ使用されます。各クライアントがリソースを使用して専用の接続をオープンし、データベース操作の完了時に接続をクローズするのではなく、接続はオープンされたままになり、多数のクライアント・リクエストによって繰り返し使用されます。接続プーリングでは、次の方法でパフォーマンス全体が向上されます。
中間層およびサーバーでの負荷の軽減
セッションの作成操作および終了操作によるリソース使用量の最小化
ソケットとファイル記述子の制限およびユーザー・ライセンス数の制限に起因するボトルネックの解消
JDBC 2.0仕様では、次の目的でJDBCデータソース接続のプールを定義できます。
リソースに対する接続の可用性を最大にするため
プール内のアイドル接続数を最小にするため
孤立した接続をプールに戻し、他のサーブレットまたはアプリケーション・サーバーでの再利用を可能にするため
接続プールの最大サイズ・プロパティを、同時にアクティブとなるユーザー・リクエストの予想最大数と同じ値に設定します。
接続プールの最小サイズ・プロパティを、同時にアクティブとなるユーザー・リクエストの予想最小数と同じ値に設定します。
接続プーリングのプロパティによって、ユーザー・リクエスト数の減少に合せて接続が段階的にプールから削除されるようになります。同様に、ユーザー・リクエスト数の増加に合せて新しい接続が作成されます。接続の再利用が最大になり、接続作成のオーバーヘッドが最小になるように、接続のバランスが維持されます。また、接続プーリングを使用して、データベースへの同時接続の数を制御することもできます。
接続プールは、すぐに使用できるDBMSへの接続のプールです。データベース接続は、接続プールの起動時にすでに確立されているため、データベース接続の確立に要するオーバーヘッドはなくなります。接続プールは、プール・ドライバを使用してHTTPサーブレットやEJBなどのサーバー・サイド・アプリケーションから利用できます。また、スタンドアロンのJavaクライアント・アプリケーションからも利用できます。
接続プーリングの最大のメリットとして、貴重なプログラム実行時間が節約され、オーバーヘッドがほとんど発生しないことがあげられます。DBMS接続の作成には非常に時間がかかります。接続プールを使用すると、ユーザーが必要とする前に接続は確立されて使用可能になります。また、必要に応じて、アプリケーション・コードで専用のJDBC接続を作成する方法もあります。DBMSの実行時に着信接続要求を処理する必要がある場合は、専用接続を使用すると処理が速くなります。
DBMSへのJDBC接続の確立には、非常に時間がかかる場合があります。アプリケーションでデータベース接続のオープンおよびクローズを繰り返す必要がある場合は、パフォーマンスの重大な問題になる可能性があります。この問題は、WebLogic ServerおよびOracle Application Serverの接続プールによって解決されます。
WebLogic ServerまたはOracle Application Serverを起動すると、接続プールからの接続がオープンされ、すべてのクライアントで使用できるようになります。クライアントが接続プールからの接続をクローズすると、その接続はプールに戻され、他のクライアントが使用できるようになります。接続自体はクローズされません。プール接続のオープンおよびクローズにはほとんどコストがかかりません。
プールに作成する接続の数について考えてみます。接続プールは、構成されたパラメータに応じて最小接続数と最大接続数の間で増減します。接続プール内の接続数を同時ユーザー数と同じにすると、常に最高のパフォーマンスが得られます。
多層構成の場合にのみ該当しますが、クラスタリングされたJDBCでは、サービスを提供しているクラスタ・メンバーに障害が発生した場合、接続パラメータを変更せずに外部JDBCクライアントでJDBC接続の再確立および再開を実行できます。WebLogicの場合、クラスタリングされたJDBCでDBMSに接続するには、データソース・オブジェクトおよびWebLogic RMIドライバが必要です。データソース・オブジェクトは、WebLogic Administration Consoleを使用してWebLogic Serverごとに定義します。
Oracleでは、OCIのTAF機能を活用することで、クラスタリングされたJDBCで提供される機能と同等以上の機能が提供されています。
OC4JでのJDBCアプリケーションのパフォーマンス・チューニングは、WebLogic Serverの場合と同様です。接続プーリングは、データベース接続の新規作成というコストのかかる操作を回避してパフォーマンスを向上させる場合に有効です。効率的なコードの作成に関するガイドラインは、Oracle Application ServerにもWebLogic Serverにも該当します。