この章では、既存のOracle Coherenceドキュメント・ライブラリ(『Oracle Coherenceスタート・ガイド』、『Oracle Coherence開発者ガイド』および『Oracle Coherenceユーザーズ・ガイド』)への変更、追加および修正の内容について説明します。Oracle Coherenceの最新ドキュメント・ライブラリは、次のURLで入手できます。
http://download.oracle.com/docs/cd/E13924_01/index.htm
この章の内容は次のとおりです。
表2-1は、Coherence*Webセッション管理モジュールでサポートされているWebコンテナと、それぞれのWebコンテナに固有のインストール情報をまとめたものです。
表 2-1 Coherence*WebでサポートされているWebコンテナ
注意:
* -server
コマンドライン・オプションを使用してCoherence*Webインストーラに渡されるサーバー・タイプの別名
Java EEアプリケーションでCoherence*Webを有効にするには、デプロイ前に、デプロイ準備ができているアプリケーション(推奨)を、自動インストーラを使用して実行する必要があります。自動インストーラで、アプリケーションをデプロイする準備が行われます。
デプロイするJava EEアプリケーション用にCoherence*Webをインストールするには:
アプリケーション・ディレクトリ、.ear
ファイルまたは.war
ファイルが、別のプロセスで使用またはアクセスされていないことを確認します。
現在のディレクトリをCoherenceライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib
、UNIXの場合は$COHERENCE_HOME/lib
)。
Javaコマンドが実行されるようにパスを構成します。
アプリケーションのフルパスおよび前述の表にあるサーバー名を指定して次のコマンドを実行し(コマンドラインで<app-path>
および<server-type>
を置き換える)、アプリケーションの検査手順を完了します。
java -jar webInstaller.jar <app-path> -inspect -server:<server-type>
アプリケーションが配置されているディレクトリで、Java EEアプリケーション用のコンフィギュレーション・ディスクリプタ・ファイルcoherence-web.xmlが作成または更新されます(すでに存在する場合)。このコンフィギュレーション・ディスクリプタには、インストーラが推奨するCoherence*Webのデフォルト設定が含まれています。このままインストール手順に進むか、設定を確認し、必要に応じて変更してからインストール手順に進むことができます。たとえば、coherence-web.xml
コンフィギュレーション・ディスクリプタでcontext-param
オプションを設定すると、特定の機能を有効化できます。
表2-2に示す設定では、すべてのServletContext
(グローバル)属性がクラスタ化され、クラスタ内のサーバーがこれらの属性に同じ値を共有し、これらの属性が変更されたときにサーブレット仕様で指定したイベントを受信します。
表2-3の設定により、アプリケーション内に存在するすべてのセッションを列挙するか、任意の1つのセッションを取得して、調査または操作できます。
表2-4の設定により、(SecureRandom
アルゴリズムを使用して生成される)HttpSession
IDの長さを拡大できます。長さの値に制限はありませんが、実際には(セッションIDの維持方法に応じて)CookieまたはURLに収まるように短くする必要があります。このIDを長くすると、セッションが意図的にハイジャックされる可能性が低くなります。
デフォルトでは、HttpSession
IDはCookie内で管理されます。アプリケーションでURLエンコーディングがサポートされている場合は、表2-5のオプションを設定して有効にします。
これらの変更が行われていることを二重にチェックした後で、ファイルを保存してエディタを終了します。シェルまたはコマンドラインから作業している場合は、必ずCoherenceのライブラリ・ディレクトリに戻ってください。
アプリケーションのフルパスを指定して次のコマンドを実行し(コマンドラインで<app-path>
を置き換える)、Coherence*Webアプリケーションのインストールを実行します。
java -jar webInstaller.jar <app-path> -install
インストーラで使用する有効なcoherence-web.xml
コンフィギュレーション・ディスクリプタが、アプリケーションと同じディレクトリ内に存在する必要があります。
更新済のアプリケーションをデプロイし、必要に応じてロード・バランサを使用して、すべてが予想どおりに機能することを確認します。ロード・バランサはテストのみを目的としているため、本番環境では使用しないでください。
Coherence*Webセッション管理モジュールをCaucho Resin 3.0.xサーバーにインストールする場合の追加手順は次のとおりです。
Coherenceのlibraryディレクトリ内で、webInstaller.jar
からcoherence-web.jar
を抽出します。
jar -xvf webInstaller.jar web-install/coherence-web.jar
これにより、coherence-web.jar
ファイルがweb-install
というサブディレクトリに抽出されます。次のコマンドを使用して、coherence-web.jar
ファイルをlibrary
ディレクトリ内の1つ上のレベルに移動します。
Windowsの場合:
move web-install\coherence-web.jar . rmdir web-install
UNIXの場合:
mv web-install/coherence-web.jar . rmdir web-install
サーバー・クラスタで実行するResinのインストールごとに、次のコマンドを使用してライブラリを更新します(ここでは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller <resin-home-path> -install
たとえば、Windowsでは次のようになります。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller C:\opt\resin30 -install
Coherence*Webセッション管理モジュールの一般的なインストール手順に従って、サーバー・タイプにResin/3.0.xを指定します。
Coherence*Webセッション管理モジュールをCaucho Resin 3.1.xサーバーにインストールする場合の追加手順は次のとおりです。
Coherenceのlibraryディレクトリ内で、webInstaller.jar
からcoherence-web.jar
を抽出します。
jar -xvf webInstaller.jar web-install/coherence-web.jar
これにより、coherence-web.jar
ファイルがweb-install
というサブディレクトリに抽出されます。次のコマンドを使用して、coherence-web.jar
ファイルをlibrary
ディレクトリ内の1つ上のレベルに移動します。
Windowsの場合:
move web-install\coherence-web.jar . rmdir web-install
UNIXの場合:
mv web-install/coherence-web.jar . rmdir web-install
サーバー・クラスタで実行するResinのインストールごとに、次のコマンドを使用してライブラリを更新します(ここでは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller <resin-home-path> -install
たとえば、Windowsでは次のようになります。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller C:\opt\resin31 -install
Coherence*Webセッション管理モジュールの一般的なインストール手順に従って、サーバー・タイプにResin/3.1.xを指定します。
Coherence*Webセッション管理モジュールをOracle OC4J 10.1.2.xサーバーにインストールする場合の追加手順は次のとおりです。
Coherenceのlibrary
ディレクトリ内で、webInstaller.jar
からcoherence-web.jar
を抽出します。
jar -xvf webInstaller.jar web-install/coherence-web.jar
これにより、coherence-web.jar
ファイルがweb-install
というサブディレクトリに抽出されます。次のコマンドを使用して、coherence-web.jar
ファイルをlibrary
ディレクトリ内の1つ上のレベルに移動します。
Windowsの場合:
move web-install\coherence-web.jar . rmdir web-install
UNIXの場合:
mv web-install/coherence-web.jar . rmdir web-install
サーバー・クラスタで実行するOC4Jのインストールごとに、次のコマンドを使用してライブラリを更新します(ここでは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller <oc4j-home-path> -install
たとえば、Windowsでは次のようになります。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller C:\opt\oracle1012\j2ee\home
Coherence*Webセッション管理モジュールの一般的なインストール手順に従って、サーバー・タイプにOracle/10.1.2.xを指定します。
Coherence*Webセッション管理モジュールをOracle WebLogic 10.xサーバーにインストールする場合の追加手順は次のとおりです。
Coherenceのlibraryディレクトリ内で、webInstaller.jar
からcoherence-web.jar
を抽出します。
jar -xvf webInstaller.jar web-install/coherence-web.jar
これにより、coherence-web.jar
ファイルがweb-install
というサブディレクトリに抽出されます。次のコマンドを使用して、coherence-web.jar
ファイルをlibrary
ディレクトリ内の1つ上のレベルに移動します。
Windowsの場合:
move web-install\coherence-web.jar . rmdir web-install
UNIXの場合:
mv web-install/coherence-web.jar . rmdir web-install
サーバー・クラスタで実行するWebLogic 10.xのインストールごとに、次のコマンドを使用してライブラリを更新します(ここでは形式上複数行に分けて表示してありますが、実際は単一のコマンドとして1行に入力します)。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller <wls-home-path> -install
たとえば、Windowsでは次のようになります。
java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller C:\bea\weblogic\wlserver_10 -install
Coherence*Webセッション管理モジュールの一般的なインストール手順に従って、サーバー・タイプにWebLogic/10.xを指定します。
検査手順において、Coherence*Webインストーラでは次のタスクが実行されます。
テンプレートのcoherence-web.xml
コンフィギュレーション・ファイルを生成します。このファイルには、アプリケーションおよびターゲットWebコンテナに関する基本的な情報と、ターゲットWebコンテナに該当する一連のデフォルトのCoherence*Webコンフィギュレーション・コンテキスト・パラメータが含まれます。既存のcoherence-web.xml
コンフィギュレーション・ファイルがある場合(Coherence*Webインストーラを前回実行したときのものなど)は、既存ファイル内のコンテキスト・パラメータが生成されたテンプレートにマージされます。
ターゲットのJava EEアプリケーション内のWebアプリケーションごとにJSPを列挙して、各JSPに関する情報をcoherence-web.xml
コンフィギュレーション・ファイルに追加します。
ターゲットのJava EEアプリケーション内のWebアプリケーションごとにTLDを列挙して、各TLDに関する情報をcoherence-web.xml
コンフィギュレーション・ファイルに追加します。
インストール手順において、Coherence*Webインストーラでは次のタスクが実行されます。
アンインストール手順でリストアできるよう、元のJava EEアプリケーションのバックアップを作成します。
検査手順の手順1で生成されたCoherence*Webコンフィギュレーション・コンテキスト・パラメータを、ターゲットのJava EEアプリケーションに含まれる各Webアプリケーションのweb.xml
ディスクリプタに追加します。
アプリケーション固有のServletContextListener
、ServletContextAttributeListener
、ServletRequestListener
、ServletRequestAttributeListener
、HttpSessionListener
およびHttpSessionAttributeListener
の各クラス(TLDで登録されたものを含む)を、各Webアプリケーションから登録解除します。
web.xml
ディスクリプタごとに、Coherence*Web ServletContextListener
を登録します。実行時、Coherence*Web ServletContextListener
は各ServletContextEvent
を、それぞれのアプリケーション固有のServletContextListener
に伝播します。
web.xml
ディスクリプタごとに、Coherence*Web ServletContextAttributeListener
を登録します。実行時、Coherence*Web ServletContextAttributeListener
は各ServletContextAttributeEvent
を、それぞれのアプリケーション固有のServletContextAttributeListener
に伝播します。
各web.xml
ディスクリプタで宣言されているアプリケーション固有のサーブレットをCoherence*Web SessionServlet
でラップします。実行時、各Coherence*Web SessionServlet
はラップされたサーブレットに委任します。
次のディレクティブを、検査手順の手順2で列挙した各JSPに追加します。
<%@ page extends="com.tangosol.coherence.servlet.api22.JspServlet" %>
アンインストール手順では、設定済のJava EEアプリケーションが、インストール手順の手順1で作成した元のバージョンのバックアップに置き換えられます。
Coherenceには軽量のソフトウェア・ロード・バランサが付随しています。この用途はテストのみです。ロード・バランサは、セッション管理などの機能をテストする際に便利で、簡単に使用できます。
複数のアプリケーション・サーバー・プロセスを1つ以上のサーバー・マシンで開始し、それぞれ一意のIPアドレスとポートの組合せでアプリケーションを実行します。
コマンド(またはシェル)ウィンドウを開きます。
現在のディレクトリをCoherenceライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib
、UNIXの場合は$COHERENCE_HOME/lib
)。
Javaコマンドが実行されるようにパスを構成します。
次のコマンドラインでソフトウェア・ロード・バランサを起動します。これらのコマンドラインをそれぞれ実行すると、デフォルトのHTTPポート(ポート80)でアプリケーションが使用可能になります。
ポート7001
と7002
で2つのアプリケーション・サーバー・インスタンスを実行している1つのマシンでロード・バランシングをローカルにテストするコマンドは次のとおりです。
java -jar coherence-loadbalancer.jar localhost:80 localhost:7001 localhost:7002
server1というマシンでロード・バランサをローカルに実行し、server1
、server2
およびserver3
のポート7001
にロード・バランシングするコマンドは次のとおりです。
java -jar coherence-loadbalancer.jar server1:80 server1:7001 server2:7001 server3:7001
前述のコマンドラインの場合、以前http://server1:7001/my.jsp
というURLでアクセスしていたアプリケーションは、http://server1:80/my.jsp
またはhttp://server1/my.jsp
というURLのみでアクセスされます。
表2-6に、サポートされているコマンドライン・オプションを示します。
表2-6 HTTPセッション管理をテストするコマンドライン・オプション
オプション | 説明 |
---|---|
-backlog |
TCP/IP受入れバックログ・オプションを、指定した値に設定します(例: |
-random |
ランダム・ロード・バランシング・アルゴリズムを使用するよう指定します(デフォルト)。 |
-roundrobin |
ラウンドロビン・ロード・バランシング・アルゴリズムを使用するよう指定します。 |
-threads |
指定した数のリクエスト/レスポンスのスレッド・ペアを使用します(したがって、追加のデーモン・スレッドの合計数は、指定した値の2倍になります)(例: |
アプリケーションで、相対リダイレクトのみ、またはロード・バランサ・アドレスが使用されていることを確認してください。
Coherenceは、Oracle WebLogicポータルと緊密に統合して、ポータル・アプリケーション用のWAN対応クラスタ化キャッシュ機能を提供します。特に、次の統合ポイントを対象としています。
Coherenceを使用したWSRPフェデレーテッド・ポータル間でのデータ共有: この項では、Coherenceと、WebLogicポータルのカスタム・データ転送メカニズムを利用するWSRPフェデレーテッド・ポータル間で効率的にデータを共有する構想を紹介します。
内部的には、WebLogicポータルは独自のキャッシュ・サービスを使用して、ポータル、パーソナライズおよびコマースの各データをキャッシュします。その説明は次を参照してください。
WebLogicポータル8.1.6以降には、サ―ド・パーティ・キャッシュ・ベンダーが実装できるP13Nキャッシュ・サービス用のSPIが備わっています。Coherenceには、P13N CacheProvider
SPIの実装が用意されています。これをWebLogicポータル・アプリケーションにインストールすると、コード変更せずに、キャッシュしたP13Nデータを透過的に管理できます。また、CoherenceとWebLogicポータルを組み合せることで、キャッシュ・トポロジをきわめて柔軟に選択できるようになります。
たとえば、ポータル・サーバーが4GBのヒープ限界(32ビットJVMの場合)に達している場合やGC時間が長くなっている場合は、キャッシュのクライアント/サーバー・トポロジを利用して、シリアライズ可能なP13Nの状態をポータルのJVMから1つ以上の専用Coherenceキャッシュ・サーバーに移動することで、ポータルのJVMのヒープ・サイズを削減し、GC時間を短縮できます。また、Coherenceの管理フレームワークを利用して統計を詳しく監視することで、より適切な状態にP13Nのキャッシュ設定を調整することができます。さらに、CoherenceのCacheProvider
を使用すると、標準のP13NキャッシュAPIを使用して、ポートレットでCoherenceのキャッシュ・サービスを利用することもできます。
CoherenceのP13N CacheProvider
をインストールするには、Coherenceインストールのlib
ディレクトリ内にあるcoherence-wlp.jar
ライブラリとcoherence.jar
ライブラリを、WebLogicポータル・アプリケーションのAPP-INF/lib
ディレクトリにコピーします。さらに、各WLPアプリケーションのMETA-INF
ディレクトリにあるp13n-cache-config.xml
ファイルで、Coherence P13N CacheProvider
をデフォルトのプロバイダとして構成する必要があります。具体的には、最初の<cache>
要素の直前に次の行を追加します。
<default-provider-id>com.tangosol.coherence.weblogic</default-provider-id>
プロバイダで使用するCoherence CacheProvider
およびCoherenceキャッシュの構成方法の詳細は、PortalCacheProvider
クラスのJavadocを参照してください。また、WebLogicポータルで使用されているキャッシュの一覧は、次のドキュメントを参照してください。
http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/caches/caches.html
Web Services for Remote Portlets(WSRP)は、任意のポータル・サーバーとサーバー・クラスタでホストされているポータル・フェデレーションのサポート用に設計されたプロトコルです。開発者は、WSRPを使用して、他のリモート・ポータルでホストされている各種ポートレットからコンテンツとユーザー・インタフェース(UI)を集約します。WSRPのみでは、スケーラブルで高い信頼性とパフォーマンスを持ったフェデレーテッド・ポータルを実装して、分散ポートレットで共有されているデータのライフサイクルを作成、アクセスおよび管理することはできません。このような課題を解決するために、WebLogicポータルにはWSRP仕様の拡張が用意されています。この拡張をOracle Coherenceと組み合せると、スケーラブルで高い信頼性とパフォーマンスを備えた方法で、WSRPのコンシューマとプロデューサから、共有する有効範囲データを作成、表示、変更したり、同時アクセスを制御できるようになります。
詳細は、次のドキュメントを参照してください。
http://www.oracle.com/technology/pub/articles/dev2arch/2005/11/federated-portal-cache.html
この項では、Coherenceソリューション開発用にJDeveloperを設定するための基本的な手順について説明します。
JDeveloperを使用して、キャッシュ・サーバー(DefaultCacheServer
)およびキャッシュ(CacheFactory
)の各インスタンスを実行できます。それぞれのインスタンスは、独立したJavaプロセスとして開始され、そのプロセスのログに標準出力を生成します。キャッシュ・コマンドなどの入力は、コマンドラインから起動する場合と同じように、プロセスに直接入力できます。この構成によって、Coherenceソリューションの開発とテストが容易になります。
JDeveloperでCoherenceを実行する手順は次のとおりです。
JDeveloperで、プロジェクトを1つだけ持った汎用アプリケーションを新規作成します。JDeveloperの操作に習熟しておられない場合は、オンライン・ヘルプで詳しい操作方法を確認してください。
アプリケーション・ナビゲータで、新しいプロジェクトをダブルクリックします。「プロジェクト・プロパティ」ダイアログ・ボックスが表示されます。
「ライブラリとクラスパス」ノードを選択します。「ライブラリとクラスパス」ページが表示されます。
「ライブラリとクラスパス」ページで、「Jar/ディレクトリの追加(&A)」をクリックします。「アーカイブまたはディレクトリの追加」ダイアログ・ボックスが表示されます。
ディレクトリ・ツリーでCOHERENCE_HOME
\lib\coherence.jar
を選択して、「選択」をクリックします。図2-1に示すように、「クラスパス・エントリ」リストにcoherence.jar
ライブラリが表示されます。
注意: Coherenceリリース3.3.xを使用する場合は、クラスパスにtangosol.jar ライブラリも必要です。 |
「プロジェクト・プロパティ」ダイアログ・ボックスで、「実行/デバッグ/プロファイル」ノードを選択します。「実行/デバッグ/プロファイル」ページが表示されます。
「実行/デバッグ/プロファイル」ページで、「新規」をクリックします。「実行コンフィギュレーションの作成」ダイアログ・ボックスが表示されます。「名前」テキスト・ボックスに、新しい実行コンフィギュレーションの名前を入力します。「設定のコピー元(&C):」ドロップダウン・リストで、「デフォルト」を選択します。「OK」をクリックします。「実行コンフィギュレーション(&R):」リストに、新しい実行コンフィギュレーションが表示されます。
「実行コンフィギュレーション(&R):」リストで新しい実行コンフィギュレーションを選択して、「編集」をクリックします。「実行コンフィギュレーションの編集」ダイアログ・ボックスが表示され、「起動設定」ノードが選択されます。
「起動設定」ページで「参照」をクリックして、「デフォルトの実行ターゲット(&D):」を選択します。「デフォルトの実行ターゲットの選択」ダイアログ・ボックスが表示されます。
ディレクトリ・ツリーでCOHERENCE_HOME
\lib\coherence.jar\com\tangosol\net\DefaultCacheServer.class
を選択して、「開く」をクリックします。図2-2に示すように、デフォルトの実行ターゲットとしてDefaultCacheServer
クラスが入力されます。
ヒント: Coherenceのシステム・プロパティを設定するには、「Javaオプション(&J):」テキスト・ボックスを使用します。 |
「ツール設定」ノードを選択します。「ツール設定」ページが表示されます。
「追加実行オプション:」セクションで、「プログラムの入力を許可(&I)」チェック・ボックスを選択します。このボックスにチェック・マークが付いている場合は、オプションが選択されています。
「OK」をクリックします。
手順6〜14を繰り返し、図2-3に示すように、デフォルトの実行ターゲットとしてCOHERENCE_HOME
\lib\coherence.jar\com\tangosol\net\CacheFactory.class
を選択します。
「OK」をクリックして、「プロジェクト・プロパティ」ダイアログ・ボックスを閉じます。
「実行」ボタンのドロップダウン・リストを使用して、キャッシュ・サーバーの実行コンフィギュレーションを選択および起動します。キャッシュ・サーバー・インスタンスが起動され、図2-4に示すようにプロセスのログ・タブに出力が表示されます。
「実行」ボタンのドロップダウン・リストを使用して、キャッシュの実行コンフィギュレーションを選択および起動します。キャッシュ・インスタンスが起動され、図2-5に示すようにプロセスのログ・タブに出力が表示されます。
キャッシュ・ファクトリの実行ログ・タブの下部にある「入力(&I):」テキスト・ボックスを使用して、キャッシュ・インスタンスと対話します。たとえば、help
と入力して[Enter]を押すと、有効なコマンドのリストを表示できます。
Javaでは、各スレッドとそのスレッドに保持されているすべてのロックのリストを標準出力にダンプできます。これは、Linux環境ではkill
コマンド、Windows環境では[Ctrl]+[Break]
で実行できます。スレッド・ダンプは、デッドロックの検出など、開発段階でのトラブルシューティングに役立ちます。
JDeveloperでCoherenceソリューションを開発する場合は、プロセスのログ・タブでスレッド・ダンプを直接確認できます。これは、JDeveloperで実行しているJavaプロセスに前述のシグナルを送信することで実行できます。
JDeveloperでスレッド・ダンプを表示する手順は次のとおりです。
シェルまたはコマンドプロンプトからJDK_HOME/bin/jps
を使用して、スレッド・ダンプに表示するスレッドを持つJavaプロセスのプロセスID(PID)を取得します。JDK1.4以前を使用している場合、Linuxではps -ef
、Windowsではtlist
をそれぞれ使用してPIDを取得します。
Linuxの場合は、kill -3
PID
を使用して、QUIT
シグナルをプロセスに送信します。Windowsの場合、[Ctrl]+[Break]
のシグナルをリモートJavaプロセスに送信するには、SendSignalなどのサード・パーティ・ツールを使用する必要があります。
JDeveloperでは、プロセスのログでスレッド・ダンプを確認できます。
JDeveloperを使用して、Coherenceのキャッシュ・コンフィギュレーション・ファイルを作成できます。JDeveloperは、cache-config.dtd
をロードして、このDTDのすべての要素をコンポーネント・パレットに出力します。さらに、このDTDとの照合によってキャッシュ・コンフィギュレーション・ファイルを検証し、XMLコード補完を提供します。
JDeveloperでキャッシュ・コンフィギュレーションを作成する手順は次のとおりです。
COHERENCE_HOME
\lib\coherence.jar
ライブラリからコンピュータ上の任意のディレクトリにcache-config.dtd
を抽出します。
JDeveloperのアプリケーション・ナビゲータで、目的のCoherenceプロジェクトをダブルクリックします。「プロジェクト・プロパティ」ダイアログ・ボックスが表示されます。
「プロジェクトのソースパス」ノードを開き、「リソース」をクリックします。「リソース」ページが表示されます。
「リソース」セクションで「追加」をクリックして、DTDファイルの抽出先ディレクトリを検索および選択します。
「対象」タブで「追加」をクリックして、cache-config.dtd
ファイルを選択します。
「OK」をクリックします。図2-6に示すように、このDTDが「対象」タブに表示されます。
図2-6 「プロジェクト・プロパティ」ダイアログ・ボックスの「リソース」に表示されたプロジェクトのDTD
「OK」をクリックして、「プロジェクト・プロパティ」ダイアログ・ボックスを閉じます。アプリケーション・ナビゲータで、プロジェクトの「リソース」フォルダにこのDTDが表示されます。
「ファイル(&F)」メニューで、「新規」をクリックします。「新規ギャラリ」ダイアログ・ボックスが表示されます。
「カテゴリ」セクションで「一般」ノードを開き、「XML」をクリックします。
「XMLドキュメント」を選択して、「OK」をクリックします。「新規XMLファイル」ダイアログ・ボックスが表示されます。
ファイル名をcoherence-cache-config.xml
として、DTDの保存先と同じディレクトリに保存します。
「OK」をクリックします。キャッシュ・コンフィギュレーション・ファイルが作成され、編集用に開かれます。また、アプリケーション・ナビゲータで、プロジェクトのリソース・フォルダにこのファイルが表示されます。
このファイルの先頭に、次のDOCTYPE
を追加します。
<?xml version="1.0" encoding="windows-1252" ?> <!DOCTYPE cache-config SYSTEM "cache-config.dtd">
コンポーネント・パレットが更新され、cache-config.dtd
ファイルにあるすべての要素が一覧表示されます。
coherence-cache-config.xml
ファイルを保存します。
この項では、『Oracle Coherenceユーザーズ・ガイド』の「C++オブジェクト・モデルについて」に対する修正について説明します。
スレッド処理に関する項ではcoherence::lang::ThreadLocal
クラスを参照していますが、これは誤りです。このクラスの正しい名前は、coherence::lang::ThreadLocalReference
です。
オブジェクトの不変性に関する項には、Handle
という語とView
という語の位置が誤って入れ替わっている文があります。この誤っている文の記述は次のとおりです。
オブジェクトをいったん不変に設定すると、可変に戻すことはできません。検証の不変性に違反するため、定数性を取り払ってHandle
をView
にすることはできません。
修正文は次のとおりです(修正箇所を「」で示します)。
オブジェクトをいったん不変に設定すると、可変に戻すことはできません。検証の不変性に違反するため、定数性を取り払って「View」を「Handle」にすることはできません。
スレッド・セーフなハンドルに関する項には、次の内容の段落があります。
これらのハンドル・タイプは、さらに同期化を実行しなくても、複数のスレッドで読取りおよび書込みを行えます。これらは主に、他の管理クラスのデータ・メンバーとして使用されており、親タイプの内部的なアトミック状態を利用してスレッド・セーフティを実現します。これらのハンドル・タイプをコード・ブロック内で複数回アクセスする場合は、通常のスタック・ベース・ハンドルに読み取って使用することをお薦めします。この通常のスタック・ベース・ハンドルへの割当てはスレッドセーフであるため、割当てを完了した後は、基本的にはスタック・ベース・ハンドルの参照解除を自由に行えます。スレッドセーフなハンドルを初期化する場合は、最初のパラメータとして親クラスへの参照を指定する必要があります。この参照は、親オブジェクトに対してself()
をコールすることで取得できます。
この段落は、次のように修正する必要があります(修正箇所を「」で示します)。
これらのハンドル・タイプは、さらに同期化を実行しなくても、複数のスレッドで読取りおよび書込みを行えます。これらは主に、他の管理クラスのデータ・メンバーとして使用されており、親タイプの内部的なアトミック状態を利用してスレッド・セーフティを実現します。これらのハンドル・タイプをコード・ブロック内で複数回アクセスする場合は、通常のスタック・ベース・ハンドルに読み取って使用することをお薦めします。この通常のスタック・ベース・ハンドルへの割当てはスレッドセーフであるため、割当てを完了した後は、基本的にはスタック・ベース・ハンドルの参照解除を自由に行えます。スレッドセーフなハンドルを初期化する場合は、最初のパラメータとして「ガーディアン・オブジェクト」への参照を指定する必要があります。この参照は、「包含する」オブジェクトに対してself()
をコールすることで取得できます。
同様に、次の内容の段落があります。
非管理クラスにも同じ手法を適用できます。これは、スレッドセーフなハンドルの親として、定義済の同期点を使用することで可能になります。このアプローチでは、親であるm_hMutex
オブジェクトの存続時間が、スレッドセーフなハンドルm_vsName
の存続時間より長いことが必要です。これは、これらを同じクラスのデータ・メンバーとして定義し、ハンドルより先に親を定義することで容易に実現できます。
この段落は、次のように修正する必要があります(修正箇所を「」で示します)。
非管理クラスにも同じ手法を適用できます。「非管理クラスは、coherence::lang::Object
を拡張しないため、スレッドセーフなハンドルのガーディアンとして使用できません。ただし、別のオブジェクトをガーディアンとして使用することは可能です。このアプローチを採用する場合は、ガーディアン・オブジェクトの存続時間が、ガード対象のスレッドセーフなハンドルの存続時間より長いことが必要です。Coherence 3.4.1以降で実現するには、System::common()
をコールして、coherence::lang::System
から永続的なガーディアンを取得します。」
例2-18「非管理クラスとしてのスレッドセーフなハンドル」に記載されているコードを、次のコードに入れ替える必要があります。
class Employee { public: Employee(String::View vsName, int32_t nId) : m_vsName(System::common(), vsName), m_nId(nId) { } public: String::View getName() const { return m_vsName; } void setName(String::View vsName) { m_vsName = vsName; } int32_t getId() const { return m_nId; } private: MemberView<String> m_vsName; const int32_t m_nId; };
「Reporterの内容の分析」の章で記述されている日付書式が変更されています。以前の日付書式では、レポートの実行年月日のみを記録していました(YYYYMMDD
)。新しい書式では、時間も記録するようになっています(YYYYMMDDHH
)。表2-7は、以前の書式から新しい書式への変更点をまとめたものです。
付録「Coherenceのエディション別機能」の「Coherenceクライアント・エディション」の表で、API言語のC++クライアントについての行が欠落しています。この行の正しい記述は次のとおりです。
表2-8 Coherenceクライアント・エディション
データ・クライアント(注意9を参照) | リアルタイム・クライアント(注意10を参照)(Extend/TCPクライアントとして構成、注意11を参照) | リアルタイム・クライアント(注意10を参照)(計算クライアントとして構成) | ||
---|---|---|---|---|
API言語 |
Java |
○ |
○ |
○ |
.NET |
○ |
○ |
× |
|
C++ |
○ |
○ |
× |
また、注意9、注意10および注意11が記述から欠落しています。これらの内容は次のとおりです。
9. データ・クライアントは、Coherence Serverのすべてのエディションで使用できます。
10. リアルタイム・クライアントはGrid Editionでのみ使用できます。
11. Extend/TCPは、TCP/IP経由のトランスポート用に構成されたCoherence*Extendの略称です。
「JMXを使用したCoherenceの管理方法」の表22-4「tangosol.coherence.management.refresh.policyプロパティの値」では、refresh-expired
をデフォルト値としていますが、これは誤りです。このプロパティの正しいデフォルト値はrefresh-ahead
です。
distributed-scheme
要素のbackup-count
属性の説明では、0
、1
または2
を推奨値としていますが、これは誤りです。正しい推奨値は0
または1
です。
この項では、付録「本番チェックリスト」の変更と機能強化について説明します。
「JVM」の項に、次の箇条書きがあります。
-Xms
と-Xmx
の両方に同じヒープ・サイズ値を使用すると、パフォーマンスおよびフェイル・ファスト・メモリー割当てが大幅に向上します。
これは次のように修正する必要があります(訂正箇所を「」で示します)。
-Xms
と-Xmx
の両方に同じヒープ・サイズ値を使用すると、「Sun JVMおよびJRockit JVMでのパフォーマンス」およびフェイル・ファスト・メモリー割当てが大幅に向上します。「各種のJVMのデプロイメントにおける次の具体的な考慮事項を参照してください。」
このリストには、次の箇条書きを追加する必要があります。
JVMでOutOfMemoryError
エラーが発生すると、未解決のままエラーが残されることがあり、クラスタに悪い影響を与える可能性があります。OutOfMemoryErrorが発生した場合の処理として、JVMをリカバリするのではなく、JVMを終了するように構成することをお薦めします。一般的なJVMで上述の構成を実行する方法は、次の具体的なデプロイメントの考慮事項を参照してください。
この項では、付録「プラットフォーム固有のデプロイメント考慮事項」の変更と機能強化について説明します。
Sun JVMへのデプロイメントに関する項に、次の記述を追加してください。
OutOfMemoryError
JVMでOutOfMemoryError
エラーが発生すると、未解決のままエラーが残されることがあり、クラスタに悪い影響を与える可能性があります。OutOfMemoryError
が発生した場合の処理として、JVMをリカバリするのではなく、JVMを終了するように構成することをお薦めします。Sun JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-XX:OnOutOfMemoryError="kill -9 %p"
Windowsの場合:
-XX:OnOutOfMemoryError="taskkill /F /PID %p"
注意: 2008年12月の時点では、1.4.2および1.6の新バージョンでこのフラグが使用できるようになっていますが、バージョン1.5は未対応です。 |
IBM JVMへのデプロイメントに関する項に、次の記述を追加してください。
OutOfMemoryError
JVMでOutOfMemoryError
エラーが発生すると、未解決のままエラーが残されることがあり、クラスタに悪い影響を与える可能性があります。OutOfMemoryError
が発生した場合の処理として、JVMをリカバリするのではなく、JVMを終了するように構成することをお薦めします。IBM JVM(1.5以上)でこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="kill -9 %pid"
Windowsの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="taskkill /F /PID %pid"
ヒープ・サイズの設定
IBM社は、JVMに固定サイズのヒープを割り当てることを推奨していません。ほとんどの場合は、-Xms
にデフォルト値を使用することをお薦めします(つまり、この設定を省略して-Xmx
のみを設定します)。詳細は、次のリンクを参照してください。