ヘッダーをスキップ

Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド
10g（10.1.3.1.0）
B31852-03
目次
目次		 索引
索引

戻る 次へ

28 OC4JへのEJBアプリケーションのデプロイ

この項の内容は次のとおりです。

詳細は、次を参照してください。

注意

Application Server Controlを使用している場合、セッションBeanとともにデプロイされるEJB 3.0エンティティは、EJB JARモジュールのApplication Server Controlビューには表示されません。詳細は、「Oracle Enterprise Manager 10g Application Server Controlの使用方法」を参照してください。 

大規模なEJBアプリケーションのデプロイ

この項の内容は次のとおりです。

詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』の大規模アプリケーションのデプロイに関する項を参照してください。

デプロイ時のメモリー不足エラーを回避するためのVMの調整

非常に大きなアプリケーション（EAR）がOC4Jにデプロイされる場合、デプロイ時にOutOfMemory例外がスローされることがあります。

VMヒープおよび永続領域構成により、このような例外が発生することがあります。デフォルトでは、ヒープおよび永続領域は64MBに設定されます。

ヒープ領域の問題がある場合は、ヒープ領域をjava -Xmx750m -Xms512mと指定する必要があります。

永続領域の問題がある場合は、永続領域をjava -Xmx750m -Xms512m -XX:PermSize=128m -XX:MaxPermSize=256mと指定する必要があります。

デプロイ時のメモリー不足エラーを回避するための一時ディレクトリの構成

デプロイ・プロセスがなんらかの理由で中断された場合、tempディレクトリのクリーンアップが必要となる場合があります。このディレクトリは、デフォルトでシステム上の/var/tmpです。デプロイ・ウィザードによって、デプロイ・プロセス時に情報を格納するために、一時ディレクトリのスワップ領域で20MBが使用されます。プロセス完了時に、tempディレクトリから追加のファイルがクリーンアップされます。ただし、ウィザードが中断されると、tempディレクトリをクリーンアップする時間や機会がない場合があります。したがって、このディレクトリから追加のデプロイメント・ファイルを手動でクリーンアップする必要があります。クリーンアップを実行しないと、ディレクトリがいっぱいになる可能性があり、その後のデプロイができなくなります。OutOfMemory例外を受信した場合は、tempディレクトリの使用可能領域をチェックしてください。

tempディレクトリを変更するには、OC4Jプロセスのコマンドライン・オプションをjava.io.tmpdir=<new_tmp_dir>に設定します。このコマンドライン・オプションは「サーバー・プロパティ」ページで設定できます。最初にOC4Jのホームページにドリルダウンします。次に「管理」セクションにスクロールダウンします。「サーバー・プロパティ」を選択します。このページで、「コマンドライン・オプション」セクションにスクロールダウンし、「OC4Jオプション」行にjava.io.tmpdirの変数定義を追加します。新規OC4Jプロセスはすべて、このプロパティを使用して起動されます。

デプロイ時のメモリー不足エラーを回避するためのバッチ・コンパイルの無効化

アプリケーション（EAR）に複数のJARファイルが含まれている場合は、OutOfMemory例外を修正するようにバッチ・デプロイを無効にできます。ただし、EARファイルにJARファイルが1つのみ含まれている場合、このアプローチではこのような例外が修正されません。この場合は、VMを調整する必要があります（「デプロイ時のメモリー不足エラーを回避するためのVMの調整」を参照）。

OC4Jがデプロイ時にOutOfMemory不足例外をスローし、VMの調整（「デプロイ時のメモリー不足エラーを回避するためのVMの調整」を参照）と一時ディレクトリの調整（「デプロイ時のメモリー不足エラーを回避するための一時ディレクトリの構成」を参照）をすでに試した場合は、非バッチ・モードでコンパイルを試すこともできます。非バッチ・モードでは必要なメモリー量が少なくなりますが、このモードではデプロイ時間が長くなります。

バッチ・コンパイルを有効または無効にするには、<application>または<orion-application>要素の属性batch-compileを使用します。

batch-compileのデフォルト値はtrueです。

バッチ・コンパイルを無効にするには、この属性をfalseに設定します。

例28-1に、orion-applicatin.xmlデプロイメント・ディスクリプタでこの属性を構成する方法を示します。

例28-1    orion-application.xmlファイルでのバッチ・コンパイルの無効化

<orion-application batch-compile ="false">
...
</orion-application>

メモリー不足エラーが解決しない場合は、バッチ・コンパイルの無効化を試します。

増分デプロイ

OC4Jでは、デプロイされたアプリケーションの一部であるEJBモジュールの増分または部分的な再デプロイがサポートされます。この機能により、モジュール全体を再デプロイする必要なく、EJB JAR内の変更されたBeanのみ再デプロイできます。以前にデプロイされ、変更されていないBeanは、引き続き使用されます。

