この章では、Coherence、Coherence*Web、ActiveCacheおよびTopLink Gridを使用するアプリケーションを12c (12.1.2)にアップグレードする手順を説明します。
次の手順に従って、CoherenceおよびCoherence*Webを使用してWebLogic Serverで実行するアプリケーションをアップグレードします。
既存のWebLogic Serverドメインで次を実行します。
Coherence*Webを使用するアプリケーションを停止してアンデプロイします。
coherence.jar
およびcoherence-web-spi.war
ファイルをアンデプロイします(デプロイされている場合)。
手順に従って、WebLogic ServerとそのドメインをWebLogic Server 12c (12.1.2)にアップグレードします。WebLogic Serverのアップグレードについては、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』を参照してください。
coherence.jar
ファイルへの参照をすべて削除するようにアプリケーションを変更します。
weblogic.xml
ファイルで、coherence-web-spi
ファイルを参照する<library-ref>
要素を削除します。
META-INF/MANIFEST.MF
ファイルで、Coherenceを拡張として識別する次の行を削除します。
Extension-List: coherence coherence-Extension-Name: coherence
クラスパスにあるcoherence.jar
ファイルへの明示的な参照をすべて削除します。
Coherence 12c (12.1.2)で必要な設定を使用するようにアプリケーションを変更します。
Coherenceリリース3.7.1.xでデフォルトのsession-cache-config.xml
ファイルを使用していた場合、12c (12.1.2)では名前がdefault-session-cache-config.xml
に変更されたことに注意してください。
たとえば、このコンテキスト・パラメータ値をCoherenceリリース3.7.1.xアプリケーションで使用していたとします。
tangosol.coherence.cacheconfig=session-cache-config.xml
12c (12.1.2)では、これをdefault-session-cache-config.xml
に変更します。
tangosol.coherence.cacheconfig=default-session-cache-config.xml
セッション・キャッシュ・ファイル名を変更する必要はありません。カスタムのsession-cache-config.xml
を作成した場合、ファイル名はそのまま使用できます。
アプリケーションがEARファイル内にある場合、12c (12.1.2)ではカスタムのsession-cache-config
ファイルのパッケージ化が変更されています。12c (12.1.2)のパッケージ化の手順については、『Oracle Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のカスタム・セッション・キャッシュ構成ファイルの使用に関する項を参照してください。
アプリケーションをWebLogic Serverに再デプロイします。
次の項では、アプリケーション・スコープ、EARスコープおよびWARスコープが指定されたクラスタで実行するアプリケーションのアップグレード方法について説明します。アプリケーションをアップグレードする前に、Coherence側の構成を最初にアップグレードする必要があります。
次の手順に従って、Coherence側の構成をアップグレードします。12c (12.1.2)以前のCoherence JARを参照する、現在使用中の12c (12.1.2)以前のCoherenceキャッシュ・サーバー起動スクリプトをすべてアップグレードする必要があります。Coherenceに付属しているスクリプトは変更する必要はありません。
Coherenceサーバーを停止します。
クラスパス(WebLogic Server 12c (12.1.2)では${ORACLE_HOME}
)を変更するように、Coherenceキャッシュ・サーバー起動スクリプトを変更します。
—coherence.jar
を${ORACLE_HOME}/coherence/lib/coherence.jar
に置き換えます。
—javax.persistence_1.*.jar
を${ORACLE_HOME}/oracle_common/modules/javax.persistence_2.0.0.0_2-0.jar
に置き換えます。
—com.oracle.toplinkgrid_1.1.0.0_11-1-1-6-0.jar
を${ORACLE_HOME}/oracle_common/modules/oracle.toplink_12.1.2/toplink-grid.jar
に置き換えます。
—org.eclipse.persistence_1.2.0.0_2-3.jar
を${ORACLE_HOME}/oracle_common/modules/oracle.toplink_12.1.2/eclipselink.jar
に置き換えます。
Coherenceサーバーを再起動します。
アプリケーション・サーバー・スコープ指定されたアプリケーションをCoherenceクラスタで実行している場合は、次の手順に従ってCoherence 12c (12.1.2)にアップグレードします。
手順に従って、WebLogic ServerとそのドメインをWebLogic Server 12c (12.1.2)にアップグレードします。WebLogic Serverとそのドメインのアップグレードについては、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』を参照してください。
管理対象サーバーを起動する前に、次の手順に従ってWebLogic Server側の構成をアップグレードします。
注意: WebLogic Server 12c (12.1.2)では、 |
WebLogic Serverクラスパスから、toplink-grid.jar
ファイルへの明示的な参照をすべて削除します。次に、古い参照の例を示します。
com.oracle.toplinkgrid_1.1.0.0_11-1-1-6-0.jar javax.persistence_1.*.jar org.eclipse.persistence_1.2.0.0_2-3.jar
WebLogic Serverクラスパスから、coherence.jar
ファイルへの明示的な参照をすべて削除します。次に、古い参照の例を示します。
coherence.jar coherence-web.jar coherence-web-spi.war
WebLogic Serverを再起動します。
アプリケーションを再デプロイします。
EARスコープ指定されたTopLinkアプリケーションをCoherenceクラスタで実行している場合は、次のいずれかの方法で、Coherence 12c (12.1.2)を使用するようにアプリケーションをアップグレードできます。
GARファイル形式を使用するようにアプリケーションをアップグレードします。「GARファイル形式の使用」を参照してください。
共有ライブラリを更新します。「共有ライブラリの更新」を参照してください。
EARファイルにパッケージ化されているtoplink-grid.jar
およびcoherence.jar
ファイルを更新します。「EARファイルへのtoplink-grid.jarおよびcoherence.jarファイルのパッケージ化」を参照してください。
注意: 次の手順は、WebLogic ServerとそのドメインをWebLogic Server 12c (12.1.2)にアップグレード済であることを前提とします。WebLogic Serverのアップグレードについては、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』を参照してください。 |
GARファイル形式の使用
次の手順は、GARファイル形式を使用するようにアプリケーションをアップグレードすることを前提とします。このアプローチをお薦めします。GARファイル形式でのアプリケーションのパッケージ化の詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』のWebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。
アプリケーションおよびWebLogic Serverクラスパスから、CoherenceおよびTopLink Grid共有ライブラリへの参照をすべて削除します。
注意: WebLogic Server 12c (12.1.2)では、 |
次に、Coherenceへの参照の例を示します。
coherence.jar coherence-web.jar coherence-web-spi.war
次に、TopLink Gridへの参照の例を示します。
com.oracle.toplinkgrid_1.1.0.0_11-1-1-6-0.jar javax.persistence_1.*.jar org.eclipse.persistence_1.2.0.0_2-3.jar
weblogic-application.xml
ファイルから、coherence.jar
およびtoplink-grid.jar
への参照を削除します。
weblogic-application.xml
ファイルから、Coherenceクラスタのプロパティを構成する<coherence-cluster-ref>
要素を削除します。
フィルタリング・クラスローダーが構成済の場合は削除します。この機能は、weblogic-application.xml
ファイルの<prefer-application-packages>
要素で定義されます。coherence.jar
およびtoplink-grid.jar
ファイルを参照する<prefer-application-packages>
要素をすべて削除します。
toplink-grid.jar
およびcoherence.jar
ファイルをEARファイル内にパッケージ化している場合は、それらをEARファイルから削除します。
WebLogic ServerおよびCoherenceサーバーを再起動します。
アプリケーションを再デプロイします。
共有ライブラリの更新
このアプローチは、toplink-grid.jar
およびcoherence.jar
ファイルを共有ライブラリとして参照しており、アプリケーションのパッケージ化を変更しないことを前提にします。この場合は、12c (12.1.2)バージョンのtoplink-grid.jar
およびcoherence.jar
ファイルを共有ライブラリとして再デプロイする必要があります。
EARファイルへのtoplink-grid.jarおよびcoherence.jarファイルのパッケージ化
このアプローチは、toplink-grid.jar
およびcoherence.jar
ファイルをEARファイルにパッケージ化していることを前提とします。この場合は、toplink-grid.jar
およびcoherence.jar
ファイルを、これらのファイルの12c (12.1.2)バージョンに置き換えます。
WARスコープ指定されたTopLinkアプリケーションをCoherenceクラスタで実行している場合は、次のいずれかの方法で、Coherence 12c (12.1.2)を使用するようにアプリケーションをアップグレードできます。
共有ライブラリを更新します。「共有ライブラリの更新」を参照してください。
WARファイルにパッケージ化されているtoplink-grid.jar
およびcoherence.jar
ファイルを更新します。
注意: 次の手順は、WebLogic ServerとそのドメインをWebLogic Server 12c (12.1.2)にアップグレード済であることを前提とします。WebLogic Serverのアップグレードについては、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』を参照してください。 |
共有ライブラリの更新
このアプローチは、toplink-grid.jar
およびcoherence.jar
ファイルを共有ライブラリとして参照しており、アプリケーションのパッケージ化を変更しないことを前提にします。この場合に必要な操作は、12c (12.1.2)バージョンのtoplink-grid.jar
およびcoherence.jar
ファイルを使用するように共有ライブラリ参照を更新することのみです。
WARファイルへのtoplink-grid.jarおよびcoherence.jarファイルのパッケージ化
このアプローチは、toplink-grid.jar
およびcoherence.jar
ファイルをEARファイルにパッケージ化していることを前提とします。この場合は、toplink-grid.jar
およびcoherence.jar
ファイルを、これらのファイルの12c (12.1.2)バージョンに置き換えます。
すべてのExtendクライアントのカスタマ(Java、C++および.NET)において、Coherence*Extendクライアントをアップグレードする前にクラスタ側をアップグレードする必要があります。これは、Coherenceクライアントおよびプロキシ・アップグレード・ポリシーに準拠しています。Coherence*Extendの現行リリースと以前のバージョンとの互換性の詳細は、『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』のCoherence*Extendのバージョン間の互換性に関する項を参照してください。
次の項では、Coherence*Webのアップグレードに関する考慮事項を説明します。
以前のリリースのCoherence*Webに含まれていたcoherence-web-spi.war
ファイルは、12c (12.1.2)では非推奨です。Coherence 12c (12.1.2)ディストリビューションではcoherence\lib
ディレクトリにcoherence-web-spi.war
ファイルが含まれていますが、このファイルは以前のバージョンのWebLogic Serverとの後方互換性を維持する目的でのみ提供されています。WebLogic Server 12c (12.1.2)以降を使用している場合は、このファイルを使用または参照する必要はありません。coherence-web-spi.war
ファイルをWebLogic Server 12c (12.1.2)以降にデプロイしようとしても無視されます。
デプロイされたアプリケーションでCoherenceデータ・キャッシュを簡単に使用し、セッション管理のためにCoherence*Webをシームレスに統合するためのWebLogic Serverの機能の集合であるActiveCacheは、主に以前のリリースで開発されたアプリケーションのアップグレードをサポートする目的で、12c (12.1.2)で引き続きサポートされます。ユーザーは、新しいWebLogic Server/Coherenceアプリケーションを開発するときに管理対象Coherenceサーバーの使用を検討することをお薦めします。ActiveCacheの詳細は、『Oracle Fusion Middleware ActiveCacheの使用』を参照してください。
以前のリリースでは、Coherence*Web SPIで使用されるCoherenceキャッシュ構成とサービスはsession-cache-config.xml
ファイルで定義されていましたが、12c (12.1.2)以降は、Coherence*Webで使用されるCoherenceキャッシュ構成とサービスはdefault-session-cache-config.xml
ファイルで定義され、このファイルはcoherence-web.jar
ファイル内にあります。default-session-cache-config.xml
ファイルで定義されているデフォルト・キャッシュ構成とサービス構成は、ほとんどすべてのWebアプリケーションに対応可能です。
Webアプリケーションでsession-cache-config.xml
という名前のファイルをパッケージ化して、独自のカスタム・セッション・キャッシュ構成を作成できます。詳細は、『Oracle Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のカスタム・セッション・キャッシュ構成ファイルの使用に関する項を参照してください。
The 11gリリース1 (10.3.6)バージョンのActiveCacheは、『Oracle Fusion Middleware ActiveCacheの使用』に記載されています。このバージョンのActiveCacheは、WebLogic ServerおよびCoherence 12c (12.1.2)に対して機能しますが、記載されている手順の一部は不要になりました。
ActiveCacheデプロイメント・トポロジの選択に関する項では、ActiveCacheをデプロイできるアプリケーションとデータ層の組合せ、すなわちクラスタ・トポロジについて説明しています。ActiveCacheを使用してアプリケーションをアップグレードする場合、後方互換性が必要な場合以外はOut-of-Processトポロジを使用しないでください。現行リリースでは、WebLogic Out-of-Processトポロジの使用をお薦めします。管理対象Coherenceサーバーを使用すれば、WebLogic Out-of-Processトポロジの構成が容易に行えます。
Cache Configuration Fileの配置に関する項では、キャッシュ構成ファイルを配置する場所を説明しています。キャッシュ構成ファイルを保存する場所によってキャッシュ・スコープ(つまり、デプロイされたアプリケーションに対するキャッシュの可視性)が決まります。この項に記載している方法は有効ですが、キャッシュ構成をシステム・クラスパスに配置することは、サーバーでCoherenceを使用するアプリケーションが現在も今後も1つしか存在しない場合を除き、お薦めできません。
アプリケーションをパッケージする場合は、GARファイルの使用をお薦めします。キャッシュ構成ファイルは、GARファイルにパッケージ化されます。GARファイルおよびそのパッケージ化構造の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
アプリケーション・サーバー・スコープのCoherenceクラスタの構成に関する項では、Coherenceキャッシュに直接アクセスしているWebLogic Serverインスタンス上でデプロイされたすべてのアプリケーションが、1つのCoherenceクラスタの一部となるような構成について説明しています。この手順では、手順1を実行しないでください。すなわち、coherence.jar
およびactive-cache.jar
ファイルをシステム・クラスパスに配置しないでください。active-cache.jar
ファイルでは、Coherence統合モジュールをクラスパスに追加するために、MANIFEST
ファイルでクラスパスを使用します。リリース12c (12.1.2)において、Coherence統合モジュールはcoherence.jar
に加えてサーバー・クラスパスに常に存在します。
EARスコープのCoherenceクラスタの構成に関する項では、各EAR内にデプロイされたすべてのアプリケーションが、1つのCoherenceクラスタの一部となるような構成について説明しています。キャッシュは、EAR内のすべてのモジュールに対して表示されます。この項で説明している手順は、説明どおりには動作しません。coherence.jar
がすでにシステム・クラスパスに配置されているため、「アプリケーション・スコープCoherenceクラスタにフィルタリング・クラスローダーを定義するには」の項に記載されている手順に従う必要があります。
EARスコープによる方法を使用する唯一の理由は、アプリケーションを他のCoherenceアプリケーションから分離するためです。この使用例は、GARファイルによるアプリケーション分離またはキャッシュ構成ファイルのscope
要素を使用する方がうまく処理できます。別の使用例は、システム・クラスパスに配置されているものとは別バージョンのcoherence.jar
を使用することですが、別バージョンの使用はお薦めできません。
WARスコープのクラスタの構成に関する項では、デプロイされた各Webアプリケーションが、独自のCoherenceクラスタになるような構成について説明しています。キャッシュは、個々のモジュールに対してのみ表示されます。この手順では、手順1および2を実行しないでください。coherence.jarおよびactive-cache.jarを共有ライブラリにデプロイせず、MANIFEST
ファイルにも記載しないでください。手順3を実行してCoherenceクラスタのシステム・リソースを参照することは可能ですが、管理対象サーバーをCoherenceクラスタのメンバーにする方法をお薦めします。
「例3-10 tangosol-coherence-override.xml」は、ロギングの構成を記述したカスタム・キャッシュ構成ファイルを示しています。リリース12c (12.1.2)ではログが統合されているため、ロギング構成は必要ありません。
キャッシュ・サーバーの起動に関する項には、キャッシュ・サーバーを起動する数種類の方法が示されています。Out-of-Processトポロジを管理対象Coherenceサーバーで置き換えないでください。ノード・マネージャを使用したキャッシュ・サーバーの起動に関する項に記載されている手順を、WebLogic Serverにより管理されている外部キャッシュ・サーバーのかわりに管理対象Coherenceサーバーを使用して実行しないでください。
この項では、Coherence 12c (12.1.2)で非推奨となった機能の代替について説明します。
packet-pool
およびmessage-pool
要素は非推奨です。Coherence 12c (12.1.2)では、APIでサイズ変更を処理するようになりました。アップグレードするには、すべての構成ファイルから要素を削除してください。
Coherence 12c (12.1.2)リリース以降、LHストア・マネージャは非推奨です。Berkeley DBの同様の機能を使用してください。
NamedCache
lock
APIは非推奨です。入力プロセッサAPI (JavaおよびC++用のEntryProcessor
、および.NET用のIEntryProcessor
)で提供されるロック・サポートをかわりに使用してください。
Coherence 12c (12.1.2)リリースでは、com.tangosol.run.xml.XmlConfigurable
インタフェースは非推奨になりました。Coherenceでは、このインタフェースを使用して、XMLパラメータをカスタム・クラスのインスタンスに注入していました。
注意:
|
Coherence 12c (12.1.2)リリースでは、<param-value>
要素内に<instance>
および<class-scheme>
(または、その他のカスタム・ネームスペース)をネストするXMLを記述して、パラメータを初期化できます。
たとえば、次のJavaコードを考えてみます。
public class MyClass { public MyClass(String s, OtherClass o, int i) { ... } } public class OtherClass { public OtherClass(String s) { ... } }
次のXMLを記述して、MyClass
およびOtherClass
クラスを初期化できます。XMLでは、MyClass
クラスが文字列Hello
World
および整数42
で初期化されます。MyClass
クラス内にあるOtherClass
クラスのインスタンスは、文字列Goodbye
World
で初期化されます。
<instance> <class-name>MyClass</class-name> <init-params> <init-param> <param-value>Hello World</param-value> </init-param> <init-param> <param-value> <instance> <class-name>OtherClass</class-name> <init-params> <init-param> <param-value>Goodbye World</param-value> </init-param> </init-params> </instance> </param-value> </init-param> <init-param> <param-value>42</param-value> </init-param> </init-params> </instance>
次の項では、Coherence 12c (12.1.2)のアップグレード時に考慮する必要がある問題について説明します。
Exalogic環境内では、DistributedCache
がExabusの最適化されたトランスポートにデフォルト設定されるようになりました。詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のDistributedCacheサービス・パラメータに関する項にある<reliable-transport
要素の説明を参照してください。
リモートRMIクライアント(別の物理コンピュータ)から接続するときは、java.rmi.server.hostname
RMIシステム・プロパティの値をクラスタ・メンバーのIPアドレスに設定してスクリプトに追加してください。このアドレスによって、クライアントに送信されるRMIスタブに正しいサーバー・アドレスが含まれることが保証されます。詳細は、『Oracle Fusion Middleware Oracle Coherenceのマネージメント』のOracle Coherence MBeanへのリモート・アクセスの許可に関する項を参照してください。
キー・アソシエーションは、Extendクライアント上でデフォルトで処理されるようになります。クラスタ上のキー・クラスを強制的に処理するために、クラスタ上でキー・アソシエーションに依存している既存のクライアント実装(Javaクライアントを含む)でdefer-key-association-check
パラメータを設定する必要があります。
キー・アソシエーション処理をExtendクライアントによってではなくクラスタ側で実行するには、クライアント側キャッシュの構成で<remote-cache-scheme>
要素内の<defer-key-association-check>
要素をtrueに設定します。次に例を示します。
<remote-cache-scheme> ... <defer-key-association-check>true</defer-key-association-check> </remote-cache-scheme>
詳細は、『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』のキー・アソシエーション・チェックの遅延に関する項を参照してください。
パフォーマンスよりもネットワーク・トラフィックの軽減を優先するために、デフォルトのニア・キャッシュ無効化戦略のauto
が変更されました。12c (12.1.2)以前の無効化戦略のデフォルト動作は、all
に設定してください。詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のニア・キャッシュの無効化戦略に関する項を参照してください。
BACKUP
CACHE
文を使用して、指定されたキャッシュのシリアライズ形式を、指定されたファイル名で表されるファイルに書き込みます。3.xから12.1.xの間に、バックアップの前方互換性または後方互換性はありません。『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のキャッシュのシリアライズされた形式のファイルへの書込みに関する項を参照してください。
resource-config
要素には、com.sun.jersey.api.core.ResourceConfig
クラスを拡張するクラスの構成情報を記述します。HTTPアクセプタでインスタンスを使用して、指定のコンテキスト・パスにマップされているCoherence RESTアプリケーション用のリソースとプロバイダ・クラスをロードします。複数のリソース構成クラスを構成して、異なるコンテキスト・パスにマップできます。詳細は、『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』の組込みHTTPサーバーを指定したデプロイに関する項を参照してください。
Coherence 12c (12.1.2)は、Oracle HotSpot JVM 1.7および1.7レベルのその他のJVMでサポートされています。JRockit 1.7は含まれないため、JRockitは必要ありません。ExtendクライアントはJVM 1.6以降(JRockitを含む)でサポートされています。詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のJVMの推奨事項に関する項を参照してください。