ヘッダーをスキップ
Oracle Application Server WebLogicからの移行
10gリリース3(10.1.3.1.0)
B31844-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

6 JDBCの移行

この章では、WebLogic ServerからOracle Application Serverにデータベース・アクセス・コードを移行する場合に必要な情報について説明します。具体的には、JDBCドライバ、データソースおよび接続プーリングの移行について説明します。

ここで説明する内容は次のとおりです。

6.1 概要

WebLogic Serverにデプロイされたアプリケーションのうち、JDBC(特にWebLogic JDBCドライバ)を使用するアプリケーションをOC4JおよびOracle JDBCドライバに移行する作業は簡単であり、移行するアプリケーションのコードを変更する必要はほとんどありません。まったくない場合もあります。JDBCの標準仕様に準拠して作成されたアプリケーションはすべて正常に動作し、最小限の作業で移行できます。主な作業は、新しい環境でのアプリケーションの構成およびデプロイです。独自の拡張機能が使用されている場合にのみ、移行作業が複雑になります。

6.1.1 データベース・アクセスを実装する場合のWebLogicとOracle Application Serverの相違点

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ドライバの概要を示します。

6.1.1.1 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でのデータソースの構成に関する項に進んでください。

6.2 データソースの移行

JDBC 2.0仕様では、java.sql.Datasourceクラスが導入され、JDBCプログラムが100%移植可能になりました。このバージョンでは、ベンダー固有の接続URLおよびマシンとポートの依存性が削除されました。また、このバージョンでは、java.sql.DriverManagerDriver、および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オブジェクトを参照できます。

6.2.1 データソースのインポート文

DataSourceオブジェクトをJNDIと併用することによって、データベースに接続するための接続プールにアクセスできます。データソースごとに個別のDataSourceオブジェクトが必要です。DataSourceオブジェクトは、接続プーリングまたは分散トランザクションのいずれかをサポートするDataSourceクラスとして実装できます。

DataSourceオブジェクトを使用するには、クライアント・コードに次のクラスをインポートします。

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

WebLogic Serverの場合はweblogic.jdbc.*パッケージ、OC4Jの場合はoracle.jdbc.*パッケージを使用します。

6.2.2 アプリケーション・サーバーでのデータソースの構成

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-locationejb-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ファイルの構成パラメータ

パラメータ 説明

class

データソースのクラス名。

connection-driver

JDBCのクラス名。

connection-retry-interval

失敗した接続を再試行するまでの待機時間(秒)。

デフォルト値は1秒です。

ejb-location

EJB対応のプーリングされたバージョンのデータベースをバインドするためのJNDIパス。このバージョンは、コンテナ管理のトランザクションで使用されます。このタイプのデータソースは、EJBおよび同様のオブジェクト内から使用されます。

このパラメータが適用されるのは、ConnectionDataSourceのみです。

inactivity-timeout

使用されていない接続がクローズされるまでキャッシュされる時間(秒)。

location

データソースをバインドするためのJNDIパス。

max-connect-attempts

失敗した接続を再試行する回数。

デフォルトは3回です。

max-connections

データソースをプーリングするためにオープンしておく接続の最大数。

min-connections

データソースをプーリングするためにオープンしておく接続の最小数。

デフォルトは0(ゼロ)です。

name

データソースの表示名。

password

データソースにアクセスするためのユーザー・パスワード(オプション)。

pooled-location

プーリングされたバージョンのデータソースをバインドするためのJNDIパス。

このパラメータが適用されるのは、ConnectionDataSourceのみです。

データベースに接続するためのdatabase-schemaファイルへの相対パスまたは絶対パス。

source-location

特殊なデータソースの基礎となるデータソース。

url

データソースのJDBC URL(java.sql.Connectionsを処理する一部のデータソースで使用)。

username

データソースにアクセスするためのユーザー名(オプション)。

wait-timeout

すべての接続が使用されている場合に接続が解放されるまでの待機時間(秒)。

デフォルトは60です。

xa-location

トランザクション・バージョンのデータソースをバインドするためのJNDIパス。

このパラメータが適用されるのは、ConnectionDataSourceのみです。

xa-source-location

特殊なデータソースの基礎となるXADataSourceOrionCMTDataSourceで使用)。


6.2.3 データソース・オブジェクトを使用したクライアント接続の取得

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ドライバを使用できるようになります。

6.3 接続プールの移行

ほとんどのWebベースのリソース(サーブレット、アプリケーション・サーバーなど)は、データベース内の情報にアクセスします。リソースは、データベースへのアクセスを試行するたびに、データベースへの接続を確立し、接続の作成および維持にシステム・リソースを使用する必要があります。また、接続が不要になった場合、その接続を解放するためにもシステム・リソースを使用する必要があります。リソースのオーバーヘッドは、Webベースのアプリケーションで特に大きくなります。これは、Webユーザーが頻繁かつ大量に接続および切断を行うためです。多くの場合、データのやり取り自体で消費されるリソースより、接続および切断で消費されるリソースの量のほうが多くなります。