この機能は、OC4Jの以前のリリースよりも大幅に拡張されています。以前のリリースでは、EJBモジュールが1つの単位として扱われ、最初にモジュールをアンデプロイしてから更新とともに再デプロイする必要がありました。

OC4Jの再起動は、再デプロイ・プロセス中にEJB構成データに変更が行われた場合にのみ必要です。変更が行われていない場合は、OC4Jを再起動せずにホット・デプロイを実行できます。

増分再デプロイ操作は、Enterprise Beanを含む更新対象のアプリケーションを自動的に停止してから、終了時にアプリケーションを自動的に再起動します。

注意

再デプロイ時に、更新されるEnterprise Beanへのすべてのアイドル・クライアント接続は失われます。すべての既存のリクエストは完了できますが、新しいリクエストはアプリケーションが再起動するまで許可されません。Enterprise Beanを再デプロイする前に、アプリケーションを停止することを強くお薦めします。 

CMPまたはBMPエンティティBeanの場合、OC4Jはコード生成機能を使用してEJBインタフェースのサーバー実装（ラッパー）を生成します。この場合、一般的には、アプリケーション全体を再デプロイするよりも変更されたBeanのみを増分再デプロイする方が効率的です。

セッションBean、メッセージドリブンBeanおよびEJB 3.0 JPAエンティティの場合、OC4Jはバイト・コード生成機能を使用してラッパーを生成します。この方法ではデプロイ時間が大幅に短縮されるため、アプリケーション全体を再デプロイしても変更されたBeanのみを再デプロイしても効率的には同じになる可能性があります。この場合、増分再デプロイの実行は任意です。

増分デプロイを使用するための一般的な手順は、次のとおりです。

  1. 多数のEnterprise Beanがあるアプリケーションをデプロイします。

  2. EJBモジュールでBean関連のクラス・ファイルを変更し、EJB JARファイル（myBeans-ejb.jarなど）を再構築します。

  3. 次のいずれかを使用して、更新されたEJB JARをOC4Jに発行します。

    • JDeveloper

    • Enterprise Manager

    • <OC4J_HOME>¥j2ee¥home¥admin.jarまたはadmin_client.jar（updateEBJModuleコマンドを使用）

    例28-2に、admin.jarの使用方法を示します。

    例28-2    admin.jarを使用した増分デプロイ

    java -jar admin.jar ormi://localhost:23791 admin welcome -application -updateEJBModule -jar myBeans-ejb.jar

  4. 手順2と3を繰り返します。

詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』の更新されたEJBモジュールの増分再デプロイに関する項を参照してください。

展開デプロイ

通常、アプリケーションは、OC4Jにデプロイする前にEARファイルにパッケージ化します。ただし、アプリケーションは、展開ディレクトリ構造に配置したままの状態でデプロイできます。この方法は、パッケージ化の手順を省略できるため、デプロイ時とテスト時に役立ちます。たとえば、JDeveloperを使用して、展開ディレクトリ構造のアプリケーションを操作できます。展開デプロイを使用すると、各デプロイの前に再アーカイブすることなく、何度でも展開ディレクトリ構造をデプロイできます。

展開デプロイ用にOC4Jを構成するには、<OC4J_HOME>¥j2ee¥home¥config¥server.xmlファイルを編集します。使用するアプリケーションのapplication要素を変更し、pathにそのアプリケーションの展開ディレクトリのルートを指定します。例28-3に、path属性を展開ディレクトリのルートに設定したアプリケーションmyappのapplication要素を示します。

例28-3    展開デプロイ用のserver.xml

<application-server  ...>
    ...
    <!-- Regular EAR deployment -->
    <application name="app" path="../../home/applications/app.ear" start="true" />

    <!-- Expanded deployment -->
    <application name="myapp" path="C:/projects/myapp" start="true" />
    ...
</application-server>

アプリケーション・デプロイのトラブルシューティング

1つ以上のアノテーションのあるEJB 3.0アプリケーションのデプロイ時に、OC4Jはそのメモリー内のejb-jar.xmlファイルをデプロイ・ディレクトリ内のorion-ejb-jar.xmlファイルと同じ場所（<ORACLE_HOME>/j2ee/home/application-deployments/
my_application/META-INF）に自動的に書き込みます。

このejb-jar.xmlファイルは、アノテーションとデプロイ済ejb-jar.xmlファイル（存在する場合）の両方から取得された構成を表します。

EJB 2.1アプリケーションをデプロイする場合、生成されたラッパー・コードを保持するには、システム・プロパティKeepWrapperCodeを設定する必要があります（「生成されたラッパー・コードのデバッグ」を参照）。

詳細は、「EJBアプリケーションのトラブルシューティング」を参照してください。

戻る 次へ
Oracle
Copyright © 2002, 2008 Oracle Corporation.
All Rights Reserved.
目次
目次		 索引
索引