接続プーリングを使用すると、接続のオーバーヘッドを多数のユーザー・リクエストに分散することによって、接続リソースの使用を制御できます。接続プールは、一連の接続オブジェクトをキャッシュしたもので、複数のクライアントがデータベースのリソースにアクセスする必要がある場合に、それらのクライアントによって共有されます。プール内の接続を作成するためのリソースは、指定した数の接続に対して一度のみ使用されます。各クライアントがリソースを使用して専用の接続をオープンし、データベース操作の完了時に接続をクローズするのではなく、接続はオープンされたままになり、多数のクライアント・リクエストによって繰り返し使用されます。接続プーリングでは、次の方法でパフォーマンス全体が向上されます。

JDBC 2.0仕様では、次の目的でJDBCデータソース接続のプールを定義できます。

これらの目的を実現するには、次の手順を実行します

  1. 接続プールの最大サイズ・プロパティを、同時にアクティブとなるユーザー・リクエストの予想最大数と同じ値に設定します。

  2. 接続プールの最小サイズ・プロパティを、同時にアクティブとなるユーザー・リクエストの予想最小数と同じ値に設定します。

接続プーリングのプロパティによって、ユーザー・リクエスト数の減少に合せて接続が段階的にプールから削除されるようになります。同様に、ユーザー・リクエスト数の増加に合せて新しい接続が作成されます。接続の再利用が最大になり、接続作成のオーバーヘッドが最小になるように、接続のバランスが維持されます。また、接続プーリングを使用して、データベースへの同時接続の数を制御することもできます。

6.3.1 接続プールの概要

接続プールは、すぐに使用できるDBMSへの接続のプールです。データベース接続は、接続プールの起動時にすでに確立されているため、データベース接続の確立に要するオーバーヘッドはなくなります。接続プールは、プール・ドライバを使用してHTTPサーブレットやEJBなどのサーバー・サイド・アプリケーションから利用できます。また、スタンドアロンのJavaクライアント・アプリケーションからも利用できます。

接続プーリングの最大のメリットとして、貴重なプログラム実行時間が節約され、オーバーヘッドがほとんど発生しないことがあげられます。DBMS接続の作成には非常に時間がかかります。接続プールを使用すると、ユーザーが必要とする前に接続は確立されて使用可能になります。また、必要に応じて、アプリケーション・コードで専用のJDBC接続を作成する方法もあります。DBMSの実行時に着信接続要求を処理する必要がある場合は、専用接続を使用すると処理が速くなります。

6.3.2 接続プールによるパフォーマンスの向上

DBMSへのJDBC接続の確立には、非常に時間がかかる場合があります。アプリケーションでデータベース接続のオープンおよびクローズを繰り返す必要がある場合は、パフォーマンスの重大な問題になる可能性があります。この問題は、WebLogic ServerおよびOracle Application Serverの接続プールによって解決されます。

WebLogic ServerまたはOracle Application Serverを起動すると、接続プールからの接続がオープンされ、すべてのクライアントで使用できるようになります。クライアントが接続プールからの接続をクローズすると、その接続はプールに戻され、他のクライアントが使用できるようになります。接続自体はクローズされません。プール接続のオープンおよびクローズにはほとんどコストがかかりません。

プールに作成する接続の数について考えてみます。接続プールは、構成されたパラメータに応じて最小接続数と最大接続数の間で増減します。接続プール内の接続数を同時ユーザー数と同じにすると、常に最高のパフォーマンスが得られます。

6.4 クラスタリングされたJDBCの概要

多層構成の場合にのみ該当しますが、クラスタリングされたJDBCでは、サービスを提供しているクラスタ・メンバーに障害が発生した場合、接続パラメータを変更せずに外部JDBCクライアントでJDBC接続の再確立および再開を実行できます。WebLogicの場合、クラスタリングされたJDBCでDBMSに接続するには、データソース・オブジェクトおよびWebLogic RMIドライバが必要です。データソース・オブジェクトは、WebLogic Administration Consoleを使用してWebLogic Serverごとに定義します。

Oracleでは、OCIのTAF機能を活用することで、クラスタリングされたJDBCで提供される機能と同等以上の機能が提供されています。

6.5 JDBCのパフォーマンス・チューニング

OC4JでのJDBCアプリケーションのパフォーマンス・チューニングは、WebLogic Serverの場合と同様です。接続プーリングは、データベース接続の新規作成というコストのかかる操作を回避してパフォーマンスを向上させる場合に有効です。効率的なコードの作成に関するガイドラインは、Oracle Application ServerにもWebLogic Serverにも該当します。