Oracle® Fusion Middleware

Oracle Coherenceでのアプリケーションの開発

12c (12.1.3)

E56206-04(原本部品番号:E47887-04)

2016年9月

このドキュメントでは、開発者およびアーキテクト向けに、分散キャッシングおよびデータ・グリッド・コンピューティングのためにCoherenceを使用するアプリケーションの開発方法について説明します。Coherenceのインストール、Coherenceクラスタの設定、Coherenceキャッシュの構成、データ・グリッド操作の実行に関する情報が含まれています。

Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発, 12c (12.1.3)

E56206-04

Copyright © 2008, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者: Joseph Ruzzi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.1.3)に関する新機能と変更された機能

- 12c (12.1.3)に関するこのドキュメントにおけるその他の大きな変更

- 12c (12.1.2)に関する新機能と変更された機能

- 12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

第I部 スタート・ガイド

1 Coherenceの概要

- 1.1 基本的な概念

- 1.1.1 クラスタ化されたデータの管理

- 1.1.2 論理層の単一のAPI、物理層のXML構成

- 1.1.3 キャッシング戦略

- 1.1.4 データ記憶域の各オプション

- 1.1.5 シリアライズの各オプション

- 1.1.6 構成可能性および拡張性

- 1.1.7 ネームスペースの階層

- 1.2 読取り/書込みキャッシング

- 1.2.1 NamedCache

- 1.2.2 キャッシュされたオブジェクトの要件

- 1.2.3 NamedCacheの使用パターン

- 1.3 キャッシュの問合せ

- 1.4 起動サービス

- 1.5 イベント・プログラミング

- 1.6 トランザクション

- 1.7 HTTPセッション管理

- 1.8 オブジェクト・リレーショナル・マッピングの統合

- 1.9 C++/.NETの統合

- 1.10 管理およびモニタリング

2 Oracle Coherence for Javaのインストール

- 2.1 システム要件

- 2.2 Coherenceのインストールの実行

- 2.2.1 Coherenceインストーラの実行

- 2.2.1.1 グラフィカル・モードでのCoherenceのインストールの実行

- 2.2.1.2 サイレント・モードでのCoherenceのインストールの実行

- 2.2.2 Coherenceクイック・インストーラの実行

- 2.2.3 Coherenceサプリメンタル・インストーラの実行

- 2.2.4 WebLogic ServerとCoherenceのインストール

- 2.3 インストール・ディレクトリの参照

- 2.4 環境変数の設定

- 2.5 Coherenceの最初の実行

- 2.5.1 基本的なクラスタの作成

- 2.5.2 キャッシュの作成

- 2.6 Mavenとの統合

- 2.7 Coherenceのアンインストール

3 構成の理解

- 3.1 デフォルトの構成ファイルの概要

- 3.2 オペレーション構成ファイルの指定

- 3.2.1 デフォルトのオペレーション・オーバーライド・ファイルの使用

- 3.2.2 オペレーション・オーバーライド・ファイルの指定

- 3.2.3 特定のオペレーション要素に対するオーバーライド・ファイルの定義

- 3.2.4 ロードされたオペレーション・オーバーライド・ファイルの表示

- 3.3 キャッシュ構成ファイルの指定

- 3.3.1 デフォルトのキャッシュ構成ファイルの使用

- 3.3.2 デフォルトのキャッシュ構成ファイルのオーバーライド

- 3.3.3 キャッシュ構成ファイルのシステム・プロパティの使用

- 3.3.4 ロードされたキャッシュ構成ファイルの表示

- 3.4 POF構成ファイルの指定

- 3.4.1 デフォルトのPOF構成ファイルのオーバーライド

- 3.4.2 POF構成ファイルのシステム・プロパティの使用

- 3.4.3 複数のPOF構成ファイルの組合せ

- 3.4.4 ロードされたPOF構成ファイルの表示

- 3.5 管理構成ファイルの指定

- 3.5.1 カスタムのレポート・グループ構成ファイルの指定

- 3.5.1.1 デフォルトのレポート・グループ構成ファイルのオーバーライド

- 3.5.1.2 レポート・グループ構成ファイルのシステム・プロパティの使用

- 3.5.2 MBean構成ファイルの指定

- 3.5.2.1 デフォルトのMBean構成オーバーライド・ファイルの使用

- 3.5.2.2 MBean構成ファイルのシステム・プロパティの使用

- 3.5.3 ロードされた管理構成ファイルの表示

- 3.6 スキーマ検証の無効化

- 3.7 XMLオーバーライド機能の理解

- 3.7.1 事前定義されたオーバーライド・ファイルの使用

- 3.7.2 カスタムのオーバーライド・ファイルの定義

- 3.7.3 同じ要素用の複数のオーバーライド・ファイルの定義

- 3.8 システム・プロパティを使用した構成の変更

- 3.8.1 事前構成されているシステム・プロパティの使用

- 3.8.2 カスタムのシステム・プロパティの作成

4 最初のCoherenceアプリケーションの作成

- 4.1 タスク1: サンプル・キャッシュの定義

- 4.2 タスク2: サンプル・クラスタの構成と起動

- 4.3 タスク3: 基本のCoherenceスタンドアロン・アプリケーションの作成と実行

- 4.3.1 サンプル・スタンドアロン・アプリケーションの作成

- 4.3.2 サンプル・スタンドアロン・アプリケーションの実行

- 4.3.3 サンプル・キャッシュの確認

- 4.4 タスク4: 基本のCoherence JavaEE Webアプリケーションの作成と実行

- 4.4.1 Webスタンドアロン・アプリケーションの作成

- 4.4.2 サンプルのWebアプリケーションのデプロイと実行

- 4.4.3 サンプル・キャッシュの確認

- 4.5 Coherence開発用のJDeveloperの使用

- 4.5.1 JDeveloperにおけるCoherenceの実行

- 4.5.2 JDeveloperにおけるスレッド・ダンプの表示

- 4.5.3 JDeveloperにおける構成ファイルの作成

5 Coherenceでのデバッグ

- 5.1 Coherenceでのデバッグの概要

- 5.2 ロギングの構成

- 5.2.1 ログ・レベルの変更

- 5.2.2 ログ出力先の変更

- 5.2.2.1 ファイルへのログ・メッセージの送信

- 5.2.3 ログ・メッセージのフォーマットの変更

- 5.2.4 ロギング文字制限の設定

- 5.2.5 CoherenceログでのJDKロギングの使用

- 5.2.6 CoherenceログでのLog4Jロギングの使用

- 5.2.7 CoherenceログでのSLF4Jの使用

- 5.3 リモート・デバッグの実行

- 5.4 Coherenceベース・アプリケーションのトラブルシューティング

- 5.4.1 Coherenceログの使用

- 5.4.2 JMX管理およびCoherenceレポートの使用

- 5.4.3 JVMオプションを使用したデバッグの促進

- 5.4.4 スレッド・ダンプの取得

- 5.4.5 ヒープ・ダンプの取得

- 5.4.6 オペレーティング・システムのモニタリング

第II部 Coherenceクラスタの使用

6 Coherenceクラスタの概要

- 6.1 クラスタの概要

- 6.2 TCMPの理解

- 6.3 クラスタ化されたサービスの理解

7 クラスタの設定

- 7.1 クラスタの設定の概要

- 7.2 クラスタの名前の指定

- 7.3 クラスタ・メンバーの識別情報の指定

- 7.4 マルチキャスト通信の構成

- 7.4.1 クラスタのマルチキャスト・アドレスの指定

- 7.4.1.1 マルチキャスト・ソケット・インタフェースの変更

- 7.4.2 マルチキャスト通信の無効化

- 7.4.3 マルチキャストの有効時間の指定

- 7.4.4 マルチキャストの参加タイムアウトの指定

- 7.4.5 マルチキャストのしきい値の変更

- 7.5 クラスタ・メンバーのユニキャスト・アドレスの指定

- 7.6 Well Knownアドレスの使用

- 7.6.1 WKAメンバーのアドレスの指定

- 7.6.2 WKAアドレス・プロバイダの指定

- 7.7 単一サーバー・モードの有効化

- 7.8 停止検出の構成

- 7.8.1 TCPリング設定の変更

- 7.8.2 ハートビート間隔の変更

- 7.8.3 停止検出の無効化

- 7.9 クラスタの優先度の指定

- 7.9.1 クラスタ・メンバーの優先度の指定

- 7.9.2 通信スレッドの優先度の指定

- 7.9.3 サービスに対するスレッドの優先度の指定

8 クラスタ・メンバーの起動および停止

- 8.1 キャッシュ・サーバーの起動

- 8.1.1 DefaultCacheServerクラスの概要

- 8.1.2 コマンド行からのキャッシュ・サーバーの起動

- 8.1.3 プログラムによるキャッシュ・サーバーの起動

- 8.2 キャッシュ・クライアントの起動

- 8.2.1 ローカル記憶域の無効化

- 8.2.2 キャッシュ・クライアントを起動するためのCacheFactoryクラスの使用

- 8.3 クラスタ・メンバーの停止

- 8.3.1 コマンド行からのクラスタ・メンバーの停止

- 8.3.2 プログラムによるキャッシュ・サーバーの停止

- 8.4 ローリング再起動の実行

- 8.4.1 ローリング再起動の実行の前提条件

- 8.4.2 ローリング再起動のためのキャッシュ・サーバーの再起動

9 クラスタ・メンバーシップの動的な管理

- 9.1 クラスタ・メンバーシップの管理の概要

- 9.2 クラスタ・オブジェクトとサービス・オブジェクトの使用

- 9.3 メンバー・オブジェクトの使用

- 9.4 メンバー・イベントのリスニング

10 TCMPの動作のチューニング

- 10.1 TCMPデータ転送の概要

- 10.2 データ転送速度の調整

- 10.2.1 パケットのフロー制御動作の調整

- 10.2.2 パケットのフロー制御の無効化

- 10.2.3 パケット・トラフィック混雑の動作の調整

- 10.3 負荷を低減するためのパケットのバンドリング

- 10.4 パケットの再転送動作の変更

- 10.4.1 パケットの再送信間隔の変更

- 10.4.2 パケットの再送信タイムアウトの変更

- 10.4.3 パケットの肯定応答遅延の構成

- 10.5 パケット・バッファのサイズの構成

- 10.5.1 パケット・バッファのサイズ設定の理解

- 10.5.2 アウトバウンド・パケット・バッファのサイズの構成

- 10.5.3 インバウンド・パケット・バッファのサイズの構成

- 10.6 パケットの最大サイズの調整

- 10.7 パケット・スピーカーのボリュームしきい値の変更

- 10.8 受信メッセージ・ハンドラの構成

- 10.8.1 時刻差異の変更

- 10.8.2 否定応答の無効化

- 10.9 ネットワーク・フィルタの使用

- 10.9.1 圧縮フィルタの使用

- 10.9.1.1 特定のサービスに対する圧縮フィルタの有効化

- 10.9.1.2 すべてのサービスに対する圧縮フィルタの有効化

- 10.9.1.3 圧縮フィルタの構成

- 10.9.2 カスタム・ネットワーク・フィルタの使用

- 10.9.2.1 カスタム・フィルタの宣言

- 10.9.2.2 特定のサービスに対するカスタム・フィルタの有効化

- 10.9.2.3 すべてのサービスに対するカスタム・フィルタの有効化

- 10.10 TCMPソケット・プロバイダ実装の変更

- 10.10.1 TCPソケット・プロバイダの使用

- 10.10.2 SDPソケット・プロバイダの使用

- 10.10.3 SSLソケット・プロバイダの使用

11 サービス・ガーディアンの使用

- 11.1 概要

- 11.2 サービス・ガーディアンの構成

- 11.2.1 ガーディアン・タイムアウトの設定

- 11.2.1.1 すべてのスレッドのガーディアン・タイムアウトの設定

- 11.2.1.2 サービス・タイプごとのガーディアン・タイムアウトの設定

- 11.2.1.3 サービス・インスタンスごとのガーディアン・タイムアウトの設定

- 11.2.2 PriorityTask APIのタイムアウト値の使用

- 11.2.3 ガーディアン・サービス失敗ポリシーの設定

- 11.2.3.1 すべてのスレッドのガーディアン失敗ポリシーの設定

- 11.2.3.2 サービス・タイプごとのガーディアン失敗ポリシーの設定

- 11.2.3.3 サービス・インスタンスごとのガーディアン失敗ポリシーの設定

- 11.2.3.4 カスタムのガーディアン失敗ポリシーの有効化

- 11.3 手動のガーディアン・ハートビートの発行

第III部 キャッシュの使用

12 Coherenceキャッシュの概要

- 12.1 分散キャッシュの理解

- 12.2 レプリケート・キャッシュの理解

- 12.3 オプティミスティック・キャッシュの理解

- 12.4 ニア・キャッシュの理解

- 12.5 ローカル・キャッシュの理解

- 12.6 リモート・キャッシュの理解

- 12.7 キャッシュ・タイプのサマリー

13 キャッシュの構成

- 13.1 概要

- 13.2 キャッシュ・マッピングの定義

- 13.2.1 正確なキャッシュ・マッピングの使用

- 13.2.2 名前パターン・キャッシュ・マッピングの使用方法

- 13.3 キャッシュ・スキームの定義

- 13.3.1 分散キャッシュ・スキームの定義

- 13.3.2 レプリケート・キャッシュ・スキームの定義

- 13.3.3 オプティミスティック・キャッシュ・スキームの定義

- 13.3.4 ローカル・キャッシュ・スキームの定義

- 13.3.4.1 ローカル・キャッシュの拡大の制御

- 13.3.4.2 カスタム・エビクション・ポリシーの指定

- 13.3.5 ニア・キャッシュ・スキームの定義

- 13.3.5.1 ニア・キャッシュの無効化戦略

- 13.4 スキームの継承の使用

- 13.5 キャッシュ・スキーム・プロパティの使用

- 13.6 パラメータ・マクロの使用

- 13.6.1 ユーザー定義パラメータ・マクロの使用

- 13.6.2 事前定義済パラメータ・マクロの使用

14 記憶域およびバッキング・マップの実装

- 14.1 キャッシュ・レイヤー

- 14.2 ローカル記憶域

- 14.3 操作

- 14.4 キャパシティ・プランニング

- 14.5 パーティション・バッキング・マップの使用

- 14.6 エラスティック・データ機能を使用したデータの保存

- 14.6.1 ジャーナルの概要

- 14.6.2 ジャーナル・スキームの定義

- 14.6.2.1 RAMジャーナル・バッキング・マップの構成

- 14.6.2.2 フラッシュ・ジャーナル・バッキング・マップの構成

- 14.6.2.3 ジャーナル・スキームの参照

- 14.6.2.4 ジャーナルの失効およびエビクションの使用

- 14.6.2.5 バックアップ記憶域でのジャーナル・スキームの使用

- 14.6.2.6 ジャーナル・スキームでのカスタム・マップ実装の有効化

- 14.6.3 ジャーナルの動作の変更

- 14.6.3.1 RAMジャーナル・リソース・マネージャの構成

- 14.6.3.2 フラッシュ・ジャーナル・リソース・マネージャの構成

- 14.7 非同期バックアップの使用

- 14.8 デルタ・バックアップの使用

- 14.8.1 デルタ・バックアップの有効化

- 14.8.2 カスタム・デルタ・バックアップ・コンプレッサの有効化

15 データ・ソースのキャッシュ

- 15.1 データ・ソースのキャッシュの概要

- 15.1.1 プラガブル・キャッシュ・ストア

- 15.1.2 リードスルー・キャッシング

- 15.1.3 ライトスルー・キャッシング

- 15.1.4 ライトビハインド・キャッシング

- 15.1.4.1 ライトビハインドの要件

- 15.1.5 リフレッシュアヘッド・キャッシング

- 15.2 キャッシュ戦略の選択

- 15.2.1 リードスルー/ライトスルーとキャッシュアサイドの比較

- 15.2.2 リフレッシュアヘッドとリードスルーの比較

- 15.2.3 ライトビハインドとライトスルーの比較

- 15.3 キャッシュ・ストアの実装の作成

- 15.4 キャッシュ・ストアの実装のプラグイン

- 15.5 キャッシュ・ストアの実装のサンプル

- 15.6 制御可能なキャッシュ・ストアの実装のサンプル

- 15.7 実装に関する考慮事項

- 15.7.1 冪等性

- 15.7.2 ライトスルーの制限

- 15.7.3 キャッシュ問合せ

- 15.7.4 リエントラント・コール

- 15.7.5 キャッシュ・サーバー・クラスパス

- 15.7.6 CacheStoreのコレクション操作

- 15.7.7 接続プール

16 シリアライズ・ページ・キャッシュ

- 16.1 シリアライズ・ページ・キャッシュの理解

- 16.2 シリアライズ・ページ・キャッシュの構成

- 16.3 パーティション・キャッシュ・サービスの最適化

- 16.4 高可用性の構成

- 16.5 ロード・バランシングおよびフェイルオーバーの構成

- 16.6 巨大なキャッシュのサポート

17 クォーラムの使用

- 17.1 クォーラムの使用の概要

- 17.2 クラスタ・クォーラムの使用

- 17.2.1 クラスタ・クォーラム・ポリシーの構成

- 17.3 パーティション・キャッシュ・クォーラムの使用

- 17.3.1 パーティション・キャッシュ・クォーラム・ポリシーの構成

- 17.4 プロキシ・クォーラムの使用

- 17.4.1 プロキシ・クォーラム・ポリシーの構成

- 17.5 カスタムのアクション・ポリシーの使用

- 17.5.1 カスタムのアクション・ポリシーの有効化

- 17.5.2 カスタム・フェイルオーバー・アクセス・ポリシーの有効化

18 キャッシュの構成例

- 18.1 ローカル・キャッシュ(単一のJVMからアクセス可能)

- 18.1.1 インメモリー・キャッシュ

- 18.1.2 サイズ制限があるインメモリー・キャッシュ

- 18.1.3 エントリの期限切れが設定されたインメモリー・キャッシュ

- 18.1.4 ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ

- 18.1.5 NIOインメモリー・キャッシュ

- 18.1.6 オンディスク・キャッシュ

- 18.1.7 サイズ制限があるオンディスク・キャッシュ

- 18.1.8 オンディスク永続キャッシュ

- 18.1.9 データベースのキャッシュ

- 18.2 クラスタ化キャッシュ(複数のJVMからアクセス可能)

- 18.2.1 パーティション・キャッシュ

- 18.2.2 オーバーフローが設定されたパーティション・キャッシュ

- 18.2.3 ジャーナル記憶域が設定されたパーティション・キャッシュ

- 18.2.4 データベースのパーティション・キャッシュ

- 18.2.5 シリアライザが設定されたパーティション・キャッシュ

- 18.2.6 ニア・キャッシュ

- 18.2.7 レプリケート・キャッシュ

- 18.2.8 オーバーフローが設定されたレプリケート・キャッシュ

19 キャッシュ構成ファイルの拡張

- 19.1 キャッシュ構成ファイルの拡張の概要

- 19.2 XMLネームスペースの宣言

- 19.3 ネームスペース・ハンドラの作成

- 19.3.1 ネームスペース・ハンドラ・インタフェースの実装

- 19.3.2 ネームスペース・ハンドラ抽象クラスの拡張

- 19.3.2.1 プロセッサの登録

- 19.3.2.2 プロセスの要素内容への注入の使用

- 19.4 例: JNDIリソース・ネームスペース・ハンドラ

- 19.4.1 JNDIリソース・ネームスペース・ハンドラの作成

- 19.4.2 JNDIネームスペース・ハンドラの宣言

- 19.4.3 JNDIリソース・ネームスペース・ハンドラの使用

第IV部 データ・グリッド操作の実行

20 Portable Object Formatの使用

- 20.1 Coherenceでのシリアライズの理解

- 20.2 POFシリアライズの概要

- 20.3 オブジェクトをシリアライズするためのPOF APIの使用

- 20.3.1 PortableObjectインタフェースの実装

- 20.3.2 PofSerializerインタフェースの実装

- 20.3.3 POF索引の割当てのガイドライン

- 20.3.4 POFオブジェクト参照の使用

- 20.3.4.1 POFオブジェクト参照の有効化

- 20.3.4.2 循環オブジェクトおよびネストされたオブジェクトのためのPOFオブジェクトIDの登録

- 20.3.5 POFオブジェクトの登録

- 20.3.6 ConfigurablePofContextクラスを使用するためのCoherenceの構成

- 20.3.6.1 ConfigurablePofContextクラスのサービスごとの構成

- 20.3.6.2 すべてのサービスに対するConfigurablePofContextクラスの構成

- 20.3.6.3 JVMに対するConfigurablePofContextクラスの構成

- 20.4 オブジェクトをシリアライズするためのPOF注釈の使用

- 20.4.1 POFシリアライズのためのオブジェクトの注釈付け

- 20.4.2 POF注釈付きオブジェクトの登録

- 20.4.3 POF構成ファイルの生成

- 20.4.4 自動索引付けの有効化

- 20.4.5 カスタム・コーディックの提供

- 20.5 POFエクストラクタとPOFアップデータの使用

- 20.5.1 POFオブジェクトの移動

- 20.5.2 POFエクストラクタの使用

- 20.5.3 POFアップデータの使用

- 20.6 POFを使用したキーのシリアライズ

21 キャッシュの事前ロード

- 21.1 キャッシュへのデータのバルク・ロード

- 21.2 分散バルク・ロードの実行

- 21.2.1 分散バルク・ロードの例

22 キャッシュ内のデータの問合せ

- 22.1 問合せの概要

- 22.1.1 問合せの概念

- 22.2 問合せの実行

- 22.2.1 フィルタ結果の効率的な処理

- 22.3 問合せ索引の使用

- 22.3.1 索引の作成

- 22.3.2 ユーザー定義索引の作成

- 22.3.2.1 MapIndexインタフェースの実装

- 22.3.2.2 IndexAwareExtractorインタフェースの実装

- 22.3.2.3 条件付き索引の使用

- 22.4 バッチ問合せの実行

- 22.5 複数値属性での問合せの実行

- 22.6 連鎖エクストラクタの使用

- 22.7 問合せのコストと効果の評価

- 22.7.1 問合せレコードの作成

- 22.7.2 問合せレコードの解析

- 22.7.2.1 問合せの実行計画レコード

- 22.7.2.2 問合せのトレース・レコード

- 22.7.3 問合せレコードの実行の例

23 連続問合せキャッシングの使用

- 23.1 連続問合せキャッシングの使用の概要

- 23.1.1 連続問合せキャッシングの用途の理解

- 23.2 連続問合せキャッシュの実装の理解

- 23.3 連続問合せキャッシュの構成

- 23.3.1 ContinuousQueryCacheに関連付けられているリソースのクリーンアップ

- 23.4 キーのみのキャッシュまたはキーと値のキャッシュ

- 23.4.1 CacheValuesプロパティとイベント・リスナー

- 23.5 ContinuousQueryCacheのリスニング

- 23.5.1 安定したマテリアライズド・ビューの実現

- 23.5.2 同期リスナーおよび非同期リスナーのサポート

- 23.6 ContinuousQueryCacheを読取り専用にする設定

24 キャッシュ内のデータの処理

- 24.1 キャッシュ内のデータの処理の概要

- 24.1.1 ターゲット処理の実行

- 24.1.2 パラレル処理の実行

- 24.1.3 問合せベースの処理の実行

- 24.1.4 データ・グリッド全体の処理の実行

- 24.2 ターゲット、パラレルおよび問合せベースの処理のためのエージェントの使用

- 24.2.1 複数のキャッシュのエントリの処理

- 24.2.2 エントリ・プロセッサの結果の無視

- 24.2.3 エントリの非同期処理

- 24.3 データ・グリッドの集計の実行

- 24.4 ノードベースの処理の実行

- 24.5 ワーク・マネージャの使用

25 マップ・イベントの使用

- 25.1 マップ・イベントの概要

- 25.1.1 リスナー・インタフェースおよびイベント・オブジェクト

- 25.1.2 イベントの保証の理解

- 25.1.3 イベントをサポートするキャッシュとクラス

- 25.2 すべてのイベントのサインアップ

- 25.3 MapListenerとしての内部クラスの使用

- 25.4 キャッシュ用のMapListenerの構成

- 25.5 特定のIDのイベントのサインアップ

- 25.6 イベントのフィルタリング

- 25.7 Liteイベントの使用

- 25.8 問合せのリスニング

- 25.8.1 イベントのフィルタリングとキャッシュされたデータのフィルタリングの比較

- 25.9 統合イベントの使用

- 25.10 バッキング・マップ・イベントの使用

- 25.10.1 分散キャッシュからの読取り可能なバッキングMapListenerイベントの生成

- 25.11 同期イベント・リスナーの使用

26 トリガーを使用したマップ操作の制御

- 26.1 マップ・トリガーの概要

- 26.2 マップ・トリガーの例

27 ライブ・イベントの使用

- 27.1 ライブ・イベントの概要

- 27.2 ライブ・イベント・タイプの理解

- 27.2.1 パーティション・キャッシュ・イベントの理解

- 27.2.1.1 エントリ・イベント

- 27.2.1.2 エントリ・プロセッサ・イベント

- 27.2.2 パーティション・サービス・イベントの理解

- 27.2.2.1 転送イベント

- 27.2.2.2 トランザクション・イベント

- 27.2.3 ライフサイクル・イベントの理解

- 27.3 ライブ・イベントの処理

- 27.3.1 イベント・インターセプタの作成

- 27.3.2 イベントのスレッディングの理解

- 27.3.3 イベント・インターセプタの登録

- 27.3.3.1 特定のキャッシュに対するイベント・インターセプタの登録

- 27.3.3.2 パーティション・サービスに対するイベント・インターセプタの登録

- 27.3.3.3 キャッシュ構成ファクトリに対するイベント・インターセプタの登録

- 27.3.3.4 カスタム登録の使用

- 27.3.3.5 イベント・インターセプタの登録のガイドライン

- 27.3.4 イベント・インターセプタの連鎖

- 27.3.4.1 イベント・インターセプタの連鎖順序の指定

28 Coherenceの問合せ言語の使用

- 28.1 Coherenceの問合せ言語構文の理解

- 28.1.1 問合せ構文の基本

- 28.1.1.1 パス式の使用

- 28.1.1.2 バインド変数の使用

- 28.1.1.3 KeyおよびValue擬似関数の使用

- 28.1.1.4 別名の使用

- 28.1.1.5 リテラル引数での引用符の使用

- 28.1.2 データの取得

- 28.1.2.1 キャッシュからのデータの取得

- 28.1.2.2 エントリの結果セットでのフィルタリング

- 28.1.3 キャッシュのライフサイクルの管理

- 28.1.3.1 キャッシュの作成

- 28.1.3.2 キャッシュのシリアライズ表現のファイルへの書込み

- 28.1.3.3 キャッシュの内容のファイルからのロード

- 28.1.3.4 クラスタからのキャッシュの削除

- 28.1.4 キャッシュ・データの処理

- 28.1.4.1 問合せ結果の集計

- 28.1.4.2 既存の値の変更

- 28.1.4.3 キャッシュ内へのエントリの挿入

- 28.1.4.4 キャッシュ内のエントリの削除

- 28.1.5 索引の処理

- 28.1.5.1 キャッシュ上での索引の作成

- 28.1.5.2 キャッシュからの索引の削除

- 28.1.6 複数の問合せ文の発行

- 28.1.6.1 問合せ文のバッチ・モードでの処理

- 28.1.7 問合せのコストと効果の表示

- 28.2 CohQLコマンド行ツールの使用

- 28.2.1 コマンド行ツールの起動

- 28.2.2 コマンド行ツールの引数の使用

- 28.2.3 コマンド行の例

- 28.3 Javaプログラムにおけるフィルタの作成

- 28.4 その他のCoherenceの問合せ言語の例

- 28.4.1 フィルタを強調表示する単純なSELECT * FROM文

- 28.4.2 予測、集計、グループ化を扱う複雑な問合せ

- 28.4.3 UPDATEの例

- 28.4.4 KeyおよびValue擬似関数の例

29 トランザクションの実行

- 29.1 トランザクションの概要

- 29.2 データの同時実行性のための明示的ロックの使用

- 29.3 データの同時実行性のためのエントリ・プロセッサの使用

- 29.4 トランザクション・フレームワークAPIの使用

- 29.4.1 トランザクション・キャッシュの定義

- 29.4.2 トランザクション内でのキャッシュ操作の実行

- 29.4.2.1 NamedCache APIの使用

- 29.4.2.2 Connection APIの使用

- 29.4.3 トランザクション接続の作成

- 29.4.4 トランザクション接続の使用

- 29.4.4.1 自動コミット・モードの使用

- 29.4.4.2 分離レベルの設定

- 29.4.4.3 即時モードの使用

- 29.4.4.4 トランザクション・タイムアウトの設定

- 29.4.5 OptimisticNamedCacheインタフェースの使用

- 29.4.6 トランザクション実行時のPOFの構成

- 29.4.7 トランザクション記憶域容量の構成

- 29.4.8 Java拡張クライアントからのトランザクションの実行

- 29.4.8.1 トランザクション用のエントリ・プロセッサの作成

- 29.4.8.2 クラスタ側のトランザクション・キャッシュの構成

- 29.4.8.3 クライアント側のリモート・キャッシュの構成

- 29.4.8.4 Javaクライアントからのトランザクション・エントリ・プロセッサの使用

- 29.4.9 トランザクション管理情報の表示

- 29.4.9.1 トランザクション・キャッシュのCacheMBean

- 29.4.9.2 TransactionManagerBean

- 29.5 Coherenceリソース・アダプタの使用

- 29.5.1 トランザクション内でのキャッシュ操作の実行

- 29.5.1.1 Coherence接続の作成

- 29.5.1.2 名前付きキャッシュの取得

- 29.5.1.3 トランザクション境界の設定

- 29.5.2 アプリケーションのパッケージ化

- 29.5.2.1 接続ファクトリのリソース参照の構成

- 29.5.2.2 リソース・アダプタのモジュール参照の構成

- 29.5.2.3 必要なライブラリの組込み

- 29.5.3 トランザクション用のCoherenceキャッシュ・アダプタの使用

30 パーティションの処理

- 30.1 データ・アフィニティの指定

- 30.1.1 データ・アフィニティの概要

- 30.1.2 KeyAssociationを使用したデータ・アフィニティの指定

- 30.1.3 KeyAssociatorを使用したデータ・アフィニティの指定

- 30.1.4 キー・アソシエーション・チェックの遅延

- 30.1.5 アフィニティの使用例

- 30.2 パーティションの数の変更

- 30.3 パーティション分散戦略の変更

- 30.3.1 パーティション割当て戦略の指定

- 30.3.2 カスタムのパーティション割当て戦略の有効化

31 スレッド実行の管理

- 31.1 優先度タスクの概要

- 31.2 優先度タスク・タイムアウトの設定

- 31.2.1 実行タイムアウトの構成

- 31.2.2 コマンド行オプション

- 31.3 優先度タスク実行オブジェクトの作成

- 31.3.1 優先度タスク・オブジェクト作成用のAPI

- 31.3.2 タスク・タイムアウトによってスローされるエラー

32 リエントラント・コールに対する制約

- 32.1 リエントラント・コールに対する制約の概要

- 32.2 リエントラント、サービスおよびサービス・スレッド

- 32.2.1 オブジェクトの親子関係

- 32.2.2 デッドロックの回避

- 32.3 リエントラントおよびリスナー

第V部 Coherence JCache実装の使用

33 Coherence JCacheの概要

- 33.1 Coherence JCache実装の概要

- 33.2 JCacheとNamedCacheの機能比較

- 33.3 Coherence JCacheの依存性

- 33.4 Coherence JCacheプロバイダの構成の概要

- 33.5 JCache入門

- 33.5.1 JCacheとは

- 33.5.2 JCacheキャッシュ・プロバイダおよびキャッシュ・マネージャ

- 33.5.3 JCacheキャッシュ

- 33.5.4 JCacheキャッシュ構成

- 33.5.5 JCacheカスタム・プログラミング

- 33.5.6 JCacheの管理

34 最初のCoherence JCacheアプリケーションの作成

- 34.1 タスク1: 単純なオブジェクトの作成

- 34.2 タスク2: ローカル・キャッシュへのオブジェクトの格納

- 34.2.1 サンプルJCacheアプリケーションの作成

- 34.2.2 サンプルJCacheアプリケーションの実行

- 34.3 タスク3: サンプル・クラスタの構成

- 34.4 タスク4: パーティション・キャッシュへのオブジェクトの格納

- 34.4.1 サンプル・キャッシュ・サーバーの起動

- 34.4.2 アプリケーションの実行

- 34.4.3 キャッシュの確認

- 34.5 タスク5: パススルー・キャッシュへのオブジェクトの格納

- 34.5.1 サンプル・キャッシュの定義

- 34.5.2 サンプル・キャッシュ・サーバーの起動

- 34.5.3 アプリケーションの実行

- 34.5.4 キャッシュの確認

35 基本的なCoherence JCacheタスクの実行

- 35.1 JCacheプロバイダとしてのCoherenceの指定

- 35.2 Coherence JCacheキャッシュの作成

- 35.2.1 ローカル・キャッシュの作成

- 35.2.2 パーティション・キャッシュの作成

- 35.2.3 パススルー・キャッシュの作成

- 35.2.4 JCacheからのCoherence固有の機能の使用

- 35.2.4.1 JCacheからのNamedCacheインスタンスへのアクセス

- 35.2.4.2 JCacheでのCoherence構成の使用

- 35.3 Coherence JCacheキャッシュの構成

- 35.3.1 格納セマンティクスの設定

- 35.3.2 キャッシュ・エントリの型の設定

- 35.3.3 キャッシュ失効の設定

- 35.3.4 リードスルーおよびライトスルー・キャッシングの有効化

- 35.3.5 管理の有効化

- 35.4 キャッシュ操作の実行

- 35.5 リードスルーおよびライトスルー・キャッシングの使用

- 35.5.1 リードスルー実装の提供

- 35.5.1.1 キャッシュの事前ロード

- 35.5.2 ライトスルー実装の提供

- 35.6 JCache POF構成ファイルの構成

- 35.7 JCache管理情報の表示

- 35.7.1 CacheConfiguration MBeanの理解

- 35.7.1.1 属性

- 35.7.1.2 操作

- 35.7.2 CacheStatistics MBeanの理解

- 35.7.2.1 属性

- 35.7.2.2 操作

- 35.7.3 パーティション・キャッシュ統計のリフレッシュ間隔の変更

36 JCacheイベントの使用

- 36.1 JCacheイベントの使用の概要

- 36.2 イベント・リスナーの作成

- 36.3 イベント・フィルタの作成

- 36.4 イベント・リスナーおよびフィルタの登録

- 36.4.1 キャッシュ構成時のイベント・リスナーおよびフィルタの登録

- 36.4.2 実行時のイベント・リスナーおよびフィルタの登録

37 JCacheエントリの処理

- 37.1 JCacheエントリの処理の概要

- 37.2 エントリ・プロセッサの作成

- 37.3 エントリ・プロセッサの使用

- 37.3.1 単一のキーに対するエントリ・プロセッサの起動

- 37.3.2 複数のキーに対するエントリ・プロセッサの起動

第VI部 付録

A オペレーション構成の要素

- A.1 オペレーション・デプロイメント・ディスクリプ

- A.2 オペレーション・オーバーライド・ファイル

- 要素リファレンス

- access-controller

- address-provider

- address-providers

- authorized-hosts

- cache-factory-builder-config

- callback-handler

- cluster-config

- cluster-quorum-policy

- coherence

- configurable-cache-factory-config

- filter

- filters

- flashjournal-manager

- flow-control

- host-range

- identity-asserter

- identity-manager

- identity-transformer

- incoming-message-handler

- init-param

- init-params

- instance

- journaling-config

- key-store

- license-config

- logging-config

- management-config

- mbean

- mbeans

- mbean-filter

- member-identity

- multicast-listener

- notification-queueing

- outgoing-message-handler

- outstanding-packets

- packet-buffer

- packet-bundling

- packet-delivery

- packet-publisher

- packet-size

- packet-speaker

- pause-detection

- provider

- ramjournal-manager

- reporter

- security-config

- serializer

- serializers

- service

- 初期化パラメータの設定

- service-guardian

- services

- shutdown-listener

- socket-address

- socket-provider

- socket-providers

- ssl

- tcp-ring-listener

- traffic-jam

- trust-manager

- unicast-listener

- volume-threshold

- well-known-addresses

- 属性リファレンス

B キャッシュ構成の要素

- B.1 キャッシュ構成デプロイメント・ディスクリプタ

- 要素リファレンス

- acceptor-config

- address-provider

- async-store-manager

- authorized-hosts

- back-scheme

- backing-map-scheme

- backup-storage

- bdb-store-manager

- bundle-config

- cache-config

- cache-mapping

- cache-service-proxy

- cachestore-scheme

- caching-scheme-mapping

- caching-schemes

- class-scheme

- custom-store-manager

- defaults

- distributed-scheme

- external-scheme

- flashjournal-scheme

- front-scheme

- http-acceptor

- identity-manager

- incoming-message-handler

- initiator-config

- init-param

- init-params

- instance

- interceptor

- interceptors

- invocation-scheme

- invocation-service-proxy

- key-associator

- key-partitioning

- key-store

- listener

- local-address

- local-scheme

- memcached-acceptor

- name-service-addresses

- near-scheme

- nio-file-manager

- nio-memory-manager

- operation-bundling

- optimistic-scheme

- outgoing-message-handler

- overflow-scheme

- paged-external-scheme

- partition-listener

- partitioned-quorum-policy-scheme

- provider

- proxy-config

- proxy-scheme

- proxy-quorum-policy-scheme

- ramjournal-scheme

- read-write-backing-map-scheme

- remote-addresses

- remote-cache-scheme

- remote-invocation-scheme

- replicated-scheme

- resource-config

- serializer

- socket-address

- socket-provider

- ssl

- tcp-acceptor

- tcp-initiator

- transactional-scheme

- trust-manager

- 属性リファレンス

C POFユーザー定義型の構成要素

- C.1 POF構成デプロイメント・ディスクリプタ

- 要素の索引

- default-serializer

- init-param

- init-params

- pof-config

- serializer

- user-type

- user-type-list

D システム・プロパティのオーバーライド

- D.1 システム・プロパティのオーバーライドの概要

- D.2 オーバーライドの例

- D.3 事前構成されているオーバーライド値

E PIF-POFバイナリ形式

- E.1 PIF-POFバイナリ形式の概要

- E.2 ストリーム形式

- E.2.1 整数値

- E.2.2 型ID

- E.3 事前定義型のバイナリ形式

- E.3.1 Int

- E.3.1.1 整数型の強制変換

- E.3.2 Decimal

- E.3.3 Floating Point

- E.3.4 Boolean

- E.3.5 Octet

- E.3.6 Octet String

- E.3.7 Char

- E.3.8 Char String

- E.3.9 Date

- E.3.10 Year-Month Interval

- E.3.11 Time

- E.3.12 Time Interval

- E.3.13 Date-Time

- E.3.13.1 日付および時間の型の強制変換

- E.3.14 Day-Time Interval

- E.3.15 Collections

- E.3.16 Arrays

- E.3.17 Sparse Arrays

- E.3.18 Key-Value Map(ディクショナリ)

- E.3.19 Identity

- E.3.20 Reference

- E.4 ユーザー定義型のバイナリ形式

- E.4.1 ユーザー定義型のバージョニング

例一覧

- 1-1 InvocationService APIのメソッド

- 4-1 サンプルのHelloWorldスタンドアロン・アプリケーション

- 4-2 サンプルのHello World JSP

- 9-1 クラスタ内で実行されているサービスの確認

- 9-2 MemberListener実装のサンプル

- 9-3 MemberEventオブジェクトのイベント・タイプ情報の使用

- 13-1 正確なキャッシュ・マッピングのサンプル

- 13-2 キャッシュ名パターン・マッピングのサンプル

- 13-3 分散キャッシュ定義のサンプル

- 13-4 レプリケート・キャッシュ定義のサンプル

- 13-5 オプティミスティック・キャッシュ定義のサンプル

- 13-6 ローカル・キャッシュ定義のサンプル

- 13-7 カスタム・エビクション・ポリシーの実装

- 13-8 coherence-cache-config.xmlファイル内のカスタム・エビクション・ポリシー

- 13-9 ニア・キャッシュ定義のサンプル

- 13-10 キャッシュ・スキーム参照の使用

- 13-11 複数のキャッシュ・スキームでのスキーム継承の使用

- 13-12 キャッシュ・プロパティの設定

- 13-13 キャッシュ・マッピングからのユーザー定義マクロのオーバーライド

- 15-1 リフレッシュアヘッド係数の指定

- 15-2 Cachestoreモジュールの例

- 15-3 CacheStoreインタフェースの実装

- 15-4 Main.java: 制御可能なCacheStoreとの相互作用

- 18-1 ローカルのインメモリー・キャッシュの構成

- 18-2 サイズ制限があるインメモリー・ローカル・キャッシュの構成

- 18-3 エントリの期限切れが設定されたインメモリー・キャッシュの構成

- 18-4 ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュの構成

- 18-5 NIOインメモリー・キャッシュの構成

- 18-6 オンディスク・キャッシュを定義する構成

- 18-7 サイズ制限があるオンディスク・キャッシュの構成

- 18-8 Berkeley DBによるオンディスク永続キャッシュの構成

- 18-9 データベースのキャッシュの構成

- 18-10 パーティション・キャッシュの構成

- 18-11 オーバーフローが設定されたパーティション・キャッシュの構成

- 18-12 RAMジャーナルが設定されたパーティション・キャッシュの構成

- 18-13 フラッシュ・ジャーナルが設定されたパーティション・キャッシュの構成

- 18-14 データベースのパーティション・キャッシュの構成

- 18-15 シリアライザが設定されたパーティション・キャッシュの構成

- 18-16 シリアライザを参照するパーティション・キャッシュ

- 18-17 デフォルト・シリアライザの定義

- 18-18 パーティション・キャッシュのローカル・キャッシュの構成

- 18-19 レプリケート・キャッシュの構成

- 18-20 オーバーフローが設定されたレプリケート・キャッシュの構成

- 19-1 NamespaceHandlerインタフェースを使用したハンドラの実装

- 19-2 明示的な登録を使用したAbstractNamespaceHandlerの実装

- 19-3 暗黙的な登録を使用したAbstractNamespaceHandlerの実装

- 20-1 PofSerializerインタフェースの実装

- 21-1 キャッシュの事前ロード

- 21-2 ConcurrentMap.putAllを使用したキャッシュの事前ロード

- 21-3 キャッシュ内で記憶域が有効なメンバーの取得

- 21-4 キャッシュのメンバーに割り当てられたファイルの一覧を取得するルーチン

- 21-5 キャッシュの各メンバーをロードするクラス

- 22-1 フィルタを指定したキャッシュの問合せ

- 22-2 問合せ結果のバッチ処理

- 22-3 索引を作成するサンプル・コード

- 22-4 key set問合せ形式の使用

- 22-5 制限フィルタの使用

- 22-6 複数値属性の問合せ

- 22-7 連鎖起動メソッド

- 22-8 サンプルの問合せ実行計画レコード

- 22-9 サンプルの問合せトレース・レコード

- 22-10 問合せレコードの例

- 23-1 連続問合せキャッシュの問合せ

- 23-2 連続問合せキャッシュのデータの取得

- 23-3 連続問合せキャッシュの構成

- 23-4 CacheValuesプロパティを構成できるコンストラクタ

- 23-5 CacheValuesプロパティの設定

- 23-6 連続問合せキャッシュへのリスナーの追加

- 23-7 連続問合せキャッシュ・エントリの処理とリスナーの追加

- 23-8 リスナー追加後の連続問合せキャッシュ・エントリの処理

- 23-9 連続問合せキャッシュ構成時のリスナーの指定

- 23-10 ContinuousQueryCacheを読取り専用にする設定

- 24-1 データ・グリッド全域の問合せ

- 24-2 InvocableMap APIの集計

- 24-3 EntryAggregator API

- 24-4 集計をパラレル実行するParallelAwareAggregator API

- 24-5 ガベージ・コレクションをリクエストする単純なエージェント

- 24-6 グリッド全体のリクエスト・モデルおよびレスポンス・モデルをサポートするエージェント

- 24-7 グリッド全体のリクエストまたはレスポンスからの結果の出力

- 24-8 ステートフル・エージェントの操作

- 24-9 ワーク・マネージャの使用

- 25-1 ObservableMap APIのメソッド

- 25-2 MapListener実装のサンプル

- 25-3 リスナーへの参照の保持

- 25-4 リスナーの削除

- 25-5 キャッシュの挿入イベントのみを出力する内部クラス

- 25-6 単一の処理メソッドへの全イベントのルーティング

- 25-7 特定の整数キーが挿入または更新された場合のイベントのトリガー

- 25-8 削除されたイベントのフィルタを指定したリスナーの追加

- 25-9 キャッシュにおける値の挿入、更新、削除

- 25-10 サンプル出力

- 25-11 キャッシュからのイベントのリスニング

- 25-12 オブジェクトのイベントのリスニング

- 25-13 MapEventFilterを使用した様々なイベントのフィルタリング

- 25-14 統合イベントの判断

- 25-15 AbstractMultiplexingBackingMapListener実装

- 25-16 詳細バッキング・マップ・リスナーを指定する分散スキーム

- 26-1 MapTriggerListener構成の例

- 26-2 MapTriggerListenerでMapTriggerを名前付きキャッシュに登録

- 26-3 MapTriggerクラス

- 26-4 MapTriggerコールと名前付きキャッシュへの引渡し

- 27-1 イベント・インターセプタの実装例

- 29-1 キャッシュでのロック操作の適用

- 29-2 エントリ・プロセッサを使用しない並列処理制御

- 29-3 エントリ・プロセッサを使用する並列処理制御

- 29-4 トランザクション・キャッシュ定義の例

- 29-5 自動コミット・トランザクションの実行

- 29-6 非自動コミット・トランザクションの実行

- 29-7 複数のキャッシュにわたるトランザクション

- 29-8 拡張クライアント・トランザクション用の入力プロセッサ

- 29-9 CMT使用時のトランザクションの実行

- 29-10 ユーザー制御トランザクションの実行

- 29-11 coherence-transaction.rar使用時のCacheAdapterクラスの使用

- 29-12 coherence-tx.rar使用時のCacheAdapterクラスの使用

- 30-1 キー・アソシエーションの作成

- 30-2 カスタムのKeyAssociator

- 30-3 キー・アソシエータの構成

- 30-4 アフィニティを使用した効率的な問合せの作成

- 31-1 タスク時間およびタスク・ハング構成のサンプル

- 31-2 クライアント・リクエスト・タイムアウト構成のサンプル

- 31-3 タスク・タイムアウトによってスローされる例外

- 34-1 単純なPersonオブジェクト

- 34-2 サンプルJCacheアプリケーション

- 36-1 イベント・リスナーの実装例

- 36-2 イベント・フィルタの実装例

- 37-1 EntryProcessorの実装例

- E-1 オクテット・ストリームに対する32ビット整数値の書込み

- E-2 オクテット・ストリームからの32ビット整数値の読込み

- E-3 オクテット・ストリームへの文字型値の書込み

- E-4 オクテット・ストリームからの文字型値の読込み

図一覧

- 12-1 分散キャッシュでのget操作

- 12-2 分散キャッシュ環境でのput操作

- 12-3 分散キャッシュでのフェイルオーバー

- 12-4 分散キャッシュのローカル記憶域

- 12-5 レプリケート・キャッシュでのget操作

- 12-6 レプリケート・キャッシュでのput操作

- 12-7 ニア・キャッシュでのput操作

- 12-8 ニア・キャッシュでのget操作

- 14-1 バッキング・マップの記憶域

- 14-2 従来のバッキング・マップの実装

- 14-3 パーティション・バッキング・マップの実装

- 15-1 リードスルー・キャッシング

- 15-2 ライトスルー・キャッシング

- 15-3 ライトビハインド・キャッシング

表一覧

- 10-1 圧縮フィルタのパラメータ

- 12-1 キャッシュのタイプと特性のサマリー

- 13-1 ニア・キャッシュの無効化戦略

- 13-2 キャッシュ構成の事前定義済パラメータ・マクロ

- 27-1 エントリ・イベント

- 27-2 エントリ・プロセッサ・イベント

- 27-3 遷移イベント

- 27-4 トランザクション・イベント

- 27-5 ライフサイクル・イベント

- 28-1 Coherenceの問合せ言語の文

- 28-2 Coherenceの問合せ言語コマンド行ツールの引数

- 29-1 Coherenceのトランザクション・オプション

- 29-2 トランザクション・キャッシュのサポートされている属性

- 29-3 TransactionManagerMBeanの属性

- 31-1 実行タイムアウトの要素

- 31-2 サービス・タイプの設定用のコマンド行オプション

- 31-3 タスク・タイムアウトをサポートするメソッド

- 33-1 JCacheとNamedCacheの機能比較

- 35-1 CacheConfiguration MBeanの属性

- 35-2 キャッシュ統計属性

- A-1 オペレーション構成の非終端要素

- A-2 access-controllerのサブ要素

- A-3 address-providerのサブ要素

- A-4 address-providersのサブ要素

- A-5 authorized-hostsのサブ要素

- A-6 cache-factory-builder-configのサブ要素

- A-7 callback-handlerのサブ要素

- A-8 cluster-configのサブ要素

- A-9 cluster-quorum-policy-schemeのサブ要素

- A-10 coherenceのサブ要素

- A-11 configurable-cache-factory-configのサブ要素

- A-12 filterのサブ要素

- A-13 filtersのサブ要素

- A-14 flashjournal-managerのサブ要素

- A-15 flow-controlのサブ要素

- A-16 host-rangeのサブ要素

- A-17 identity-asserterのサブ要素

- A-18 identity-managerのサブ要素

- A-19 identity-transformerのサブ要素

- A-20 incoming-message-handlerのサブ要素

- A-21 init-paramのサブ要素

- A-22 init-paramsのサブ要素

- A-23 instanceのサブ要素

- A-24 journaling-configのサブ要素

- A-25 key-storeのサブ要素

- A-26 license-configのサブ要素

- A-27 logging-configのサブ要素

- A-28 management-configのサブ要素

- A-29 mbeanのサブ要素

- A-30 mbeansのサブ要素

- A-31 mbean-filterのサブ要素

- A-32 member-identityのサブ要素

- A-33 multicast-listenerのサブ要素

- A-34 notification-queuingのサブ要素

- A-35 outgoing-message-handlerのサブ要素

- A-36 outstanding-packetsのサブ要素

- A-37 packet-bufferのサブ要素

- A-38 packet-bundlingのサブ要素

- A-39 packet-deliveryのサブ要素

- A-40 packet-publisherのサブ要素

- A-41 packet-sizeのサブ要素

- A-42 packet-speakerのサブ要素

- A-43 pause-detectionのサブ要素

- A-44 providerのサブ要素

- A-45 ramjournal-managerのサブ要素

- A-46 reporterのサブ要素

- A-47 security-configのサブ要素

- A-48 serializerのサブ要素

- A-49 serializersのサブ要素

- A-50 serviceのサブ要素

- A-51 DistributedCacheサービスのパラメータ

- A-52 ReplicatedCacheサービスのパラメータ

- A-53 OptimisiticCacheサービスのパラメータ

- A-54 起動サービスのパラメータ

- A-55 LocalCacheサービスのパラメータ

- A-56 プロキシ・サービスのパラメータ

- A-57 RemoteCacheサービスのパラメータ

- A-58 RemoteInvocationサービスのパラメータ

- A-59 NameServiceのパラメータ

- A-60 RemoteNameServiceのパラメータ

- A-61 service-guardianのサブ要素

- A-62 servicesのサブ要素

- A-63 shutdown-listenerのサブ要素

- A-64 socket-addressのサブ要素

- A-65 socket-providerのサブ要素

- A-66 socket-providersのサブ要素

- A-67 sslのサブ要素

- A-68 tcp-ring-listenerのサブ要素

- A-69 traffic-jamのサブ要素

- A-70 trust-managerのサブ要素

- A-71 unicast-listenerのサブ要素

- A-72 packet-speakerのサブ要素

- A-73 well-known-addressesのサブ要素

- A-74 オペレーション・デプロイメント・ディスクリプタの属性

- B-1 キャッシュ構成の非終端要素

- B-2 acceptor-configのサブ要素

- B-3 address-providerのサブ要素

- B-4 async-store-managerのサブ要素

- B-5 authorized-hostsのサブ要素

- B-6 back-schemeのサブ要素

- B-7 backing-map-schemeのサブ要素

- B-8 backup-storageのサブ要素

- B-9 bdb-store-managerのサブ要素

- B-10 bundle-configのサブ要素

- B-11 cache-configのサブ要素

- 表B-12 cache-mappingのサブ要素

- B-13 cache-service-proxyのサブ要素

- B-14 cachestore-schemeのサブ要素

- B-15 caching-scheme-mappingのサブ要素

- B-16 caching-schemesのサブ要素

- B-17 class-schemeのサブ要素

- B-18 custom-store-managerのサブ要素

- B-19 defaultsのサブ要素

- B-20 distributed-schemeのサブ要素

- B-21 external-schemeのサブ要素

- B-22 flashjournal-schemeのサブ要素

- B-23 front-schemeのサブ要素

- B-24 http-acceptorのサブ要素

- B-25 identity-managerのサブ要素

- B-26 incoming-message-handlerのサブ要素

- B-27 initiator-configのサブ要素

- B-28 init-paramのサブ要素

- B-29 init-paramsのサブ要素

- B-30 instanceのサブ要素

- B-31 interceptorのサブ要素

- B-32 interceptorsのサブ要素

- B-33 invocation-schemeのサブ要素

- B-34 invocation-service-proxyのサブ要素

- B-35 key-associatorのサブ要素

- B-36 key-partitioningのサブ要素

- B-37 key-storeのサブ要素

- B-38 listenerのサブ要素

- B-39 local-addressのサブ要素

- B-40 local-schemeのサブ要素

- B-41 memcached-acceptorのサブ要素

- B-42 name-service-addressesのサブ要素

- B-43 near-schemeのサブ要素

- B-44 nio-file-managerのサブ要素

- B-45 nio-memory-managerのサブ要素

- B-46 operation-bundlingのサブ要素

- B-47 optimistic-schemeのサブ要素

- B-48 outgoing-message-handlerのサブ要素

- B-49 overflow-schemeのサブ要素

- B-50 paged-external-schemeのサブ要素

- B-51 partition-listenerのサブ要素

- B-52 partitioned-quorum-policy-schemeのサブ要素

- B-53 providerのサブ要素

- B-54 proxy-configのサブ要素

- B-55 proxy-schemeのサブ要素

- B-56 proxy-quorum-policy-schemeのサブ要素

- B-57 ramjournal-schemeのサブ要素

- B-58 read-write-backing-map-schemeのサブ要素

- B-59 remote-addressesのサブ要素

- B-60 remote-cache-schemeのサブ要素

- B-61 remote-invocation-schemeのサブ要素

- B-62 replicated-schemeのサブ要素

- B-63 resource-configのサブ要素

- B-64 serializerのサブ要素

- B-65 socket-addressのサブ要素

- B-66 socket-providerのサブ要素

- B-67 sslのサブ要素

- B-68 tcp-acceptorのサブ要素

- B-69 tcp-initiatorのサブ要素

- B-70 transactional-schemeのサブ要素

- B-71 trust-managerのサブ要素

- B-72 キャッシュ構成デプロイメント・ディスクリプタの属性

- C-1 POFの構成要素

- C-2 default-serializerのサブ要素

- C-3 init-paramのサブ要素

- C-4 init-paramsのサブ要素

- C-5 pof-configのサブ要素

- C-6 serializerのサブ要素

- C-7 user-typeのサブ要素

- C-8 user-type-listのサブ要素

- D-1 事前構成されているシステム・プロパティのオーバーライド値

- E-1 パック整数の最初のオクテットの各領域

- E-2 パック整数の後続オクテットの各領域

- E-3 型IDがない整数値のバイナリ形式

- E-4 事前定義型のID

- E-5 型と値を組み合せた型ID

- E-6 intデータ型と値を結合する型ID

- E-7 他の型に強制変換される可能性がある整数型の型ID

- E-8 10進値を示すことが可能な型ID

- E-9 IEEE 754の特殊な値を示すことが可能な型ID

- E-10 ブール値を示すことが可能な型ID

- E-11 オクテット値として使用可能な整数値

- E-12 Char String形式の値

- E-13 様々な値のコレクションおよび共通コレクション形式

- E-14 様々な値の配列および共通配列形式

- E-15 様々な値のスパース配列および共通スパース配列形式

- E-16 キー/値のペアのバイナリ形式

- E-17 キーの型が共通の場合の、キー/値のペアのバイナリ形式

- E-18 キーと値の型が共通の場合の、キー/値のペアのバイナリ形式

- E-19 「By Reference」セマンティックのバイナリ形式

はじめに

『Oracle Coherenceでのアプリケーションの開発』にようこそ。このドキュメントでは、コンテキストに沿った情報、手順および例を示しています。これらは、Coherenceの使用方法やCoherenceベースのアプリケーションの開発方法を開発者やアーキテクトに示すことを目的としたものです。

対象読者

『Oracle Coherenceでのアプリケーションの開発』の対象読者は次のとおりです。

- 主な対象読者 - Oracle Coherenceの中心的な概念を理解し、Oracle Coherenceのデータ・グリッドを活用したアプリケーションを構築しようというアプリケーション開発者。

- 二次的な対象読者 - Oracle Coherenceの中心的な概念を理解し、データ・グリッドベースのソリューションを構築しようというシステム・アーキテクト。

対象読者は、このガイドを使用するにあたって、Javaに精通している必要があります。また、このガイドに示す例では、Oracle Coherence製品をインストールして使用することが必要です。IDEの使用は、このガイドの使用に際しては不要ですが、ここに示す例を使用した作業を進めるにはお薦めします。キャッシュ・ストア機能を使用する場合には、データベースおよびデータベースの基礎知識が必要です。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、次のOracle Coherenceのドキュメントを参照してください。

- Oracle Coherence*WebでのHTTPセッション・マネージメントの管理

- Oracle Coherenceの管理

- Oracle Coherenceリモート・クライアントの開発

- Oracle Coherenceの統合

- Oracle Coherenceのマネージメント

- Oracle Coherenceの保護

- Oracle Coherenceチュートリアル

- Oracle Coherence Java APIリファレンス

- Oracle Coherence C++ APIリファレンス

- Oracle Coherence .NET APIリファレンス

- Oracle Coherenceリリース・ノート

表記規則

このドキュメントでは、次の表記規則が使用されます。

規則

意味

太字

太字は、アクションに関連付けられているグラフィカル・ユーザー・インタフェース要素と、本文中または用語集で定義されている用語を示します。

イタリック体

イタリック体は、特定の値を指定する必要があるプレースホルダーや変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル・コード、画面に表示されるテキストまたは入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、Oracle Coherenceの新機能と変更された機能について、およびこのガイドに記載されるその他の重要な変更について紹介し、詳細情報へのリンクを提供します。このドキュメントは、旧名『Oracle Coherence開発者ガイド』の新版です。

12c (12.1.3)に関する新機能と変更された機能

このドキュメントでのOracle Coherence 12c (12.1.3)に含まれる新機能と変更された機能は次のとおりです。

- クライアント・アプリケーションにJavaでキャッシュを使用する標準APIを提供するJCacheプロバイダ実装。付録P「Coherence JCache実装の使用」を参照してください。

- RAMジャーナルまたはフラッシュ・ジャーナル内のエントリを自動的に削除するジャーナルの失効およびエビクション。ジャーナルの失効およびエビクションの使用に関する項を参照してください。

- エントリ・プロセッサを非同期的に起動できる非同期エントリ・プロセッサ。「エントリの非同期処理」を参照してください。

12c (12.1.3)に関するこのドキュメントにおけるその他の大きな変更

このマニュアルは、12c (12.1.3)の情報でいくつかの部分が更新されています。次の表に、追加または変更された項を示します。

- マルチキャスト・アドレスの指定につき、ドキュメントを改訂しました。「クラスタのマルチキャスト・アドレスの指定」を参照してください。

- イベント・インターセプタの登録につき、ドキュメントを改訂しました。「イベント・インターセプタの登録」を参照してください。

- ライブ・イベント・スレッド・モデルのドキュメントを改訂しました。「イベントのスレッディングの理解」を参照してください。

- すべての新しい要素および変更された要素につき、オペレーション構成リファレンスが変更されました。付録A「オペレーション構成の要素」を参照してください。

- すべての新しい要素および変更された要素につき、キャッシュ構成リファレンスが変更されました。付録B「キャッシュ構成の要素」を参照してください。

12c (12.1.2)に関する新機能と変更された機能

このドキュメントでのOracle Coherence 12c (12.1.2)に含まれる新機能と変更された機能は次のとおりです。

- Oracle Universal Installerおよびパッチ

- 完全なインストーラ。すべてのインストール・オプションが提供され、グラフィカル・モードまたはサイレント・モードで動作できます。「Coherenceインストーラの実行」を参照してください。

- クイック・インストーラ。サイレント・インストーラが提供されますが、APIのドキュメントおよびサンプルは含まれません。「Coherenceクイック・インストーラの実行」を参照してください。

- サプリメンタル・インストーラ。APIのドキュメントおよびサンプルのみが提供されます。「Coherenceサプリメンタル・インストーラの実行」を参照してください。

- アンインストーラ。Coherenceのインストールをアンインストールできます。「Coherenceのアンインストール」を参照してください。

- Mavenの統合。ビルド・プロセスにおいてCoherenceなどの容易化および標準化を図ります。「Mavenとの統合」を参照してください。

- SLF4Jの統合。SLF4Jロギングを可能にします。「CoherenceログでのSLF4Jの使用」を参照してください。

- クラスタの優先度。クラスタ・メンバー、クラスタ通信コンポーネントおよびスレッドの重要度を割り当てるために使用します。「クラスタの優先度の指定」を参照してください。

- ローカル・ニア・キャッシュの無効化戦略。ニア・キャッシュに、統合削除でないすべてのバッキング・マップ・イベントをリスニングするように指示します。「ニア・キャッシュの無効化戦略」を参照してください。

- フラッシュ・ジャーナルの高いサイズ。ジャーナルから失効した値の削除を開始するタイミングを決定するもので、自動チューニングの基準になります。「フラッシュ・ジャーナル・リソース・マネージャの構成」を参照してください。

- 非同期バックアップ。クライアントは、バックアップ操作中も引き続きリクエストに応答できます。「非同期バックアップの使用」を参照してください。

- クォーラム・フェイルオーバー・アクセス・ポリシー。キャッシュ・サーバーがパーティション・バックアップを適切に再確立できるよう、フェイルオーバー・イベント中にクライアント・リクエストの負荷を軽減します。「カスタム・フェイルオーバー・アクセス・ポリシーの有効化」を参照してください。

- カスタムXMLネームスペースおよびネームスペース・ハンドラ。ユーザー定義のXML要素および属性をキャッシュ構成ファイルに追加できるようにします。第19章「キャッシュ構成ファイルの拡張」を参照してください。

- POF構成ジェネレータ。@Portable注釈が含まれるクラスのユーザー定義型エントリを含むPOF構成ファイルを自動的に作成します。「POF構成ファイルの生成」を参照してください。

- 暗黙的ロック。トランザクションのような方法で、単一のエントリ・プロセッサから複数のキャッシュのキャッシュ・エントリを更新できるようにします。「複数のキャッシュのエントリの処理」を参照してください。

- ライブ・イベント。データ・グリッドに対する操作を実行する際に、クラスタ内での拡張を可能にするイベント・プログラミング・モデルです。このモデルでは、監視可能なクラスタ操作の発生を表すイベントを使用します。第27章「ライブ・イベントの使用」を参照してください。

- パーティション割当て戦略。記憶域が有効なクラスタ・メンバーにどのようにパーティションを割り当てるかを定義します。「パーティション分散戦略の変更」を参照してください。

- InfiniBandメッセージ・バス(IMB)プロバイダ。Remote Direct Memory Access (RDMA)、ゼロ・メッセージ・コピー、カーネル・バイパス、予報通知およびカスタム・ヒープ外バッファをサポートするネイティブInfiniBandプロトコルです。IMBは、Oracle Exalogicシステムでのみ使用できます。<reliable-transport>要素の設定の詳細は、付録16597584「unicast-listenerのサブ要素」および付録16597584「distributed-schemeのサブ要素」を参照してください。

12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

このマニュアルは、12c (12.1.2)の情報でいくつかの部分が更新されています。次の表に、追加または変更された項を示します。

- システム要件が変更されました。「システム要件」を参照してください。

- インストール・ディレクトリの構造の説明が変更されました。「インストール・ディレクトリの参照」を参照してください。

- パケット・バッファの構成手順が変更されました。「パケット・バッファのサイズの構成」および「パケットの最大サイズの調整」を参照してください。

- ニア・キャッシュの無効化戦略の項が変更され、新しいデフォルトの動作が追加されました。「ニア・キャッシュの無効化戦略」を参照してください。

- キーのシリアライズに関する項が追加され、キーをシリアライズする際の考慮事項が記載されました。「POFを使用したキーのシリアライズ」を参照してください。

- キー・アソシエーション・チェックの遅延に関する項が追加されました。「キー・アソシエーション・チェックの遅延」を参照してください。

- 分散キャッシュ・サービスのデフォルトのパーティション数の変更に関する項が追加されました。「パーティションの数の変更」を参照してください。

- すべての新しい要素および変更された要素につき、オペレーション構成リファレンスが変更されました。付録A「オペレーション構成の要素」を参照してください。

- すべての新しい要素および変更された要素につき、キャッシュ構成リファレンスが変更されました。付録B「キャッシュ構成の要素」を参照してください。

第I部

スタート・ガイド

第I部は、次の章で構成されています。

- 第1章「Coherenceの概要」

- 第2章「Oracle Coherence for Javaのインストール」

- 第3章「構成の理解」

- 第4章「最初のCoherenceアプリケーションの作成」

- 第5章「Coherenceでのデバッグ」

1 Coherenceの概要

この章では、Coherenceの概念と機能の概要について説明します。製品の機能、その使用方法および特定機能の実装方法について、簡単にまとめてあります。この章で取り上げた項目に関しては、このガイド全体をとおして詳細に説明しています。

この章には次の項が含まれます:

- 基本的な概念

- 読取り/書込みキャッシング

- キャッシュの問合せ

- 起動サービス

- イベント・プログラミング

- トランザクション

- HTTPセッション管理

- オブジェクト・リレーショナル・マッピングの統合

- C++/.NETの統合

- 管理およびモニタリング

1.1 基本的な概念

この項のトピックでは、Coherenceの基本概念について説明し、Coherenceを使用したデータのクラスタ化に関連するいくつかの重要な機能について説明します。

1.1.1 クラスタ化されたデータの管理

Coherenceの中核をなすのは、クラスタ化されたデータ管理の概念です。この概念を実現するには、次の目標を達成する必要があります。

- 完全に一貫した、単一システム・イメージ(SSI)

- 読取りおよび書込みアクセスのスケーラビリティ

- 高速で透過的なフェイルオーバーおよびフェイルバック

- 記憶域および処理の線形スケーラビリティ

- シングル・ポイント障害(SPOF)の排除

- クラスタ全体のロックおよびトランザクション

この基盤の上に、データベース・キャッシング、HTTPセッション管理、グリッド・エージェントの起動、分散問合せなど、Coherenceが提供する様々なサービスが構築されます。これらの機能を詳細に説明する前に、いくつかの基本的なCoherenceの側面について説明します。

1.1.2 論理層の単一のAPI、物理層のXML構成

Coherenceでは、クラスタ化されたデータを管理するために、多数のトポロジがサポートされています。これらの各トポロジには、パフォーマンスとフォルト・トレランスに関してトレードオフがあります。単一のAPIを使用することで、必要に応じてトポロジの選択をデプロイまで遅延できます。これにより、開発者はCoherenceの一貫した論理表示を確認しながら、チューニング時またはアプリケーションで変更が必要なときの柔軟性を確保できます。

1.1.3 キャッシング戦略

Coherenceは複数のキャッシュ実装を提供しています。

- ローカル・キャッシュの理解: 非クラスタ化キャッシング用のローカルのヒープ上のキャッシング。

- レプリケート・キャッシュの理解: 容量の少ない、頻繁に読取りが実行されるキャッシュに最適です。

- 分散キャッシュの理解: 読取りおよび書込みアクセスに対して線形スケーラビリティが実現されます。データはノード間で自動的、動的、および透過的にパーティション化されます。分散アルゴリズムがネットワーク・トラフィックを最小化し、データが徐々に移動されることでサービスの停止が回避されます。

- ニア・キャッシュの理解: 分散キャッシングのスケーラビリティで、ローカル・キャッシングのパフォーマンスが提供されます。パフォーマンスと同期の保証とのトレードオフに応じて、様々な戦略でのニア・キャッシュが可能です。

インプロセス・キャッシングでは、オブジェクトがローカルJVM内で管理されるため、最高レベルのrawパフォーマンスを提供します。この利点は、ローカル、レプリケート、オプティミスティックおよびニア・キャッシュの実装により最も直接的に実現されます。

アウトオブプロセス(クライアント/サーバー)キャッシングには、専用キャッシュ・サーバーを使用するオプションが用意されています。これは、ワークロードをパーティション化する(アプリケーション・サーバーの負荷を軽減するため)場合に役立ちます。これは、パーティション・キャッシュの実装を使用して、単一のコマンド行オプション、またはXML構成の1行のエントリでクライアント・ノードのローカル記憶域を無効化するだけで実行できます。

(ニア・キャッシュ機能を使用した)階層キャッシングにより、アプリケーション・サーバー上のローカル・キャッシュと、より大きなキャッシュ・サーバー上のパーティション・キャッシュを組み合せて、パーティション・キャッシュのスケーラビリティとローカル・キャッシュのrawパフォーマンスを融合できます。これは、専用キャッシュ・サーバーおよび同一の場所に配置されたキャッシング(アプリケーション・サーバーJVM内に保存されたキャッシュ・パーティション)の実装に役立ちます。

キャッシュの構成と使用の詳細は、第I部「キャッシュの使用」を参照してください。

1.1.4 データ記憶域の各オプション

ほとんどのユーザーは、ヒープ上の記憶域を専用キャッシュ・サーバーと組み合せて使用しますが、Coherenceにはデータ記憶域用の複数のオプションがあります。

- ヒープ上: 最速のオプション。ただし、JVMガベージ・コレクションの実行時間に影響する場合があります。

- ジャーナル: ジャーナル技術を使用し、ソリッド・ステート・ディスク向けに最適化されたRAM記憶域とディスク記憶域の組合せ。ジャーナルベースの記憶域では、シリアライズおよびデシリアライズが必須です。

- ファイルベース: Berkeley Database JEの記憶域システムを使用します。

Coherenceの記憶域は一時的なものであり、ディスクベースの記憶域オプションではキャッシュされたデータのみを管理します。Coherenceには、永続記憶域として、CacheLoaderやCacheStoreのほか、バッキング・マップが用意されています。

詳細は、第14章「記憶域およびバッキング・マップの実装」を参照してください。

1.1.5 シリアライズの各オプション

シリアライズは、多くの場合、クラスタ化されたデータ管理における最も費用を要する部分になるため、Coherenceではデータのシリアライズ/デシリアライズ用に次のオプションを用意しています。

- com.tangosol.io.pof.PofSerializer - Portable Object Format (POF)は言語に依存しないバイナリ形式です。POFは領域と時間の両面で効率を向上させるように設計された、Coherenceの推奨シリアライズ・オプションです。第20章「Portable Object Formatの使用」を参照してください。

- java.io.Serializable - 最も単純で処理の遅いオプション。

- java.io.Externalizable - 開発者が手動でシリアライズを実装する必要がありますが、パフォーマンスの大幅な向上が見込めます。java.io.Serializableと比べて、シリアライズされたデータのサイズを2倍以上削減できます(分散キャッシュでは、一般的にデータがシリアライズされた形式でキャッシュされるため特に有用です)。最も重要なのは、CPU使用率が劇的に削減されるということです。

- com.tangosol.io.ExternalizableLite - java.io.Externalizableと非常によく似ていますが、より効率的なI/Oストリームの実装を使用することで、パフォーマンスの向上とメモリー使用量の削減を図れます。

- com.tangosol.run.xml.XmlBean – ExternalizableLiteのデフォルトの実装です。

1.1.6 構成可能性および拡張性

CoherenceのAPIでは、Coherenceのすべての機能へのアクセスを提供します。このAPIで最も頻繁に使用されるサブセットは、単純なXMLオプションを介して公開されるため、一般的な使用例での作業が最低限に抑えられます。APIを介した直接の構成と、より簡単なXML構成を組み合せても問題はありません。

Coherenceは、必要に応じてそのモジュールを置換できるように設計されています。たとえば、ローカルのバッキング・マップ(各ノードの実際の物理データ記憶域を提供する)は、必要に応じて簡単に置換できます。これは、ほとんどの場合は不要ですが、万が一のために用意されています。一般的な目安として、作業の80%は簡単に実行できますが、残りの20%(特殊なケース)の作業は多少の労力を要します。ただし、ほとんどの場合、難無く実行できるはずです。

1.1.7 ネームスペースの階層

Coherenceは、サービス・セットとして編成されます。その基礎となるのはクラスタ・サービスです。クラスタは、Coherenceインスタンス(各コンピュータの1つ以上のJVMで、JVMごとに1つのインスタンスを持つ)のセットとして定義されます。クラスタ・サービスの下には、Coherence APIを構成する各種サービスがあります。これには、様々なキャッシング・サービス(レプリケート、分散など)および起動サービス(クラスタの様々なノードへのエージェントのデプロイ用)が含まれます。サービスの各インスタンスには名前が付けられ、各タイプには、通常、デフォルトのサービス・インスタンスがあります。

キャッシュ・サービスには、名前付きキャッシュ(com.tangosol.net.NamedCache)が含まれます。これはデータベース表と似ており、通常は関連するオブジェクトのセットが含まれます。

クラスタ・サービスとCoherenceによって提供されるその他のクラスタベースのサービスの詳細は、第6章「Coherenceクラスタの概要」を参照してください。

1.2 読取り/書込みキャッシング

この項では、キャッシュ・インスタンスの取得と操作のためにアプリケーションによって使用される主要インタフェースであるNamedCache APIの概要を示します。また、NamedCache APIの使用方法についても説明します。

1.2.1 NamedCache

次のソース・コードは、NamedCacheインスタンスへの参照を返します。必要に応じて、基礎となるキャッシュ・サービスが起動されます。NamedCacheインタフェースの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

import com.tangosol.net.*;
...
NamedCache cache = CacheFactory.getCache("MyCache");

Coherenceでは、MyCacheの名前マッピング用のキャッシュ構成XMLファイルをスキャンします。これは、Webコンテナのweb.xmlファイルにおけるサーブレット名のマッピングと似ています。Coherenceのキャッシュ構成ファイルには、最も単純なケースでのキャッシュ名からキャッシュ・スキームへのマッピングのセットと、キャッシュ・スキームのセットが含まれます。

デフォルトで、Coherenceは、coherence.jarのルートにあるcoherence-cache-config.xmlファイルを使用します。これは、JVMコマンド行で-Dtangosol.coherence.cacheconfig=file.xmlを使用してオーバーライドできます。この引数では、ファイル・システム・パスまたはJavaリソース・パスを参照できます。

com.tangosol.net.NamedCacheインタフェースは、他のいくつかのインタフェースを拡張します。

- java.util.Map: get()、put()、remove()などの基本的なMapメソッド。

- com.tangosol.util.ObservableMap: キャッシュ・イベントをリスニングするメソッド(第25章「マップ・イベントの使用」を参照してください)。

- com.tangosol.net.cache.CacheMap: キャッシュ内のキーのコレクションを取得(Mapとして)するため、およびオブジェクトをキャッシュに入れるためのメソッド。エントリをキャッシュに入れるときに、有効期限の値を追加することもできます。

- com.tangosol.util.QueryMap: キャッシュの問合せ用のメソッド(『Oracle Coherenceでのアプリケーションの開発』の「キャッシュの問合せ」を参照してください)

- com.tangosol.util.ConcurrentMap: lock()やunlock()などの同時アクセス用のメソッド。

- com.tangosol.util.InvocableMap: キャッシュ・データのサーバー側の処理用メソッド

1.2.2 キャッシュされたオブジェクトの要件

キャッシュのキーと値は、シリアライズ可能(たとえば、java.io.Serializable)である必要があります。さらに、キャッシュ・キーはhashCode()とequals()メソッドの実装を提供する必要があり、これらのメソッドはクラスタ・ノード間で一貫性のある結果を返す必要があります。これは、hashCode()およびequals()の実装は、オブジェクトのシリアライズ可能な状態(つまり、オブジェクトの一時的でないフィールド)にのみ基づいている必要があることを示しています。String、Integer、Dateなどのほとんどの組込みのJava型はこの要件を満たしています。一部のキャッシュの実装(特にパーティション・キャッシュ)では、等価の検証にキー・オブジェクトのシリアライズされた形式を使用します。つまり、equals()でtrueを返すキーは、同様の方法でシリアライズされる必要があります。ほとんどの組込みのJava型はこの要件を満たしています。

1.2.3 NamedCacheの使用パターン

NamedCacheの使用方法には、一般的には2つのアプローチがあります。

- いくつかの追加機能(問合せ、並行性)を持つが、永続性バッキングは含まないjava.util.Mapのクラスタ化された実装(サイド・キャッシュ)。

- 外部データ・ソースへのアクセスの切離しの手段(インライン・キャッシュ)。この場合、アプリケーションではNamedCacheインタフェースを使用し、このNamedCacheによって、基礎となるデータベース(または他のリソース)が管理されます。

通常、インライン・キャッシュは、次のデータのキャッシュに使用されます。

- データベース: キャッシュの最も直感的な使用方法。単純にデータベース表を(Javaオブジェクトの形式で)キャッシュします。

- サービス: メインフレーム、Webサービス、サービス・ビューロ。(計算コストまたは実際のアクセス料金が発生するために)アクセスに多額の費用がかかるリソースを表すサービス。

- 計算: 財務上の計算、集計、およびデータ変換。インライン・キャッシュを使用すると、計算の重複を容易に回避できます。計算が完了している場合、その結果はキャッシュから容易に取得できます。任意のシリアライズ可能なオブジェクトはキャッシュ・キーとして使用できるため、計算パラメータを含むオブジェクトをキャッシュ・キーとして簡単に使用できます。

インライン・キャッシングの詳細は、第15章「データ・ソースのキャッシュ」を参照してください。

ライトバックの各オプションは次のとおりです。

- ライトスルー: 外部データ・ソースに常に最新の情報が含まれるようにします。データをすぐに永続化させる必要がある場合、またはデータ・ソースを他のアプリケーションと共有する場合に使用されます。

- ライトビハインド: 書込みを外部データ・ソースにキャッシュすることで、高いパフォーマンスが得られます。書込みをバッファリングしてデータ・ソースの負荷を分散させることができるだけでなく、複数の書込みを組み合せてI/Oをさらに削減できますデータがすぐにはディスクに永続化されないというデメリットがある一方で、クラスタ全体にすぐに配信されるためサーバー障害に強いというメリットがあります。さらに、データ・セット全体がキャッシュされている場合、このオプションを使用すると、アプリケーションはデータ・ソースの完全な障害を一時的に切り抜けることができます。キャッシュの読取りおよび書込みでは、データ・ソースへの同期アクセスが必要ないからです。

読取り専用のインライン・キャッシュを実装するには、com.tangosol.net.cache.CacheLoaderインタフェースで2つのメソッドを実装するだけで済みます。1つはシングルトン読取り用、もう1つはバルク読取り用です。Coherenceでは、抽象クラスcom.tangosol.net.cache.AbstractCacheLoaderが用意されています。これは、バルク・メソッドのデフォルトの実装を提供します。つまり、単一メソッドpublic Object load(Object oKey)の実装のみが必要であることを意味します。このメソッドは、任意のキャッシュ・キーを受け入れ、適切な値オブジェクトを返します。

読取り/書込みキャッシングを実装する場合、com.tangosol.net.cache.AbstractCacheStoreを拡張する必要があります(またはインタフェースcom.tangosol.net.cache.CacheStoreを実装する)。これにより、次のメソッドが追加されます。

public void erase(Object oKey);
public void eraseAll(Collection colKeys);
public void store(Object oKey, Object oValue);
public void storeAll(Map mapEntries);

メソッドerase()は、外部データ・ソースから指定されたキーを削除します。メソッドstore()は、データ・ソースの指定されたアイテムが存在すればそれを更新し、存在しなければそれを挿入します。

CacheLoaderまたはCacheStoreを実装したら、coherence-cache-config.xmlファイルを介してそれに接続できます。

1.3 キャッシュの問合せ

Coherenceには、キャッシュされたデータを問い合せる機能が用意されています。パーティション・キャッシュを使用すると、問合せは索引付けされ、並列化されます。つまり、サーバーをパーティション・キャッシュに追加すると、スループット(1秒当たりの問合せ合計)が向上するのみでなく、待機時間が減少して問合せにかかるユーザー時間が短くなります。NamedCacheに問い合せるには、すべてのオブジェクトで共通のインタフェース(またはベース・クラス)を実装する必要があります。オブジェクトの任意のフィールドを問合せできます。索引はオプションで、パフォーマンスを向上させるために使用されます。レプリケート・キャッシュを使用する場合、問合せはローカルで実行され、索引は使用されません。詳細は、第22章「キャッシュ内のデータの問合せ」を参照してください。

索引をNamedCacheに追加するには、まず値エクストラクタが必要です(入力に値オブジェクトを受け入れ、そのオブジェクトの属性を返します)。索引はいくつでも追加できます(重複した索引は無視されます)。また、キャッシュへのデータの挿入前または挿入後に、いつでも追加できます。

問合せは、キャッシュされたデータにしか適用されないことに注意してください。そのため、データ・セット全体をキャッシュにロードしていない場合は、問合せを使用できません(部分的にロードされたセットを管理するサポートが追加されている場合を除く)。

開発者は問合せ用の追加のカスタム・フィルタを実装して、問合せの並列化を活用できます。特にパフォーマンスを重視する問合せでは、索引に対応したフィルタを実装できます。これにより、Coherenceの内部的な索引構造にアクセスできます。

Coherenceには組込みのオプティマイザがあり、最適な順序で索引を適用します。問合せの対象は限定されるため、オプティマイザは効果的かつ効率的な機能です。オプティマイザを保守する必要はありません。

1.4 起動サービス

Coherenceの起動サービスでは、計算エージェントをクラスタ内の様々なノードにデプロイできます。これらのエージェントは、実行スタイル(デプロイして非同期にリスニングする)または問合せスタイル(デプロイして同期的にリスニングする)で実行可能です。起動サービスの使用方法の詳細は、第24章「キャッシュ内のデータの処理」を参照してください。

起動サービスは、com.tangosol.net.InvocationServiceインタフェースを通じてアクセスされ、次の2つのメソッドを含みます。

例1-1 InvocationService APIのメソッド

public void execute(Invocable task, Set setMembers, InvocationObserver observer);
public Map query(Invocable task, Set setMembers);

サービスのインスタンスは、com.tangosol.net.CacheFactoryクラスから取得できます。

Coherenceでは、タスク指向処理のWorkManager APIを実装します。

1.5 イベント・プログラミング

Coherenceでは2つのイベント・プログラミング・モデルがサポートされており、これらのモデルによって、アプリケーションはクラスタ操作の通知を受信して反応を返すことができます。アプリケーションは、どのコンピュータがイベントを発生させたのかに関係なく、イベントを論理概念として監視できます。イベントにより、Coherenceをアプリケーション固有のロジックで拡張する一般的な方法が提供されます。イベント・プログラミング・モデルには、次のものがあります。

- ライブ・イベント - ライブ・イベント・プログラミング・モデルでは、様々なタイプのイベントを受信するように登録されたユーザー定義イベント・インターセプタを使用します。アプリケーションは、イベント・タイプに基づいて実行するアクションを決定します。マップ・イベントを使用することで使用可能な数々のイベントも、ライブ・イベントの使用でサポートされます。詳細は、第27章「ライブ・イベントの使用」を参照してください。

- マップ・イベント - マップ・イベント・プログラミング・モデルでは、基礎となるマップ実装にアタッチされたユーザー定義マップ・リスナーを使用します。マップ・イベントでは、カスタマイズ可能なサーバーベースのフィルタおよび軽量イベントが提供され、これらによってネットワークのトラフィックおよび処理を最低限に抑えることができます。マップ・リスナーはJavaBeanパラダイムに従っており、システム・キャッシュ・イベント(エビクションなど)やアプリケーション・キャッシュ・イベント(get/put操作など)を区別できます。イベントの使用方法の詳細は、第25章「マップ・イベントの使用」を参照してください。

1.6 トランザクション

Coherenceには様々なトランザクション・オプションが用意されています。たとえば、ConcurrentMapインタフェースおよびEntryProcessor APIを使用した基本データの同時実行性、暗黙的ロックおよびEntryProcessor APIを使用したパーティションレベルのトランザクション、トランザクション・フレームワークAPIを使用したアトミック・トランザクション、Coherenceリソース・アダプタを使用したXAの完全サポートなどです。詳細は、第29章「トランザクションの実行」を参照してください。

1.7 HTTPセッション管理

Coherence*Webは、広範なアプリケーション・サーバーをサポートする、HTTPセッション管理モジュールです。Coherence*Webの詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

Coherenceセッション管理を使用する場合、アプリケーションを変更する必要はありません。Coherence*Webでは、ニア・キャッシュを使用して、ほぼ無限のスケーラビリティを持つ完全にフォルト・トレラントなキャッシングを提供します(数百個のクラスタ・ノードで問題なく機能します)。

1.8 オブジェクト・リレーショナル・マッピングの統合

ほとんどのORM製品では、CoherenceがL2キャッシング・プラグインとしてサポートされています。これらのソリューションは、Coherence内のエンティティ・データをキャッシュすることで、複数サーバー上のアプリケーションによるキャッシュされたデータの共有を可能にします。詳細は、『Oracle Coherenceの統合』を参照してください。

1.9 C++/.NETの統合

Coherenceでは、クロス・プラットフォームのクライアントがサポートされます(TCP/IP上)。すべてのクライアントが、同じワイヤ・プロトコルを使用します(サーバーでは、クライアントのプラットフォームの違いが認識されません)。また、これらのいずれのクライアントにもサード・パーティ・コンポーネント(埋込みJVMや言語ブリッジなど)はありません。ワイヤ・プロトコルでは、すべてのクライアント・プラットフォームでイベント・フィードおよび一貫したインプロセス・キャッシングがサポートされます。Coherence*Extendを使用してリモートのC++クライアントおよび.NETクライアントをサポートするための手順の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

1.10 管理およびモニタリング

Coherenceでは、Java Management Extensions (JMX)を使用して管理機能とモニタリング機能を提供します。CoherenceでのJMXの使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

2 Oracle Coherence for Javaのインストール

この章では、Oracle Coherence for Java(略してCoherence)のインストールおよび実行手順について説明します。Coherence*Extendクライアント・ディストリビューション(C++および.NET)またはCoherence*Webのインストール手順については説明していません。これらのコンポーネントのインストール手順の詳細は、それぞれ『Oracle Coherenceリモート・クライアントの開発』および『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

この章には次の項が含まれます:

- システム要件

- Coherenceのインストールの実行

- インストール・ディレクトリの参照

- 環境変数の設定

- Coherenceの最初の実行

- Mavenとの統合

- Coherenceのアンインストール

2.1 システム要件

Coherenceインストーラを実行するための最小要件は次のとおりです。

- 300MHz CPU

- 512 MBスワップ領域

- 256カラー・モニター(GUIベースのインストールにのみ必要)

- JDK 1.6.0_4以上

開発環境でCoherenceを実行するために推奨される最小限のシステム要件を次に示します。

- 100 MBのディスク領域(APIのドキュメントおよびサンプルを含む完全なインストールの場合)

- 1GBのRAM (Javaの最大ヒープ・サイズを512MBとした場合) - この容量のRAMでは、すべてのデータのバックアップを格納するように構成された単一ノード上での理想的な150MBの最大キャッシュ・サイズ(150MB x 2)がサポートされ、1/3以上のヒープをスクラッチおよびJVMタスクに使用できます。キャッシュ・サイズの計算の詳細は、『Oracle Coherenceの管理』を参照してください。

- キャッシュ・サーバーおよびクライアント用にJVM (JREまたはJDK) 1.7以上。Coherence*Extendクライアント用に1.6以上。多くの場合、開発にはJDKが使用されます。JDKはJavaアプリケーションのモニタリングおよびトラブルシューティングのためのツールを提供しますが、Coherenceの実行には必須ではありません。

- 必要なJavaのバージョンをサポートするWindowsベースまたはUNIXベースのシステム

- ネットワーク・アダプタ

2.2 Coherenceのインストールの実行

Coherenceは、Oracle Universal Installerを使用してインストールします。このインストーラは、Oracle製品のインストールとパッチ・サービスの両方を提供します。Coherenceに使用可能なインストーラは次のとおりで、この項で詳細を説明します。

- fmw_version_coherence.jar - 完全なCoherenceのインストールで、グラフィカル・モードとサイレント・モードのどちらでも実行できます。「Coherenceインストーラの実行」を参照してください。

- fmw_version_coherence_quick.jar - 最小限のCoherenceのインストールで、常にサイレント・モードで実行されます。クイック・インストーラではフットプリントが少なくなりますが、APIのドキュメントおよびサンプルは含まれません。「Coherenceクイック・インストーラの実行」を参照してください。

- fmw_version_coherence_quick_supplemental.jar - サプリメンタル・インストールで、常にサイレント・モードで実行されます。サプリメンタル・インストーラには、APIのドキュメントおよびサンプルのみが含まれます。「Coherenceサプリメンタル・インストーラの実行」を参照してください。

- fmw_version_wls.jar - 完全なWebLogic Serverのインストールで、Coherenceも含まれます。「WebLogic ServerとCoherenceのインストール」を参照してください。

Coherenceは、常にORACLE_HOME/coherenceディレクトリにインストールされます。Coherenceのドキュメントでは、coherenceディレクトリへの完全なパスをCOHERENCE_HOMEと呼びます。

2.2.1 Coherenceインストーラの実行

Coherenceインストーラは、fmw_version_coherence.jarという実行可能なJava ARchive (JAR)ファイルとして配布されます。ターゲット・コンピュータでインストーラを実行するには、javaコマンドを使用します。このインストーラでは、グラフィカル・モードとサイレント・モードのどちらもサポートされています。インストーラのオプションに関する詳細なヘルプについては、インストーラの実行中に-help引数を使用してください。

この項には次のトピックが含まれます:

- グラフィカル・モードでのCoherenceのインストールの実行

- サイレント・モードでのCoherenceのインストールの実行

2.2.1.1 グラフィカル・モードでのCoherenceのインストールの実行

グラフィカル・モードでのCoherenceのインストールの実行手順は、次のとおりです。

1. fmw_version_coherence.jarファイルをターゲット・コンピュータにコピーします。

2. コマンド・プロンプトから、ディレクトリをcoherence_version.jarファイルの場所に変更し、次のコマンドを実行します(JAVA_HOME/binがコンピュータのPATHにあると想定します)。

java -jar fmw_version_coherence.jar

Oracle Coherenceのインストーラが起動し、「ようこそ」画面が表示されます。UNIXベースのプラットフォームの場合は、(「ようこそ」画面より前に)最初に、Oracle製品のインベントリ・データが書き込まれるインベントリ・ディレクトリを選択するように指示されます。インベントリ・ディレクトリを作成するには、画面上の指示に従います。

3. 「次へ」をクリックします。「インストールの場所」画面が表示されます。ドロップダウン・リストを使用して、Coherenceのインストール先の既存のORACLE_HOMEディレクトリを選択するか、絶対パスを入力して新しいCoherence ORACLE_HOMEディレクトリを作成します。必要に応じて「参照」をクリックしてディレクトリを検索します。ディレクトリは、既存のCoherenceのインストールを含むことはできません。

4. 「次へ」をクリックします。「インストール・タイプ」画面が表示されます。インストールするオプションを選択します。

5. 「次へ」をクリックします。「インストール・サマリー」画面が表示されます。インストールを確認します。今回のインストールを別のコンピュータに複製する予定がある場合は、「レスポンス・ファイルの保存」をクリックします。まったく同じインストール設定でサイレント・インストールを実行する際に使用可能なレスポンス・ファイルが作成されます。サイレント・インストールの実行の詳細は、「サイレント・モードでのCoherenceのインストールの実行」を参照してください。

6. 「インストール」をクリックします。「インストールの進行状況」画面が表示され、成功および失敗したタスクがすべて表示されます。

7. 「次へ」をクリックします。「インストール 完了」画面が表示され、インストールのサマリーが表示されます。

8. 「終了」をクリックし、Oracle Coherenceインストーラを閉じます。

2.2.1.2 サイレント・モードでのCoherenceのインストールの実行

サイレント・モードでは、グラフィカル・インタフェースを使用せずにCoherenceをインストールでき、リモート・インストールの場合またはスクリプトの一部としてインストールを組み込む場合に便利です。サイレント・モードでは、一般的に、name=valueのペアとしてインストール・パラメータを含むレスポンス・ファイル(.rsp)を使用します。グラフィカル・モードでインストーラを実行し、「インストール・サマリー」画面でインストール・パラメータをレスポンス・ファイルに保存することでレスポンス・ファイルを作成します。保存したファイルを使用して他のコンピュータでインストールをレプリケートするか、必要に応じてファイルを編集してインストールを変更します。

サイレント・モードでのCoherenceのインストールの実行手順は、次のとおりです。

1. fmw_version_coherence.jarファイルおよびレスポンス・ファイルをターゲット・コンピュータにコピーします。

2. コマンド・プロンプトから、ディレクトリをcoherence_version.jarファイルの場所に変更し、次のコマンドを実行します(JAVA_HOME/binがコンピュータのPATHにあると想定します)。

java -jar fmw_version_coherence.jar -silent -responseFile full_path_to_response_file -waitForCompletion

UNIXベースのプラットフォームの場合は、oraInst.locインベントリ・ディレクトリ・ポインタ・ファイルがデフォルトの場所(/etc)に見つからないと、そのファイルの場所を要求されます。このコンピュータにOracle製品をインストールしたのが初めてである場合は、createCentralInventory.shスクリプトを使用して、/etcディレクトリのインベントリ・ディレクトリ・ポインタ・ファイルを設定できます。このスクリプトには、ルート権限が必要です。

oraInst.locファイルにカスタムの場所を使用する場合は、-invPtrLocインストーラ・オプションを使用して場所を指定します。例:

java -jar fmw_version_coherence.jar -silent -responseFile full_path_to_response_file -waitForCompletion -invPtrLoc /MyDirectory/oraInst.loc

oraInst.locファイルの内容には、インベントリ・ディレクトリの場所および所有者グループが含まれます。例:

inventory_loc=/MyDirectory/oraInventory
inst_group=group

2.2.2 Coherenceクイック・インストーラの実行

クイック・インストールは、fmw_version_coherence_quick.jarという実行可能なJARファイルとして配布されます。ターゲット・コンピュータでインストーラを実行するには、javaコマンドを使用します。インストーラのオプションに関する詳細なヘルプについては、インストーラの実行中に-help引数を使用してください。

クイック・インストールは、オプションのないサイレント・インストールを実行します。この配布に含まれるライフサイクル・ツールは多くありませんが、Oracleインベントリの一部として、将来ライフサイクル操作を使用できるCoherenceコンポーネントを登録します。また、このインストールには、APIのドキュメントおよびコード・サンプルは含まれません。結果として、通常のCoherenceインストーラよりもインストール・プロセスが高速になり、インストール・フットプリントが小さくなります。ユーザーの操作を必要とせずにスクリプトの一部としてCoherenceをインストールする理想的な方法です。

Coherenceのクイック・インストールの実行手順は、次のとおりです。

1. fmw_version_coherence_quick.jarファイルをターゲット・コンピュータのディレクトリにコピーします。

2. コマンド・プロンプトから、ディレクトリをfmw_version_coherence_quick.jarファイルの場所に変更し、次のコマンドを実行します(JAVA_HOME/binがコンピュータのPATHにあると想定します)。

java -jar fmw_version_coherence_quick.jar ORACLE_HOME=/oracle

ORACLE_HOME変数の値は、CoherenceがインストールされるORACLE_HOMEディレクトリを指定します。この値は絶対パスである必要があります。ディレクトリがすでに存在する場合は、空であるか、または既存の有効なORACLE_HOMEである必要があります。ディレクトリは、既存のCoherenceのインストールを含むことはできません。ディレクトリが存在しない場合は、インストーラによって作成されます。また、空である現在の作業ディレクトリからインストールを開始し、ORACLE_HOME変数を省略することも可能で、この場合は現在の作業ディレクトリがORACLE_HOMEディレクトリになります。例:

cd /oracle
java -jar /tmp/fmw_version_coherence_quick.jar

UNIXベースのプラットフォームの場合、クイック・インストーラは/etcディレクトリ内のoraInst.locインベントリ・ディレクトリ・ポインタ・ファイルを見つけようとします。ファイルが見つからない場合は、/tmpディレクトリがインベントリ・ディレクトリとして使用されます。このコンピュータにOracle製品をインストールしたのが初めてである場合は、createCentralInventory.shスクリプトを使用して、/etcディレクトリのインベントリ・ディレクトリ・ポインタ・ファイルを設定できます。このスクリプトには、ルート権限が必要です。

oraInst.locファイルにカスタムの場所を使用する場合は、-invPtrLocインストーラ・オプションを使用して場所を指定します。例:

java -jar fmw_version_coherence_quick.jar -invPtrLoc /MyDirectory/oraInst.loc

oraInst.locファイルの内容には、インベントリ・ディレクトリの場所および所有者グループが含まれます。例:

inventory_loc=/MyDirectory/oraInventory
inst_group=group

2.2.3 Coherenceサプリメンタル・インストーラの実行

サプリメンタル・インストールは、fmw_version_coherence_quick_supplemental.jarという実行可能なJARファイルとして配布されます。この配布は、既存のCoherenceインストールにAPIのドキュメントおよびコード・サンプルをインストールするために使用します。サプリメンタル・インストーラは、オプションなしのサイレント・インストールを実行します。通常は、ユーザーの操作なしでスクリプトの一部としてインストールを実行するクイック・インストーラとあわせて使用します。APIのドキュメントおよびコード・サンプルが不要な場合は、サプリメンタル・インストールをスキップできます。

1. fmw_version_coherence_quick_supplemental.jarファイルをCoherenceのインストール先のORACLE_HOMEディレクトリにコピーします。

2. コマンド・プロンプトから、ディレクトリをfmw_version_coherence_quick_supplemental.jarファイルの場所に変更し、次のコマンドを実行します(JAVA_HOME/binがコンピュータのPATHにあると想定します)。

java -jar fmw_version_coherence_quick_supplemental.jar

インストールが開始され、ステータス・メッセージが出力されます。

2.2.4 WebLogic ServerとCoherenceのインストール

WebLogic ServerインストーラにはCoherenceの配布が含まれており、WebLogic Serverと同じORACLE_HOMEディレクトリにCoherenceがインストールされます。WebLogic Serverには、WebLogic Serverドメイン内でのCoherenceの管理方法およびデプロイ方法を標準化するCoherence統合が用意されています。この統合により、CoherenceをWebLogic Serverのサブシステムにして、Coherence環境の管理にWebLogic Serverのツールおよびインフラストラクチャ(Java EEスタイルのパッケージ化およびデプロイ、リモート・サーバー管理、サーバー・クラスタ、WebLogic Scripting Tool (WLST)の自動化、管理コンソールによる構成など)を使用できます。WebLogic ServerとCoherenceのインストールの詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

2.3 インストール・ディレクトリの参照

COHERENCE_HOMEには、次のディレクトリが含まれます。

- bin - このディレクトリには、キャッシュ・サーバーの起動、開発ツールの起動、ネットワーク・タスクの実行など、様々なタスクを実行するための共通のスクリプト・セットが含まれています。スクリプトは、Windowsベース(.cmd)とUNIXベース(.sh)の両方の形式が用意されています。

- doc - このディレクトリには、Coherence Java APIリファレンスおよびOracle Technology Network (OTN)上のCoherenceのドキュメントへのリンクが含まれています。Coherence Java APIリファレンスは、JARファイルとして配布されており、抽出する必要があります。このJARは、開発中にアクセスを容易にするためにIDEにインポートすることもできます。
Coherence Java APIリファレンスを抽出するには、次のコマンドを/apiディレクトリから実行します(JAVA_HOME/binがコンピュータのPATHにあると想定します)。

jar -xvf CoherenceJavaDoc-version.jar

- example - このディレクトリには、多くのCoherence機能を示す一連の例とCoherence APIの使用方法が含まれています。サンプルのビルドおよび実行の詳細は、『Oracle Coherenceチュートリアル』を参照してください。

- lib - このディレクトリには、提供されているすべてのライブラリが含まれています。coherence.jarライブラリは主要な開発およびランタイム・ライブラリです。このライブラリについては、このドキュメント全体を通じて詳細に説明しています。

- plugins – このディレクトリには、一般的な統合を行うためのプラグインが含まれています。CoherenceはプラグインをMavenおよびJava VisualVMに提供します。Mavenプラグインは、CoherenceをMavenビルド・プロセスの一部に統合するために使用されます。CoherenceのMavenプラグインの詳細は、「Mavenとの統合」を参照してください。Java VisualVMプラグインは、Coherenceモニタリングを提供するために使用されます。Java VisualVMプラグインの詳細は、『Oracle Coherenceのマネージメント』を参照してください。

2.4 環境変数の設定

次のシステム環境変数を設定することもできますが、Coherenceを実行するために必ず設定しなければならないわけではありません。

- JAVA_HOME - この変数はCOHERENCE_HOME/binディレクトリに含まれるスクリプトを実行するときに使用されます。この変数の値はJavaインストール・ディレクトリへのフル・パスです。JAVA_HOMEが設定されていない場合は、コンピュータのデフォルトのJavaインストール・ディレクトリが使用されます。この変数を設定すると、スクリプトで特定のJavaバージョンが使用されるようにすることができます。

- COHERENCE_HOME - この変数は、通常は便宜上設定されるものです。この変数の値はORACLE_HOME/coherenceディレクトリへのフル・パスです。

2.5 Coherenceの最初の実行

COHERENCE_HOME/binディレクトリには、開発およびテストの際に使用される、設計用に提供されたスクリプトが含まれています。cache-serverスクリプトはデフォルト構成を使用してキャッシュ・サーバーを起動します。coherenceスクリプトは、デフォルト構成を使用してキャッシュ・ファクトリ・インスタンスを起動します。キャッシュ・ファクトリ・インスタンスには、特にキャッシュの作成と操作に使用されるコマンド行ツールが含まれています。

この例では、基本的なクラスタを作成した後、クラスタにホストされるキャッシュをコマンド行ツールを使用して作成および操作します。

2.5.1 基本的なクラスタの作成

この手順では、キャッシュ・サーバーと2つのキャッシュ・ファクトリ・インスタンスという3つの独立したJavaプロセスで構成される基本的なクラスタを作成します。簡素化を図るため、この2つのプロセスは単一のマシン上に置かれます。この3つのプロセスは1つのコンピュータ上に共存します。キャッシュ・サーバーは、デフォルトで、バックアップ・データを格納するように構成されます。2つのキャッシュ・ファクトリ・インスタンスは、デフォルトで、バックアップ・データを格納しないように構成されます。各プロセスが起動されるたびに、それら3つのプロセスが自動的に結合され、クラスタ・メンバー(クラスタ・ノードとも呼ばれる)となります。

この例では、これらのクラスタ・メンバーがネットワーク上で実行されている可能性のある既存のCoherenceクラスタに参加しないようにするために、Coherenceの初期状態のデフォルト構成を多少修正してプライベートなクラスタを作成します。

注意:
Coherenceは、デフォルトではマルチキャストを使用してクラスタ・メンバーを検出します。ネットワークでマルチキャストを使用できない場合は、ユニキャストを使用するようにCoherenceを構成できます。詳細は、「Well Knownアドレスの使用」を参照してください。

基本的なクラスタを作成するには:

1. テキスト・エディタを使用してCOHERENCE_HOME/bin/cache-serverスクリプトを開きます。

2. java_opts変数を修正します。次のように、システム・プロパティtangosol.coherence.clusterおよびtangosol.coherence.clusterportを含めてください。

set java_opts="-Xms%memory% -Xmx%memory% -Dtangosol.coherence.cluster=cluster_name -Dtangosol.coherence.clusterport=port"

cluster_nameおよびportを、クラスタ内で一意の値に置き換えます。たとえば、クラスタ名に自分の名前を使用し、ポート番号に電話番号の最後の4桁を使用します。

3. cache-serverスクリプトを保存して閉じます。

4. COHERENCE_HOME/bin/coherenceスクリプトに対してステップ1から3を繰り返します。

5. cache-serverスクリプトを実行します。キャッシュ・サーバーが起動し、このクラスタ・メンバーに関する情報が出力されます。

6. coherenceスクリプトの2つのインスタンスを実行します。インスタンスが起動するたびに、それぞれのクラスタ・メンバーに関する情報が出力されます。インスタンスはそれぞれ、コマンド行ツールのコマンド・プロンプトを返します。

2.5.2 キャッシュの作成

この手順では、キャッシュが作成され、基本クラスタ上でホストされます。最初のキャッシュ・ファクトリ・インスタンスのコマンド行ツールを使用して、単純な文字列がキャッシュに入力されます。次に、2番目のキャッシュ・ファクトリ・インスタンスのコマンド行ツールを使用して、キャッシュから文字列が読み出されます。サンプルは非常に単純であり、あまり実用的ではありませんが、Coherenceキャッシュの出荷時の特性を端的に示しています。さらに、これらの手順は、通常はCoherence APIを使用して直接実行されます。

キャッシュを作成するには:

1. いずれかのキャッシュ・ファクトリ・インスタンスのコマンド・プロンプトで、cacheコマンドを使用してTestという名前のキャッシュを作成します。

cache Test

2. コマンド・プロンプトでputコマンドを使用してキーと値の組合せを入力することにより(空白で区切る)、単純な文字列を新しいキャッシュに配置します。

put key1 Hello

コマンドによってnullが返され、表示されます。putコマンドは、所定のキーに対して常に前の値を返します。null値が返されたのは、これがそのキーに最初に入力された値だったためです。

3. もう1つのキャッシュ・ファクトリ・インスタンスに切り替えて、コマンド・プロンプトでcacheコマンドを使用してTestという名前のキャッシュを作成します。

cache Test

4. このコマンド・プロンプトで、getコマンドを使用してキャッシュ内の文字列を読み出して、次のキー名を入力します。

get key1

コマンドによってhelloが返され、表示されます。キャッシュ・ファクトリ・プロセスが両方とも同一クラスタに属しており、Testキャッシュがすべてのクラスタ・メンバーに認識されているため、どちらのプロセスを使用してもキャッシュ・エントリの追加または削除が可能です。また、キャッシュ・サーバーにキャッシュ・データのバックアップが格納されているため、いずれの(または両方の)キャッシュ・ファクトリ・プロセスがシャットダウンされてもキャッシュ・データは保持されます。

2.6 Mavenとの統合

Mavenは、プロジェクトの依存性、サード・パーティの依存性およびビルドのライフサイクル定義の構成を可能にするビルドおよび依存性システムです。ソフトウェアのプロジェクトでは、ビルド・プロセスを容易化および標準化するためにMavenがよく使用されます。Mavenの詳細は、http://maven.apache.org/を参照してください。

Oracle Middlewareには、Oracleホーム・ディレクトリをMavenリポジトリと同期化し、Mavenの使用と命名規則を標準化するプラグインが用意されています。このプラグインを使用すると、CoherenceアーティファクトをMavenリポジトリにアップロードできるようになり、それによってアーティファクトが開発プロジェクトでどのように消費されているかが容易化されます。Mavenの設定および同期化プラグインの使用の詳細は、『Continuous Integrationを使用したアプリケーションの開発』を参照してください。

また、Mavenの統合には、Coherenceグリッド・アーカイブ(GAR)用のアーキタイプおよびパッケージ化プラグインが含まれます。Coherence GARは、CoherenceアプリケーションをWLSドメイン内にデプロイする際に通常使用されるモジュール・タイプです。Mavenアーキタイプ・プラグインはGAR構造を生成し、サンプルの構成ファイルを提供します。パッケージ化プラグインは、プロジェクトの内容および依存性に基づいてGARを生成し、依存性、ソースおよび構成ファイルが正しくGARにコピーされるようにします。

Coherence用のMavenプラグインおよび構成ファイルは、COHERENCE_HOME/pluginsディレクトリにあります。Maven GARプラグインおよびアーキタイプは、同期化プラグインの一部としてエンタープライズ・リポジトリにインストールされます。プラグインを使用してCoherenceをビルド・プロセスに組み込む手順については、『Continuous Integrationを使用したアプリケーションの開発』を参照してください。

2.7 Coherenceのアンインストール

Coherenceをアンインストールするには、Oracle Fusion Middleware Deinstallerを使用します。アンインストーラでは、アンインストールするCoherenceのORACLE_HOMEディレクトリのコンポーネントを選択することができ、CoherenceのORACLE_HOMEディレクトリを完全に削除する場合にも使用できます。

アンインストール・ウィザードを使用してCoherenceをアンインストールするには:

1. UNIXベースのプラットフォームの場合はCoherenceのORACLE_HOME/oui/bin/deinstall.shスクリプトを使用して、Windowsの場合はCoherenceのORACLE_HOME\oui\bin\deinstall.cmdスクリプトを使用して、アンインストーラを起動します。Windowsの場合は、スクリプトへのショートカットが使用可能で、これはスタート・メニューのOracleプログラム・グループの中にあります。Oracle Fusion Middleware Deinstallerが起動し、「ようこそ」画面が表示されます。

2. 「次へ」をクリックします。「アンインストール・サマリー」画面が表示され、アンインストールされる機能の一覧が表示されます。

3. 「アンインストール」をクリックします。「アンインストールの進行状況」画面が表示され、成功および失敗したタスクがすべて表示されます。

4. 「次へ」をクリックします。「アンインストール完了」画面が表示され、アンインストールのサマリーが表示されます。

5. 「終了」をクリックし、Oracle Fusion Middleware Deinstallerを閉じます。

注意:
ORACLE_HOMEディレクトリ内の追加ファイルは手動で削除する必要があります。Windowsの場合は、スタート・メニューにあるOracleプログラム・グループも手動で削除する必要があります。

3 構成の理解

この章ではCoherenceで提供されるデフォルトの構成ファイルのそれぞれについて説明し、それらのファイルをアプリケーションやソリューションに応じてオーバーライドしてCoherenceの独自の構成ファイルを作成する手順について詳述します。

この章には次の項が含まれます:

- デフォルトの構成ファイルの概要

- オペレーション構成ファイルの指定

- キャッシュ構成ファイルの指定

- POF構成ファイルの指定

- 管理構成ファイルの指定

- スキーマ検証の無効化

- XMLオーバーライド機能の理解

- システム・プロパティを使用した構成の変更

3.1 デフォルトの構成ファイルの概要

Coherenceでは、デフォルトのXML構成ファイル・セットがCOHERENCE_HOME\lib\coherence.jarライブラリに用意されています。これらのファイルおよび関連するスキーマについては、Coherenceのライブラリをディレクトリに解凍すれば簡単に確認できます。

構成ファイルにはデフォルト値が設定されており、Coherenceを最小の変更ですぐに使用できます。これらのファイルは実例を示すことのみを目的としたものであり、再利用したり、特定のアプリケーションやソリューションで必要とされる変更を加えたりできます。ただし、構成ファイルを別に作成して、デフォルトの構成ファイルをオーバーライドすることをお薦めします。

デフォルトの構成ファイルの内容は、次のとおりです。

- tangosol-coherence.xml - このファイルにはオペレーション設定とランタイム設定が含まれており、クラスタ、通信、およびデータ管理の各サービスの作成と構成に使用されます。このファイルは一般にオペレーション・デプロイメント・ディスクリプタと呼ばれます。このファイルのスキーマは、coherence-operational-config.xsdファイルです。オペレーション・デプロイメント・ディスクリプタの要素の完全なリファレンスは、付録A「オペレーション構成の要素」を参照してください。

- tangosol-coherence-override-dev.xml - Coherenceが開発者モードで起動されると、このファイルによってtangosol-coherence.xmlファイルのオペレーション設定がオーバーライドされます。Coherenceはデフォルトで開発者モードで起動され、このファイルの設定が使用されます。このファイルの設定は開発環境に適しています。このオーバーライド・ファイルのスキーマ・ファイルとオペレーション・デプロイメント・ディスクリプタのスキーマは同一です。

- tangosol-coherence-override-eval.xml - Coherenceが評価モードで起動されると、このファイルによってtangosol-coherence.xmlファイルのオペレーション設定がオーバーライドされます。このファイルの設定はCoherenceの評価に適しています。このオーバーライド・ファイルのスキーマ・ファイルとオペレーション・デプロイメント・ディスクリプタのスキーマは同一です。

- tangosol-coherence-override-prod.xml - Coherenceが本番モードで起動されると、このファイルによってtangosol-coherence.xmlファイルのオペレーション設定がオーバーライドされます。このファイルの設定は本番環境に適しています。このオーバーライド・ファイルのスキーマ・ファイルとオペレーション・デプロイメント・ディスクリプタのスキーマは同一です。

- coherence-cache-config.xml - このファイルを使用して、クラスタ内で使用できる様々な種類のキャッシュを指定します。このファイルは一般にキャッシュ構成デプロイメント・ディスクリプタと呼ばれます。このファイルのスキーマは、coherence-cache-config.xsdファイルです。このファイルの要素の完全なリファレンスは、付録B「キャッシュ構成の要素」を参照してください。

- coherence-pof-config.xml - このファイルは、POF (Portable Object Format)を使用してオブジェクトをシリアライズするときにカスタムのデータ型を指定するために使用します。このファイルは一般にPOF構成デプロイメント・ディスクリプタと呼ばれます。このファイルのスキーマは、coherence-pof-config.xsdファイルです。このファイルの要素の完全なリファレンスは、付録C「POFユーザー定義型の構成要素」を参照してください。

- 管理構成ファイル - Coherence管理レポートを構成するために使用される一連のファイルです。これらのファイルは、coherence.jarの中の/reportsディレクトリ内にあります。これらのファイルには、任意の数のレポート定義ファイルを参照するレポート・グループ構成ファイル(デフォルトではreport-group.xml)が含まれます。各レポート定義ファイルにより、特定メトリックのセットに基づいて管理情報を表示するレポート・ファイルが作成されます。これらのファイルのスキーマは、それぞれcoherence-report-config.xsdファイルおよびcoherence-report-group-config.xsdファイルです。これらの構成ファイルの要素のリファレンスおよびレポートの使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

3.2 オペレーション構成ファイルの指定

オペレーション・デプロイメント・ディスクリプタtangosol-coherence.xmlにはオペレーション設定とランタイム設定が用意されており、クラスタ、通信、およびデータ管理の各サービスの作成と構成に使用されます。Coherenceは、実行時に、クラスパスで最初に見つかったtangosol-coherence.xmlファイルを使用します。

Coherenceで提供されるデフォルトのオペレーション・デプロイメント・ディスクリプタはcoherence.jarライブラリのルートにあります。このファイルは必要に応じて変更できます。ただし、オペレーション・ランタイム構成時には、このファイルをオーバーライドすることをお薦めします。XMLのオーバーライド機能の詳細は、「XMLオーバーライド機能の理解」を参照してください。

この項には次のトピックが含まれます:

- デフォルトのオペレーション・オーバーライド・ファイルの使用

- オペレーション・オーバーライド・ファイルの指定

- 特定のオペレーション要素に対するオーバーライド・ファイルの定義

- ロードされたオペレーション・オーバーライド・ファイルの表示

オペレーション・ランタイムの構成手順の詳細は、第I部「Coherenceクラスタの使用」を参照してください。

3.2.1 デフォルトのオペレーション・オーバーライド・ファイルの使用

デフォルトのtangosol-coherence.xmlファイルの要素は、実行時のクラスパスにtangosol-coherence-override.xmlという名前のオペレーション・オーバーライド・ファイルを置くことによりオーバーライドされます。オーバーライド・ファイルの構造は、すべての要素がオプションであることを除き、オペレーション・デプロイメント・ディスクリプタと同一です。オーバーライド・ファイルには変更される要素のみが含まれます。欠落している要素は、tangosol-coherence.xmlファイルからロードされます。

一般的に、オペレーション・オーバーライド・ファイルは、オペレーション・ランタイムを構成するための最も包括的な方法を提供し、開発環境と本番環境の両方で使用されます。

デフォルトのオペレーション・オーバーライド・ファイルを使用するには:

1. tangosol-coherence-override.xmlという名前のファイルを作成します。

2. ファイルを編集し、オーバーライドするオペレーション要素を追加します。
次の例では、クラスタ名を構成し、デフォルトのクラスタ名をオーバーライドします。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name system-property="tangosol.coherence.cluster">
MyCluster</cluster-name>
</member-identity>
</cluster-config>
</coherence>

3. ファイルを保存して閉じます。

4. オペレーション・オーバーライド・ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるオーバーライド・ファイルを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

ヒント:
開発中にcache-serverスクリプトおよびcoherenceスクリプトを使用するときには、各スクリプトでJava -cp引数を使用してtangosol-coherence-override.xmlファイルの場所をクラスパスに追加してください。

3.2.2 オペレーション・オーバーライド・ファイルの指定

tangosol.coherence.overrideシステム・プロパティでは、デフォルトのtangosol-coherence-override.xmlファイルのかわりに使用されるオペレーション・オーバーライド・ファイルを適宜指定します。指定するファイルの構造は、すべての要素がオプションであることを除き、オペレーション・デプロイメント・ディスクリプタと同一です。欠落している要素は、tangosol-coherence.xmlファイルからロードされます。

tangosol.coherence.overrideシステム・プロパティを使用すると、異なるオペレーション構成間での切り替えを簡単に行えるため、開発およびテストの際に便利です。

オペレーション・オーバーライド・ファイルを指定するには:

1. テキスト・ファイルを作成します。

2. ファイルを編集し、オーバーライドするオペレーション要素を追加します。
次の例では、マルチキャスト・ポート番号を構成します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<port system-property="tangosol.coherence.clusterport">3059</port>
</multicast-listener>
</cluster-config>
</coherence>

3. ファイルをXMLファイルとして保存して閉じます。

4. オペレーション・オーバーライド・ファイルの名前をtangosol.coherence.overrideシステム・プロパティの値として指定します。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。このシステム・プロパティでオペレーション・オーバーライド・ファイルの場所を指定するときには、URLを使用することもできます。
次の例では、キャッシュ・サーバーを起動して、COHERENCE_HOMEにあるオペレーション・オーバーライド・ファイルcluster.xmlを使用します。

java -Dtangosol.coherence.override=cluster.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.2.3 特定のオペレーション要素に対するオーバーライド・ファイルの定義

オーバーライド・ファイルを作成すると、特定のオペレーション要素の内容をオーバーライドできます。オーバーライド・ファイルは、ルート要素とオーバーライドされる要素が一致している必要があることを除き、オペレーション・デプロイメント・ディスクリプタと同一構造です。特定のオペレーション要素のためのオーバーライド・ファイルの定義の詳細は、「カスタムのオーバーライド・ファイルの定義」を参照してください。

一般的に、特定のオペレーション要素のためのオーバーライド・ファイルを使用すると、オペレーション・デプロイメント・ディスクリプタの修正可能な箇所を詳細に制御して、デプロイメント・シナリオごとに異なる構成を作成できます。

特定のオペレーション要素のためのオーバーライド・ファイルを定義するには:

1. 「デフォルトのオペレーション・オーバーライド・ファイルの使用」の説明に従って、tangosol-coherence-override.xmlファイルを作成します。

2. オーバーライドする要素にxml-override属性を追加します。xml-override属性の値はオーバーライド・ファイルの名前です。
次の例では、<cluster-config>要素をオーバーライドするために使用するオーバーライド・ファイルcluster-config.xmlを定義します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config xml-override="/cluster-config.xml">
...
</cluster-config>
</coherence>

3. ファイルを保存して閉じます。

4. テキスト・ファイルを作成します。

5. ファイルを編集して、オーバーライドする要素に対応するXMLノードを追加します。XMLルート要素はオーバーライドする要素と一致させる必要があります。
ステップ2の例を使用して、<cluster-config>要素をオーバーライドするための次のノードを作成し、マルチキャスト・ジョイント・タイムアウトを指定します。

<?xml version='1.0'?>

<cluster-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<multicast-listener>
<join-timeout-milliseconds>4000</join-timeout-milliseconds>
</multicast-listener>
</cluster-config>

6. xml-override属性で使用されている名前をファイルに付けてXMLファイルとして保存します。

7. 両方のオーバーライド・ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるオーバーライド・ファイルを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.2.4 ロードされたオペレーション・オーバーライド・ファイルの表示

Coherenceノードの出力に、起動時にロードされるオペレーション構成ファイルの場所と名前が示されます。オペレーション構成メッセージは、プロセスを起動するときに発行される最初のメッセージです。この出力は、複数のオーバーライド・ファイルを使用するときに特に有用ですが、Coherenceのアプリケーションやソリューションを開発およびテストするときにも役立ちます。

次の出力例は、発行される典型的なメッセージを示しています。

Loaded operational configuration from resource "jar:file:/D:/coherence/lib/
coherence.jar!/tangosol-coherence.xml"
Loaded operational overrides from resource "jar:file:/D:/coherence/lib/
coherence.jar!/tangosol-coherence-override-dev.xml"
Loaded operational overrides from resource "file:/D:/coherence/
tangosol-coherence-override.xml"
Optional configuration override "/cluster-config.xml" is not specified
Optional configuration override "/custom-mbeans.xml" is not specified

前述の出力は、coherence.jarに含まれるオペレーション・デプロイメント・ディスクリプタがロードされたこと、およびこのファイルの設定が2つのロードされたオーバーライド・ファイルtangosol-coherence-override-dev.xmlおよびtangosol-coherence-override.xmlによってオーバーライドされることを示しています。また、2つのオーバーライド・ファイルは、特定のオペレーション要素のために定義されましたが、実行時には見つかることもロードされることもありませんでした。

3.3 キャッシュ構成ファイルの指定

キャッシュ構成デプロイメント・ディスクリプタ・ファイルcoherence-cache-config.xmlは、クラスタ内で使用できる様々な種類のキャッシュを指定するために使用されます。Coherenceの実行時には、クラスパスで最初に見つかったcoherence-cache-config.xmlファイルが使用されます。Coherenceでは、サンプルのcoherence-cache-config.xmlファイルが提供されており、coherence.jarライブラリのルートに配置されています。このサンプル・ファイルは、デモ用のものです。サンプル・ファイルは必要に応じて変更または再利用できますが、サンプル・ファイルを使用するかわりにカスタムのキャッシュ構成デプロイメント・ディスクリプタを作成することをお薦めします。

注意:

- クラスタ内のすべてのキャッシュ・サーバー・ノードで同一のキャッシュ構成ディスクリプタを使用することをお薦めします(必須ではありません)。

- Coherenceでは、キャッシュ構成デプロイメント・ディスクリプタを起動させる必要があります。実行時にキャッシュ構成デプロイメント・ディスクリプタが起動していないと、構成リソースのロードに失敗したことを伝えるエラー・メッセージが表示され、見つからなかったファイルの名前と場所も示されます。

この項には次のトピックが含まれます:

- デフォルトのキャッシュ構成ファイルの使用

- デフォルトのキャッシュ構成ファイルのオーバーライド

- キャッシュ構成ファイルのシステム・プロパティの使用

- ロードされたキャッシュ構成ファイルの表示

キャッシュの構成手順の詳細は、第I部「キャッシュの使用」を参照してください。

3.3.1デフォルトのキャッシュ構成ファイルの使用

Coherenceは、初期状態では、クラスパスで最初に見つかったcoherence-cache-config.xmlファイルを使用するように構成されています。coherence-cache-config.xmlファイルを使用するには、このファイルが、クラスパスの、coherence.jarライブラリよりも上位にある必要があります。そうでない場合は、coherence.jarにあるサンプルのcoherence-cache-config.xmlファイルが使用されます。

デフォルトのキャッシュ構成ファイルを使用するには:

1. coherence.jarにあるサンプルのcoherence-cache-config.xmlファイルのコピーを作成して、それを別の場所に保存します。サンプル・ファイルのキャッシュ定義はデモ用です。このファイルを基にしてソリューション固有のキャッシュ構成を作成するようにしてください。

2. coherence-cache-config.xmlファイルの保存場所が、実行時のクラスパスの、coherence.jarファイルよりも上位にあることを確認します。
次の例では、COHERENCE_HOMEにあるキャッシュ構成ファイルcoherence-cache-config.xmlを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.3.2 デフォルトのキャッシュ構成ファイルのオーバーライド

キャッシュ構成デプロイメント・ディスクリプタのデフォルトの名前と場所は、<configurable-cache-factory-config>要素のオペレーション・デプロイメント・ディスクリプタに指定されています。この要素をオーバーライドして、デフォルトのキャッシュ構成ファイルとは異なる名前と場所が使用されるように指定できます。

デフォルトのキャッシュ構成ファイルをオーバーライドするには:

1. coherence.jarにあるデフォルトのキャッシュ構成ファイルcoherence-cache-config.xmlのコピーを作成して別名で保存します。

2. 「デフォルトのオペレーション・オーバーライド・ファイルの使用」の説明に従って、tangosol-coherence-override.xmlファイルを作成します。

3. オペレーション・オーバーライド・ファイルを編集して、ステップ1で作成されたキャッシュ構成ファイルの名前を指定する<configurable-cache-factory-config>ノードを入力します。キャッシュ構成ファイルがクラスパスにない場合は、ファイルのフルパス(または相対パス)も入力します。この要素では、キャッシュ構成ファイルの場所を指定するときに、URLを使用することもできます。
次の例では、キャッシュ構成デプロイメント・ディスクリプタMyConfig.xmlを指定します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<configurable-cache-factory-config>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value system-property="tangosol.coherence.cacheconfig">
MyConfig.xml</param-value>
</init-param>
</init-params>
</configurable-cache-factory-config>
</coherence>

4. ファイルを保存して閉じます。

5. オペレーション・オーバーライド・ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるオペレーション・オーバーライド・ファイルとカスタムのキャッシュ構成ファイルを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.3.3 キャッシュ構成ファイルのシステム・プロパティの使用

tangosol.coherence.cacheconfigシステム・プロパティを使用して、構成されたデフォルトのキャッシュ構成デプロイメント・ディスクリプタのかわりに使用するカスタムのキャッシュ構成デプロイメント・ディスクリプタを指定します。システム・プロパティを使用すると、異なる構成間での切替えを簡単に行えるため、開発およびテストの際に便利です。

カスタムのキャッシュ構成ファイルを指定するには、tangosol.coherence.cacheconfigシステム・プロパティの値としてファイルの名前を入力します。これは、通常、Coherenceノードの起動時にJavaオプション-Dを使用して指定されます。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。このシステム・プロパティでキャッシュ構成ファイルの場所を指定するときには、URLを使用することもできます。

次の例では、キャッシュ・サーバーを起動し、COHERENCE_HOMEにあるキャッシュ構成デプロイメント・ディスクリプタMyConfig.xmlを指定します。

java -Dtangosol.coherence.cacheconfig=MyConfig.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.3.4 ロードされたキャッシュ構成ファイルの表示

Coherenceノードの出力に、起動時にロードされるキャッシュ構成デプロイメント・ディスクリプタの場所と名前が示されます。構成メッセージはCoherenceの著作権情報の後に最初に表示されるメッセージです。Coherenceのアプリケーションやソリューションを開発およびテストするときには、この出力が特に役立ちます。

次の出力例は、キャッシュ構成デプロイメント・ディスクリプタMyconfig.xmlがロードされたことを示すキャッシュ構成メッセージを示しています。

Loaded cache configuration from resource "file:/D:/coherence/Myconfig.xml"

3.4 POF構成ファイルの指定

POF構成デプロイメント・ディスクリプタ・ファイルpof-config.xmlは、POF (Portable Object Format)を使用したシリアライズでのカスタム・ユーザー型の指定に使用されます。Coherenceは、実行時に、クラスパスで最初に見つかったpof-config.xmlファイルを使用します。

注意:

- クラスタ内のすべてのノードで同一のPOF構成デプロイメント・ディスクリプタを使用することをお薦めします。

- POFシリアライザがキャッシュ・スキームの一部として構成されている場合や、すべてのキャッシュ・スキームに対してグローバルに構成されている場合にかぎり、POF構成デプロイメント・ディスクリプタがロードされます。デフォルトのcoherence-cache-config.xmlには、POFシリアライザを定義するサンプルのキャッシュ・スキームが用意されていますが、デフォルトでコメント・アウトされています。

この項には次のトピックが含まれます:

- デフォルトのPOF構成ファイルのオーバーライド

- POF構成ファイルのシステム・プロパティの使用

- 複数のPOF構成ファイルの組合せ

- ロードされたPOF構成ファイルの表示

POFユーザー型の構成手順の詳細は、第20章「Portable Object Formatの使用」を参照してください。

3.4.1 デフォルトのPOF構成ファイルのオーバーライド

デフォルトのpof-config.xml POF構成ファイルは、coherence.jarライブラリのルートにあります。Coherenceは、初期状態では、クラスパスで最初に見つかったpof-config.xmlファイルを使用するように構成されています。別のpof-config.xmlファイルを使用するには、このファイルが、クラスパスの、coherence.jarライブラリよりも上位にある必要があります。そうでない場合は、coherence.jarライブラリにあるデフォルトのpof-config.xmlファイルが使用されます。

POF構成ファイルは、個別のアプリケーションにあわせてカスタマイズする必要があります。デフォルトのPOF構成ファイルは、coherence-pof-config.xmlファイルを参照してください。これには、Coherence固有のユーザー型が定義されており、POF構成ファイルを作成するときには常に必要となります。

デフォルトのPOF構成ファイルをオーバーライドするには:

1. XMLファイルを作成します。

2. ファイルを編集して、デフォルトのCoherence POFユーザー型を含む<pof-config>ノードを作成します。

<?xml version="1.0"?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
</user-type-list>
</pof-config>

3. pof-config.xmlという名前でファイルを保存して閉じます。

4. POF構成ファイルが実行時のクラスパスにあることを確認します。
次の例では、キャッシュ・サーバーを起動し、COHERENCE_HOMEにあるPOF構成ファイルを使用します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.4.2 POF構成ファイルのシステム・プロパティの使用

tangosol.pof.configシステム・プロパティを使用して、デフォルトのpof-config.xmlファイルのかわりに使用するカスタムのPOF構成デプロイメント・ディスクリプタを指定します。システム・プロパティを使用すると、異なる構成間での切替えを簡単に行えるため、開発およびテストの際に便利です。

カスタムのPOF構成ファイルを指定するには:

1. XMLファイルを作成します。

2. ファイルを編集して、デフォルトのCoherence POFユーザー型を含む<pof-config>ノードを作成します。

<?xml version="1.0"?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
</user-type-list>
</pof-config>

3. ファイルを保存して閉じます。

4. そのファイルの名前をtangosol.pof.configシステム・プロパティの値として指定します。これは、通常、Coherenceノードの起動時にJavaオプション-Dを使用して指定されます。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。このシステム・プロパティでPOF構成ファイルの場所を指定するときには、URLを使用することもできます。
次の例では、キャッシュ・サーバーを起動し、COHERENCE_HOMEにあるPOF構成デプロイメント・ディスクリプタMyPOF.xmlを指定します。

java -Dtangosol.pof.config=MyPOF.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.4.3 複数のPOF構成ファイルの組合せ

<include>要素は、POF構成デプロイメント・ディスクリプタ内で、定義済のユーザー型を別のPOF構成デプロイメント・ディスクリプタ内に含めるために使用されます。これにより、ユーザー型をわかりやすく編成できるようになります(アプリケーション別や開発グループ別など)。

注意:
複数のPOF構成ファイルを組み合せる場合は、定義済の各ユーザー型が一意の<type-id>を持つ必要があります。型IDが含まれていない場合には、コンポジット構成ファイル内でのそのユーザー型の出現順序に基づいて型IDが指定されます。

複数のPOF構成ファイルを組み合せるには:

1. 起動時にロードされる既存のPOF構成ファイルを開きます。

2. POF構成ファイルの名前を値として持つ<include>要素を追加します。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。ファイルの場所としてURLを使用することもできます。
次の例では、デフォルトのCoherence POF構成ファイルと2つのPOF構成ファイルを組み合せて使用します。

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
<include>hr-pof-config.xml</include>
<include>crm-pof-config.xml</include>
</user-type-list>
</pof-config>

3. ファイルを保存して閉じます。

4. 必要があれば、POF構成ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるPOF構成ファイルを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.4.4 ロードされたPOF構成ファイルの表示

Coherenceノードの出力に、起動時にロードされるPOF構成デプロイメント・ディスクリプタの場所と名前が示されます。構成メッセージは、Coherenceの著作権情報の後に表示されるメッセージの一部であり、POFを使用するように構成されたキャッシュ・サービスと関連付けられています。Coherenceのアプリケーションやソリューションを開発およびテストするときには、この出力が特に役立ちます。

次の出力例は、4つのPOF構成デプロイメント・ディスクリプタがロードされたことを示すPOF構成メッセージです。

Loading POF configuration from resource "file:/D:/coherence/my-pof-config.xml"
Loading POF configuration from resource "file:/D:/coherence/coherence-pof-config.xml"
Loading POF configuration from resource "file:/D:/coherence/hr-pof-config.xml"
Loading POF configuration from resource "file:/D:/coherence/crm-pof-config.xml"

3.5 管理構成ファイルの指定

管理構成には様々な構成ファイルが使用されます。これらには、次のものが含まれます。

- レポート・グループ構成ファイル - レポート・グループ構成ファイルは、レポート定義ファイルの名前と場所、およびレポートが書き込まれる出力ディレクトリのリストを示すために使用されます。このファイルの名前と場所は、オペレーション・デプロイメント・ディスクリプタに定義されます。デフォルトでは、report-group.xmlファイルが使用され、このファイルはcoherence.jarの/reportsディレクトリに存在します。必要に応じて、追加のレポート・グループ構成ファイルを指定して、カスタム・レポート・グループ・ファイルを作成することもできます。

- レポート構成ファイル - レポート構成ファイルでは、レポートを定義し、特定メトリックのセットに基づいて管理情報を表示するレポート・ファイルが作成されます。レポート構成ファイルは、実行時に使用されるレポート・グループ構成ファイルで参照される必要があります。デフォルトのレポート構成ファイルはcoherence.jarの/reportsディレクトリにあり、デフォルトのレポート・グループ構成ファイルによって参照されます。カスタムのレポート構成ファイルも必要に応じて作成できます。

- custom-mbeans.xml - デフォルトのMBean構成オーバーライド・ファイルです。このファイルを使用してCoherenceのJMX管理およびモニタリング・フレームワーク内でカスタムMBean(アプリケーション・レベルのMBean)を定義します。これにより、クラスタ内のどのノードからでも任意のアプリケーション・レベルのMBeanを管理およびモニターできます。カスタムMBeanはオペレーション・オーバーライド・ファイル内に定義できます。ただし、一般的にはカスタムMBeanではなくMBean構成オーバーライド・ファイルが使用されます。

この項には次のトピックが含まれます:

- カスタムのレポート・グループ構成ファイルの指定

- MBean構成ファイルの指定

- ロードされた管理構成ファイルの表示

Coherenceの管理方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

3.5.1 カスタムのレポート・グループ構成ファイルの指定

デフォルトのレポート・グループ構成ファイルの名前と場所は、<management-config>ノード内のオペレーション構成デプロイメント・ディスクリプタに指定されています。カスタムのレポート・グループ構成ファイルは、オペレーション・オーバーライド・ファイルまたはシステム・プロパティを使用して指定できます。

注意:
レポート・グループ構成ファイルは、JMX管理が有効な場合にかぎりロードされます。次の例では、MBeanサーバーをホストするノード上でJMX管理を有効にします。

3.5.1.1 デフォルトのレポート・グループ構成ファイルのオーバーライド

カスタムのレポート・グループ構成ファイルの名前と場所は、オペレーション・オーバーライド・ファイルを使用して指定できます。このメカニズムによって、レポート・グループ構成ファイルのデフォルトの名前と場所がオーバーライドされます。

デフォルトのレポート・グループ構成ファイルをオーバーライドするには:

1. XMLファイルを作成します。

2. 次のようにファイルを編集して<report-group>ノードを作成します。この例では、単一のレポートを構成します。

<?xml version='1.0'?>

<report-group xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-report-group-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-report-group-config coherence-report-group-config.xsd">
<frequency>1m</frequency>
<output-directory>./</output-directory>
<report-list>
<report-config>
<location>reports/report-node.xml</location>
</report-config>
</report-list>
</report-group>

3. ファイルを保存して閉じます。

4. 「デフォルトのオペレーション・オーバーライド・ファイルの使用」の説明に従って、tangosol-coherence-override.xmlファイルを作成します。

5. ファイルを編集して、レポート・グループ構成ファイルの名前を指定する<management-config>ノードを指定します。レポート・グループ構成ファイルがクラスパスにない場合は、ファイルのフルパス(または相対パス)も入力します。この要素では、レポート・グループ構成ファイルの場所を指定するときに、URLを使用することもできます。
次の例では、JMX管理を有効にし、レポート・グループ構成デプロイメント・ディスクリプタmy-group.xmlを指定します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<management-config>
<managed-nodes system-property="tangosol.coherence.management">
all</managed-nodes>
<reporter>
<configuration system-property="tangosol.coherence.management.report.
configuration">my-group.xml</configuration>
</reporter>
</management-config>
</coherence>

6. ファイルを保存して閉じます。

7. オペレーション・オーバーライド・ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるオペレーション・オーバーライド・ファイルとレポート・グループ構成ファイルを使用してキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.5.1.2 レポート・グループ構成ファイルのシステム・プロパティの使用

tangosol.coherence.management.report.configurationシステム・プロパティを使用して、デフォルトのreport-group.xmlファイルのかわりに使用するカスタムのレポート・グループ構成ファイルを指定します。システム・プロパティを使用すると、異なる構成間での切替えを簡単に行えるため、開発およびテストの際に便利です。

カスタムのレポート・グループ構成ファイルを指定するには、システム・プロパティtangosol.coherence.management.report.configurationの値としてファイルの名前を入力します。これは、通常、Coherenceノードの起動時にJavaオプション-Dを使用して指定されます。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。このシステム・プロパティでレポート・グループ構成ファイルの場所を指定するときには、URLを使用することもできます。

次の例では、キャッシュ・サーバーを起動し、JMX管理を有効にして、COHERENCE_HOMEにあるレポート・グループ構成ファイルmy-group.xmlを指定します。

java -Dtangosol.coherence.management=all -Dtangosol.coherence.management.report.configuration=my-group.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.5.2 MBean構成ファイルの指定

オペレーション・デプロイメント・ディスクリプタtangosol-coherence.xmlは、オペレーション・オーバーライド・ファイルcustom-mbeans.xmlを定義するため(特に、カスタムのMBeansを定義するため)に使用されます。オーバーライド・ファイルの名前と場所は、MBean構成ファイルのシステム・プロパティを使用して指定することもできます。

3.5.2.1 デフォルトのMBean構成オーバーライド・ファイルの使用

カスタムMBeansは、オーバーライド・ファイルcustom-mbeans.xml内に定義されます。Coherenceは、実行時に、クラスパスで最初に見つかったcustom-mbeans.xmlファイルが使用されます。

デフォルトのMBean構成オーバーライド・ファイルを使用するには:

1. custom-mbeans.xmlという名前のファイルを作成します。

2. 次のようにファイルを編集して空の<mbeans>ノードを作成します。

<?xml version='1.0'?>

<mbeans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
</mbeans>

3. ファイルを保存して閉じます。

4. カスタムMBean構成オーバーライド・ファイルが実行時のクラスパスにあることを確認します。
次の例では、COHERENCE_HOMEにあるデフォルトのMBean構成オーバーライド・ファイルを使用するキャッシュ・サーバーを起動します。

java -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.5.2.2 MBean構成ファイルのシステム・プロパティの使用

tangosol.coherence.mbeansシステム・プロパティでは、デフォルトのオーバーライド・ファイルcustom-mbeans.xmlのかわりに使用されるMBean構成オーバーライド・ファイルを指定します。システム・プロパティを使用すると、異なるMBean構成間での切替えを簡単に行えるため、開発およびテストの際に便利です。

MBean構成オーバーライド・ファイルを指定するには、tangosol.coherence.mbeansシステム・プロパティの値としてファイルの名前を入力します。これは、通常、Coherenceノードの起動時にJavaオプション-Dを使用して指定されます。クラスパスにファイルがない場合は、ファイルのフルパス(または相対パス)と名前を入力します。このシステム・プロパティでMBean構成オーバーライド・ファイルの場所を指定するときには、URLを使用することもできます。

次の例では、キャッシュ・サーバーを起動し、COHERENCE_HOMEにあるMBean構成オーバーライド・ファイルmy-mbeans.xmlを指定します。

java -Dtangosol.coherence.mbeans=my-mbeans.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

3.5.3 ロードされた管理構成ファイルの表示

Coherenceノードの出力に、起動時にロードされるレポート・グループ構成ファイルおよびMBean構成ファイルの場所と名前が示されます。Coherenceのアプリケーションやソリューションを開発およびテストするときには、この出力が特に役立ちます。

レポート・グループ構成ファイル

レポート・グループ構成メッセージは、Coherenceの著作権情報の後に表示されるメッセージの一部です。

次の出力例は、my-group.xmlファイルがロードされたことを示すレポート・グループ構成メッセージを示しています。

Loaded Reporter configuration from "file:/D:/coherence/my-group.xml

MBean構成オーバーライド・ファイル

MBean構成メッセージは、他のオペレーション・オーバーライド・メッセージとともに表示されるものであり、プロセスの起動時に最初に表示されるメッセージの一部です。この出力は、オーバーライド・ファイルを使用するときには特に有用ですが、Coherenceのアプリケーションやソリューションを開発およびテストするときにも役立ちます。

次の出力例は、デフォルトのMBean構成オーバーライド・ファイルがロードされたことを示すオペレーション・オーバーライド・メッセージを示しています。

Loaded operational overrides from resource "file:/D:/coherence/custom-mbeans.xml"

3.6 スキーマ検証の無効化

Coherenceでは、スキーマ検証を使用して、構成ファイルが個々のスキーマ定義に準拠していることを確認します。スキーマ参照を含む構成ファイルは、構成ファイルがロードされると、スキーマに対して自動的に検証されます。検証エラーが発生すると即座に失敗となり、エラーの原因となる要素を示すエラー・メッセージが出力されます。ベスト・プラクティスとして、スキーマ検証は常に使用することをお薦めします。

スキーマ検証は、必要に応じて無効化できます。スキーマ検証を無効化するには、構成ファイルからxsi:schemaLocation属性を削除します。次の例では、スキーマ参照を含まず、ロード時に検証されないtangosol-coherence-override.xmlファイルを作成します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config">
...
</coherence>

注意:
スキーマ検証を無効にすると、XMLが不正な場合にCoherenceは失敗します。構文エラーは無視されるため、すぐに判明しない場合があります。

3.7 XMLオーバーライド機能の理解

XMLオーバーライド機能は、coherence.jarにあるデフォルト・オペレーション・デプロイメント・ディスクリプタtangosol-coherence.xmlを編集することなくオペレーション設定を変更可能な構成メカニズムです。Coherenceのオペレーション・ランタイムを構成するには、この方法をお薦めします。

XMLオーバーライド機能は、特定のオペレーションXML要素を持つXMLドキュメント(通称、オーバーライド・ファイル)を関連付けることによって有効になります。XML要素とそのいずれのサブ要素も、後から必要に応じてオーバーライド・ファイル内で修正されます。実行時に、Coherenceによりオーバーライド・ファイルがロードされ、その要素によってtangosol-coherence.xmlファイル内の要素が置換または追加されます。

オーバーライド・ファイルは実行時に存在している必要はありません。ただし、オーバーライド・ファイルが存在する場合は、そのファイルのルート要素とファイルによりオーバーライドされる要素が一致している必要があります。また、サブ要素はオプションです。サブ要素は、オーバーライド・ファイルに定義されていない場合、tangosol-coherence.xmlファイルからロードされます。通常、変更または追加されるサブ要素のみがオーバーライド・ファイルに追加されます。

この項には次のトピックが含まれます:

- 事前定義されたオーバーライド・ファイルの使用

- カスタムのオーバーライド・ファイルの定義

- 同じ要素用の複数のオーバーライド・ファイルの定義

3.7.1 事前定義されたオーバーライド・ファイルの使用

複数のオーバーライド・ファイルが事前定義されており、オペレーション・デプロイメント・ディスクリプタ内の要素をオーバーライドできます。これらのファイルは手動で作成され、クラスパスに保存されます。

- tangosol-coherence-override.xml - このオーバーライド・ファイルは<coherence>ルート要素用に定義され、オペレーション・デプロイメント・ディスクリプタ内の任意の要素をオーバーライドするために使用されます。このファイルのルート要素は<coherence>要素である必要があります。

- custom-mbeans.xml - このオーバーライド・ファイルは<mbeans>要素用に定義され、オペレーション・デプロイメント・ディスクリプタにカスタムのMBeanを追加するために使用されます。このファイルのルート要素は<mbeans>要素である必要があります。

- cache-factory-config.xml - このオーバーライド・ファイルは<configurable-cache-factory-config>要素に定義されており、構成キャッシュ・ファクトリをカスタマイズするために使用されます。このオーバーライド・ファイルは通常コンテナの統合をサポートするためにのみ使用されます。一般的に、<configurable-cache-factory-config>要素をオーバーライドすることはありません。

- cache-factory-builder-config.xml - このオーバーライド・ファイルは<cache-factory-builder-config>要素に対して定義されており、キャッシュ・ファクトリ・ビルダーをカスタマイズするために使用されます。このオーバーライド・ファイルは通常コンテナの統合をサポートするためにのみ使用されます。一般的に、<cache-factory-builder-config>要素をオーバーライドすることはありません。

次の例では、tangosol-coherence-override.xmlファイルを使用してデフォルトのクラスタ名をオーバーライドします。その他のオペレーション設定はすべてtangosol-coherence.xmlファイルからロードされます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name system-property="tangosol.coherence.cluster">MyCluster
</cluster-name>
</member-identity>
</cluster-config>
</coherence>

次の例では、tangosol-coherence-override.xmlファイルを使用して、このノード上の分散キャッシュ・サービスのローカル・ストレージを無効にします。複数出現する要素を区別するためにid属性が使用されます。id属性は、オーバーライドされる要素のid属性と一致している必要があります。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="4">
<param-name>local-storage</param-name>
<param-value system-property="tangosol.coherence.distributed.
localstorage">false</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

次の例では、custom-mbean.xmlファイルを使用して標準のMBean定義をMBeanのリストに追加します。

<mbeans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<mbean id="100">
<mbean-class>com.oracle.customMBeans.Query</mbean-class>
<mbean-name>type=Query</mbean-name>
<enabled>true</enabled>
</mbean>
</mbeans>

3.7.2 カスタムのオーバーライド・ファイルの定義

tangosol-coherence.xmlデプロイメント・ディスクリプタ内の要素はすべて、事前定義されたtangosol-coherence-override.xmlファイルを使用してオーバーライドできます。ただし、より詳細な構成の管理が必要な場合があります。たとえば、ソリューションでオペレーション・デプロイメント・ディスクリプタの特定の要素のみを変更できるようにして、全体を変更することはできないようにする必要がある場合があります。また別の例として、様々なユースケースに基づいた様々な構成が必要となるソリューションもあります。そうした状況に対応するには、カスタムのオーバーライド・ファイルを使用します。

xml-overrideおよびid属性の使用

オーバーライド・ファイルはxml-override属性とid属性(必要な場合)を使用して定義されます。これらの属性はいずれもオプションで指定されるものであり、オーバーライドされるオペレーション要素に追加されます。オーバーライド・ファイルの使用をサポートするオペレーション要素のリストは、「属性リファレンス」を参照してください。

xml-override属性の値は、ClassLoader.getResourceAsStream(String name)メソッドを使用してcoherence.jarライブラリに含まれるクラスにアクセス可能なドキュメントの名前です。一般的には、ファイルの名前には/という接頭辞が付いており、ファイルは実行時のクラスパスにあります。属性でオーバーライド・ファイルの場所を指定するときには、URLを使用することもできます。

たとえば、<cluster-config>要素をオーバーライドするために使用されるオーバーライド・ファイルcluster-config.xmlを定義するには、次のようにtangosol-coherence-override.xmlファイル内の<cluster-config>要素にxml-override属性を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config xml-override="/cluster-config.xml">
...
</cluster-config>
</coherence>

このオーバーライド・ファイルを使用するには、cluster-config.xmlという名のドキュメントを作成し、そのドキュメントとベース・ドキュメント(この場合はtangosol-coherence-override.xml)が実行時のクラスパス内のディレクトリにあることを確認します。この例の場合、次に示すように、オーバーライド・ファイルのルート要素は<cluster-config>である必要があります。

<?xml version='1.0'?>

<cluster-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<multicast-listener>
<join-timeout-milliseconds>4000</join-timeout-milliseconds>
</multicast-listener>
</cluster-config>

id属性は、複数回出現する要素を識別するために使用します。

たとえば、分散キャッシュ・サービスの<service>要素をオーバーライドするために使用されるカスタムのオーバーライド・ファイルdist-service-config.xmlを定義するには、次のようにidが3の<service>要素にxml-override属性を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3" xml-override="/dist-service-config.xml">
</service>
</services>
</cluster-config>
</coherence>

このオーバーライド・ファイルを使用するには、dist-service-config.xmlという名前のドキュメントを作成し、そのドキュメントが実行時のクラスパス内のディレクトリにあることを確認します。この例の場合、次に示すように、オーバーライド・ファイルのルート要素は<service>である必要があります。

<?xml version='1.0'?>

<service id="3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<init-params>
<init-param id="1">
<param-name>standard-lease-milliseconds</param-name>
<param-value>2</param-value>
</init-param>
</init-params>
</service>

注意:
オーバーライド・ドキュメント内の要素のidに一致する要素がベース・ドキュメントにないと、その要素はベース・ドキュメントに追加されます。

3.7.3 同じ要素用の複数のオーバーライド・ファイルの定義

同一要素に対して複数のオーバーライド・ファイルを定義して、オペレーション・オーバーライド・ファイルを連鎖化できます。これによりステージングや本番などの様々なデプロイメント・シナリオに応じたオペレーション構成が可能になります。

たとえば、coherence.jarにあるオペレーション・デプロイメント・ディスクリプタtangosol-coherence.xmlでは、次のように<coherence>要素のためのオペレーション・オーバーライド・ファイルを定義します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd"
xml-override="{tangosol.coherence.override/tangosol-coherence-override-{mode}
.xml}">
...
</coherence>

モード固有のオーバーライド・ファイルもcoherence.jarにあり、Coherence起動モード(<license-mode>要素の値)に基づいて使用されます。モード固有の各オペレーション・オーバーライド・ファイルは、次のようにデフォルトのオペレーション・オーバーライド・ファイルを定義します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd"
xml-override="/tangosol-coherence-override.xml">
...
</coherence>

tangosol-coherence-override.xmlファイルの<coherence>要素に対して4つのオーバーライド・ファイルを定義できます。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd"
xml-override="/tangosol-coherence-override-staging.xml">
...
</coherence>

必要に応じて連鎖を継続できます。これらのファイルはすべて、クラスパス内のディレクトリに置かれていれば実行時にロードされます。連鎖内の上位にあるファイルが常に下位のファイルをオーバーライドします。

3.8 システム・プロパティを使用した構成の変更

コマンド行オーバーライド機能により、システム・プロパティを使用してオペレーションおよびキャッシュ設定をオーバーライドできます。システム・プロパティは通常、Javaの-Dオプションを使用してJavaコマンド行で指定されます。これによりクラスタ内のすべてのノードで同一のオペレーション構成ファイルおよびキャッシュ構成ファイルを使用しながらノードごとに構成をカスタマイズできるようになります。システム・プロパティを使用すると、開発中の設定を簡単かつ迅速に変更することもできます。

この項には次のトピックが含まれます:

- 事前構成されているシステム・プロパティの使用

- カスタムのシステム・プロパティの作成

3.8.1 事前構成されているシステム・プロパティの使用

Coherenceでは、様々なオペレーション設定およびキャッシュ設定をオーバーライドするために使用される多数のシステム・プロパティが事前構成されています。表D-1に事前構成されたすべてのシステム・プロパティを示してあります。事前構成されたシステム・プロパティは、デフォルトのデプロイメント・ディスクリプタtangosol-coherence.xmlおよびcoherence-cache-config.xmlにそれぞれsystem-property属性を使用して定義されています。

たとえば、事前構成されたtangosol.coherence.log.levelシステム・プロパティは、次のようにtangosol-coherence.xmlファイル内に定義されています。

<logging-config>
...
<severity-level system-property="tangosol.coherence.log.level">5
</severity-level>
...
</logging-config>

事前構成されたシステム・プロパティを使用するには、起動時にJavaの -Dオプションを使用してシステム・プロパティを追加します。前述の例では、キャッシュ・サーバーの起動時に次のようにログ・レベル・システム・プロパティが指定されます。

java -Dtangosol.coherence.log.level=3 -cp COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

注意:
オペレーション・オーバーライド・ファイルを使用する場合、およびカスタム・キャッシュ構成ファイルを作成する場合、事前構成されたシステム・プロパティは常にオーバーライドされる要素とともに配置する必要があります。そうしないと、そのプロパティは使用できなくなります。

3.8.2 カスタムのシステム・プロパティの作成

任意のオペレーション構成要素またはキャッシュ構成要素に対してカスタムのシステム・プロパティを作成できます。事前構成されたシステム・プロパティの名前は必要に応じて変更することもできます。

システム・プロパティは、オーバーライドする要素にsystem-property属性を追加することによって定義されます。system-property属性の値には任意のユーザー定義名を使用できます。カスタムのシステム・プロパティは通常、オペレーション・オーバーライド・ファイル(tangosol-coherence-override.xmlなど)およびカスタムのキャッシュ構成ファイルに定義されます。

オペレーション要素に対するシステム・プロパティの定義

次の例では、オペレーション要素<join-timeout-milliseconds>に対してシステム・プロパティmulticast.join.timeoutを定義し、オペレーション・オーバーライド・ファイルに追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds system-property="multicast.join.timeout">30000
</join-timeout-milliseconds>
</multicast-listener>
</cluster-config>
</coherence>

キャッシュ構成要素に対するシステム・プロパティの定義

次の例では、<cache-name>要素に対してシステム・プロパティcache.nameを定義し、カスタムのキャッシュ構成ファイルに追加します。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name system-property="cache.name"></cache-name>
...

事前定義されたシステム・プロパティの変更

次の例では、オペレーション要素<cluster-name>の事前定義されたシステム・プロパティ名を変更し、オペレーション・オーバーライド・ファイルに追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name system-property="myapp.cluster.name"></cluster-name>
</member-identity>
</cluster-config>
</coherence>

注意:
システム・プロパティを削除するには、要素からシステム・プロパティ属性を削除します。実行時にシステム・プロパティを使用するときにそれが存在しないと、無視されます。

4 最初のCoherenceアプリケーションの作成

この章では、Coherenceの基本的なサンプルを作成および実行するための手順を示し、Coherenceの様々な基本概念について説明します。サンプル・アプリケーションは、簡単なHello Worldアプリケーションであり、スタンドアロンのJavaアプリケーションおよびJSPアプリケーションとして実装されます。最後のJDeveloperに関する項には、Coherenceによる開発時にJDeveloperをセットアップするためのいくつかの基本手順が記載されています。

注意:
この章のサンプルは、基本的なものであり、一般的な概念を説明することのみを目的としています。詳細な例は、インストールに同梱されている例を参照してください。例は、Coherenceのサプリメンタル・インストールの一部としても配布されています。サンプルのビルドおよび実行の詳細は、『Oracle Coherenceチュートリアル』を参照してください。

この章には次の項が含まれます:

- タスク1: サンプル・キャッシュの定義

- タスク2: サンプル・クラスタの構成と起動

- タスク3: 基本のCoherenceスタンドアロン・アプリケーションの作成と実行

- タスク4: 基本のCoherence JavaEE Webアプリケーションの作成と実行

- Coherence開発用のJDeveloperの使用

4.1 タスク1: サンプル・キャッシュの定義

キャッシュは、キャッシュ構成デプロイメント・ディスクリプタ内に定義されており、アプリケーション内で名前によって参照されます。このため、アプリケーションのコードを変更せずにキャッシュの構成を変更できます。次のキャッシュ構成では、キャッシュ名hello-exampleにマップされた基本的な分散キャッシュを定義しています。

キャッシュのサンプルを定義するには:

1. XMLファイルexample-config.xmlを作成します。

2. 次の分散キャッシュの定義をファイルにコピーします。

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>hello-example</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

3. ファイルを保存して閉じます。

4.2 タスク2: サンプル・クラスタの構成と起動

キャッシュはCoherenceクラスタ上にホストされます。Coherenceを実行するJVMプロセスはすべて、実行時に自動的にクラスタに参加し、クラスタによって提供されるキャッシュおよびその他のサービスにアクセス可能になります。クラスタに参加したJVMは、クラスタ・ノードまたはクラスタ・メンバーと呼ばれます。この章のサンプル・アプリケーションでは、キャッシュ・サーバー・プロセスとHello Worldアプリケーション・プロセスの2つの個別のJavaプロセスによってクラスタが形成されます。簡素化を図るため、この2つのプロセスは単一のマシン上に置かれます。この2つのプロセスは1つのコンピュータ上に共存します。キャッシュ・サーバーは、デフォルトでキャッシュ・データを格納するように構成されます。

サンプルのクラスタでは、オペレーション・オーバーライド・ファイルを使用して初期状態のデフォルト・クラスタ構成を修正します。具体的には、デフォルト構成を修正してプライベート・クラスタを作成し、ネットワーク上で実行されている可能性のある既存のCoherenceクラスタに2つのプロセスが参加しないようにします。また、デフォルト構成を修正して、デフォルトのキャッシュ構成ファイルのかわりにexample-config.xmlがロードされるようにします。

サンプルのクラスタを構成して起動するには:

1. tangosol-coherence-override.xmlという名前のファイルを作成します。

2. 次のオーバーライド構成を追加して、cluster_nameおよびportをクラスタ内で一意の値に置き換えます。たとえば、クラスタ名に自分の名前を使用し、ポート番号に電話番号の最後の4桁を使用します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name>cluster_name</cluster-name>
</member-identity>

<multicast-listener>
<address>224.3.6.0</address>
<port>port</port>
<time-to-live>0</time-to-live>
</multicast-listener>
</cluster-config>

<configurable-cache-factory-config>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value system-property="tangosol.coherence.cacheconfig">
example-config.xml</param-value>
</init-param>
</init-params>
</configurable-cache-factory-config>
</coherence>

3. example-config.xmlファイルが保存されているディレクトリにファイルを保存します。

4. コマンド・プロンプトから、DefaultCacheServerクラスを使用してキャッシュ・サーバー・インスタンスを起動し、coherence.jarライブラリおよび構成ファイルの場所をJavaの -cpオプションで指定します。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

4.3 タスク3: 基本のCoherenceスタンドアロン・アプリケーションの作成と実行

ステップ3では、サンプルのHello Worldアプリケーションの作成、サンプルの実行と検証などの、一連の手順を実行します。アプリケーションはコマンド行から実行され、キャッシュ・サーバーに参加するキャッシュ・ノードを起動します。そして、キーk1と値Hello World!をhello-exampleキャッシュに入れます。キー値の取得と出力が済むとアプリケーションが終了します。最後に、追加のクラスタ・ノードが起動され、キーがキャッシュ内にあることが確認されます。

4.3.1 サンプル・スタンドアロン・アプリケーションの作成

アプリケーションは、Coherence APIを使用してキャッシュにアクセスし、キャッシュとの相互作用を図ります。CacheFactoryクラスはキャッシュ・インスタンスの取得のために使用され、NamedCacheインタフェースはキャッシュからのオブジェクトの取得と格納のために使用されます。Hello Worldアプリケーションは非常に基本的ですが、CacheFactoryクラスとNamedCacheインタフェースの使用方法を実際に示します。

例4-1 サンプルのHelloWorldスタンドアロン・アプリケーション

package com.examples;

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;

public class HelloWorld {

public static void main(String[] args) {

String key = "k1";
String value = "Hello World!";

CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("hello-example");

cache.put(key, value);
System.out.println((String)cache.get(key));

CacheFactory.shutdown();
}
}

4.3.2 サンプル・スタンドアロン・アプリケーションの実行

サンプルのスタンドアロン・アプリケーションを実行するには:

1. コマンド・プロンプトからHello Worldアプリケーションをコンパイルします。例:

javac -cp COHERENCE_HOME\lib\coherence.jar com\examples\HelloWorld.java

2. Hello Worldアプリケーションを実行します。Javaの-cpオプションを使用して、coherence.jarライブラリの場所と構成ファイルを指定します。また、クライアントがパーティション化されたデータをローカルに保存しないように制限します。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.example.HelloWorld

Hello Worldアプリケーションが起動します。キャッシュ・ファクトリ・インスタンスが作成され、クラスタのメンバーになります。値Hello World!を持つキーk1がhello-exampleキャッシュにロードされます。次に、このキーがキャッシュから取得され、その値が出力の一部に含まれます。最後に、キャッシュ・ファクトリがシャットダウンされてクラスタを離脱すると、Hello Worldアプリケーションが終了します。

4.3.3 サンプル・キャッシュの確認

この例のキャッシュ・サーバーは、デフォルトでキャッシュのデータを格納するように構成されます。データは、クラスタのすべてのメンバーが使用可能であり、それらのメンバーがクラスタから離脱した後も保持されます。たとえば、Hello Worldアプリケーションは、キャッシュにキーをロードし、そのキーを表示してから終了します。ただし、キャッシュとキーは、その後もすべてのクラスタ・メンバーが使用できます。

この手順では、接続ファクトリ・コマンド行ツールを使用して、hello-exampleキャッシュに接続し、キャッシュ内のすべての項目を一覧表示します。ここでは、Coherenceのキャッシュが永続性と分散性の両方の性質を持っていることを示します。

キャッシュを確認するには:

1. コマンド・プロンプトから、CacheFactoryクラスを使用してスタンドアロンのキャッシュ・ファクトリ・インスタンスを起動し、coherence.jarライブラリおよび構成ファイルの場所を、Java -cpオプションを使用して指定します。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.tangosol.net.CacheFactory

キャッシュ・ファクトリ・インスタンスが起動し、クラスタのメンバーとなり、コマンド行ツールのコマンド・プロンプトを返します。

2. コマンド行ツールのコマンド・プロンプトで、cacheコマンドを使用してhello-exampleキャッシュを取得します。

cache hello-example

3. コマンド行ツールのコマンド・プロンプトで、listコマンドを使用してキャッシュの内容を取得します。

list

コマンドは次の文字列を返し、表示します。

k1 = Hello World!

4.4 タスク4: 基本のCoherence JavaEE Webアプリケーションの作成と実行

ステップ4では、Hello WorldアプリケーションをJSPページとして再実装するなどの、一連の手順を実行します。サンプルをJavaEEサーバーにデプロイされるWebアプリケーションとしてパッケージ化する手順も含まれています。アプリケーションはアプリケーション・サーバー上で実行され、キャッシュ・サーバーに参加するキャッシュ・ノードを起動します。キーk2と値Hello World!がhello-exampleキャッシュに入れられ、キーの値が取得および出力されてからアプリケーションが終了します。最後に、追加のクラスタ・ノードが起動され、キーがキャッシュ内にあることが確認されます。

注意:
WebLogic Serverには、Coherenceアプリケーションのパッケージ化およびデプロイを標準化するCoherence統合が用意されています。Coherenceアプリケーションのパッケージ化およびデプロイに関するWeblogic Serverの手順については、『Oracle Coherenceの管理』を参照してください。この項の手順は、WebLogic Server固有のもの(WebLogic Serverに推奨される手順)ではありません。

4.4 Webスタンドアロン・アプリケーションの作成

サンプルのWebアプリケーションを作成するには:

1. 次のように基本のWebアプリケーション・ディレクトリ構造を作成します。

/
/WEB-INF
/WEB-INF/classes
/WEB-INF/lib

2. 次のJSPをテキスト・ファイルにコピーして、hello.jspという名前でWebアプリケーション・ディレクトリのルートに保存します。

例4-2 サンプルのHello World JSP

<html>
<head>
<title>My First Coherence Cache</title>
</head>
<body>
<h1>
<%@ page language="java"
import="com.tangosol.net.CacheFactory,
com.tangosol.net.NamedCache"
%>
<%
String key = "k2";
String value = "Hello World!";

CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("hello-example");

cache.put(key, value);
out.println((String)cache.get(key));

CacheFactory.shutdown();
%>
</h1>
</body>
</html>

3. 次の空のWebアプリケーション・デプロイメント・ディスクリプタをテキスト・ファイルにコピーして、web.xmlという名前で/WEB-INFディレクトリに保存します。

<?xml version = '1.0' ?>
<web-app/>

4. coherence.jarファイルをWEB-INF/libディレクトリにコピーします。

5. example-config.xmlファイルとtangosol-coherence-override.xmlファイルをWEB-INF/classesディレクトリにコピーします。

6. jarユーティリティを使用してWeb ARchive (WAR)ファイルを作成し、hello.warという名前で保存します。たとえば、Webアプリケーション・ディレクトリのルートでコマンド・プロンプトから次のコマンドを発行します。

jar -cvf hello.war *

アーカイブには次のファイルが含まれます。

/hello.jsp
/WEB-INF/web.xml
/WEB-INF/classes/example-config.xml
/WEB-INF/classes/tangosol-coherence-override.xml
/WEB-INF/lib/coherence.jar

4.4.2 サンプルのWebアプリケーションのデプロイと実行

サンプルのWebアプリケーションをデプロイおよび実行するには:

1. hello.warファイルをJavaEEサーバーにデプロイします。

2. ブラウザから次のURLを使用してhello.jspファイルにアクセスし、Hello Worldアプリケーションを実行します。hostおよびportを、デプロイメント固有の値に置き換えます。

http://host:port/hello/hello.jsp

Hello Worldアプリケーションが起動します。キャッシュ・ファクトリ・インスタンスが作成され、クラスタのメンバーになります。値Hello World!を持つキーk2がhello-exampleキャッシュにロードされます。次に、このキーがキャッシュから取得され、その値がブラウザに表示されます。最後にキャッシュ・ファクトリがシャットダウンされ、クラスタを離脱します。

4.4.3 サンプル・キャッシュの確認

この例のキャッシュ・サーバーは、デフォルトでキャッシュのデータを格納するように構成されます。データは、クラスタのすべてのメンバーが使用可能であり、それらのメンバーがクラスタから離脱した後も保持されます。たとえば、Hello Worldアプリケーションは、キャッシュにキーをロードし、そのキーを表示してから終了します。ただし、キャッシュとキーは、その後もすべてのクラスタ・メンバーが使用できます。

この手順では、接続ファクトリ・コマンド行ツールを使用して、hello-exampleキャッシュに接続し、キャッシュ内のすべての項目を一覧表示します。ここでは、Coherenceのキャッシュが永続性と分散性の両方の性質を持っていることを示します。

キャッシュを確認するには:

1. コマンド・プロンプトから、CacheFactoryクラスを使用してスタンドアロンのキャッシュ・ファクトリ・インスタンスを起動し、coherence.jarライブラリおよび構成ファイルの場所を、Java -cpオプションを使用して指定します。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.tangosol.net.CacheFactory

キャッシュ・ファクトリ・インスタンスが起動し、クラスタのメンバーとなり、コマンド行ツールのコマンド・プロンプトを返します。

2. コマンド行ツールのコマンド・プロンプトで、cacheコマンドを使用してhello-exampleキャッシュを取得します。

cache hello-example

3. コマンド行ツールのコマンド・プロンプトで、listコマンドを使用してキャッシュの内容を取得します。

list

コマンドは次の文字列を返し、表示します。

k2 = Hello World!

4.5 Coherence開発用のJDeveloperの使用

この項では、Coherenceの開発用にJDeveloperをセットアップするための基本手順を説明します。この説明は、IDE内でCoherenceを実行するためのものであり、開発時の一般的なアプローチになります。説明はJDeveloperに固有のものですが、任意のIDEで同じアプローチが可能です。具体的な手順は、IDEのドキュメントを参照してください。

- JDeveloperにおけるCoherenceの実行

- JDeveloperにおけるスレッド・ダンプの表示

- JDeveloperにおける構成ファイルの作成

4.5.1 JDeveloperにおけるCoherenceの実行

JDeveloperを使用してキャッシュ・サーバー(DefaultCacheServer)およびキャッシュ・インスタンス(CacheFactory)を実行できます。各インスタンスはそれぞれ別のJavaプロセスとして起動され、標準出力をプロセス・ログに記録します。キャッシュ・コマンドなどの入力は、コマンド行から起動された場合と同様にプロセスに直接入力できます。この構成では、Coherenceソリューションの開発とテストが可能です。

JDeveloperでCoherenceを実行するには:

1. JDeveloperで、単一のプロジェクトを含む新規の汎用アプリケーションを作成します。初めてJDeveloperを使用する場合は、オンライン・ヘルプで詳細な手順を参照してください。

2. 「アプリケーション・ナビゲータ」で新規のプロジェクトをダブルクリックします。「プロジェクト・プロパティ」ダイアログ・ボックスが表示されます。

3. 「ライブラリとクラスパス」ノードを選択します。「ライブラリとクラスパス」ページが表示されます。

4. 「ライブラリとクラスパス」ページで「JAR/ディレクトリの追加」をクリックします。「アーカイブまたはディレクトリの追加」ダイアログ・ボックスが表示されます。

5. ディレクトリ・ツリーから「COHERENCE_HOME\lib\coherence.jar」を選択して、「選択」をクリックします。次のように、coherence.jarライブラリが「クラスパス・エントリ」リストに表示されます。

6. 「プロジェクト・プロパティ」ダイアログ・ボックスで、「実行/デバッグ/プロファイル」ノードを選択します。「実行/デバッグ/プロファイル」ページが表示されます。

7. 「実行/デバッグ/プロファイル」ページで「新規」をクリックします。「実行構成の作成」ダイアログ・ボックスが表示されます。「名前」テキスト・ボックスに新規の実行構成の名前を入力します。「設定のコピー元」ドロップダウン・ボックスで「デフォルト」を選択します。「OK」をクリックします。新規の実行構成が「実行構成」リストに表示されます。

8. 「実行構成」リストから、新規の実行構成を選択して「編集」をクリックします。「実行構成の編集」ダイアログ・ボックスが表示され、「起動設定」ノードが選択されます。

9. 「起動設定」ページで「参照」をクリックして「デフォルトの実行ターゲット」を選択します。「デフォルトの実行ターゲットの選択」ダイアログ・ボックスが表示されます。

10. ディレクトリ・ツリーから「COHERENCE_HOME\lib\coherence.jar\com\
tangosol\net\DefaultCacheServer.class」を選択して、「開く」をクリックします。次のようにデフォルトの実行ターゲットとしてDefaultCacheServerクラスが指定されます。

ヒント:
Coherenceのシステム・プロパティを設定するには、「Javaオプション」テキスト・ボックスを使用します。

11. 「ツール設定」ノードを選択します。「ツール設定」ページが表示されます。

12. 「追加実行オプション」セクションで「プログラムの入力を許可」チェック・ボックスを選択します。ボックス内のチェック・マークは、オプションが選択されていることを示します。

13. 「OK」をクリックします。

14. ステップ6から14を繰り返し、次のようにデフォルトの実行ターゲットとしてCOHERENCE_HOME\lib\coherence.jar
\com\tangosol\net\CacheFactory.classを選択します。

15. 「OK」をクリックして、「プロジェクト・プロパティ」ダイアログ・ボックスを閉じます。

16. 「実行」ボタンのドロップダウン・リストからキャッシュ・サーバーの実行構成を選択して起動します。キャッシュ・サーバーのインスタンスが起動され、次のように出力がプロセスのログ・タブに表示されます。

17. 「実行」ボタンのドロップダウン・リストからキャッシュの実行構成を選択して起動します。キャッシュのインスタンスが起動され、次のように出力がプロセスのログ・タブに表示されます。

18. キャッシュ・ファクトリの実行中ログ・タブの下部にある入力テキスト・ボックスを使用してキャッシュ・インスタンスに関する操作を実行します。たとえば、「help」と入力して「Enter」キーを押すと、有効なコマンドのリストが表示されます。

4.5.2 JDeveloperにおけるスレッド・ダンプの表示

Javaでは、スレッドとスレッドによって保持されているすべてのロックのリストを標準出力にダンプできます。これは、Linux環境ではkillコマンド、Windows環境では[Ctrl]+[Break]で実行できます。スレッド・ダンプは、デッドロックの検出など、開発段階でのトラブルシューティングに役立ちます。

JDeveloperでCoherenceソリューションを開発する場合は、プロセスのログ・タブにスレッド・ダンプを直接表示できます。そのためには、JDeveloperで実行されているJavaプロセスに前述の信号を送信します。

JDeveloperでスレッド・ダンプを表示するには:

1. シェルまたはコマンド・プロンプトから、JDK_HOME/bin/jpsを使用して、スレッド・ダンプを表示するJavaプロセスのプロセスID (PID)を取得します。

2. Linuxの場合、kill -3 PIDを使用して、QUITシグナルをプロセスに送信します。Windowsの場合、[Ctrl]+[Break]のシグナルをリモートJavaプロセスに送信するため、SendSignalなどのサード・パーティ・ツールを使用する必要があります。
JDeveloperでは、スレッド・ダンプをプロセスのログに出力できます。

4.5.3 JDeveloperにおける構成ファイルの作成

JDeveloperを使用してCoherenceの構成ファイルを作成できます。JDeveloperによって適切なXSDファイルがロードされ、「コンポーネント・パレット」内に要素がすべてリストされます。さらに、JDeveloperは、構成ファイルをXSDと照合して検証し、XMLコードを完了させます。次の手順によって、キャッシュ構成ファイルとオペレーション・オーバーライド・ファイルが作成されます。同一の手順を、任意のCoherence構成ファイルに対して使用できます。

JDeveloperでキャッシュ構成ファイルとオペレーション・オーバーライド・ファイルを作成するには:

1. COHERENCE_HOME\lib\coherence.jarライブラリのcoherence-cache-config.xsd、coherence-cache-config-base.xsd、coherence-operational-config.xsd、coherence-operational-config-base.xsdおよびcoherence-config-base.xsdを自分のコンピュータのディレクトリに解凍します。

2. JDeveloperの「アプリケーション・ナビゲータ」でCoherenceのプロジェクトをダブルクリックします。「プロジェクト・プロパティ」ダイアログ・ボックスが表示されます。

3. 「プロジェクトのソースパス」ノードを展開して「リソース」をクリックします。「リソース」ページが表示されます。

4. 「リソース」セクションで「追加」をクリックしてXSDファイルが解凍されたディレクトリを選択します。

5. 「対象」タブで「追加」をクリックしてXSDファイルを選択します。個々のファイルを明示的に追加するのでなく、ディレクトリ内のすべてのファイルをまとめて追加することもできます。

6. 「OK」をクリックします。次のようにXSDが「対象」タブにリストされます。

7. 「OK」をクリックして、「プロジェクト・プロパティ」ダイアログ・ボックスを閉じます。プロジェクトのXSDが「アプリケーション・ナビゲータ」の「リソース」フォルダの下にリストされます。

8. 「ファイル」メニューで「新規」をクリックします。「新規ギャラリ」ダイアログ・ボックスが表示されます。

9. 「カテゴリ」セクションで「一般」ノードを展開し、「XML」をクリックします。

10. 「XMLドキュメント」を選択して「OK」をクリックします。XMLファイルの作成ダイアログ・ボックスが表示されます。

11. ファイル名として「coherence-cache-config.xml」を入力して、XSDと同じディレクトリに保存します。実行時に、このファイルがクラスパス内のcoherence.jarファイルの前に置かれている必要があります。

12. 「OK」をクリックします。プロジェクトのキャッシュ構成ファイルが作成され、編集用に開かれて、「アプリケーション・ナビゲータ」の「リソース」フォルダの下にリストされます。

13. ファイルの先頭に、次のスキーマ参照を追加します。

<?xml version="1.0" ?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">

「コンポーネント・パレット」がリフレッシュされ、coherence-cache-config.xsdファイル内の使用可能な要素がすべてリストされます。

14. coherence-cache-config.xmlファイルを保存します。

15. ステップ8から12を繰り返して、オペレーション・オーバーライド・ファイルtangosol-coherence-override.xmlを作成します。実行時に、このファイルがクラスパスに存在する必要があります。

16. ファイルの先頭に、次のスキーマ参照を追加します。

<?xml version="1.0" ?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">

「コンポーネント・パレット」がリフレッシュされ、coherence-operational-config.xsdファイル内の使用可能な要素がすべてリストされます。

17. tangosol-coherence-override.xmlファイルを保存します。

5 Coherenceでのデバッグ

この章では、ロギングを構成するための手順を説明し、Coherenceアプリケーションのデバッグおよびトラブルシューティングの際の一般的な注意点を示します。

この章には次の項が含まれます:

- Coherenceでのデバッグの概要

- ロギングの構成

- リモート・デバッグの実行

- Coherenceベース・アプリケーションのトラブルシューティング

5.1 Coherenceでのデバッグの概要

一般的に、Coherenceアプリケーションは1つのコンピュータ上で開発されます。キャッシュ・サーバーおよびアプリケーションはIDE内で起動され、必要に応じてアプリケーションをデバッグします。このような開発環境は、セットアップしやすく、最適に実行され、デバッグも容易です。ほとんどのアプリケーションは、この方法で作成およびテストできます。単一サーバーで実行するCoherenceの構成の詳細は、「単一サーバー・モードの有効化」を参照してください。

開発中にロギングを使用し、JVMデバッグ・オプションを有効にして、必要に応じてスレッドおよびヒープ・ダンプを取得することで、ほとんどのエラーを検出できることが理想的です。また、OracleのJava VisualVMやJConsoleなどのプロファイル・ツールおよびIDEは、問題を診断する機能を備えています。ただし、Coherenceアプリケーションは、最終的に分散環境でテストする必要があります。テスト環境でのデバッグおよびトラブルシューティングは、データおよびプロセスがクラスタ全体に完全に分散され、ネットワークがアプリケーションに影響するので、より困難になります。Java Debug Wire Protocol (JDWP)とCoherenceのJMX管理およびレポート機能を使用してリモート・デバッグを行うと、分散環境でのデバッグおよびトラブルシューティングが容易になります。

Oracleサポートの使用

Oracleサポートは、問題をデバッグする際に役立ち、https://support.oracle.comから利用できます。サポートに問題を送付する場合、必ず圧縮ファイルに次の項目を含めてください。

- アプリケーション・コード

- 構成ファイル

- すべてのクラスタ・メンバーのログ・ファイル

- 特定の環境では、スレッドおよびヒープ・ダンプが必要です。アプリケーションの実行が低速な場合やハングしそうな場合は、スレッド・ダンプを送信してください。アプリケーションでメモリー不足が発生する場合や、想定より多くのメモリーを消費する場合は、ヒープ・ダンプを送信してください。

5.2 ロギングの構成

Coherenceは、独自のロギング・フレームワークを持ち、一般的なアプリケーションのロギング環境を提供するlog4j、slf4jおよびJavaロギングの使用もサポートします。システムの重要な部分への影響を軽減するために、Coherenceでのロギングは優先度の低い専用のスレッドで実行されます。ロギングは事前構成されており、必要に応じてデフォルト設定を変更する必要があります。

この項には次のトピックが含まれます:

- ログ・レベルの変更

- ログ出力先の変更

- ログ・メッセージのフォーマットの変更

- ロギング文字制限の設定

- CoherenceログでのJDKロギングの使用

- CoherenceログでのLog4Jロギングの使用

- CoherenceログでのSLF4Jの使用

5.2.1 ログ・レベルの変更

ロガーのログ・レベルにより、出力されるログ・メッセージを決定します。デフォルトのログ・レベルは、エラー、警告、情報、および一部のデバッグ・メッセージを出力します。開発時は、ログ・レベルを最大設定まで上げて、すべてのデバッグ・メッセージをログに記録するようにします。使用可能なログ・レベルは、次のとおりです。

- 0 - このレベルには、ロギング・レベルに関連付けられていないメッセージが含まれます。

- 1 - このレベルには、前のレベルのメッセージに加えて、エラー・メッセージも含まれます。

- 2 - このレベルには、前のレベルのメッセージに加えて、警告メッセージも含まれます。

- 3 - このレベルには、前のレベルのメッセージに加えて、情報メッセージも含まれます。

- 4-9 - このレベルには、前のレベルのメッセージに加えて、内部デバッグ・メッセージも含まれます。ログ・レベルを上げると、より多くのログ・メッセージが出力されます。デフォルトのログ・レベルは5です。

- -1 - ログ・メッセージは出力されません。

ログ・レベルを変更するには、オペレーション・オーバーライド・ファイルを編集して、<severity-level>要素を<logging-config>要素の中に追加して、レベル番号を指定します。例:

...
<logging-config>
...
<severity-level system-property="tangosol.coherence.log.level">9
</severity-level>
...
</logging-config>
...

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.log.levelシステム・プロパティを使用してログ・レベルを指定することもできます。例:

-Dtangosol.coherence.log.level=9

5.2.2 ログ出力先の変更

ロガーは、複数の出力先にログ・メッセージを出力するように構成できます。コンソールへの標準出力に、stdoutとstderr (デフォルト)の両方を使用できます。ロガーは、指定されたファイルにメッセージを出力することもできます。

また、Coherenceでは、JDK、log4jおよびSLF4Jの使用がサポートされており、アプリケーションとCoherenceで共通のロギング・フレームワークを共有できます。詳細は、「CoherenceログでのJDKロギングの使用」および「CoherenceログでのLog4Jロギングの使用」、「CoherenceログでのSLF4Jの使用」を参照してください。

ログ出力先を変更するには、オペレーション・オーバーライド・ファイルを編集して、<destination>要素を<logging-config>要素の中に追加して、出力先を指定します。例:

...
<logging-config>
<destination system-property="tangosol.coherence.log">stdout</destination>
...
</logging-config>
...

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.logシステム・プロパティを使用して、ログの出力先を指定することもできます。例:

-Dtangosol.coherence.log=stdout

5.2.2.1 ファイルへのログ・メッセージの送信

<destination>要素内にパスとファイル名を指定することで、ファイルにログ・メッセージを出力するようにロガーを構成できます。指定されたパスは、存在している必要があります。指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。出力はファイルに追加され、サイズの制限はありません。プロセス間ではログ・ファイルを共有できません。プロセスが再起動するとログ・ファイルは置き換えられます。ファイルへのログ・メッセージの送信は、一般的には開発およびテスト時に行われ、特にログ・メッセージをOracleサポートに送信する必要がある場合に役立ちます。

次の例では、/tmpディレクトリに書き込まれるcoherence.logという名前のログ・ファイルを指定しています。

...
<logging-config>
<destination system-property="tangosol.coherence.log">/tmp/coherence.log
</destination>
...
</logging-config>
...

5.2.3 ログ・メッセージのフォーマットの変更

必要な詳細情報の量に応じて、デフォルトのログ・メッセージのフォーマットを変更できます。ログ・メッセージには、静的なテキストのほかに、実行時に置き換えられる次の任意のパラメータを含めることができます。

注意:
ログ・メッセージのフォーマットを変更する場合は、注意深く行う必要があります。メンバーやスレッドなどの重要な情報が失われると、問題のデバッグが困難になる場合があります。

パラメータ

説明

{date}

このパラメータは、メッセージがログに記録された日付/時刻(ミリ秒まで)を示します。

{uptime}

このパラメータは、クラスタ・メンバーが稼働していた時間を示します。

{product}

このパラメータは、製品名とライセンス・タイプを示します。

{version}

このパラメータは、Coherenceのバージョンとビルドの詳細を示します。

{level}

このパラメータは、メッセージのロギング重大度レベルを示します。

{thread}

このパラメータは、メッセージをログに記録したスレッド名を示します。

{member}

このパラメータは、クラスタ・メンバーIDを示します(クラスタが現在実行中の場合)。

{location}

このパラメータは、完全修飾クラスタ・メンバーID: cluster-name、site-name、rack-name、machine-name、process-nameおよびmember-name(クラスタが現在実行中の場合)を示します。

{role}

このパラメータは、クラスタ・メンバーの指定されたロールを示します。

{text}

このパラメータは、メッセージのテキストを示します。

{ecid}

このパラメータは、実行コンテキストID (ECID)を示します。ECIDは、Oracleコンポーネント間のリクエストにアタッチされるグローバルに一意のIDです。ECIDは、Oracle固有の診断機能であり、Oracleコンポーネントのログ・ファイルにわたってログ・メッセージを関連付けるために使用されます。また、複数のリクエストが並行して処理される場合に1つのコンポーネント内の同じリクエストに関するログ・メッセージを追跡するためにも使用されます。自身のログにECIDを含めるCoherenceクライアントは、Coherenceを起動するときに、アクティブなダイナミック・モニタリング・サービス(DMS)実行コンテキストを持っている必要があります。
注意: JDKロギングをOracle Diagnostic Logging (ODL)ハンドラとともに使用する場合、ECIDは自動的にODLレコード・フォームの一部となるので、ODL{ecid}パラメータは適用されません。

ログ・メッセージのフォーマットを変更するには、オペレーション・オーバーライド・ファイルを編集して、<message-format>要素を<logging-config>要素の中に追加して、フォーマットを指定します。例:

...
<logging-config>
...
<message-format>[{date}] &lt;{level}&gt; (thread={thread})  -->{text}
</message-format>
...
</logging-config>
...

5.2.4 ロギング文字制限の設定

ロギング文字制限により、ロガー・デーモン・プロセスがメッセージ・キューから処理する最大文字数を指定します。この数を超過すると、キューに残っているメッセージがすべて破棄されます。廃棄されたメッセージはロギング・システムにより要約され、廃棄されたメッセージ数とその合計サイズの詳細が単一のログ・エントリに示されます。例:

Asynchronous logging character limit exceeded; discarding 5 log messages (lines=14, chars=968)

切捨ては一時的なものにすぎません。キューが処理されると(空になると)ロガーはリセットされ、後続のメッセージがログに記録されるようになります。

注意:
合計文字数が最大値を超えるメッセージが切り捨てられることはありません。

文字制限は、ロギングにより障害状態から回復できない状況を回避するために使用されます。たとえば、ロギングによりすでにタイトなタイミングが深刻化する場合があります。そうなると追加的に障害が発生し、さらに多くのロギングが生成されることになります。このサイクルは、回復不能になるまで続くことがあります。ロギングに制限をかけることで、このサイクルの発生を回避します。

ログの文字の制限を設定するには、オペレーション・オーバーライド・ファイルを編集して、<character-limit>要素を<logging-config>要素の中に追加します。文字制限は、0 (Integer.MAX_VALUE)または正の整数で入力します。例:

...
<logging-config>
...
<character-limit system-property="tangosol.coherence.log.limit">12288
</character-limit>
</logging-config>
...

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.log.limitシステム・プロパティを使用して、ログの文字制限を指定するすることもできます。例:

-Dtangosol.coherence.log.limit=12288

5.2.5 CoherenceログでのJDKロギングの使用

JDKロギング・フレームワークを使用するアプリケーションでは、CoherenceもJDKロギングを使用するように構成できます。JDKロギングの詳細は、このドキュメントでは述べません。JDKロギングの詳細は、http://download.oracle.com/javase/7/docs/technotes/guides/logging/overview.htmlを参照してください。

CoherenceログでJDKロギングを使用するには、次の手順を実行します。

1. logging.propertiesファイルを作成します。次の例では、コンソールとファイルの両方にメッセージを出力するようにJDKロガーを構成します。コンソールおよびファイルへの出力は、FINESTログ・レベルを使用するように構成されています。ファイル・ハンドラ・パターンの場合、指定されたパスが存在している必要があります。また、指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。

handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler

.level=INFO
Coherence.level=FINEST

java.util.logging.FileHandler.pattern=/tmp/coherence%u.log
java.util.logging.FileHandler.limit=50000
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

注意:

- 前述の例では、Coherenceはロガー・オブジェクト名として使用され、Coherenceロギング・フレームワークで使用されるデフォルト名になります。オペレーション・オーバーライド・ファイルの<logger-name>要素内で名前を指定するか、tangosol.coherence.log.loggerシステム・プロパティの値として名前を指定することで、異なる名前を使用できます。

- JDKロギング・レベルをFINESTに設定して、Coherenceロギング設定がJDKロギングにどのログ・メッセージを構成するかを決定できるようにします。

2. オペレーション・オーバーライド・ファイルの<destination>要素の値としてjdkを指定することで、JDKロギングを使用するようにCoherenceを構成します。例:

...
<logging-config>
<destination system-property="tangosol.coherence.log">jdk</destination>
...
</logging-config>
...

3. logging.propertiesファイルが、java.util.logging.config.fileシステム・プロパティを使用して指定されていることを確認してください。例:

-Djava.util.logging.config.file=myfile

JDKのログ・レベルとCoherenceのログ・レベルのマッピング

次の表に、JDKのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。

JDKのログ・レベル

Coherenceのログ・レベル

OFF

NONE

FINEST

INTERNAL

SEVERE

ERROR

WARNING

WARNING

INFO

INFO

FINE

LEVEL_D4

FINER

LEVEL_D5

FINEST

LEVEL_D6

FINEST

LEVEL_D7

FINEST

LEVEL_D8

FINEST

LEVEL_D9

ALL

ALL

5.2.6 CoherenceログでのLog4Jロギングの使用

log4jロギング・フレームワークを使用するアプリケーションでは、Coherenceもlog4jロギングを使用するように構成できます。log4jロギングの詳細は、このドキュメントでは述べません。log4jロギングの詳細は、http://logging.apache.org/log4j/1.2/manual.htmlを参照してください。

Coherenceログでlog4jロギングを使用するには、次の手順を実行します。

1. log4j.propertiesファイルを作成します。次の例では、コンソールとファイルの両方にメッセージを出力するようにlog4jロガーを構成します。コンソールおよびファイルへの出力は、FATALログ・レベルを使用するように構成されています。ファイルに追加する場合、指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。

log4j.logger.Coherence=FATAL, stdout, file

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%m%n

log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=/tmp/coherence.log
log4j.appender.file.MaxFileSize=10MB
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%m%n

注意:

- 前述の例では、Coherenceはロガー・オブジェクト名として使用され、Coherenceロギング・フレームワークで使用されるデフォルト名になります。オペレーション・オーバーライド・ファイルの<logger-name>要素内で名前を指定するか、tangosol.coherence.log.loggerシステム・プロパティの値として名前を指定することで、異なる名前を使用できます。

- log4jロギング・レベルをFATALに設定して、Coherenceロギング設定がlog4jロギングにどのログ・メッセージを構成するかを決定できるようにします。

2. オペレーション・オーバーライド・ファイルの<destination>要素の値としてlog4jを指定することで、log4jロギングを使用するようにCoherenceを構成します。例:

...
<logging-config>
<destination system-property="tangosol.coherence.log">log4j</destination>
...
</logging-config>
...

3. 実行時にlog4j.jarファイルとlog4j.propertiesファイルの両方がクラスパスに存在するようにしてください。

Log4Jのログ・レベルとCoherenceのログ・レベルのマッピング

次の表に、log4jのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。

Log4Jのログ・レベル

Coherenceのログ・レベル

OFF

NONE

DEBUG

INTERNAL

ERROR

ERROR

WARN

WARNING

INFO

INFO

DEBUG

LEVEL_D4

DEBUG

LEVEL_D5

DEBUG

LEVEL_D6

DEBUG

LEVEL_D7

DEBUG

LEVEL_D8

DEBUG

LEVEL_D9

ALL

ALL

5.2.7 CoherenceログでのSLF4Jの使用

SLF4Jロギングを使用するアプリケーションでは、CoherenceもSLF4Jロギングを使用するように構成できます。SLF4Jロギングの詳細は、このドキュメントでは述べません。SLF4Jロギングの詳細は、http://www.slf4j.org/を参照してください。

SLF4Jロギングを使用する手順は次のとおりです。

1. オペレーション・オーバーライド・ファイルの<destination>要素の値としてslf4jを指定します。例:

...
<logging-config>
<destination system-property="tangosol.coherence.log">slf4j</destination>
...
</logging-config>
...

2. slf4j-api.jarファイルと、適切なロギング・フレームワークSLF4JバインディングJARが両方ともクラスパスにあることを確認します。

5.3 リモート・デバッグの実行

Java Debug Wire Protocol (JDWP)は、リモートでJVMをデバッグする機能を備えています。ほとんどのIDEツールは、JDWPをサポートし、リモート・デバッグを可能にするリモートJVMに接続するために使用されます。リモートJVMへの接続方法については、IDEのドキュメントを参照してください。

キャッシュ・サーバーでリモート・デバッグを有効にするには、次のJVMオプションを使用してキャッシュ・サーバーを起動します。キャッシュ・サーバーを起動したら、IDEのデバッガを使用して、指定されたポート(この例では5005)でJVMに接続します。

-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

アプリケーションが単一ノード・クラスタ上にない場合、クラスタのメンバー間でデータが分散されるため、Coherenceアプリケーションのリモート・デバッグは困難になる場合があります。たとえば、パラレル・グリッド操作を実行する場合、その操作は当該のデータが存在するクラスタ・メンバー上で実行されます。データが存在するのはどのメンバーか保証されていないので、最適な方法は単一のキャッシュ・サーバーを使用するようにテストを制約することです。

また、ガーディアンおよびパケット・タイムアウトを使用すると、クラスタのデバッグが困難になる場合があります。デバッガがパケットの公開、クラスタおよびサービス・スレッドを停止すると、クラスタ間で切断が発生する場合があります。そのようなシナリオでは、デバッグ・セッション中はガーディアンを無効にしてパケット・タイムアウトを増加します。これらの設定の構成の詳細は、「service-guardian」を参照してください。

5.4 Coherenceベース・アプリケーションのトラブルシューティング

ここでは、一般的なトラブルシューティングの注意事項を示します。Coherenceベース・アプリケーションのトラブルシューティングは、他のJavaアプリケーションのトラブルシューティングとほとんどかわりません。ほとんどのIDEは、プロセスを補助する機能を備えています。また、Java VisualVM、JConsole、サード・パーティ・ツールなど多くのツールでは、Javaアプリケーションのモニターとトラブルシューティングを行うための容易な手段を提供しています。Javaのトラブルシューティングの詳細は、OTNのJava SEのトラブルシューティングのセクションを参照してください。

http://www.oracle.com/technetwork/java/javase/index-138283.html

単一のサーバー・クラスタ上でのCoherenceアプリケーションのトラブルシューティングは、一般的には単純になります。デバッグがしやすくなるため、ほとんどのCoherence開発作業はそのような環境で行われます。分散クラスタにデプロイされたアプリケーションのトラブルシューティングは、より困難になる場合があります。

この項には次のトピックが含まれます:

- Coherenceログの使用

- JMX管理およびCoherenceレポートの使用

- JVMオプションを使用したデバッグの促進

- スレッド・ダンプの取得

- ヒープ・ダンプの取得

- オペレーティング・システムのモニタリング

5.4.1 Coherenceログの使用

ログ・メッセージは、Coherenceのモニターとトラブルシューティングに使用される情報を提供します。ほとんどのログ・メッセージは、『Oracle Coherenceの管理』のログの用語集に関する項に説明があります。用語集には、追加の詳細情報およびメッセージが出力されたときに実行する処理が解説されています。

アプリケーションの開発およびデバッグ時に、デフォルトの初期状態の構成と異なるログの構成を行うことは非常に重要です。特に、最高のログ・レベル(JDKまたはlog4jロギングの使用時のレベル9またはALL)を使用すると、すべてのログ・メッセージが出力されるようになります。また、JDKまたはlog4jのロギングの使用も検討してください。両方のフレームワークとも、ファイル出力とコンソール出力の同時使用をサポートしています。最後に、すべてのログ・ファイルを共通のディレクトリに配置することを検討してください。共通ディレクトリを使用すると、ログ・ファイルの確認やCoherenceサポート・チーム宛のそれらのログ・ファイルのパッケージが容易になります。ロギングのすべての側面の構成の詳細は、「ロギングの構成」を参照してください。

5.4.2 JMX管理およびCoherenceレポートの使用

Coherence管理は、Java Management Extensions (JMX)を使用して実装されます。Coherenceのヘルス状態および安定性の詳細を示す多くのMBeanが提供されます。MBeanは重要な分析情報を提供し、アプリケーションを開発環境から完全な分散環境に移行する際に使用する必要があります。MBeanには、JConsoleおよびVisualVMまたは、JMXをサポートする任意の管理ツールを使用してアクセスできます。またCoherenceには、MBeanから情報を長期的に収集するレポートが含まれ、単にMBeanをモニタリングするのみでは不可能な履歴情報を提供できます。レポートは、多くの場合、トラブルシューティングで重要となる傾向を特定するために使用されます。管理およびレポートは、デフォルトでは有効でないので、有効にする必要があります。Coherenceに備わる管理機能の使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

5.4.3 JVMオプションを使用したデバッグの促進

ほとんどのJVMには、デバッグおよびトラブルシューティングを補助するためのオプションが含まれます。これらのオプションを使用して、情報を最大限に取得します。使用可能なオプションは、JVMベンダーのドキュメントを参照してください。このセクションで説明するJVMオプションは、Java HotSpot固有のものです。すべてのJVMオプションの詳細情報と使用方法は、Java HotSpot VMオプションのWebページを参照してください。

>http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html">>http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

>次のJVMオプション(標準および非標準)は、アプリケーションのデバッグおよびトラブルシューティング時に役立ちます。

- >

- >
>>-verbose:gcまたは>-Xloggc:>file - これらのオプションは、それぞれのガベージ・コレクション・イベントの追加ログを有効にするために使用されます。分散システムでは、単一のJVM上でGCが停止すると、多数のJVMのパフォーマンスに影響する場合があります。そのため、ガベージ・コレクションを注意深くモニターすることが重要になります。>-Xloggcオプションは冗長GCと似ていますが、タイムスタンプが含まれます。

- >
>>-Xprofおよび>-Xrunhprof - これらのオプションは、JVMプロファイル・データを表示するために使用され、本番システムでの使用を目的としたものではありません。

- >
>>-XX:-PrintGC、>-XX:-PrintGCDetailsおよび>-XX:-PrintGCTimeStamps - これらのオプションも、ガベージ・コレクション時にメッセージを出力するために使用されます。

- >
>>-XX:-HeapDumpOnOutOfMemoryErrorおよび>-XX:HeapDumpPath=./java_pid><pid>>.hprof - これらのオプションは、>java.lang.OutOfMemoryErrorがスローされたときにヒープ・ダンプを開始するために使用されます。

- >
>>-XX:ErrorFile=./hs_err_pid><pid>>.log - このオプションを使用すると、エラー・データがファイルに保存されます。

5.4.4 スレッド・ダンプの取得

スレッド・ダンプは、JVM内の各スレッドの詳細情報(スレッド状態など)を確認するために使用されます。スレッド・ダンプには、デッドロックした各スレッドの情報も含まれます(適用可能な場合)。Coherenceはマルチスレッド・アーキテクチャおよび分散アーキテクチャが採用されているため、スレッド・ダンプは有用です。スレッド・ダンプは、多くの場合、動作の遅いアプリケーションやデッドロックしたアプリケーションのトラブルシューティングに使用されます。スレッド・ダンプは単なるスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずスレッド・ダンプのセットを含めてください。

Coherenceは、ClusterMBean MBeanにあるネイティブlogClusterState JMX操作およびClusterNodeMBean MBeanにあるネイティブlogNodeState JMX操作を提供します。これらの操作によって、それぞれ、複数のクラスタ・メンバーまたは1つのクラスタ・メンバーに対するスレッド・ダンプ(未処理のポーリングを含む)が開始されます。Coherence MBeanの詳細なリファレンスは、『Oracle Coherenceのマネージメント』を参照してください。

UnixまたはLinuxオペレーティング・システム上でローカルにスレッド・ダンプを実行するには、アプリケーション・コンソールで[Ctrl]+[\]キーを押します。Windows上でスレッド・ダンプを実行するには、[Ctrl]+[Break](または[Pause])キーを押します。両方の方法とも、スレッド・ダンプとヒープ・サマリーが含まれます。

ほとんどのIDEは、IDEでの作業時にスレッド・ダンプを取得するために使用できるスレッド・ダンプ機能を備えています。また、UnixおよびLinuxオペレーティング・システムでは、kill -3 pidを使用して、IDEでリモート・スレッド・ダンプを発生させることができます。Windowsの場合、SendSignalなどのサード・パーティ・ツールを使用して、[Ctrl]+[Break]のシグナルをリモートJavaプロセスに送信し、IDEでダンプを発生させます。

OracleのJava VirtualVM (jvisualvm)やJConsole (jconsole)などのプロファイル・ツールは、スレッド・ダンプを実行できます。これらのツールは、トラブルシューティングおよびデバッグ用の単一のツールを備えており、スレッドの詳細以外に様々な種類の情報を表示するので、非常に有用です。

最後に、jstackツールを使用して、任意のプロセスのスレッド・ダンプを取得できます。たとえば、jpsを使用してJavaプロセスIDを検索してから、コマンド行で次を実行します。

jstack <pid>

jstackツールはサポートされていません。JDKの将来のバージョンで使用可能になるかどうかは未定です。

5.4.5 ヒープ・ダンプの取得

ヒープ・ダンプは、JVMヒープ内のすべてのオブジェクトの詳細情報を確認するために使用されます。この情報には、ロードされたオブジェクトのインスタンス数およびオブジェクトに割り当てられたメモリー容量が含まれます。一般的にヒープ情報は、リソースの浪費またはパフォーマンスの低下の原因となっている可能性のあるアプリケーションの部分を見つけるために使用されます。Coherenceの完全な分散環境では、アプリケーションの処理がクラスタを横断して発生し、問題となるオブジェクトは必ずしもJVMにローカルであるとはかぎらないので、ヒープ・ダンプは扱いづらくなる場合があります。ヒープ・ダンプは単なる一時のスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずヒープ・ダンプを含めてください。

ヒープ・ダンプを最も簡単に取得するには、プロファイル・ツールを使用します。OracleのJava VirtualVM (jvisualvm)およびJConsole (jconsole)は、ヒープ・ダンプ機能を備えています。また、ほとんどのIDEは、IDEでの作業時にヒープ・ダンプを取得するために使用できるスレッド・ダンプ機能を備えています。

代替案として、jmapツールを使用するとヒープ・ダンプを取得でき、jhatツールを使用するとヒープ・ダンプを表示できます。たとえば、jpsを使用してJavaプロセスIDを検索してから、コマンド行で次を実行します。

jmap -dump:format=b,file=/coherence.bin pid

ブラウザでヒープ・ダンプを表示するには、コマンド行で次を実行してから、返されたアドレスを参照します。ファイルは、VisualVMにロードして表示することもできます。

jhat /coherence.bin

jmapおよびjhatツールはサポートされていません。JDKの将来のバージョンで使用可能になるかどうかは未定です。

5.4.6 オペレーティング・システムのモニタリング

Coherenceベース・アプリケーションのトラブルシューティングおよびデバッグを行う際は、必ずクラスタ・メンバーのオペレーティング・システムをモニターします。オペレーティング・システムのチューニングが不十分な場合、クラスタ全体のパフォーマンスに影響することがあり、アプリケーションに悪影響がある場合があります。パフォーマンスのチューニングの詳細は、『Oracle Coherenceの管理』を参照してください。

特に、次の領域をモニターすることは重要です。

- CPU - プロセッサが長時間100%で稼働しているか?

- メモリー/スワッピング - 使用可能なRAMメモリーを使い尽くし、スワップ・スペースの使用が発生しているか?

- ネットワーク - バッファ・サイズ、ダイアグラム・サイズ、およびMaximum Transmission Unit (MTU)サイズが、パフォーマンスおよび成功率に影響しているか?

オペレーティング・システムの全体のヘルス状態をモニターするには、Unix/Linuxではvmstatおよびtop、WindowsではperfmonおよびWindows Sysinternalsから使用可能なツール(たとえば、procexpやprocmonなど)を使用します。ネットワークのパフォーマンスのテスト方法の詳細は、『Oracle Coherenceの管理』を参照してください。

第II部

Coherenceクラスタの使用

第II部は次の章で構成されています。

- 第6章「Coherenceクラスタの概要」

- 第7章「クラスタの設定」

- 第8章「クラスタ・メンバーの起動および停止」

- 第9章「クラスタ・メンバーシップの動的な管理」

- 第10章「TCMPの動作のチューニング」

- 第11章「サービス・ガーディアンの使用」

6 Coherenceクラスタの概要

この章では、Coherenceクラスタと、クラスタ・メンバーがTangosol Cluster Management Protocol (TCMP)を使用して相互に通信する方法について説明します。クラスタ化されたサービスについても説明します。

この章には次の項が含まれます:

- クラスタの概要

- TCMPの理解

- クラスタ化されたサービスの理解

6.1 クラスタの概要

Coherenceクラスタは、Coherenceを実行するJVMプロセスのネットワークです。JVMは、自動的に結合されてクラスタを形成し、クラスタ・メンバーまたはクラスタ・ノードと呼ばれます。クラスタ・メンバーどうしは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。クラスタ・メンバーでは、マルチキャスト通信(ブロードキャスト)とユニキャスト通信(Point-to-Point通信)の両方でTCMPを使用します。

クラスタには、そのクラスタのすべてのメンバーで共有するサービスがあります。このサービスの例として、接続サービス(ルート・クラスタ・サービスなど)、キャッシュ・サービス(分散キャッシュ・サービス)、処理サービス(呼出しサービスなど)があります。各クラスタ・メンバーは、このようなサービスを提供でき、また利用できます。クラスタの最初のメンバーは上位メンバーと呼ばれ、多くの場合は、そのクラスタの作成に必要なコア・サービスを開始します。クラスタの上位メンバーがシャットダウンした場合は、他のいずれかのクラスタ・メンバーが上位メンバーの役割を引き受けることが前提となっています。

6.2 TCMPの理解

TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの伝送に使用する、IPベースのプロトコルです。TCMPは、次のものを使用するように構成できます。

- UDP/IPマルチキャストとUDP/IPユニキャストの組合せ: これはデフォルトの構成です。

- UDP/IPユニキャストのみ(マルチキャストなし): 「マルチキャスト通信の無効化」を参照してください。この構成は、マルチキャストをサポートしていないネットワーク環境やオプションによるマルチキャストが構成されていないネットワーク環境で使用します。

- TCP/IPのみ(UDP/IPマルチキャストもUDP/IPユニキャストもなし): 「TCPソケット・プロバイダの使用」を参照してください。この構成は、TCPを優先するネットワーク環境で使用します。

- SDP/IPのみ(UDP/IPマルチキャストもUDP/IPユニキャストもなし)。「SDPソケット・プロバイダの使用」を参照してください。この構成は、SDPを優先するネットワーク環境で使用します。

- TCP/IPまたはSDP/IPを介したSSL。「SSLソケット・プロバイダの使用」を参照してください。この構成は、高度なセキュリティで保護した通信をクラスタ・メンバー間で必要とするネットワーク環境で使用します。

マルチキャストの使用

マルチキャストは次のように使用します。

- クラスタの検出: マルチキャストを使用して、新しいメンバーが参加可能な状態で稼働しているクラスタがあるかどうかを検出します。

- クラスタ・ハートビート: マルチキャストを通じてクラスタの最も古いメンバーからハートビートが定期的に送信されます。その頻度は構成可能で、デフォルトでは1秒間に1回に設定されています。

- メッセージ配信: 複数のクラスタ・メンバーへの配信が必要なメッセージは、マルチキャストを通じて送信されることがよくあります。一方、ユニキャストを使用すると、メッセージは一度に1人のメンバーに送信されます。

ユニキャストの使用

ユニキャストは次のように使用します。

- 直接的なメンバー間(Point-to-Point)通信。メッセージ、非同期の肯定応答(ACK)、非同期の否定応答(NACK)およびPeer-to-Peerハートビートなどがあります。クラスタでの通信のほとんどはPoint-to-Pointです。

- 状況によっては、複数のメンバーを対象とするメッセージでも、ユニキャストを通じて送信されることがあります。これは、非常に大きなクラスタでトラフィック・フローを形成したりCPUの負荷を軽減するために実行されます。

- マルチキャスト通信が無効な場合、すべての通信はユニキャストを使用して送信されます。

TCPの使用

TCPは次のように使用します。

- TCP/IPリングを追加の停止検出メカニズムとして使用し、実際のノード障害と無応答ノードとを識別します(JVMがフルGCを実行する場合など)。

- データ転送にはTCPを排他的に使用するようにTCMPを構成できます。UDPの場合と同様、転送にユニキャストのみを使用するように構成できるほか、ユニキャストとマルチキャストの両方を使用するように構成することもできます。

プロトコルの信頼性

TCMPプロトコルは、あらゆるメッセージについて信頼性の高いインオーダー配信を実現します。基盤となるUDP/IPプロトコルでは信頼性のある配信やインオーダー配信ができないため、TCMPでは、キュー型の完全非同期ACKおよびNACKに基づいたメカニズムと、メッセージの確実な順序付けに不可欠な一意のIDを使用して信頼性のあるメッセージ配信を実現しています。

プロトコルのリソースの利用

TCMPプロトコル(デフォルトでの構成)には、クラスタ・サイズに関係なく、JVMごとに3つのUDP/IPソケット(マルチキャスト用に1つとユニキャスト用に2つ)および6つのスレッドのみが必要です。これはCoherenceのスケーラビリティで重要な要素です。これにより、サーバー数に関係なく、クラスタの各ノードで追加のネットワーク接続を必要とせずに、Point-to-Pointによるクラスタ・メンバーとの通信、または一群のクラスタ・メンバーとの通信が可能になります。

オプションのTCP/IPリングでは、いくつかのTCP/IPソケットおよび1つのスレッドを追加で使用します。

プロトコルのチューニング性

TCMPプロトコルは非常にチューニング性が高いため、特定のネットワーク・トポロジの利用や、地理的に分散したクラスタにある低帯域幅で長待機時間のセグメントに対する許容差の追加が可能です。Coherenceには出荷時の初期設定の構成があります。TCMP属性の中には、実行時に動的に自己構成できるものがありますが、デプロイ目的でそれらをオーバーライドすることやロックダウンすることも可能です。

6.3 クラスタ化されたサービスの理解

Coherenceの機能はサービスの概念に基づいています。各クラスタ・メンバーは、サービスを登録、提供および利用できます。クラスタ・メンバーでは、複数のサービスを実行できます。クラスタ・メンバーは常に単一のルート・クラスタ・サービスを含み、任意の数のグリッド・サービスも含むことができます。グリッド・サービスには、クラスタ内でそのサービスを一意に識別するサービス名と、サービスの機能を定義するサービス・タイプが設定されています。各サービス・タイプ(ルート・クラスタ・サービスを除く)には、複数のインスタンスが存在する場合もあります。

サービスは、機能に基づいて次のカテゴリに分類されます。カテゴリは明確化のために使用されているもので、実際のコンポーネントやサービス間の関係を示すものではありません。

接続サービス

- クラスタ・サービス: クラスタ・ノードがクラスタに参加する必要がある場合に自動的に起動され、多くの場合ルート・クラスタ・サービスと呼ばれます。各クラスタ・ノードでは、常にこのタイプのサービスが1つのみ実行されます。このサービスの役割は、他のクラスタ・ノードの検出、クラスタ・ノードの障害の検出およびクラスタ内の他のサービスの可用性の登録です。

- プロキシ・サービス: このサービスを使用すると、クラスタの外部で稼動しているクライアントからの接続(TCPを使用)が可能になります。多くのアプリケーションは、すべてのクライアントがクラスタ・メンバーでもあるように構成しますが、クラスタ外部でクライアントを実行することが望ましい場合も少なくありません。数百から数千のクライアント・プロセスが存在する場合、クライアントがJavaプラットフォーム上で稼働していない場合、またはきわめて高度な分離が必要な場合には、リモート・クライアントが特に便利です。

処理サービス

- 起動サービス: このサービスはクラスタ化された起動を提供し、グリッド・コンピューティング・アーキテクチャをサポートします。このサービスを使用すると、クライアントにある任意のノード、ノードの任意のグループ、またはクラスタ全体に対してアプリケーションからエージェントを起動できます。エージェントの起動には、リクエスト/レスポンス方式、fire and forget方式、または非同期のユーザー定義可能な方式を使用できます。

データ・サービス

- 分散型キャッシュ・サービス: このサービスを使用すると、クラスタ・ノードからクラスタ間にデータを分散(パーティション化)できます。これにより、キャッシュにある各データは、1つのクラスタ・ノードでのみ管理(保持)されます。分散キャッシュ・サービスは、ペシミスティック・ロックをサポートしています。また、データ損失のないフェイルオーバーをサポートするために、各データが1つ以上の他のクラスタ・ノードにバックアップされるように、このサービスを構成することも可能です。さらには、一部のクラスタ・ノードのみデータをまったく保持しないように構成することもできます。これは、分散データを保持しないようにアプリケーション・サーバー・プロセスを設定し、追加のキャッシュ・サーバーJVMを実行して分散キャッシュ記憶域を提供することで、アプリケーション・サーバー・プロセスのJavaヒープ・サイズを制限する場合などに有用です。分散キャッシュの詳細は、「分散キャッシュの理解」を参照してください。

- レプリケート・キャッシュ・サービス: このサービスを実行するすべてのクラスタ・ノードにサービス自身のすべてのデータを完全にレプリケートする、同期化されたレプリケート・キャッシュ・サービスです。レプリケート・キャッシュでは、ペシミスティック・ロックをサポートして、データに変更が発生した場合はすべてのクラスタ・メンバーが更新を受け取れるようにしています。レプリケート・キャッシュは、一般には内部アプリケーション・メタデータの管理に使用します。レプリケート・キャッシュの詳細は、「レプリケート・キャッシュの理解」を参照してください。

- オプティミスティック・キャッシュ・サービス: これは、レプリケート・キャッシュ・サービスのオプティミスティック並行処理バージョンです。サービス自身のすべてのデータをすべてのクラスタ・ノードに完全にレプリケートし、一貫性を維持するためにオプティミスティック・データベース・ロックと同様の最適化を採用しています。同一時刻に様々なサーバーから複数の更新が実行されても、最終的にはすべてのサーバーが同じ現在値になります。オプティミスティック・キャッシュ・サービスはペシミスティック・ロックをサポートしていないため、通常は、最後に認識した値を読取り専用の目的でキャッシュする場合にのみ使用することをお薦めします。このサービスが使用されることはめったにありません。オプティミスティック・キャッシュの詳細は、「オプティミスティック・キャッシュの理解」を参照してください。

クラスタ化サービスは通常1つのデーモン・スレッドを使用しますが、さらに大きな処理帯域幅をサービスに提供するように構成できるスレッド・プールをオプションで用意しています。たとえば、起動サービスと分散キャッシュ・サービスはどちらもスレッド・プーリングを完全にサポートすることで、データベースのロード処理、パラレル分散問合せ、およびエージェントの起動を加速化します。

前述のサービスは、クラスタ・サービスの基本にすぎず、Coherenceが提供するキャッシュ・タイプのすべてではありません。Coherenceは、クラスタ化サービスをバッキング・マップやオーバーフロー・マップなどのキャッシュ機能と組み合せることにより、きわめて柔軟性が高く、構成可能なオプション・セットをクラスタ化アプリケーションに提供します。

キャッシュ・サービス内には、任意の数の名前付きキャッシュが存在します。名前付きキャッシュは標準のJCache APIを提供します。このAPIは、キーと値のペアを保持するjava.util.MapというJavaコレクションAPIをベースとしています。

7 クラスタの設定

この章では、Coherenceクラスタのセットアップおよび構成方法と、デフォルトの即時利用可能なクラスタ設定を変更する方法について説明します。

この章には次の項が含まれます:

- クラスタの設定の概要

- クラスタの名前の指定

- クラスタ・メンバーの識別情報の指定

- マルチキャスト通信の構成

- クラスタ・メンバーのユニキャスト・アドレスの指定

- Well Knownアドレスの使用

- 単一サーバー・モードの有効化

- 停止検出の構成

- クラスタの優先度の指定

7.1 クラスタの設定の概要

Coherenceには、デフォルトで、デモの目的で即時利用できるクラスタ構成が用意されています。これを使用すると、クラスタを容易に作成でき、ほとんどの場合、構成を変更する必要はなく、あるとしてもわずかです。一方、デモを目的としていない場合は、デフォルトの設定を使用しないことをお薦めします。その場合は、クラスタを実行するネットワーク環境とクラスタを使用するアプリケーションの要件に基づいて、独自のクラスタを設定します。ユニットのテストおよび基本的な開発で使用するのであれば、単一サーバー・モードで動作するクラスタを構成してもかまいません。

クラスタの設定では、少なくともクラスタの名前およびクラスタのマルチキャスト・アドレスを定義する必要があります。マルチキャストが望ましくない環境や使用できない環境では、Well Knownアドレス(WKA)機能の設定が必要になります。以降のこの章で説明するタスクは、クラスタを設定する場合に使用するものであり、デフォルトの設定を変更する必要がある場合には、このすべてのタスクを実行する必要があります。

クラスタは、オペレーション・オーバーライド・ファイル(tangosol-coherence-override.xml)の中で設定します。各クラスタ・メンバーはオーバーライド・ファイルを使用して、オペレーション・デプロイメント・ディスクリプタで定義されているデフォルトの構成をオーバーライドする固有の値を指定します。オペレーション・オーバーライド・ファイルの使用方法の詳細は、「オペレーション構成ファイルの指定」を参照してください。また、この章で取り上げているすべてのオペレーション要素の説明と使用方法は、付録A「オペレーション構成要素」を参照してください。

7.2 クラスタの名前の指定

クラスタ名は、ネットワークの中で各クラスタを一意に識別するユーザー定義の名前です。複数のクラスタ・メンバーが参加してクラスタを構成するには、同じクラスタ名を指定する必要があります。既存のクラスタにクラスタ・メンバーとして参加するときに、誤ったクラスタ名を指定すると、そのクラスタ・メンバーは起動できません。同じネットワークに複数の異なるクラスタを作成するには、一意のマルチキャスト・ポートを使用して、一意のクラスタ名を使用することが普通です。

注意:
クラスタ名を明示的に指定していない場合、クラスタ・メンバーではシステムで生成されたクラスタ名が使用されます。システム生成の名前(および即時利用可能なマルチキャストのデフォルト設定)を使用すると、ネットワーク上でクラスタ構成が重複する可能性が高くなります。その結果、予期しないクラスタにクラスタ・メンバーが誤って参加することがあります。

クラスタ名を指定するには、オペレーション・オーバーライド・ファイルを編集して、クラスタ名を記述した<cluster-name>要素を<member-identity>要素に追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name system-property="tangosol.coherence.cluster">MyCluster
</cluster-name>
</member-identity>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.clusterシステム・プロパティを使用してクラスタ名を指定できます。例:

-Dtangosol.coherence.cluster=name

7.3 クラスタ・メンバーの識別情報の指定

クラスタの中でクラスタ・メンバーに識別情報を指定するには、一連の識別子を使用します。この識別情報を使用して、クラスタの中でクラスタ・メンバーを区別し、メンバーのロールを扱います。クラスタのタスクを実行するときにクラスタ・サービスで使用する識別子もあります。最後に、この識別情報は管理情報(JMXなど)を表示する際に便利であり、識別情報を使用することでログのエントリの解釈も容易になります。次に各識別子を示します。

- サイト名 - クラスタ・メンバーをホストする地理的なサイトの名前。名前の指定がない場合は、サーバーのドメイン名が使用されます。WANによるクラスタリングでは、メンバーが配置されるデータセンターをこの値で特定します。サイト名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(地理的に別のサイトにあるデータの明示的なバックアップ)の基盤として使用できます。サイト名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

- ラック名 - メンバーがホストされている地理的サイト内の場所の名前。多くの場合、ケージ、ラックまたはブレードフレームの識別子です。ラック名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(別のブレードフレームにあるデータの明示的なバックアップ)の基盤として使用できます。ラック名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

- マシン名 - クラスタ・メンバーをホストするサーバーの名前。名前の指定がない場合は、サーバーのホスト名が使用されます。この名前は、IDを作成する際の基礎として使用されます。クラスタ・サービスでは、データが別のコンピュータにバックアップされていることをこのIDを使用して確認し、単一障害点の発生を防止します。

- プロセス名 - クラスタ・メンバーをホストするJVMプロセスの名前。名前の指定がない場合は、JVMプロセス番号が使用されます。プロセス名を使用すると、同じコンピュータで稼動している複数のJVMを容易に区別できます。

- メンバー名 - クラスタ・メンバーの一意な名前。この名前を使用すると、特に同じコンピュータや同じJVMで稼動している複数のクラスタ・メンバーを容易に区別できます。メンバー名の指定が必要ない場合でも、(ベスト・プラクティスとして)必ずメンバー名を指定することをお薦めします。

- ロール名 - クラスタでクラスタ・メンバーが持っているロール。ロール名を使用すると、クラスタ・メンバーをキャッシュ・サーバーやキャッシュ・クライアントなどの専門のロールにアプリケーションで整理できます。名前の指定がない場合は、デフォルトのロール名(キャッシュ・サーバーの場合はCoherenceServer、キャッシュ・クライアントの場合はapplication_class_name)が使用されます。

メンバーの識別情報を指定するには、オペレーション・オーバーライド・ファイルを編集して、次に示すように<member-identity>要素にメンバーの識別情報要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<site-name system-property="tangosol.coherence.site">pa-1</site-name>
<rack-name system-property="tangosol.coherence.rack">100A</rack-name>
<machine-name system-property="tangosol.coherence.machine">prod001
</machine-name>
<process-name system-property="tangosol.coherence.process">JVM1
</process-name>
<member-name system-property="tangosol.coherence.member">C1</member-name>
<role-name system-property="tangosol.coherence.role">Server</role-name>
</member-identity>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、次のシステム・プロパティを使用してクラスタ・メンバーの識別情報を指定できます。

-Dtangosol.coherence.site=pa-1 -Dtangosol.coherence.rack=100A  -Dtangosol.coherence.machine=prod001 -Dtangosol.coherence.process=JVM1
-Dtangosol.coherence.member=C1 -Dtangosol.coherence.role=Server

7.4 マルチキャスト通信の構成

クラスタ・メンバーは、他のクラスタ・メンバーを検出するときおよびクラスタに属する複数のメンバーにメッセージを伝達するときにマルチキャスト通信を使用します。マルチキャスト・ストームなどが発生しないように、マルチキャストはクラスタのプロトコルによってきわめて慎重に使用されます。デフォルトでは、全クラスタ・メンバーの25%を超えるメンバーにデータを転送する場合にのみ、マルチキャストが使用されます。マルチキャストが有効になっていても、トラフィックの大半はユニキャストを使用して転送されます。一般的なパーティション化したキャッシュを基本とするクラスタでは、ほとんどの転送はPoint-to-Pointであり、クラスタのメンバーシップとパーティションの所有権のみがクラスタ全体にブロードキャストされます。

マルチキャスト通信は、<multicast-listener>ノードのオペレーション・オーバーライド・ファイルの中で構成します。クラスタ・メンバーを起動するときにマルチキャスト通信を構成するためのシステム・プロパティも多数用意されています。

この項には次のトピックが含まれます:

- クラスタのマルチキャスト・アドレスの指定

- マルチキャスト通信の無効化

- マルチキャストの有効時間の指定

- マルチキャストの参加タイムアウトの指定

- マルチキャストのしきい値の変更

7.4.1 クラスタのマルチキャスト・アドレスの指定

クラスタ・メンバーにはマルチキャスト・アドレス(IPアドレスとポート)を指定できます。複数のクラスタ・メンバーが参加してクラスタを構成するには、それぞれが同じマルチキャスト・アドレスを使用する必要があります。マルチキャスト・アドレスを明示的に指定していない場合、クラスタ・メンバーではデフォルトのマルチキャスト・アドレスが使用されます。このデフォルト値はリリース・バージョンによって異なり、アドレスは{build}.{major version}.{minor version}.{patch}、ポートは{major version}.{minor version}.{patch}という表記規則にそれぞれ従います。

注意:
デフォルトのマルチキャスト・アドレス(およびシステムで生成されたクラスタ名)を使用すると、ネットワーク上でクラスタ構成が重複する可能性が高くなります。その結果、予期しないクラスタにクラスタ・メンバーが誤って参加することがあります。

同じネットワーク上で互いに独立している複数のクラスタは、必ずそれぞれ一意のマルチキャスト・アドレスを使用する必要があります。技術的に言うと、互いに独立しているクラスタは同じIPアドレスまたは同じポートを共有することも可能です。ただし、IPアドレスまたはポートを共有すると、不要なネットワーク・トラフィックの増加につながる可能性があります。余分なネットワーク・トラフィックはパフォーマンスに影響し、ネットワーク・カードが過負荷となる可能性があります。そのため、推奨のベスト・プラクティスは各クラスタでIPアドレスおよびポートの両方を一意にすることです。

注意:
Linuxのいくつかのバージョンでは、同じネットワーク上の互いに独立しているクラスタはIPアドレスおよびポートの両方を一意にする必要があります。

クラスタのマルチキャスト・アドレスを指定するには、オペレーション・オーバーライド・ファイルを編集して<address>要素と<port>要素の両方を追加し、クラスタ・メンバーが使用するアドレスとポートを指定します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<address system-property="tangosol.coherence.clusteraddress">224.3.6.0
</address>
<port system-property="tangosol.coherence.clusterport">3059</port>
</multicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるtangosol.coherence.clusteraddressとtangosol.coherence.clusterportを使用してクラスタのマルチキャスト・アドレスを指定できます。例:

-Dtangosol.coherence.clusteraddress=224.3.6.0 -Dtangosol.coherence.clusterport=3059

7.4.1.1 マルチキャスト・ソケット・インタフェースの変更

マルチキャスト・ソケットは、ユニキャスト・リスナーと同じIPアドレスのネットワーク・インタフェース(NIC)にバインドされます。これと異なるNICをマルチキャストに構成することはできますが、クラスタの部分的な障害を引き起こす可能性があることから、ごくわずかな例外を除いてお薦めできません。

NICが2つある場合、マルチキャスト・トラフィックに使用するインタフェース(およびそれに伴うネットワーク)は、ユニキャスト(UDP/IP)トラフィックとTCPリング(TCP/IP)トラフィックに使用するインタフェース(およびそれに伴うネットワーク)とは別になります。このシナリオでは、一方のインタフェース(ネットワーク)に障害が発生しても、もう一方のインタフェースでは通信を正常に継続しているので、障害検出とフェイルオーバーが機能しません。クラスタリング・プロトコルではメンバー(およびそれに付随するインタフェース)の障害を扱うので、障害が発生したメンバーを迅速に検出してクラスタリングから除外できるように、すべての通信が障害状態になるようにする方が有利です。

デフォルトのマルチキャスト・ネットワーク・インタフェースを変更するには、オペレーション・オーバーライド・ファイルを編集して、マルチキャスト・ソケットのバインド先とするIPアドレスを指定した<interface>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<interface>192.168.0.1</interface>
</multicast-listener>
</cluster-config>
</coherence>

7.4.2 マルチキャスト通信の無効化

ネットワーク環境によっては、マルチキャスト・トラフィックが望ましくない場合や許可されない場合があり得ます。その場合はWell Knownアドレス機能を使用して、Coherenceでマルチキャストが使用されないようにします。これによってマルチキャスト検出が無効になり、同時にすべてのデータ転送に対してマルチキャストが無効になります。かわりにユニキャスト(Point-to-Point)が使用されます。Coherenceは可能なかぎりPoint-to-Point通信を使用するように設計されているため、大半のアプリケーション・プロファイルでは、パフォーマンスに対する実質的な影響はありません。「Well Knownアドレスの使用」を参照してください。

注意:
マルチキャストを無効にすると、ネットワークに対する負荷が大きくなります。しかし、これが問題になるのは、メンバー数が100を超える大規模なクラスタのみです。

7.4.3 マルチキャストの有効時間の指定

有効時間(TTL)値の設定は、ネットワーク上でマルチキャストのUDP/IPパケットを伝送できる最大距離を指定するものです。TTLは、パケットが存続するホップ数で表されます。各ネットワーク・インタフェース、ルーターおよびマネージド・スイッチが1ホップと見なされます。

TTL値には、機能するうえで必要な最小の整数値を指定します。過剰に大きい値を設定すると、他のLANセグメントに不必要に大きい帯域幅が使用される可能性があり、オペレーティング・システムやネットワーク・デバイスでマルチキャスト・トラフィックが無効になることさえあります。一般的に、シンプルなスイッチ構成のバックボーンでは、TTL値を1に設定すれば問題ありません。インテリジェントなスイッチを備えた高度なバックボーンでは、2以上の値が必要になることがあります。値0は、開発やテストに使用するシングル・サーバー・クラスタで使用します。シングル・サーバー・クラスタの詳細は、「単一サーバー・モードの有効化」を参照してください。

TTLを指定するには、オペレーション・オーバーライド・ファイルを編集して、TTL値を指定した<time-to-live>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<time-to-live system-property="tangosol.coherence.ttl">3</time-to-live>
</multicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.ttlシステム・プロパティを使用してTTL値を指定できます。例:

-Dtangosol.coherence.ttl=3

7.4.4 マルチキャストの参加タイムアウトの指定

マルチキャストの参加タイムアウトは、クラスタへの参加をクラスタ・メンバーが待機する時間を定義します。このタイムアウトが経過しても既存のクラスタが検出されない場合、そのクラスタ・メンバーは独自にクラスタを起動し、自身がそのクラスタの上位クラスタ・メンバーになります。開発やテストでは、短いタイムアウトを指定してもかまいません。本番環境では一般的に30秒のタイムアウトで十分です。

注意:
クラスタの最初のメンバーは、参加タイムアウトの全期間を待機してから、上位メンバーのロールが必要であると見なします。クラスタの起動タイムアウトが参加タイムアウトよりも短いと、クラスタが起動している間にそのクラスタの最初のメンバーは動作を停止します。クラスタ・メンバーのタイムアウトは、パケット・パブリッシャのタイムアウトを使用して指定します(<timeout-milliseconds>)。「packet-delivery」を参照してください。

参加タイムアウトを指定するには、オペレーション・オーバーライド・ファイルを編集して、タイムアウト値を指定した<join-timeout-milliseconds>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds>6000</join-timeout-milliseconds>
</multicast-listener>
</cluster-config>
</coherence>

注意:
<join-timeout-milliseconds>の設定は、マルチキャスト通信およびユニキャスト通信の両方で使用されます。

7.4.5 マルチキャストのしきい値の変更

クラスタ・メンバーは、クラスタのパケットの送信でマルチキャスト通信とユニキャスト通信の両方を使用します。マルチキャストのしきい値を使用して、パケットの配信にマルチキャストを使用するかユニキャストを使用するかを判断します。このしきい値に大きい値または小さい値を設定することで、クラスタではどちらか一方の通信スタイルが頻繁に使用されるようになります。マルチキャスト通信を無効にすると、このしきい値設定は使用されません。

マルチキャストのしきい値は、1 - 100%の範囲の比率で指定します。n個のメンバーで構成するクラスタでは、d個(範囲は0 - n-1)のノードにパケットを送信するクラスタ・メンバー(dにこのクラスタ自身は算入しません)は、次の条件が成立する場合にのみ、マルチキャストを使用してパケットを送信します。

- ネットワークを介して複数のノード(d > 1)にパケットを送信する。

- そのノードの数が、指定のしきい値よりも大きい(d > (n-1) * (しきい値/100))。
たとえば、マルチキャストのしきい値が25%でメンバーが25個のクラスタの場合、そのクラスタ・メンバーではパケットの送信先メンバーが6個以上の場合にのみ、マルチキャストを使用します(24 * .25 = 6)。

この値を1に設定すると、クラスタでは基本的にすべてのマルチポイントトラフィックにマルチキャストを使用できます。この値を100に設定すると、クラスタでは、明示的なブロードキャスト・トラフィック(クラスタのハートビートやクラスタの検出など)を除いてすべてのマルチポイント・トラフィックにユニキャストが使用されます。これは、100%のしきい値を超過することはあり得ないからです。25 (デフォルト値)に設定すると、パケットの送信先が全ノードの1/4未満であれば、クラスタ・メンバーは送信にユニキャストを使用します。パケットの送信先が全ノードの1/4以上であれば、マルチキャストを使用して送信します。

マルチキャストのしきい値を指定するには、オペレーション・オーバーライド・ファイルを編集して、しきい値を指定した<multicast-threshold-percent>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<multicast-listener>
<multicast-threshold-percent>40</multicast-threshold-percent>
</multicast-listener>
</cluster-config>
</coherence>

7.5 クラスタ・メンバーのユニキャスト・アドレスの指定

クラスタ・メンバーは、クラスタでの通信の大半を占めるメンバー間(Point-to-Point)の直接通信ではユニキャストを使用します。デフォルトのユニキャスト・アドレス(IPアドレスとポート)が使用されますが、必要に応じて<unicast-listener>要素で明示的なアドレスを指定することもできます。マルチキャスト・ソケットは、ユニキャスト・アドレスで定義したものと同じインタフェースにバインドします。「マルチキャスト・ソケット・インタフェースの変更」を参照してください。

ユニキャスト・リスナーは、次のように構成されます。

- <address> - クラスタ・メンバーは、java.net.InetAddress.getLocalHost()のコールを使用してバインド先のIPアドレスを取得しようとします。localhostをループバック・アドレスとして定義しているシステムではlocalhostの使用が機能しないことがあります。その場合は、コンピュータ名または固有のIPアドレスを指定する必要があります。コンピュータに複数のIPまたはNICがある場合も、アドレスを明示的に指定する必要があります。
<address>要素では、Classless Inter-Domain Routing (CIDR)注釈がサポートされています。これは、正確なIPアドレスを指定するかわりに、バインドするローカルIPアドレスにサブネットおよびマスク・パターンを使用します。CIDRでは、同じサブネット上の複数のコンピュータで1つのアドレス構成を共有できるため、構成が単純になります。各クラスタ・メンバーは同じCIDRアドレス・ブロックを指定し、アドレス・パターンに一致する各コンピュータ上のローカルNICが自動的に検出されます。たとえば、同じネットワーク上に配置されており、それらの192.168.1.*アドレス上でクラスタを実行する複数のマルチNICコンピュータのユニキャスト・アドレスを指定するには、192.168.1.0/24などのアドレスを指定します。すると、各ノードが、そのパターンに一致するローカルNICを検出します。/24接頭辞サイズは、192.168.1.0から192.168.1.255までの最大256個の使用可能アドレスに一致します。

- <port> - クラスタ・メンバーは2つのユニキャストUDPポートを使用します。デフォルトの動作では、1番目のポート(port1)としてポート8088の使用を試みます。ポート8088が使用できない場合は、自動ポート調整を使用して、次に使用可能なポートを選択します。2番目のポート(port2)が自動的に開き、デフォルトでport1の次に使用可能なポート(使用可能であれば、port1 + 1)として設定されます。自動ポート調整は無効化できます。この場合は、port1が使用可能であることが必要で、2番目のポートは必ずport1 + 1になります。
2つのUDPポートを使用する理由は次のとおりです。

- インバウンド・トラフィックとアウトバウンド・トラフィック間の競合を削減し、両方での大量の転送を回避して、同じポートで受信する。

- コヒーレンスなメンバー間では、オペレーティング・システムのMTU (Maximum Transmission Unit)に基づく最適なパケット・サイズでの通信が可能になる。サイズが大きなパケットに一方のUDPを使用し、サイズがネットワークのMTU以下であるパケットにはもう一方のポートを使用します。この分離によって、サイズに基づいて別個のパケット・バッファを使用できます。

- ソケット・バッファの表面的なサイズを増やさずに、メンバー数が500を超える大規模なクラスタを実行できる。

クラスタ・メンバーのユニキャスト・アドレスを指定するには、オペレーション・オーバーライド・ファイルを編集して、<address>要素と<port>要素の両方(さらに、必要に応じて<port-auto-adjust>要素)を追加し、クラスタ・メンバーが使用するアドレスとポートを指定します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<address system-property="tangosol.coherence.localhost">192.168.0.1
</address>
<port system-property="tangosol.coherence.localport">8090</port>
<port-auto-adjust system-property="tangosol.coherence.localport.adjust">
true
</port-auto-adjust>
</unicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.localhost、tangosol.coherence.localportおよびtangosol.coherence.localport.adjustの各システム・プロパティを使用してユニキャスト・アドレスを指定できます。例:

-Dtangosol.coherence.localhost=192.168.0.1 -Dtangosol.coherence.localport=8090 -Dtangosol.coherence.localport.adjust=true

7.6 Well Knownアドレスの使用

Well Knownアドレス(WKA)機能は、クラスタ・メンバーがマルチキャストのかわりにユニキャストを使用してクラスタを検出し、それに参加できるようにするメカニズムです。マルチキャスト・ネットワーキングが望ましくないか使用できない環境やマルチキャストを適切にサポートするように構成されていない環境でWKAを使用することが普通です。WKAを有効にすると、すべてのクラスタでマルチキャスト通信が無効になります。

クラスタを起動できる少数のクラスタ・メンバー(これをWKAメンバーといいます)を指定することでWKAが有効になります。WKAメンバーの最適な数はクラスタのサイズで異なります。一般的には、WKAメンバーの数はクラスタの10%程度にします。スイッチごとのWKAメンバーを1つか2つにすることをお薦めします。

各WKAメンバーは、クラスタの稼動中は利用可能な状態を維持している必要がありますが、どの時点でも同時にアクティブになっている必要はありません。クラスタ・メンバーがクラスタを検出してそこに参加するためには、WKAメンバーが1つのみ稼動可能になっている必要があります。さらに、クラスタに参加したクラスタ・メンバーは、すべてのクラスタ・メンバーのアドレスの通知を受け、各クラスタ・メンバーに個別にメッセージを送信することでブロードキャストを実行します。これにより、すべてのWKAメンバーが動作を停止しても、クラスタは稼動できます。ただし、このクラスタに新しいクラスタ・メンバーは参加できません。参加できるためには、そのクラスタ・メンバー自身がWKAメンバーになるか、いずれかのWKAメンバーが起動する必要があります。この場合は、クラスタの最上位メンバーがWKAメンバーのリストをポーリングし、そのWKAメンバーが既存のクラスタに再度参加できるようにします。

WKAメンバーを指定する方法は2つあります。まず、アドレスのリストを明示的に定義する方法があります。もう1つは、アドレス・プロバイダの実装を使用してWKAアドレスのリストを取得する方法です。どちらの方法も、オペレーション・オーバーライド・ファイルの中で<unicast-listener>要素の<well-known-addresses>サブ要素で構成します。

この項には次のトピックが含まれます:

- WKAメンバーのアドレスの指定

- WKAアドレス・プロバイダの指定

7.6.1 WKAメンバーのアドレスの指定

<socket-address>要素の中でWKAメンバーを明示的に指定します。任意の数の<socket-address>要素を定義できますが、それぞれの要素では、<address>要素と<port>要素を使用してWKAメンバーのアドレスとポートの両方を定義する必要があります。独自のアドレスを指定したクラスタ・メンバーがあれば、そのクラスタ・メンバーは起動時にWKAメンバーになります。様々なクラスタ・メンバーが他のクラスタ・メンバーとは無関係に稼動することがないように、すべてのクラスタ・メンバーに対してWKAメンバーのリストは同一であることが必要です。次の例では2つのWKAメンバーを指定しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<well-known-addresses>
<socket-address id="1">
<address>192.168.0.100</address>
<port>8088</port>
</socket-address>
<socket-address id="2">
<address>192.168.0.101</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

注意:
WKAメンバーを設定する際は、そのポート値と、そのメンバーのユニキャスト・リスナー・ポートに対して指定したポート値とが一致している必要があります。ユニキャスト・ポートの設定の詳細は、「クラスタ・メンバーのユニキャスト・アドレスの指定」を参照してください。

WKAシステム・プロパティの使用

オペレーション・オーバーライド・ファイルでアドレスを指定するかわりに、システム・プロパティであるtangosol.coherence.wkaとtangosol.coherence.wka.portを使用して単独のWKAメンバーを指定できます。これらのシステム・プロパティは、デモやテストのシナリオで単独のWKAメンバーを簡単に指定できるようにすることを目的としたものです。例:

-Dtangosol.coherence.wka=192.168.0.100 -Dtangosol.coherence.wka.port=8088

複数のWKAメンバーのアドレスを指定するシステム・プロパティを別途作成するには、オペレーション・オーバーライド・ファイルを使用して複数のWKAメンバーのアドレスを定義し、WKAメンバーのアドレス要素ごとにsystem-property属性を定義する必要があります。この属性には、目的の要素をオーバーライドするために使用するシステム・プロパティ名を指定する必要があります。次の例では、システム・プロパティを指定した2つのアドレスを定義しています。

注意:
WKAメンバーのリストを指定する追加のシステム・プロパティは、テストの際または管理された本番環境で定義できます。ただし、ベスト・プラクティスは、オペレーション・オーバーライド・ファイルを重点的に使用して本番環境でWKAメンバーを指定することです。これにより、すべてのクラスタ・メンバーに対して同じWKAメンバーのリストが存在するようになります。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<well-known-addresses>
<socket-address id="1">
<address system-property="tangosol.coherence.wka"></address>
<port system-property="tangosol.coherence.wka.port"></port>
</socket-address>
<socket-address id="2">
<address system-property="tangosol.coherence.wka2"></address>
<port system-property="tangosol.coherence.wka2.port"></port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

前述の例では、次のようにシステム・プロパティを使用してWKAメンバーのアドレスを指定しています。

-Dtangosol.coherence.wka=192.168.0.102 -Dtangosol.coherence.wka.port=8090 -Dtangosol.coherence.wka2=192.168.0.103 -Dtangosol.coherence.wka2.port=8094

システム・プロパティの定義の詳細は、「カスタム・システム・プロパティの作成」を参照してください。

7.6.2WKAアドレス・プロバイダの指定

WKAアドレス・プロバイダは、プログラムでWKAメンバーを定義する方法を実現します。WKAアドレス・プロバイダはcom.tangosol.net.AddressProviderインタフェースを実装する必要があります。静的リストのような簡素な実装から、動的な検出プロトコルを使用するような複雑な実装まで可能です。このアドレス・プロバイダは、存在するすべてのアドレスを返したことを示す終端NULLアドレスを返す必要があります。クラスタ・メンバーが起動するときに、このアドレス・プロバイダ実装がコールされます。

注意:
返された例外や処理されない例外によって遅延が発生すると、検出の遅延の原因となり、その結果、メンバーに対するクラスタ・サービスが全面的にシャットダウンすることがあります。したがって、実装では細心の注意が必要です。負荷の大きい操作(ネットワーク・フェッチなど)が関わる実装では、com.tangosol.net.RefreshableAddressProviderクラスを拡張することによって、そのような操作を非同期で処理できます。

WKAアドレス・プロバイダの実装を使用するには、<address-provider>要素を追加し、<class-name>要素の中で実装クラスの完全修飾名を指定します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<well-known-addresses>
<address-provider>
<class-name>package.MyAddressProvider</class-name>
</address-provider>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

<address-provider>要素で<class-factory-name>要素および<method-name>要素を使用することもできます。前者の要素は、AddressProviderインスタンスを作成するためのファクトリ・クラスを指定します。後者の要素は、オブジェクトをインスタンス化するファクトリ・クラスに対して静的ファクトリ・メソッドを指定します。次の例では、MyAddressProviderFactoryクラスでgetAddressProviderメソッドを使用してアドレス・プロバイダのインスタンスを取得します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<well-known-addresses>
<address-provider>
<class-factory-name>package.MyAddressProviderFactory
</class-factory-name>
<method-name>getAddressProvider</method-name>
</address-provider>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

クラスやクラス・ファクトリの実装に必要な初期化パラメータはすべて、<init-params>要素を指定して指定できます。初期化パラメータには、一致するシグネチャを持つパブリック・コンストラクタが含まれる実装によってアクセスできます。次の例では、iMaxTimeパラメータが2000に設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<well-known-addresses>
<address-provider>
<class-name>package.MyAddressProvider</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</address-provider>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

7.7 単一サーバー・モードの有効化

単一サーバー・モードは、1台のコンピュータ上でのみ実行するように制限され、ネットワークにはアクセスしないクラスタです。単一サーバー・モードは開発やユニット・テストでクラスタを容易に起動および停止できます。

単一サーバー・モードを有効にするには、オペレーション・オーバーライド・ファイルを編集して、0に設定した<time-to-live>要素と、ループバックにルーティングするアドレスに設定したユニキャスト<address>要素を追加します。ほとんどのコンピュータでは、このアドレスを127.0.0.1に設定すれば問題ありません。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<address system-property="tangosol.coherence.localhost">127.0.0.1
</address>
</unicast-listener>
<multicast-listener>
<time-to-live system-property="tangosol.coherence.ttl">0</time-to-live>
</multicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、システム・プロパティであるtangosol.coherence.ttlとtangosol.coherence.localhostを使用して単一サーバー・モードを有効化できます。例:

-Dtangosol.coherence.ttl=0 -Dtangosol.coherence.localhost=127.0.0.1

UNIXオペレーティング・システムのいくつか(一部のバージョンのLinuxを含む)およびMac OS Xでは、TTLをゼロに設定するのみではクラスタを単独のコンピュータとして完全には分離できません。このような場合は、一意なクラスタ名も構成する必要があります。既存のクラスタ名と異なるクラスタ名を使用しているクラスタ・メンバーは、その既存のクラスタには参加できません。クラスタ名の構成の詳細は、「クラスタの名前の指定」を参照してください。

最後に、Mac OS XおよびLinuxのいくつかのバージョンでは、localhostのループバック・ルートが構成されておらず、クラスタの起動に失敗します。そのようなシナリオでは、WKA機能を使用して、クラスタ・メンバーの検出を確保します。例:

-Dtangosol.coherence.localhost=127.0.0.1 -Dtangosol.coherence.ttl=0
-Dtangosol.coherence.wka=127.0.0.1

WKAの構成の詳細は、「Well Knownアドレスの使用」を参照してください。

7.8 停止検出の構成

停止検出は、クラスタ・メンバーに発生した障害を迅速に検出するためのクラスタ・メカニズムです。障害が発生したクラスタ・メンバーはクラスタから除外され、他のすべてのクラスタ・メンバーには離脱したメンバーについての通知が送信されます。検出停止を使用することで、実際に障害が発生したメンバーと応答しなくなっているメンバーとを区別できます。たとえば、JVMが完全なガベージ・コレクションを実行しているときは、メンバーが応答しなくなります。

停止検出は、プロセス障害(TcpRingコンポーネント)とハードウェア障害(IpMonitorコンポーネント)の両方を特定します。プロセス障害は、クラスタUDP通信に使用されるものと同じポートで開いているTCP接続のリングを使用して検出されます。各クラスタ・メンバーはユニキャストのハートビートを発行し、最も上位のクラスタ・メンバーは、ブロードキャスト・メッセージとなるクラスタ・ハートビートを発行します。ハードウェア障害は、トレースICMP Pingまたは疑似Pingを発行してTCPポート7を使用するJava InetAddress.isReachableメソッドを使用して検出します。停止検出はデフォルトで有効になっていますが、<tcp-ring-listener>要素で構成できます。

この項には次のトピックが含まれます:

- TCP-Ring設定の変更

- ハートビート間隔の変更

- 停止検出の無効化

7.8.1 TCPリング設定の変更

TCPリング・リスナーのデフォルトの動作を変更するために使用する設定がいくつかあります。これには、クラスタ・メンバーをホストしているコンピュータが到達不可能になっていると判断するまでの試行回数と時間の変更などがあります。これらのデフォルトの設定はそれぞれ3回と15秒です。TCP/IPソケットのバックログ・キューも設定可能で、デフォルトではオペレーティング・システムで使用する値が設定されています。

TCPリング設定を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のTCPリング要素を追加します。

注意:
<ip-timeout>および<ip-attempts>の要素の値は、許容できる一時的なネットワークの停止に影響を与えないだけの大きな値にする必要があります。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<ip-timeout system-property="tangosol.coherence.ipmonitor.pingtimeout">
25s</ip-timeout>
<ip-attempts>5</ip-attempts>
<listen-backlog>10</listen-backlog>
</tcp-ring-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.ipmonitor.pingtimeoutシステム・プロパティを使用してタイムアウトを指定できます。例:

-Dtangosol.coherence.ipmonitor.pingtimeout=20s

7.8.2 ハートビート間隔の変更

停止検出のハートビート間隔を変更できます。この間隔を長くすると、最低限必要なネットワーク・トラフィックを小さく抑えることができますが、障害が発生したメンバーを検出できなくなることがあります。デフォルトのハートビート値は1秒です。

注意:
ハートビート設定とは、ハートビートの発行が必要かどうかを評価する頻度を技術的に制御するものです。指定した間隔の中で実際にハートビートが発行されるかどうかは、評価プロセスによって変化します。

停止検出のハートビート間隔を変更するには、オペレーション・オーバーライド・ファイルを編集して、ハートビート値を指定した<heartbeat-milliseconds>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<heartbeat-milliseconds>5000</heartbeat-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

7.8.3 停止検出の無効化

停止検出はデフォルトで有効になっているので、無効にするには明示的な指定が必要です。停止検出を無効にしても、最低限必要なネットワーク・トラフィックを小さく抑えることができるのみであり、その一方で障害が発生したメンバーを検出できなくなることがあります。無効にすると、クラスタ・メンバーはパケット・パブリッシャの再送信タイムアウト間隔を使用して、他のメンバーがUDPパケットへの応答を停止していることを判断します。デフォルトでは、このタイムアウト間隔は5分に設定されています。詳細は「パケットの再送信タイムアウトの変更」を参照してください。

注意:
パケット・パブリッシャの再送信タイムアウトを使用して、障害が発生したクラスタ・メンバーを検出する方法は、エラーが発生しやすく、ガベージ・コレクションの実行時間が長くなることから誤検出を招くことがあります。

停止検出を無効にするには、オペレーション・オーバーライド・ファイルを編集して、falseに設定した<enabled>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<enabled>false</enabled>
</tcp-ring-listener>
</cluster-config>
</coherence>

7.9 クラスタの優先度の指定

クラスタの優先度のメカニズムを使用すると、クラスタ・メンバーおよびメンバーの中で実行している様々なスレッドに優先度の値を割り当てることができます。

この項には次のトピックが含まれます:

- クラスタ・メンバーの優先度の指定

- 通信スレッドの優先度の指定

- サービスに対するスレッドの優先度の指定

7.9.1 クラスタ・メンバーの優先度の指定

クラスタ・メンバーの優先度は、同等の複数のメンバーに対する様々な処理の順番を指定するための基礎として使用します。2つのメンバーのどちらかをクラスタから除外することが必要になった場合に、そのどちらに障害が発生していて排除すべきかを客観的に判断できないまれな条件下では、優先度の低いメンバーが除外されます。

クラスタ・メンバーの優先度を指定するには、オペレーション・オーバーライド・ファイルを編集して、優先度を指定した<priority>要素を<member-identity>ノードに追加します。優先度は1から10の値で指定し、10を指定すると優先度が最も高くなります。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<priority system-property="tangosol.coherence.priority">1</priority>
</member-identity>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.priorityシステム・プロパティを使用してクラスタ・メンバーの優先度を指定できます。例:

-Dtangosol.coherence.priority=1

7.9.2 通信スレッドの優先度の指定

スレッドの優先度をサポートするクラスタ・コンポーネントがいくつかあります。この優先度は、Javaスレッドの実行の重要度を判断するための基礎として使用します。このコンポーネントとして、マルチキャスト・リスナー、ユニキャスト・リスナー、TCPリング・リスナー、パケット・スピーカー、パケット・パブリッシャおよび受信メッセージ・ハンドラがあります。デフォルトの優先度設定では、パケット・パブリッシャの優先度が最も高く、次の順位が受信メッセージ・ハンドラで、残りのコンポーネントがこれに続きます。

スレッドの優先度は、それぞれのコンポーネントの構成要素の中で指定します(それぞれ、<unicast-listener>、<multicast-listener>、<packet-speaker>、<packet-publisher>、<tcp-ring-listener>および<incoming-message-handler>の各要素)。たとえば、ユニキャスト・リスナーに対してスレッドの優先度を指定するには、オペレーション・オーバーライド・ファイルを編集して、優先度を指定した<priority>要素を<unicast-listener>ノードに追加します。優先度は1から10の値で指定し、10を指定すると優先度が最も高くなります。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<priority>5</priority>
</unicast-listener>
</cluster-config>
</coherence>

7.9.3 サービスに対するスレッドの優先度の指定

クラスタ・サービスではスレッドの優先度がサポートされています。この優先度は、Javaスレッドの実行の重要度を判断するための基礎として使用し、サービスのどのスレッドが重要とみなされているのかを示します。優先度を設定できるスレッドのタイプは、サービス・スレッド、イベント・ディスパッチャ・スレッドおよびワーカー・スレッドの3つです。デフォルトの設定では、サービス・スレッドとイベント・ディスパッチャ・スレッドにワーカー・スレッドよりも高い優先度が与えられています。

サービスのスレッド優先度は、オペレーション・オーバーライド・ファイルで <service>要素をオーバーライドすることで、クラスタ内のすべてのサービスに対して変更できます。ただし、より最適な方法は、キャッシュ・スキームを定義するときにキャッシュ構成ファイル内でサービス・インスタンスに対してスレッド優先度を構成することです。キャッシュの定義方法の詳細は、「キャッシュ・スキームの定義」を参照してください。<service-priority>、<event-dispatcher-priority>および<worker-priority>サブ要素をそれぞれ使用して、値を1から10の値で入力し、10を指定すると優先度が最も高くなります。例:

...
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>MyDistributedService</service-name>
<service-priority>10</service-priority>
<event-dispatcher-priority>10</event-dispatcher-priority>
<worker-priority>5</worker-priority>
...
</distributed-scheme>
...

8 クラスタ・メンバーの起動および停止

この章では、キャッシュ・サーバーとキャッシュ・クライアントを起動する方法と停止する方法について基本的な説明を提供します。マルチキャストを使用する際のクラスタの構築に問題がある場合は、『Oracle Coherenceの管理』でマルチキャスト接続テストの実行方法を参照してください。

この章には次の項が含まれます:

- キャッシュ・サーバーの起動

- キャッシュ・クライアントの起動

- クラスタ・メンバーの停止

- ローリング再起動の実行

8.1 キャッシュ・サーバーの起動

キャッシュ・サーバーは、キャッシュしたデータを保存するクラスタ・メンバーです。複数のクラスタ・サーバーでクラスタを構成できます。各キャッシュ・サーバーはそれぞれ専用のJVMを使用します。

この項には次のトピックが含まれます:

- DefaultCacheServerクラスの概要

- コマンド行からのキャッシュ・サーバーの起動

- プログラムによるキャッシュ・サーバーの起動

8.1.1 DefaultCacheServerクラスの概要

キャッシュ・サーバーを起動するには、com.tangosol.net.DefaultCacheServerクラスを使用します。キャッシュ・サーバーはコマンド行から起動するか、またはプログラムによって起動できます。キャッシュ・サーバーを起動する際は、次の引数を使用します。

- クラスパスで見つかるキャッシュ構成ファイルの名前、またはグリッド・アーカイブ(GAR)へのパス。両方が指定された場合、GARが優先されます。GARは、Coherenceアプリケーションからなるアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、ディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。GARの作成の詳細は、『Oracle Coherenceの管理』を参照してください。

- GARのアプリケーション名(オプション)。名前を指定しない場合は、アーカイブ名が使用されます。(ディレクトリ名、または.gar拡張子なしのファイル名)。この名前は、クラスタ上の別のアプリケーションに使用されるアプリケーション・スコープを提供します。

- 停止済のサービスを確認する間隔(秒数)。停止したサービスは、自動的に開始するように設定されている場合のみ、自動的に開始されます(キャッシュ構成ファイルの<autostart>要素で構成します)。引数が指定されなかった場合のデフォルト値は5秒です。

8.1.2 コマンド行からのキャッシュ・サーバーの起動

通常、キャッシュ・サーバーはコマンド行から起動します。Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成ファイルの詳細は、第3章「構成の理解」を参照してください。

次の例では、キャッシュ・サーバー・メンバーを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、2秒ごとにサービスの再起動を確認します。

java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer 2

次の例では、キャッシュ・サーバー・メンバーを起動し、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトを使用します。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。

java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar

注意:
クラスパスにあるキャッシュ構成ファイルよりも、GARファイル内にパッケージ化されたキャッシュ構成ファイルが優先されます。

キャッシュ・サーバー・インスタンスを容易に起動できるように、COHERENCE_HOME\bin\cache-serverスクリプトが用意されています。このスクリプトを使用すると、基本的な環境を設定してDefaultCacheServerクラスを実行できます。このスクリプトには、Windowsベース・プラットフォーム用とUNIXベース・プラットフォーム用の両方があります。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。

ヒント:
テスト中は、各キャッシュ・サーバーを一意に特定する複数のスクリプトをそれぞれ異なる名前で作成しておくと便利なことがあります。たとえば、cahe-server-a、cache-server-bのようにします。

8.1.3 プログラムによるキャッシュ・サーバーの起動

キャッシュ・サーバーを起動するときに、必要に応じてアプリケーションでDefaultCacheServerクラスを使用または拡張できます。たとえば、キャッシュ・サーバーとそのサービスを起動する前に、アプリケーション固有の設定や処理を実行できます。

次の例では、mainメソッドを使用してキャッシュ・サーバーを起動します。

String[] args = new String[]{"my-cache-config.xml", "5"};
DefaultCacheServer.main(args);

DefaultCacheServer(ConfigurableCacheFactory)コンストラクタは、ファクトリ・クラスを使用して、指定されたキャッシュ構成ファイルを使用するキャッシュ・サーバー・インスタンスを作成します。次の例では、ExtensibleConfigurableCacheFactoryの実装を使用し、DefaultCacheServerインスタンスを作成し、startAndMonitor(long)メソッドを使用して前の例と同様にキャッシュ・サーバーを起動します。

ExtensibleConfigurableCacheFactory factory;
factory = new ExtensibleConfigurableCacheFactory("my-cache-config.xml");

DefaultCacheServer dcs = new DefaultCacheServer(factory);
dcs.startAndMonitor(5000);

staticメソッドであるstartDaemon()メソッドは、専用デーモン・スレッドでキャッシュ・サーバーを起動し、管理対象コンテナ内で使用することを目的としています。

2つの追加のstatic起動メソッド(start()およびstart(ConfigurableCacheFactory))を使用してキャッシュ・サーバーを起動し、制御を返すこともできます。ただし、多くの場合は、後方互換性を維持できるこれらのメソッドのかわりにキャッシュ・ファクトリ・クラスを使用します。

よりきめ細かい制御を必要とするアプリケーションでは、DefaultCacheServerクラスのサブクラスを作成し、このクラスのメソッドを無効にして、目的とする任意のカスタム処理を実行できます。DefaultCacheServerクラスの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

8.2 キャッシュ・クライアントの起動

キャッシュ・クライアントは、クラスタに参加してそのクラスタのサービスと相互作用するクラスタ・メンバーです。キャッシュ・クライアントには、キャッシュとの間でデータをやりとりするアプリケーションのような単純なものもあれば、キャッシュにあるデータを処理するデータ・グリッド演算アプリケーションのような複雑なものもあります。キャッシュ・クライアントとキャッシュ・サーバーとの大きな違いは、一般的にクラスタの記憶域にはキャッシュ・クライアントは関与しないという点です。

この項には次のトピックが含まれます:

- ローカル記憶域の無効化

- キャッシュ・クライアントを起動するためのCacheFactoryクラスの使用

8.2.1 ローカル記憶域の無効化

パーティション・キャッシュ・サービス(分散キャッシュ)を使用するキャッシュ・クライアントでは、パーティション化したデータを保持しないようにします。記憶域を無効にしたキャッシュ・クライアントは良好なパフォーマンスを示し、使用するリソースも少なくてすみます。パーティション化したデータを分散する範囲は、キャッシュ・サーバー・インスタンスどうしのみとする必要があります。

tangosol.coherence.distributed.localstorageシステム・プロパティを使用して、プロセス単位でローカル記憶域を無効化します。これにより、キャッシュ・クライアントとキャッシュ・サーバーで同じ構成ディスクリプタを使用できます。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.MyApp

8.2.2 キャッシュ・クライアントを起動するためのCacheFactoryクラスの使用

com.tangosol.net.CacheFactoryクラスを使用してキャッシュのインスタンスを取得するアプリケーションはクラスタのメンバーとなり、キャッシュ・クライアントと見なされます。次の例は、キャッシュ・クライアントを起動する最も一般的な方法を示しています。

CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("cache_name");

キャッシュ・クライアントであるアプリケーションを起動するときは、Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成ファイルの詳細は、第3章「構成の理解」を参照してください。

次の例では、キャッシュ・クライアントであるアプリケーションを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、メンバー上の記憶域を無効化します。

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.MyApp

テスト用のCOHERENCE_HOME\bin\coherenceスクリプトが用意されており、このスクリプトでキャッシュ・クライアント・インスタンスを起動できます。このスクリプトでは、基本的な環境を設定し、記憶域を無効化して、プロンプトを返すCacheFactoryクラスを実行します。プロンプトは、キャッシュおよびクラスタとやり取りを行うコマンドを入力するために使用されます。このスクリプトには、Windowsベース・プラットフォーム用とUNIXベース・プラットフォーム用の両方があります。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。このクラスは、スクリプトを使用せずに、コマンド行から直接起動することもできます。例:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dtangosol.coherence.distributed.localstorage=false com.tangosol.net.CacheFactory

CoherenceアプリケーションがGARとしてパッケージ化されている場合は、クライアント・メンバーが起動された後にプロンプトでserverコマンドを使用して、CacheFactoryインスタンスによってGARをロードできます。

server [<path-to-gar>] [<app-name>]

次の例では、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトをロードします。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。

Map (?) server D:\example\MyGAR.gar

8.3 クラスタ・メンバーの停止

この項には次のトピックが含まれます:

- コマンド行からのクラスタ・メンバーの停止

- プログラムによるキャッシュ・サーバーの停止

8.3.1 コマンド行からのクラスタ・メンバーの停止

クラスタ・メンバーをシャットダウンするには、UNIXプラットフォームではkillコマンド、WindowsプラットフォームではCtrl+cを使用することが普通です。これらのコマンドでは、JVMの通常の終了で呼び出される標準のJVMシャットダウン・フックを開始します。

注意:
kill -9コマンドを発行すると、異常なJVM終了が始まり、シャットダウン・フックは実行されません。ただし、終了するサービスがノードセーフであることが(JMXの管理を使用した確認で)終了前にわかっている場合は、一般的には正常なシャットダウンは不要です。

シャットダウン・コマンドを受け取ったクラスタ・メンバーが実行するアクションは、オペレーション・オーバーライド・ファイルの<shutdown-listener>要素で構成します。次のオプションを使用できます。

- none - 明示的なシャットダウン・アクションは実行しません。外部シャットダウンに対する動作が目的どおりであることをテストで検証済である場合を除き、本番ではこの値の設定をお薦めします。

- force - (デフォルト)Cluster.stop()をコールすることにより、ノードのハードストップ(強制停止)を実行します。これは、デフォルトの初期状態の動作です。

- graceful - Cluster.shutdown()をコールすることにより、通常のシャットダウンを実行します。

- true - forceと同じ。

- false - noneと同じ。

次の例では、シャットダウン・フックをnoneに設定します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<shutdown-listener>
<enabled system-property="tangosol.coherence.shutdownhook">none</enabled>
</shutdown-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルのかわりにtangosol.coherence.shutdownhookシステム・プロパティを使用して、シャットダウン・フックの動作を指定します。例:

-Dtangosol.coherence.shutdownhook=none

8.3.2 プログラムによるキャッシュ・サーバーの停止

DefaultCacheServerクラスには、キャッシュ・サーバーのシャットダウンに使用するメソッドが2つ用意されています。

注意:
DefaultCacheServerクラス自身がstaticメンバーとして保持しているインスタンスをシャットダウンするスタンドアロン・アプリケーションで、シャットダウンがコールされることを想定しています。

- shutdown() - DefaultCacheServer.main()メソッドまたはDefaultCacheServer.start()メソッドを使用して別のスレッドで起動したキャッシュ・サーバーのシャットダウンに使用するstaticメソッドです。

- shutdownServer() - このメソッドは、アプリケーションが保持しているDefaultCacheServerインスタンスに対してコールします。

8.4 ローリング再起動の実行

ローリング再起動は、再起動中にデータを失うことなく、クラスタ内のキャッシュ・サーバーを再起動する技術です。ローリング再起動を使用すると、キャッシュ・サーバーを再起動している間も、そのキャッシュ・サーバーのデータをクラスタ上の他のキャッシュ・サーバーに再配布できます。クラスタ内の各キャッシュ・サーバーを順番に再起動して、クラスタ全体の再起動を効果的に行うことができます。

通常、ローリング再起動は、キャッシュ・サーバーやそのホスト・コンピュータを更新する必要がある場合や、キャッシュ・サーバーを新しいポイント・リリースにアップグレードする場合に実行されます。ただし、この技術は、キャッシュ・データの一部を現在管理しているキャッシュ・サーバーを再起動するときにいつでも使用できます。

注意:
クラスタをアップグレードするときに、ローリング再起動はパッチ・セットまたはパッチ・セット更新をアップグレードするためにのみ使用でき、メジャーまたはマイナー・リリースのアップグレードでは使用できません。Oracle Fusion Middlewareのリリース番号の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

8.4.1 ローリング再起動の実行の前提条件

ローリング再起動には、最初に考慮しておくべき点があり、クラスタを起動する前に設定が必要です。次の前提条件を満たしていないクラスタでは、ローリング再起動を実行できません。

- クラスタ内のキャッシュ・サーバーは、単一のキャッシュ・サーバーのシャットダウンを処理するための十分な容量を備えている必要があります(n - 1。nはクラスタ内のキャッシュ・サーバーの数)。キャッシュ・サーバーが最大容量での稼働に達すると、データの再配布中にメモリー不足の例外が発生する可能性があります。キャパシティ・プランニングの詳細は、『Oracle Coherenceの管理』を参照してください。

- すべてのキャッシュ・サーバーでリモートJMX管理が有効になっていて、最低でも2つのキャッシュ・サーバーに稼働中のMBeanサーバーが含まれている必要があります。JConsoleなどのMBeanブラウザを使用して、MBeanサーバーに接続できることを確認してください。JMX管理の構成およびMBeanサーバー・インスタンスへの接続の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

8.4.2 ローリング再起動のためのキャッシュ・サーバーの再起動

次の手順を使用して、キャッシュ・サーバーを再起動します。ホスト・コンピュータを再起動する場合は、コンピュータをシャットダウンする前にすべてのキャッシュ・サーバー・プロセスが停止していることを確認してください。

キャッシュ・サーバーを再起動するには:

1. MBeanブラウザを使用して、Coherence MBeanサーバーに接続します。再起動しようとしているキャッシュ・サーバーがMBeanサーバーをホストしていないことを確認します。

2. Coherence Service MBeanから、キャッシュ構成ファイル内で構成されているキャッシュに対応するクラスタ・サービスを選択します。

3. 任意のクラスタ・メンバーのStatusHA属性をチェックし、属性の値がMACHINE-SAFEであることを確認します。MACHINE-SAFE状態は、所定のコンピュータで稼働しているキャッシュ・サーバーのすべてがデータを失わずに停止可能であることを示します。属性がMACHINE-SAFEでない場合は、再起動を実行する前に、(場合によっては別のコンピュータで)追加のキャッシュ・サーバーを起動する必要があります。StatusHA属性の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

4. キャッシュ・サーバーをシャットダウンします。

5. MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。

6. キャッシュ・サーバーを再起動します。

7. MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。

8. 他のキャッシュ・サーバーを再起動する場合は、ステップ4から7を繰り返します。

9 クラスタ・メンバーシップの動的な管理

この章では、プログラムによるクラスタ内のメンバーおよびサービスの管理方法とメンバーおよびサービスのイベントのリスニング方法について説明します。

この章には次の項が含まれます:

- クラスタ・メンバーシップの管理の概要

- クラスタ・オブジェクトとサービス・オブジェクトの使用

- メンバー・オブジェクトの使用

- メンバー・イベントのリスニング

9.1 クラスタ・メンバーシップの管理の概要

Coherenceでは、新しいサーバーの起動時にそれらのサーバーをクラスタに自動的に追加し、シャットダウンまたは障害の発生時にそれらのサーバーの離脱を自動的に検出することによって、クラスタ・メンバーシップを管理します。アプリケーションはこの情報への完全なアクセスが許可されており、メンバーがクラスタに参加したり、クラスタから離脱した際にイベント通知を受信するようにサインアップできます。Coherenceでは、メンバーのそれぞれが提供および使用するすべてのサービスも追跡されます。この情報は、サーバーに障害が発生した場合のサービスの回復計画およびクラスタのすべてのメンバーにわたるデータ管理の負荷分散に多用されます。

9.2 クラスタ・オブジェクトとサービス・オブジェクトの使用

アプリケーションは、任意のキャッシュからキャッシュのサービスのローカル表現への参照を取得できます。また、任意のサービスからクラスタのローカル表現への参照を取得することもできます。

CacheService service = cache.getCacheService();
Cluster      cluster = service.getCluster();

Clusterオブジェクトで、クラスタ内で実行されているサービス・セットを確認できます。例9-1で説明します。

例9-1 クラスタ内で実行されているサービスの確認

...
for (Enumeration enum = cluster.getServiceNames(); enum.hasMoreElements(); )
{
String sName = (String) enum.nextElement();
ServiceInfo info = cluster.getServiceInfo(sName);
// ...
}
...

ServiceInfoオブジェクトは、名前、タイプ、バージョン、メンバーシップなどの情報を提供します。

この機能の詳細は、NamedCache、CacheService、Service、ServiceInfoおよびClusterのAPIドキュメントを参照してください。

9.3 メンバー・オブジェクトの使用

アプリケーションでクラスタ内の各メンバーに関して確認できる主な情報は次のとおりです。

- メンバーのIPアドレス

- メンバーがクラスタに参加した日付/時刻

たとえば、クラスタに4つのサーバーがあり、各サーバーでアプリケーションのコピー(インスタンス)が1つ実行されていて、アプリケーションの4つのインスタンスすべてがクラスタ化されているとします。この場合、そのクラスタは4つのメンバーで構成されます。アプリケーションでは、次のようにClusterオブジェクトからローカルのMemberを確認できます。

Member memberThis = cluster.getLocalMember();

また、Clusterオブジェクトから、クラスタ・メンバーの全体セットを確認することもできます。

Set setMembers = cluster.getMemberSet();

ServiceInfoオブジェクトで、そのサービスに参加しているクラスタ・メンバー・セットを確認できます。

ServiceInfo info = cluster.getServiceInfo(sName);
Set setMembers = info.getMemberSet();

この機能の詳細は、MemberのAPIドキュメントを参照してください。

9.4 メンバー・イベントのリスニング

クラスタおよびサービスのメンバーシップの変更をリスニングするには、アプリケーションで、MemberListenerインタフェース(「例9-2」を参照)を実装するクラスを作成する必要があります。作成したリスナー・クラスは、サービスのaddMemberListenerメソッドを使用するか、キャッシュ・スキーム定義に<member-listener>要素を追加することによって、サービスに追加されます。

プログラムを使用する方法と比較して、構成を使用する方法には次の2つの利点があります。第1に、プログラムを使用した場合は、実行中のサービスにのみリスナーを追加できます。そのため、最初のMEMBER_JOINEDイベントが見逃されます。第2に、対応するサービスを実行するすべてのクラスタ・ノードのそれぞれで、addMemberListenerコールを発行する必要があります。構成による方法では、これら両方の問題が解決されます。

次の例では、addMemberListenerメソッドを使用して、サービスにMyMemberListenerという名前のリスナー実装を追加します。

Service service = cache.getCacheService();
service.addMemberListener(package.MyMemberListener);

このサービスは、名前で検索することもできます。

Service service = cluster.getService(sName);
service.addMemberListener(package.MyMemberListener);

次の例では、<member-listener>要素を分散キャッシュ・スキーム定義に追加することによって、MyMemberListenerという名前のリスナー実装をDistributedCacheという名前のサービスに追加します。

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<member-listener>
<class-name>package.MyMemberListener</class-name>
</member-listener>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<member-listener>要素は、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<invocation-scheme>および<proxy-scheme>の各要素で使用できます。有効なキャッシュ構成要素のリファレンスについては、付録B「キャッシュ構成の要素」を参照してください。

注意:
<member-listener>要素を使用してリスナーをサービスに追加する場合は、MemberListener実装にパブリック・デフォルト・コンストラクタが必要です。

例9-2は、受信したすべてのメンバーシップ・イベントを出力するMemberListener実装を示しています。

例9-2 MemberListener実装のサンプル

public class MemberEventPrinter
extends Base
implements MemberListener
{
public void memberJoined(MemberEvent evt)
{
out(evt);
}

public void memberLeaving(MemberEvent evt)
{
out(evt);
}

public void memberLeft(MemberEvent evt)
{
out(evt);
}
}

MemberEventオブジェクトは、イベント・タイプ(MEMBER_JOINED、MEMBER_LEAVINGまたはMEMBER_LEFT)、イベントを生成したメンバー、およびイベントのソースとして動作するサービスについての情報を保持します。また、イベントにはisLocal()メソッドが用意されており、これは対象のメンバーがクラスタに参加または離脱しようとしていることをアプリケーションに示します。これは、障害の発生後にアプリケーションがクラスタに自動的に参加しなおす、ソフトな再起動の認識に役立ちます。

注意:
CacheFactory.shutdown()メソッドをコールすると、すべてのリスナーが登録解除されます。その場合、MEMBER_LEAVINGとMEMBER_LEFTの両方のイベントが送信されます。その他の原因でメンバーが終了した場合は、MEMBER_LEFTイベントのみが送信されます。

例9-3は、MemberEventオブジェクトでカプセル化された情報の使用方法を示しています。

例9-3 MemberEventオブジェクトのイベント・タイプ情報の使用

public class RejoinEventPrinter
extends Base
implements MemberListener
{
public void memberJoined(MemberEvent evt)
{
if (evt.isLocal())
{
out("this member just rejoined the cluster: " + evt);
}
}

public void memberLeaving(MemberEvent evt)
{
}

public void memberLeft(MemberEvent evt)
{
}
}

これらの機能の詳細は、Service、MemberListenerおよびMemberEventのAPIドキュメントを参照してください。

10 TCMPの動作のチューニング

この章では、デフォルトのTCMP設定を変更する方法について説明します。TCMPについても簡単に説明します。TCMPの詳細は、「TCMPの理解」を参照してください。また、チューニング上の考慮事項と方法を数多く取り上げている『Oracle Coherenceの管理』も参照してください。

この章には次の項が含まれます:

- TCMPデータ転送の概要

- データ転送速度の調整

- 負荷を低減するためのパケットのバンドル

- パケットの再転送動作の変更

- パケット・バッファのサイズの構成

- パケットの最大サイズの調整

- パケット・スピーカーのボリュームしきい値の変更

- 受信メッセージ・ハンドラの構成

- ネットワーク・フィルタの使用

- TCMPソケット・プロバイダ実装の変更

10.1 TCMPデータ転送の概要

クラスタ・メンバーどうしは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの伝送に使用する、IPベースのプロトコルです。TCMPは非同期プロトコルなので、サーバー上で多数のスレッドが同時に通信している場合でも、通信がブロックされることがありません。また、非同期通信では、ネットワークの待機時間(2つの異なるサイト間でルーティングされるネットワーク上での待機時間など)が特定の操作の速度に影響を与える場合でも、クラスタ・スループットに影響が及ぶことはありません。

TCMPプロトコルは非常にチューニング性が高いため、特定のネットワーク・トポロジの利用や、地理的に分散したクラスタにある低帯域幅で長待機時間のセグメントに対する許容差の追加が可能です。Coherenceには出荷時の初期設定の構成があります。TCMP属性の中には、実行時に動的に自己構成できるものがありますが、デプロイ目的でそれらをオーバーライドすることやロックダウンすることも可能です。TCMPの動作は、パフォーマンスのテストに基づいて変更する必要があります。Coherenceには、ネットワーク上でのTCMPのデータ転送パフォーマンスを評価するために使用できるデータグラム・テストが用意されています。データグラム・テスト・ユーティリティを使用してネットワークのパフォーマンスをテストする方法の詳細は、『Oracle Coherenceの管理』を参照してください。

TCMPデータ転送の動作は、tangosol-coherence-override.xmlファイルの中で、<packet-publisher>、<packet-speaker>、<incoming-message-handler>および<outgoing-message-handler>の各要素を使用して構成します。この章で取り上げるTCMP関連要素すべてのリファレンスは、付録A「オペレーション構成要素」を参照してください。

10.2 データ転送速度の調整

データの転送速度は<flow-control>要素と<traffic-jam>要素を使用して制御します。パケットの障害を最小限に抑えながら最大限のスループットを得るうえで、これらの要素は効果的です。ネットワークが低速な場合やパケット・バッファが小さい場合は、ここで説明する速度調整設定を変更することが普通です。

この項には次のトピックが含まれます:

- パケットのフロー制御動作の調整

- パケットのフロー制御の無効化

- パケット・トラフィック輻輳動作の調整

10.2.1 パケットのフロー制御動作の調整

フロー制御を使用して、所定のクラスタ・メンバーへのパケット転送速度を動的に調整します。この調整は、Point-to-Point転送でのクラスタ・メンバーの応答性を数値化した統計に基づいて実行されます。フロー制御は、応答できなくなったクラスタ・メンバーが大量のパケットであふれる状況を防止します。

<flow-control>要素でフロー制御を構成します。フロー制御の動作を調整するための設定には、次の2つがあります。

- <pause-detection> - 応答しなくなったクラスタ・メンバーに再送信するパケットの最大数を制御する設定です。この数のパケットを送信しても応答しないメンバーは一時停止していると判断されます。一時停止していると判断されたクラスタ・メンバー宛てのパケットは、そのメンバーが応答を再開するまで低速で送信されます。ガベージ・コレクションの実行時間が長いと、このような一時停止が発生します。この値は<maximum-packets>要素を使用して指定します。デフォルトのパケット数は16です。0を指定すると、一時停止の検出が無効になります。

- <outstanding-packets> - クラスタ・メンバーに送信する未確認パケットの数を定義する設定です。送信した未確認パケット数がこの値に達すると、以降はそのメンバーにパケットを遅延送信します。この値には、<maximum-packets>要素を使用して数値を明示的に指定するか、<maximum-packets>要素と<minimum-packets>要素の両方を使用して値の範囲を指定します。範囲を指定すると、この設定はネットワーク統計に基づいて動的に調整されます。最大値には256パケットを超える値を指定する必要があり、デフォルト値は4096パケットです。最小値には16パケットを超える値を指定する必要があり、デフォルト値は64パケットです。

フロー制御の動作を調整するには、オペレーション・オーバーライド・ファイルを編集して、次のように<pause-detection>要素と<outstanding-packets>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<flow-control>
<pause-detection>
<maximum-packets>32</maximum-packets>
</pause-detection>
<outstanding-packets>
<maximum-packets>2048</maximum-packets>
<minimum-packets>128</minimum-packets>
</outstanding-packets>
</flow-control>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

10.2.2 パケットのフロー制御の無効化

フロー制御を無効にするには、オペレーション・オーバーライド・ファイルを編集して、<flow-control>要素の中に、falseに設定した<enabled>要素を追加します。次に例を示します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<flow-control>
<enabled>false</enabled>
</flow-control>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

10.2.3 パケット・トラフィック混雑の動作の調整

パケット・トラフィック混雑とは、クライアント・スレッドによりエンキューされ、パブリッシャがネットワークへの送信を待機している保留パケットの数が、パケット・パブリッシャによって許容不可と判断されるレベルに達した状態です。<traffic-jam>要素でトラフィック混雑の動作を構成します。トラフィック混雑の動作を調整する設定には、次の2つがあります。

- <maximum-packets> - パケット・パブリッシャで許容できる保留パケットの最大数を制御する設定です。保留パケット数がこの値を超えると、輻輳が発生していると判断され、その場合はクライアント・リクエスト(システム・スレッド以外のローカル・スレッドからのリクエスト)の速度を遅くする必要があります。この構成した上限パケット数を超えると、未処理のパケット数がこの指定した上限値を下回るまで、クライアント・スレッドは強制的に一時停止状態になります。この設定で再送信キューのサイズを制限することにより、予期しないメモリー不足状態のほとんどは発生しなくなります。0を指定すると、この上限は設定されません。デフォルト値は8192です。

- <pause-milliseconds> - パケット・パブリッシャが輻輳状態のときにメッセージを送信しようとするクライアント・スレッドを一時停止する時間(ミリ秒)を制御する設定です。パブリッシャは、渋滞が解消されるまでメッセージの送信を許可せず、このプロパティで指定された期間中、スレッドのスリープ処理を繰り返します。デフォルト値は10です。

パケット上限値が小さすぎる場合や一時停止時間が長すぎる場合は、パブリッシャによってすべての保留パケットが送信され、送信するパケットがなくなることがあります。この状態が検出されると、定期的に警告がログに記録されます。理想的な値は、パブリッシャで実行する処理がなくならず、同時にキューが制御できないほど大きくならないような値です。一時停止時間は短い時間(10ミリ秒以下)に設定し、パケット数の上限は大きい値(5000を超える値)に設定します。

<traffic-jam>要素と<flow-control>要素を使用した設定はPoint-to-Pointモードで動作し、受信側に未処理パケットが多数存在する場合は送信のみがブロックされます。<traffic-jam>要素の<maximum-packets>サブ要素の値を、<outstanding-packets>要素の<maximum-packets>値よりも大きく設定することをお薦めします。<flow-control>が無効な場合、<traffic-jam>では未処理のパケットがすべて考慮されます。

エンキュー動作の速度を調整するには、オペレーション・オーバーライド・ファイルを編集して、次のように<maximum-packets>要素と<pause-milliseconds>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<traffic-jam>
<maximum-packets>8192</maximum-packets>
<pause-milliseconds>10</pause-milliseconds>
</traffic-jam>
</packet-publisher>
</cluster-config>
</coherence>

10.3 負荷を低減するためのパケットのバンドリング

複数の小さいパケットを1つの大きいパケットにバンドルして、ネットワーク・スイッチ・インフラストラクチャへの負荷を低減できます。パケットのバンドリングは、<packet-bundling>要素の中で次のような設定で構成します。

- <maximum-defferal-time> - 別のパケットのバンドルを待機している間のパケットの最大遅延時間を指定する設定です。この値を0に設定すると、待機のないアルゴリズムとなり、即座にアクセスできるパケットのみがバンドルされます。0より大きい値を設定すると、追加のパケットが得られるまで待機する間に、多少の送信遅延が発生します。スループットに有害な影響が出ないように、通常この値は250マイクロ秒未満に設定します。単位を指定しない場合は、ナノ秒と見なされます。デフォルト値は1us (マイクロ秒)です。

- <agression-factor> - パケット遅延アルゴリズムのアグレッシブさを指定する設定です。<maximum-deferral-time>要素は遅延時間の上限を定義しますが、<aggression-factor>要素は平均の遅延時間に影響します。積極性の値が高いほど、パブリッシャが追加のパケットを待つ時間が長くなります。この係数は実数で表します。多くの場合は待機時間を最小に抑えながらパケットの使用率を上げることができるように、0.0から1.0の値を使用します。デフォルト値は0です。

デフォルトのpacket-bundlingの設定は積極性が最小で、測定可能な遅延なしでバンドルが発生することを許容します。より積極的なバンドリングの利点は、ネットワーク・インフラストラクチャとアプリケーション・オブジェクトの一般的なデータ・サイズおよびアクセス・パターンにより異なります。

パケットのバンドリング動作を調整するには、オペレーション・オーバーライド・ファイルを編集して、次のように<maximum-defferal-time>要素と<agression-factor>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<packet-bundling>
<maximum-deferral-time>1us</maximum-deferral-time>
<aggression-factor>0</aggression-factor>
</packet-bundling>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

10.4 パケットの再転送動作の変更

TCMPでは、通知パケットを使用して、確認を要求するパケットを受信したことを応答します。肯定応答(ACK)パケットは、パケットが正しく受信されたので、再送信が不要であることを示します。多数の小さいACKパケットによってネットワーク帯域幅が浪費されないように、1つの送信元に対する複数のACKパケットは1つのACKパケットにまとめられます。肯定応答が得られないパケットは、パケット・パブリッシャに構成した再送信間隔に基づいて再転送されます。

否定応答(NACK)パケットは、パケットが正しく受信されていないことを示すものなので、そのパケットは再転送されます。受信したパケットの順序を検査してパケットの損失があることがわかると、否定応答が送信されます。否定応答があると、パブリッシャの再送信間隔に関係なく、はるかに早いタイミングでパケットが再送信されます。否定応答を無効にするには、「否定応答の無効化」を参照してください。

この項には次のトピックが含まれます:

- パケットの再送信間隔の変更

- パケットの再送信タイムアウトの変更

- パケットの肯定応答遅延の構成

10.4.1 パケットの再送信間隔の変更

パケットの再送信間隔は、送信に対応するACKパケットをパケット・パブリッシャが待機する最小時間(ミリ秒)を指定します。この時間が経過するとパケットが再送信されます。デフォルトの再送信間隔は200ミリ秒です。

パケットの再送信間隔を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のように<resend-milliseconds>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<resend-milliseconds>400</resend-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

10.4.2 パケットの送信タイムアウトの変更

パケットの再送信タイムアウト間隔は、ACKパケットが受信されない場合にパケットの再送信を継続する最長時間(ミリ秒)を指定します。このタイムアウトが経過すると、受信側が終了しているかどうかの判断が下されます。これを決定するには、他のノードがその受信者と通信できているかどうかなど、他のデータも考慮されます。デフォルト値は300000ミリ秒です。本番環境で使用する場合の推奨値は、300000を超え、予想される最大のGCの全所要時間の2倍より大きな値です。

注意:
デフォルトの停止検出メカニズムはTCPリング・リスナーです。このリスナーは、再送信タイムアウト間隔が経過する前に、障害が発生しているクラスタ・メンバーを検出します。停止検出の詳細は「停止検出の構成」を参照してください。

パケットの再送信タイムアウト間隔を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のように<timeout-milliseconds>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<timeout-milliseconds>420000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>

10.4.3 パケットの肯定応答遅延の構成

ACKパケットおよびNACKパケットの送信を必要に応じて変更できるようになるまでパケット・パブリッシャが待機する時間です。ACKパケットとNACKパケットの遅延間隔は、次の設定を使用して<notification-queueing>要素の中で構成します。

- <ack-delay-milliseconds> - ACKパケットを送信するまでパケット・パブリッシャが遅延する最長時間(ミリ秒)を指定する要素です。複数の肯定応答をまとめてACKパケットが満たされると、より早いタイミングでそのACKパケットが送信されることがあります。リモート・メンバーのパケット配信再送信タイムアウトが経過する前にACKを受信して処理する時間を十分に確保できるように、リモート・メンバーのパケット配信再送信タイムアウトよりも相当に小さい値を設定する必要があります。デフォルト値は16です。

- <nack-delay-milliseconds> - NACKパケットを送信するまでパケット・パブリッシャが遅延する最長時間(ミリ秒)を指定する要素です。デフォルト値は1です。

ACKおよびNACKの遅延間隔を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のように<ack-delay-milliseconds>要素と<nack-delay-milliseconds>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<notification-queueing>
<ack-delay-milliseconds>32</ack-delay-milliseconds>
<nack-delay-milliseconds>1</nack-delay-milliseconds>
</notification-queueing>
</packet-publisher>
</cluster-config>
</coherence>

10.5 パケット・バッファのサイズの構成

パケット・バッファはオペレーティング・システムのバッファであり、データグラム・ソケットで使用します(ソケット・バッファともいいます)。オペレーティング・システムに対してバッファ処理を要求するパケットの数を制御するようにパケット・バッファを構成できます。パケット・バッファは、ユニキャスト・リスナーとマルチキャスト・リスナーでインバウンド・バッファとして使用し、パケット・パブリッシャでアウトバウンド・バッファとして使用します。

この項には次のトピックが含まれます:

- パケット・バッファのサイズ設定の理解

- アウトバウンド・パケット・バッファのサイズの構成

- インバウンド・パケット・バッファのサイズの構成

10.5.1 パケット・バッファのサイズ設定の理解

パケット・バッファのサイズは、次の設定を使用して、パケット数またはバイト数に基づいて構成できます。

- <maximum-packets> - データグラム・ソケットに対してソケット自身のサイズを調整してバッファすることを要求するパケット数を(構成済のパケット・サイズに基づいて)指定します。詳細は、java.net.SocketOptions#SO_SNDBUFプロパティおよびjava.net.SocketOptions#SO_RCVBUFプロパティを参照してください。基礎となるソケットの実装で一定のサイズ以上をサポートできない場合、実際のバッファ・サイズは小さくなることがあります。パケット・サイズの構成の詳細は、「パケットの最大サイズの調整」を参照してください。

- <size> - 基礎となるソケット・バッファに要求されるサイズをバイト単位で指定します。

オペレーティング・システムでは、指定されたパケット・バッファ・サイズを参考値として扱うにすぎず、指定の量を割り当てることは要求されません。割り当てられた領域が要求量よりも少ないと、Coherenceでは警告が発行され、領域が制限されたバッファを使用して稼動を継続するので、十分なパフォーマンスが得られない可能性があります。領域が大きいバッファが割り当てられるようにオペレーティング・システムを構成する方法の詳細は、『Oracle Coherenceの管理』を参照してください。

領域が大きいインバウンド・バッファを使用すると、Javaのガベージ・コレクタに起因するJVMの一時停止からCoherenceのネットワーク層を保護するうえで効果的です。JVMが一時停止している間、Coherenceではどのインバウンド・ソケットからもパケットをデキューできません。パケット・バッファのオーバーフローを引き起こすほど一時停止時間が長いと、発信元ノードがパケット消失を検出してパケットを再送信する必要があるため、パケットの受信が遅延します。

10.5.2 アウトバウンド・パケット・バッファのサイズの構成

アウトバウンド・パケット・バッファは、パケットを転送するときにパケット・パブリッシャで使用します。バッファのサイズを変更するときは、スループットと待機時間の両面からパフォーマンスを評価する必要があります。バッファのサイズを大きくするとスループットが増加し、逆に小さくすると待機時間が短くなります。

アウトバウンド・パケット・バッファのサイズを構成するには、オペレーション・オーバーライド・ファイルを編集して、<packet-publisher>ノードに<packet-buffer>要素を追加し、<size>要素(バイト単位)または<maximum-packets>要素(パケット数単位)を使用してパケット・バッファのサイズを指定します。デフォルト値は32パケットです。次の例では、パケット数に基づいてパケット・バッファのサイズを指定しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-buffer>
<maximum-packets>64</maximum-packets>
</packet-buffer>
</packet-publisher>
</cluster-config>
</coherence>

10.5.3 インバウンド・パケット・バッファのサイズの構成

マルチキャスト・リスナーとユニキャスト・リスナーはそれぞれ専用のインバウンド・パケット・バッファを備えています。インバウンド・パケット・バッファのサイズを構成するには、オペレーション・オーバーライド・ファイルを編集して、(<multicast-listener>ノードまたは<unicast-listener>ノードに) <packet-buffer>要素を追加し、<size>要素(バイト単位)または<maximum-packets>要素(パケット数単位)を使用してパケット・バッファのサイズを指定します。デフォルト値は、マルチキャスト・リスナーで64パケット、ユニキャスト・リスナーで1428パケットです。

次の例では、ユニキャスト・リスナーのパケット・バッファのサイズをバイト数で指定しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<packet-buffer>
<size>1500000</size>
</packet-buffer>
</unicast-listener>
</cluster-config>
</coherence>

次の例では、マルチキャスト・リスナーのパケット・バッファのサイズをパケット数で指定しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-buffer>
<maximum-packets>128</maximum-packets>
</packet-buffer>
</packet-publisher>
</cluster-config>
</coherence>

10.6 パケットの最大サイズの調整

クラスタ通信の効率とスループットが最適になるように、UDPパケットの最大サイズと最適サイズを調整できます。クラスタ・ノードは、いずれも同一の最大パケット・サイズを使用する必要があります。ネットワークの使用率を最適化するには、この値にネットワークのMTU (maximum transmission unit)より32バイト小さい値を指定する必要があります。

注意:
Microsoft Windowsで1024バイトを超えるUDPパケット・サイズを指定する場合、転送速度が最適になるようにレジストリ設定を調整する必要があります。COHRENCE_HOME/bin/optimize.reg登録ファイルにはレジストリ設定が保存されています。Windowsでデータグラムのサイズを設定する方法の詳細は、『Oracle Coherenceの管理』を参照してください。

パケットのサイズは<packet-size>要素で構成し、次の設定を指定します。

- <maximum-length> - すべてのクラスタ・メンバーが問題なく処理できるパケット・サイズをバイト単位で指定します。この値は、クラスタ内のすべてのメンバーで同一にする必要があります。小さい値を設定することでクラスタの最大サイズを意図的に制限できます。この値は512以上とする必要があります。デフォルト値は64KBです。

- <preferred-length> - ユニキャスト・ソケットおよびマルチキャスト・ソケットで送受信されるDatagramPacketオブジェクトの最適サイズをバイト単位で指定します。
これには<maximum-length>値よりも大きい値または小さい値を指定できます。この値は、クラスタ内のすべてのメンバーで同一にする必要はありません。理想的な値は、UDPパケット・ヘッダー(32バイト)またはTCPパケット・ヘッダー(52バイト)用の十分な容量を確保しながら、ネットワークのMTUの範囲に収まる値です。

この値は512以上とする必要があります。デフォルト値は、ローカル・ノードのMTUに基づいて自動的に計算されます。MTUを取得できない場合は1500のMTUが使用され、パケット・ヘッダーにあわせて調整されます(UDPの場合は1468、TCPの場合は1448)。

このパケット・サイズを調整するには、オペレーション・オーバーライド・ファイルを編集して、次のように<maximum-length>要素と<preferred-length>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-size>
<maximum-length>49152</maximum-length>
<preferred-length>1500</preferred-length>
</packet-size>
</packet-publisher>
</cluster-config>
</coherence>

10.7 パケット・スピーカーのボリュームしきい値の変更

ネットワークの送信操作がブロックされている可能性があることをpacket-publisherが検出すると、パケット・スピーカーはネットワークにパケットを送信します。これにより、パケット・パブリッシャはI/Oのブロックを回避し、送信パケットの準備を続行できます。パケット・パブリッシャは、パケットの負荷の変化に伴ってスピーカーを使用するかどうかを動的に選択します。

パケットの負荷が比較的低い場合、スピーカーの操作をパブリッシャのスレッドで実行すると効率が向上することがあります。パケットの負荷が高い場合、スピーカーを使用すると、スピーカーによってネットワーク上でパケットを送信しながらパブリッシャはパケットの準備を続けることができます。

パケット・スピーカーを構成するには、<volume-threshold>要素を使用して、アクティブにするスピーカー・デーモンに送信できるようにしておくことが必要な最小のパケット数を指定します。値を指定しない場合は(デフォルト)、パケット・バッファに合わせて値が設定されます。

パケット・スピーカーのボリュームしきい値を指定するには、オペレーション・オーバーライド・ファイルを編集して、次のように<volume-threshold>要素を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-speaker>
<enabled>true</enabled>
<volume-threshold>
<minimum-packets>32</minimum-packets>
</volume-threshold>
</packet-speaker>
</cluster-config>
</coherence>

10.8 受信メッセージ・ハンドラの構成

受信メッセージ・ハンドラは、UDPパケットを論理メッセージにアセンブルし、それを適切なCoherenceサービスにディスパッチして処理できるようにします。<incoming-message-handler>要素で受信メッセージ・ハンドラを構成します。

この項には次のトピックが含まれます:

- 時刻差異の変更

- 否定応答の無効化

10.8.1 時刻差異の変更

<maximum-time-variance>要素では、新しいクラスタ・メンバーのシステム時刻と現在のクラスタ時刻との間の差異を測定する際に、ブロードキャスト・メッセージの送受信間の最大時刻差異を指定します。差異が小さいほど、クラスタ内で実行中の複数のシステム間でクラスタ時刻が接近する確率が高まりますが、クラスタに参加するプロセスは、指定された差異内でメッセージの交換が起こることが可能になるまで延長されます。通常は、20ミリ秒程度の値で十分ですが、負荷の高いクラスタや複数のネットワーク・ホップでは、より大きな値が必要になる場合があります。デフォルト値は16です。

最大の時刻差異を変更するには、オペレーション・オーバーライド・ファイルを編集して、次のように<maximum-time-variance>を追加します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<incoming-message-handler>
<maximum-time-variance>16</maximum-time-variance>
</incoming-message-handler>
</cluster-config>
</coherence>

10.8.2 否定応答の無効化

受信メッセージ・ハンドラに対して、否定応答を無効化できます。無効にすると、パケットが正しく受信されていなくても、ハンドラはそのパケットの送信側に何も通知しません。この場合、パケットの送信側は、指定の再送信タイムアウト間隔の経過を待ったうえでパケットを再送信します。パケットの応答の詳細は、「パケットの再転送動作の変更」を参照してください。

否定応答を無効にするには、オペレーション・オーバーライド・ファイルを編集して、falseに設定した<use-nack-packets>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<incoming-message-handler>
<use-nack-packets>false</use-nack-packets>
</incoming-message-handler>
</cluster-config>
</coherence>

10.9 ネットワーク・フィルタの使用

ネットワーク・フィルタは、低レベルのTCMPストリーム・プロトコルにプラグインするためのメカニズムです。Coherenceによってネットワーク経由で送信されるメッセージはすべて、このプロトコルを使用してストリームされます。Coherenceには、事前定義済圧縮フィルタが含まれており、必要に応じてカスタム・フィルタもサポートされます。

この項には次のトピックが含まれます:

- 圧縮フィルタの使用

- カスタム・ネットワーク・フィルタの使用

フィルタは、オペレーション・デプロイメント・ディスクリプタで定義され、tangosol-coherence-override.xmlファイル内で明示的に有効化されている必要があります。

注意:
フィルタは、すべてのメンバーで使用するか、まったく使用しないかのいずれかにします。一方のクラスタ・メンバーがフィルタを使用しているのにもう一方が使用していない場合、メッセージ・プロトコルに障害が発生します。フィルタを構成する前に、クラスタ全体を停止してください。

10.9.1 圧縮フィルタの使用

圧縮フィルタはjava.util.zipパッケージに基づいており、メッセージ・コンテンツを圧縮してネットワークの負荷を軽減します。フィルタは、CPUの使用率に余裕があり、ネットワーク帯域幅が不十分な場合に便利です。圧縮フィルタは、com.tangosol.net.CompressionFilterクラスで定義され、<filters>ノード内のオペレーション・デプロイメント・ディスクリプタで宣言されます。圧縮フィルタの構成済名はgzipです。これは特定のサービスに対してフィルタを有効化する場合またはすべてのサービスに対してフィルタを有効化する場合に使用されます。

この項には、次のトピックが含まれます:

- 特定のサービスに対する圧縮フィルタの有効化

- すべてのサービスに対する圧縮フィルタの有効化

- 圧縮フィルタの構成

10.9.1.1 特定のサービスに対する圧縮フィルタの有効化

特定のサービスに対して圧縮フィルタを有効化するには、そのサービスの定義内に<use-filters>要素を含め、gzipに設定した<filter-name>サブ要素を追加します。次の例では、分散キャッシュ・サービス定義を構成して、圧縮フィルタを有効化します。このサービスのインスタンスであるすべてのサービスは、自動的にこのフィルタを使用します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<service-type>DistributedCache</service-type>
<service-component>PartitionedService.PartitionedCache
</service-component>
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
</service>
</services>
</cluster-config>
</coherence>

10.9.1.2 すべてのサービスに対する圧縮フィルタの有効化

すべてのサービスに対して圧縮フィルタを有効化するには、<outgoing-message-handler>要素内に<use-filters>要素を追加し、gzipに設定した<filter-name>サブ要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<outgoing-message-handler>
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
</outgoing-message-handler>
</cluster-config>
</coherence>

10.9.1.3 圧縮フィルタの構成

圧縮フィルタには、フィルタの動作を構成できるパラメータが含まれています。表10-1で、使用可能な各パラメータについて説明します。詳細は、java.util.zip.Deflaterを参照してください。

次の例は、圧縮フィルタの構成戦略を示しており、デフォルトの圧縮戦略およびレベルを変更します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<filters>
<filter id="1">
<filter-name>gzip</filter-name>
<filter-class>com.tangosol.net.CompressionFilter</filter-class>
<init-params>
<init-param id="1">
<param-name>strategy</param-name>
<param-value>huffman-only</param-value>
</init-param>
<init-param id="2">
<param-name>level</param-name>
<param-value>speed</param-value>
</init-param>
</init-params>
</filter>
</filters>
</cluster-config>
</coherence>

表10-1 圧縮フィルタのパラメータ

パラメータ名

説明

buffer-length

圧縮バッファ長をバイト単位で指定します。有効な値は、正の整数またはゼロです。デフォルト値は0です。

level

圧縮レベルを指定します。有効な値は次のとおりです。

- default (デフォルト)

- compression

- speed

- なし

strategy

圧縮戦略を指定します。有効な値は次のとおりです。

- gzip (デフォルト)

- huffman-only

- filtered

- default

10.9.2 カスタム・ネットワーク・フィルタの使用

カスタム・ネットワーク・フィルタを必要に応じて作成できます。カスタム・フィルタは、com.tangosol.io.WrapperStreamFactoryインタフェースを実装する必要があります。WrapperStreamFactoryインタフェースにより、入力(受信メッセージ)または出力(送信メッセージ)でラップ(フィルタリング)されるストリームが提供され、元のストリームをラップするストリーム・バックが見込まれます。これらのメソッドは、メッセージの受信および送信のたびにコールされます。これらのAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

この項には、次のトピックが含まれます:

- カスタム・フィルタの宣言

- 特定のサービスに対するカスタム・フィルタの有効化

- すべてのサービスに対するカスタム・フィルタの有効化

10.9.2.1 カスタム・フィルタの宣言

カスタム・フィルタは、tangosol-coherence-override.xmlファイルの<filters>要素内で宣言します。次の例は、MyFilterというカスタム・フィルタの定義方法を示しています。カスタム・フィルタを宣言するときは、フィルタIDを3より大きくする必要があります。これはオペレーション・デプロイメント・ディスクリプタで宣言されている事前定義済フィルタが3つあるためです。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<filters>
<filter id="4">
<filter-name>MyFilter</filter-name>
<filter-class>package.MyFilter</filter-class>
<init-params>
<init-param id="1">
<param-name>foo</param-name>
<param-value>bar</param-value>
</init-param>
</init-params>
</filter>
</filters>
</cluster-config>
</coherence>

10.9.2.2 特定のサービスに対するカスタム・フィルタの有効化

特定のサービスに対してカスタム・フィルタを有効化するには、そのサービスの定義内に<use-filters>要素を含め、そのフィルタ名に設定した<filter-name>サブ要素を追加します。次の例では、MyFilterというカスタム・フィルタを分散キャッシュ・サービスに対して有効化します。このサービスから派生するすべてのキャッシュは、自動的にこのフィルタを使用します。サービスが開始されるときにフィルタがインスタンス化され、サービスが停止するまで保持されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<service-type>DistributedCache</service-type>
<service-component>PartitionedService.PartitionedCache
</service-component>
<use-filters>
<filter-name>MyFilter</filter-name>
</use-filters>
</service>
</services>
</cluster-config>
</coherence>

10.9.2.3 すべてのサービスに対するカスタム・フィルタの有効化

すべてのサービスに対してカスタム・フィルタをグローバルに有効化するには、<outgoing-message-handler>要素内に<use-filters>要素を追加し、そのフィルタ名に設定した<filter-name>サブ要素を追加します。次の例では、MyFilterというカスタム・フィルタをすべてのサービスに対して有効化します。Coherenceにより起動時にフィルタがインスタンス化され、クラスタが停止するまで保持されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<outgoing-message-handler>
<use-filters>
<filter-name>MyFilter</filter-name>
</use-filters>
</outgoing-message-handler>
</cluster-config>
</coherence>

10.10 TCMPソケット・プロバイダ実装の変更

Coherenceには、TCMPで使用するために、複数の基本的なソケット・プロバイダ実装が(デフォルト・システム・ソケット・プロバイダのほかに)用意されています。TCMPで使用するソケット・プロバイダは、<unicast-listener>要素でユニキャスト・リスナー向けに構成します。

この項には次のトピックが含まれます:

- TCPソケット・プロバイダの使用

- SDPソケット・プロバイダの使用

- SSLソケット・プロバイダの使用

10.10.1 TCPソケット・プロバイダの使用

TCPソケット・プロバイダは、可能なかぎりTCPベースのソケットを生成するソケット・プロバイダです。このソケット・プロバイダは、TCPによってバッキングされるDatagramSocketのインスタンスを作成します。WKA機能とともに使用するTCMPは(マルチキャストを無効化)、UDPを必要とせずにTCPを介して全面的に機能します。

注意:
WKA機能を併用せずにこのソケット・プロバイダを使用すると(マルチキャストを有効化)、すべてのユニキャスト通信にTCPが使用されます。マルチキャストは、グループベースの通信に使用されます。

TCPソケット・プロバイダでは、クラスタ・メンバーのペアごとに最大で2つのTCP接続を使用します。このTCPトラフィックは、ブロックしないNIOベースのソケットを使用してすべて管理されるので、トラフィック管理用のスレッドが別に追加されることはありません。したがって、既存のTCMPスレッドですべての接続を扱います。これらの接続は要求に応じて使用され、なんらかの理由で切断されると、必要に応じて自動的に再度開放されます。送信/受信の競合の低減とパフォーマンスの顕著な向上を図るために、2つの接続が使用されます。TCMPでは、信頼できるプロトコルを使用していることをほとんど認識していないので、保証済の配信とフロー制御を引き続き管理しています。

TCPソケット・プロバイダを指定するには、オペレーション・オーバーライド・ファイルを編集して、tcpの値を指定した<socket-provider>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider system-property="tangosol.coherence.socketprovider">tcp
</socket-provider>
</unicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.socketproviderシステム・プロパティを使用してこのソケット・プロバイダを指定できます。例:

-Dtangosol.coherence.socketprovider=tcp

10.10.2 SDPソケット・プロバイダの使用

SDPソケット・プロバイダは、JVMおよび基礎となるネットワーク・スタックでSDPがサポートされている場合に、可能であれば常にSDPベースのソケットを生成するソケット・プロバイダです。このソケット・プロバイダは、SDPによってバッキングされるDatagramSocketのインスタンスを作成します。WKA機能とともに使用するTCMPは(マルチキャストを無効化)、UDPを必要とせずにSDPを介して全面的に機能します。

注意:
WKA機能を併用せずにこのソケット・プロバイダを使用すると(マルチキャストを有効化)、すべてのユニキャスト通信にSDPが使用されます。マルチキャストは、グループ・ベースの通信に使用されます。

SDPソケット・プロバイダを指定するには、オペレーション・オーバーライド・ファイルを編集して、sdpの値を指定した<socket-provider>要素を追加します。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider system-property="tangosol.coherence.socketprovider">sdp
</socket-provider>
</unicast-listener>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.socketproviderシステム・プロパティを使用してこのソケット・プロバイダを指定できます。例:

-Dtangosol.coherence.socketprovider=sdp

10.10.3 SSLソケット・プロバイダの使用

SSLソケット・プロバイダは、SSLで保護したソケットのみを生成するソケット・プロバイダです。このソケット・プロバイダは、SSL/TCPまたはSSL/SDPによってバッキングされるDatagramSocketのインスタンスを作成します。マルチキャスト・ソケットに対してはSSLがサポートされていないので、このプロバイダでTCMPが機能するためにはWKA機能(マルチキャストを無効化)を使用する必要があります。

デフォルトのSSL構成を使用すると、信頼できるすべてのピアが単一のJKSキーストアにあるピア信頼に基づいて、双方向のSSL接続を容易に構成できます。より詳細な構成を別のアイデンティティ・マネージャおよびトラスト・マネージャで定義することで、認証局による信頼の検証が可能になります。TCMPの下で機能するSSLの構成方法と使用方法の詳細は、『Oracle Coherenceの保護』を参照してください。

11 サービス・ガーディアンの使用

この章では、デッドロックされたサービス・スレッドを検出および解決するためのサービス・ガーディアンの使用方法および構成方法、さらにカスタムの失敗ポリシーの実装方法について説明します。

この章には次の項が含まれます:

- 概要

- サービス・ガーディアンの構成

- 手動のガーディアン・ハートビートの発行

11.1 概要

サービス・ガーディアンは、Coherenceのスレッドでデッドロックを検出して解決しようとするメカニズムです。あるメンバー上のデッドロックされたスレッドは、クラスタに新しいノードを追加できない、クラスタに現在含まれるノードからのリクエストに対応できないなど、クラスタの他の部分に明らかな望ましくない多くの動作を引き起こす可能性があります。

サービス・ガーディアンは、Coherenceで所有され、作成されたスレッドが発行する定期的なハートビートを受け取ります。構成されているタイムアウトより前にスレッドからハートビートを発行できなくなると、サービス・ガーディアンによって修正処置が実行されます。タイムアウトと修正処置(リカバリ)は両方とも必要に応じて構成できます。

注意:
デッドロックという用語が必ずしも意味どおりのデッドロックを表すわけではありません。適時にハートビートを発行しないスレッドが、長い実行プロセスを実行していたり、遅いリソースを待機していたりする可能性があります。サービス・ガーディアンでは、デッドロックされたスレッドと遅いスレッドを区別することはできません。

Coherenceによって実行されるインタフェース

次のインタフェースの実装が、Coherence所有のスレッドによって実行されます。実装のプロセスが、構成されているガーディアン・タイムアウトを超えると、サービス・ガーディアンはスレッドをリカバリしようとします。リストは包括的ではなく、エンド・ユーザーによって実装される最も一般的なインタフェースのみを示しています。

com.tangosol.net.Invocable
com.tangosol.net.cache.CacheStore
com.tangosol.util.Filter
com.tangosol.util.InvocableMap.EntryAggregator
com.tangosol.util.InvocableMap.EntryProcessor
com.tangosol.util.MapListener
com.tangosol.util.MapTrigger
リカバリの理解

サービス・ガーディアンのリカバリ・メカニズムでは、スレッドがデッドロックされているかどうかを判断するために一連の手順が使用されます。修正処置は、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた場合に実行されます。実行する修正処置は構成可能であり、必要に応じてカスタムの処置を作成できます。次に、リカバリ・メカニズムの概要を示します。

- ソフト・タイムアウト - このリカバリ・メカニズムではまず、構成されているタイムアウトに達する直前にスレッドを中断しようとします。次のログ・メッセージの例は、ソフト・タイムアウト・メッセージを示しています。

<Error> (thread=DistributedCache, member=1): Attempting recovery (due to soft
timeout) of Daemon{Thread="Thread[WriteBehindThread:CacheStoreWrapper(com.
tangosol.examples.rwbm.TimeoutTest),5,WriteBehindThread:CacheStoreWrapper(com.
tangosol.examples.rwbm.TimeoutTest)]", State=Running}

スレッドを中断でき、その結果ハートビートが発行されると、通常の処理が再開します。

- ハード・タイムアウト - このリカバリ・メカニズムでは、構成されているタイムアウトに達するとスレッドを停止しようとします。次のログ・メッセージの例は、ハード・タイムアウト・メッセージを示しています。

<Error> (thread=DistributedCache, member=1): Terminating guarded execution (due
to hard timeout) of Daemon{Thread="Thread[WriteBehindThread:CacheStoreWrapper
(com.tangosol.examples.rwbm.TimeoutTest),5,WriteBehindThread:CacheStoreWrapper
(com.tangosol.examples.rwbm.TimeoutTest)]", State=Running}

- 最後に、スレッドを停止できない場合、リカバリ・メカニズムでは、構成されている失敗ポリシーに基づいて処理が実行されます。実行可能な処理には、クラスタ・サービスの停止、JVMの停止、カスタム処理の実行などがあります。次のログ・メッセージの例は、リカバリ・メカニズムで実行される処理を示しています。

<Error> (thread=Termination Thread, member=1): Write-behind thread timed out;
stopping the cache service

11.2 サービス・ガーディアンの構成

サービス・ガーディアンは、初期状態で有効になっており、タイムアウト値と失敗ポリシーの2つの項目が構成されています。タイムアウト値は、サービス・ガーディアンがリカバリを開始する前にスレッドからのハートビートの受取りを待機する時間です。失敗ポリシーは、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた後に実行される修正処置です。

11.2.1 ガーディアン・タイムアウトの設定

サービス・ガーディアン・タイムアウトは、必要な粒度レベルに基づいて3種類の方法で設定できます。

- すべてのスレッド - このオプションでは、1つのタイムアウト値をクラスタ・ノード上のCoherence所有のスレッドすべてに適用できます。これはデフォルトの構成で、デフォルトで305000ミリ秒に設定されています。

- サービス・タイプごとのスレッド - このオプションでは、サービス・タイプごとに異なるタイムアウト値を設定できます。タイムアウト値は、すべてのサービス・インスタンスのスレッドに適用されます。特定のサービス・タイプにタイムアウトが指定されていないと、そのタイムアウトはすべてのスレッドに設定されているデフォルトのタイムアウトに設定されます。

- サービス・インスタンスごとのスレッド - このオプションでは、サービス・インスタンスごとに異なるタイムアウト値を設定できます。特定のサービス・インスタンスにタイムアウトが設定されていないと、そのサービスのタイムアウト値が指定されている場合はそれが使用され、指定されていない場合はすべてのスレッドに設定されているタイムアウトが使用されます。

タイムアウト値を0に設定すると、スレッドの保護が停止します。一般的に、サービス・ガーディアン・タイムアウト値は、パケット配信のタイムアウト値と同じか、それより長く設定する必要があります。

注意:
ガーディアン・タイムアウトは、read-write-backing-mapスキームで構成するキャッシュ・ストアの実装に使用することもできます。この場合、<cachestore-timeout>要素を0に設定します。これによって、このタイムアウトがデフォルトのガーディアン・タイムアウトに設定されます。「read-write-backing-map-scheme」を参照してください。

11.2.1.1 すべてのスレッドのガーディアン・タイムアウトの設定

あるクラスタ・ノード内のすべてのスレッドにガーディアン・タイムアウトを設定するには、オペレーション・オーバーライド・ファイルの<service-guardian>要素内に<timeout-milliseconds>要素を追加します。次の例では、タイムアウト値が120000ミリ秒に設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<timeout-milliseconds>120000</timeout-milliseconds>
</service-guardian>
</cluster-config>
</coherence>

<timeout-milliseconds>の値は、tangosol.coherence.guard.timeoutシステム・プロパティを使用して設定することもできます。

11.2.1.2 サービス・タイプごとのガーディアン・タイムアウトの設定

サービス・タイプごとにガーディアン・タイムアウトを設定するには、オペレーション・オーバーライド・ファイルにあるサービスのguardian-timeout初期化パラメータをオーバーライドします。次の例では、DistributedCacheサービスのガーディアン・タイムアウトが120000ミリ秒に設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="17">
<param-name>guardian-timeout</param-name>
<param-value>120000</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

guardian-timeout初期化パラメータは、DistributedCache、ReplicatedCache、OptimisticCache、InvocationおよびProxyの各サービスに設定できます。特定のサービスのguardian-timeoutパラメータのオーバーライドに使用する適切なサービスIDおよび初期化パラメータIDについては、coherence.jarファイルにあるtangosol-coherence.xmlファイルを参照してください。

ガーディアン・タイムアウトを設定する、各サービスのシステム・プロパティは、それぞれ次のとおりです。

tangosol.coherence.distributed.guard.timeout
tangosol.coherence.replicated.guard.timeout
tangosol.coherence.optimistic.guard.timeout
tangosol.coherence.invocation.guard.timeout
tangosol.coherence.proxy.guard.timeout

11.2.1.3 サービス・インスタンスごとのガーディアン・タイムアウトの設定

サービス・インスタンスごとにガーディアン・タイムアウトを設定するには、キャッシュ構成ファイルのキャッシュ・スキーム定義に<guardian-timeout>要素を追加します。次の例では、分散キャッシュ・スキームのガーディアン・タイムアウトが120000ミリ秒に設定されます。

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<guardian-timeout>120000</guardian-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<guardian-timeout>要素は、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<transaction-scheme>、<invocation-scheme>および<proxy-scheme>の各スキームで使用できます。

11.2.2 PriorityTask APIのタイムアウト値の使用

Invocable、EntryProcessorおよびEntryAggregatorインタフェースのカスタム実装によって、com.tangosol.net.PriorityTaskインタフェースを実装できます。この場合、サービス・ガーディアンでは、getExecutionTimeoutMillis()から返される値より長い間タスクが実行されている場合にリカバリが試行されます。APIの使用方法の詳細は、第31章「スレッド実行の管理」を参照してください。

実行タイムアウトは、キャッシュ構成ファイルで定義されている<invocation-scheme>要素内の<task-timeout>要素を使用して設定できます。Invocationサービスの場合、<task-timeout>要素によって、PriorityTaskインタフェースを実装するInvocableタスクのタイムアウト値が指定されますが、この実行タイムアウト値が明示的に指定されるわけではありません。つまり、getExecutionTimeoutMillis()メソッドは0を返します。

<task-timeout>要素を0に設定すると、デフォルトのガーディアン・タイムアウトが使用されます。<task-timeout>要素の使用をサポートする様々なキャッシュ・スキームの詳細は、付録B「キャッシュ構成の要素」を参照してください。

11.2.3 ガーディアン・サービス失敗ポリシーの設定

サービス失敗ポリシーでは、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた場合に実行される修正処置が指定されます。適用可能なポリシーは次のとおりです。

- exit-cluster - このポリシーでは、応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。指定のポリシーがない場合、これがデフォルトのポリシーです。

- exit-process - このポリシーでは、応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - このポリシーでは、検出された問題がログに記録されますが、修正処置は実行されません。

- カスタム - com.tangosol.net.ServiceFailurePolicyインタフェースを実装するJavaクラスの名前。「カスタムのガーディアン失敗ポリシーの有効化」を参照してください。

サービス・ガーディアン失敗ポリシーは、必要な粒度レベルに基づいて3種類の方法で設定できます。

- すべてのスレッド - このオプションでは、1つの失敗ポリシーをクラスタ・ノード上のCoherence所有のスレッドすべてに適用できます。これが初期状態の構成です。

- サービス・タイプごとのスレッド - このオプションでは、サービス・タイプごとに異なる失敗ポリシーを設定できます。ポリシー値は、すべてのサービス・インスタンスのスレッドに適用されます。特定のサービス・タイプにポリシーが指定されていないと、そのポリシーはすべてのスレッドに設定されているデフォルトのポリシーに設定されます。

- サービス・インスタンスごとのスレッド - このオプションでは、サービス・インスタンスごとに異なる失敗ポリシーを設定できます。特定のサービス・インスタンスにポリシーが設定されていないと、そのサービスのポリシーが指定されている場合はそれが使用され、指定されていない場合はすべてのスレッドに設定されているポリシーが使用されます。

11.2.3.1 すべてのスレッドのガーディアン失敗ポリシーの設定

ガーディアン失敗ポリシーを設定するには、オペレーション・オーバーライド・ファイルの<service-guardian>要素内に<service-failure-policy>要素を追加します。次の例では、失敗ポリシーがexit-processに設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>exit-process</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>

11.2.3.2 サービス・タイプごとのガーディアン失敗ポリシーの設定

サービス・タイプごとに失敗ポリシーを設定するには、オペレーション・オーバーライド・ファイルにあるサービスのservice-failure-policy初期化パラメータをオーバーライドします。次の例では、DistributedCacheサービスの失敗ポリシーがloggingポリシーに設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="18">
<param-name>service-failure-policy</param-name>
<param-value>logging</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

service-failure-policy初期化パラメータは、DistributedCache、ReplicatedCache、OptimisticCache、InvocationおよびProxyの各サービスに設定できます。特定のサービスのservice-failure-policyパラメータのオーバーライドに使用する適切なサービスIDおよび初期化パラメータIDについては、coherence.jarファイルにあるtangosol-coherence.xmlファイルを参照してください。

11.2.3.3 サービス・インスタンスごとのガーディアン失敗ポリシーの設定

サービス・インスタンスごとに失敗ポリシーを設定するには、キャッシュ構成ファイルのキャッシュ・スキーム定義に<service-failure-policy>要素を追加します。次の例では、分散キャッシュ・スキームの失敗ポリシーがloggingに設定されます。

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<guardian-timeout>120000</guardian-timeout>
<service-failure-policy>logging</service-failure-policy>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<service-failure-policy>要素は、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<transaction-scheme>、<invocation-scheme>および<proxy-scheme>の各スキームで使用できます。

11.2.3.4 カスタムのガーディアン失敗ポリシーの有効化

カスタムの失敗ポリシーを使用するには、<instance>のサブ要素を追加し、ServiceFailurePolicyインタフェースを実装する完全修飾クラス名を指定します。<instance>要素の使用の詳細は、「instance」を参照してください。次の例では、MyFailurePolicyクラスに実装されているカスタムの失敗ポリシーが有効になります。カスタムの失敗ポリシーは、(次に示しているように)すべてのスレッドに対して有効にすることも、キャッシュ・スキーム定義内でサービス・インスタンスごとに有効にすることもできます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-name>package.MyFailurePolicy</class-name>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>

代替案として、<instance>要素では、ServiceFailurePolicyインスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次の例では、MyPolicyFactoryクラスでgetPolicyメソッドを使用してカスタムの失敗ポリシーのインスタンスが取得されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-factory-name>package.MyPolicyFactory</class-factory-name>
<method-name>getPolicy</method-name>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、iMaxTimeパラメータが2000に設定されます。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-name>package.MyFailurePolicy</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>

11.3 手動のガーディアン・ハートビートの発行

com.tangosol.net.GuardSupportクラスでは、アプリケーションでガーディアンにハートビートを手動で発行する際に使用できるハートビート・メソッドが用意されています。

GuardSupport.heartbeat();

既知の実行時間の長い操作の場合、操作がスタック状態にあると見なすまでの経過時間(ミリ秒数)を指定してハートビートを発行できます。

GuardSupport.heartbeat(long cMillis);

第III部

キャッシュの使用

第III部は次の章で構成されています。

- 第12章「Coherenceキャッシュの概要」

- 第13章「キャッシュの構成」

- 第14章「記憶域およびバッキング・マップの実装」

- 第15章「データ・ソースのキャッシュ」

- 第16章「シリアライズ・ページ・キャッシュ」

- 第17章「クォーラムの使用」

- 第18章「キャッシュの構成例」

12 Coherenceキャッシュの概要

この章では、Coherenceで提供される基本的なキャッシュのタイプの概要を説明し、それぞれのタイプを比較します。

この章には次の項が含まれます:

- 分散キャッシュの理解

- レプリケート・キャッシュの理解

- オプティミスティック・キャッシュの理解

- ニア・キャッシュの理解

- ローカル・キャッシュの理解

- リモート・キャッシュの理解

- キャッシュ・タイプのサマリー

12.1 分散キャッシュの理解

分散キャッシュ(パーティション・キャッシュ)は、線形スケーラビリティを持つクラスタ化されたフォルト・トレラント・キャッシュです。データは、クラスタのすべての記憶域メンバー間でパーティション化されます。フォルト・トレランスを実現するため、パーティション・キャッシュでは、各データをクラスタ内の1つ以上の個別コンピュータに保持するように構成できます。分散キャッシュはCoherenceで最もよく使用されるキャッシュです。

Coherenceでは、分散キャッシュは、複数のクラスタ・ノードに分散されたデータのコレクションとして定義されるため、クラスタ内の1つのノードがキャッシュ内の各データに対応し、その対応がクラスタ・ノード間で分散(ロード・バランシング)されます。

分散キャッシュには、いくつかの重要な留意事項があります。

- パーティション化: 分散キャッシュ内のデータは、同じデータが2つのサーバーで保持されることがないようにすべてのサーバーに分配されます。キャッシュのサイズ、およびキャッシュの管理に関連する処理能力は、クラスタのサイズとともに線形に拡大します。また、キャッシュ内のデータに対する読取り操作を単一ホップ(他のサーバーを多くても1つしか必要としない)で実行できることになります。書込み操作は、バックアップが構成されていない場合に単一ホップで実行できます。

- ロード・バランシング: データがサーバー間に均等に分配されるため、データを管理する役割はクラスタ全体を通して自動的にロード・バランシングされます。

- 位置の透過性: データはクラスタ・ノード全体に分配されますが、データのアクセスにはまったく同じAPIが使用され、各APIメソッドからも同じ動作が実行されます。これを位置の透過性と呼びます。ローカルのJCache、レプリケートされたキャッシュ、または分散キャッシュではAPIおよびAPIの動作が同じになるため、開発者はキャッシュのトポロジに基づいてコードを記述する必要がありません。

- フェイルオーバー: Coherenceのすべてのサービスは、データ損失のないフェイルオーバーおよびフェイルバックを実行しますが、分散キャッシュ・サービスも例外ではありません。分散キャッシュ・サービスではバックアップの回数を設定できます。バックアップ回数を1以上に設定すれば、いずれかのクラスタ・ノードに障害が発生しても、データを失うことはありません。

分散キャッシュにアクセスするには、ネットワークを介して別のクラスタ・ノードに接続する必要があります。他の条件がすべて同じであるとして、n個のクラスタ・ノードがある場合は、(n-1)/nの操作がネットワークを経由することになります。

図12-1は、分散キャッシュのget操作の際の概念図です。

図12-1 分散キャッシュでのget操作

各データは1つのクラスタ・ノードのみで管理されるため、ネットワーク経由の読取り操作は単一ホップ操作になります。このタイプのアクセスは、Point-to-Point通信を使用できるためスイッチド・ネットワークを最大限に活用できます。そのため、スケーラビリティに非常に優れています。

図12-2は、分散キャッシュのput操作の際の概念図です。

図12-2 分散キャッシュ環境でのput操作

上の図では、データはプライマリ・クラスタ・ノードとバックアップ・クラスタ・ノードに送信されています。これはフェイルオーバーを目的としたものであり、この場合のバックアップ回数は1になります。(デフォルトのバックアップ回数の設定は1です。)キャッシュのデータがクリティカルでない(ディスクから再ロードできる)場合は、バックアップ回数をゼロに設定できますが、クラスタ・ノードに障害が発生したときに分散キャッシュ・データの一部が失われる可能性があります。キャッシュがきわめてクリティカルな場合は、バックアップ回数を2などの高い値に設定します。バックアップ回数は、キャッシュ・エントリの追加、変更、削除などによるキャッシュの変更パフォーマンスにのみ影響します。

キャッシュに対する変更は、すべてのバックアップが変更を受信したことを認識するまで完了したとは見なされません。分散キャッシュのバックアップを使用する場合は、キャッシュの変更パフォーマンスが若干低下します。しかし、クラスタ・ノードに予期しない障害が発生しても、データの整合性が維持されることが保証され、データが損失することはありません。

分散キャッシュのフェイルオーバーでは、バックアップ・データがプライマリ記憶域に昇格されます。あるクラスタ・ノードに障害が発生すると、残りのすべてのクラスタ・ノードは、障害が発生したクラスタ・ノードがプライマリ記憶域で停止時に管理していたデータを各自のバックアップ記憶域から判別します。これらのデータの管理は、それをバックアップ記憶域に保持していたクラスタ・ノードに引き継がれます。

図12-3は、分散キャッシュのフェイルオーバーの際の概念図です。

図12-3 分散キャッシュでのフェイルオーバー

バックアップに複数のレベルがある場合は、最初のバックアップでデータがバックアップされ、2番目以降のバックアップでは前のバックアップがバックアップされるようになります。レプリケート・キャッシュ・サービスとまったく同じように、サーバーの障害時にはロック情報も維持されます。ただし、唯一の例外として、障害が発生したクラスタ・ノードのロックは自動的に解除されます。

分散キャッシュ・サービスでは、データを格納するクラスタ・ノードと格納しないクラスタ・ノードを構成できます。この設定はローカル記憶域の有効化と呼ばれています。ローカル記憶域を有効化するオプションで構成されたクラスタ・ノードは、分散キャッシュのキャッシュ記憶域とバックアップ記憶域を提供します。この設定にかかわらず、位置の透過性により、データはすべてのクラスタ・ノードでまったく同じように表示できます。

図12-4は、分散キャッシュのgetおよびput操作の際のローカル記憶域の概念図です。

図12-4 分散キャッシュのローカル記憶域

「ローカル記憶域有効」オプションには、次のような利点があります。

- クラスタ・ノードの「ローカル記憶域有効」を選択しない場合、データが他のクラスタ・ノードにキャッシュされるため、このノードのJavaヒープ・サイズはキャッシュ内のデータ量に影響されません。この機能は、大きなJavaヒープを持つ古いバージョンのJVMでアプリケーション・サーバー・プロセスを実行している場合に特に有用です。これらのプロセスは、ヒープ・サイズとともに急激に増加するガベージ・コレクションの一時停止に妨げられることが多いためです。

- Coherenceでは、クラスタ・ノードごとに、サポートされている任意のJVMバージョンを実行できます。したがって、「ローカル記憶域有効」を有効にしたクラスタ・ノードでは、大きいヒープ・サイズ、またはエラスティック・データを使用するCoherenceのヒープ外記憶域をサポートする、新しいJVMバージョンを実行できます。記憶域が有効なノードと記憶域が無効なノードの間では、それぞれ異なるJVMバージョンを使用できますが、記憶域が有効なノード間では、すべて同じJVMバージョンを使用する必要があります。

- 「ローカル記憶域有効」オプションを使用すると、一部のクラスタ・ノードをキャッシュ・データの格納目的にのみ使用できます。このようなクラスタ・ノードをCoherenceキャッシュ・サーバーと呼びます。キャッシュ・サーバーは、主にCoherenceの分散問合せ機能の拡張に使用されます。

12.2 レプリケート・キャッシュの理解

レプリケート・キャッシュはクラスタ化されたフォルト・トレラントなキャッシュで、そこではデータがクラスタ内のすべてのメンバーに完全にレプリケートされます。このキャッシュは、読取りに対して線形パフォーマンスのスケーラビリティで最速の読取りパフォーマンスを示しますが、書込みのスケーラビリティは優れていません(クラスタ内のすべてのメンバーに書込み処理が必要なため)。データがすべてのサーバーにレプリケートされるので、サーバーを追加した場合でもキャッシュの合計容量は増加しません。レプリケート・キャッシュは、一般的に読取り専用の小さなデータ・セットで使用されます。

注意:
分散キャッシュとは異なり、レプリケート・キャッシュでは、記憶域が有効なクラスタ・メンバーと記憶域が無効なクラスタ・メンバーが区別されません。

自身のメモリ内でデータにアクセスできる各クラスタ・ノード(JVM)にデータがレプリケートされているため、レプリケート・キャッシュには大変高速にアクセスできます。このタイプのアクセスはゼロ待機時間アクセスと呼ばれることが多く、アプリケーションに最高速のデータ・アクセスが要求される状況においては、まさに理想的な機能です。ただし、ゼロ待機時間アクセスはデータが最初にアクセスされた後にのみ発生することに注意してください。レプリケート・キャッシュでは、アクセスがあるまでデータはシリアライズされた形式で格納され、アクセスされた際にデシリアライズされます。データへのアクセスが発生する各クラスタ・ノードで、(データが最初に作成されたノードの場合でも)最初のデシリアライズ・ステップを実行する必要があります。レプリケート・キャッシュを使用する場合は、デシリアライズ・ステップにはパフォーマンス・コストがかかることを考慮する必要があります。

信頼性のあるレプリケート・キャッシュを構築するには、いくつかの課題があります。その1つは、どのような方法で高いスケーラビリティとパフォーマンスを得るかということです。キャッシュに対する更新はすべてのクラスタ・ノードに送信する必要があり、たとえ同じデータへの更新が同時に複数行われても、最終的にはすべてのクラスタ・ノードのデータが一致している必要があります。また、あるクラスタ・ノードがロックをリクエストしても、すべてのクラスタ・ノードがそれに従う必要はありません。そうしないと、スケーラビリティがきわめて低くなります。さらに、クラスタ・ノードに障害が発生した場合は、すべてのデータおよびロック情報が安全に維持される必要があります。Coherenceは、このようなシナリオをすべて透過的に処理し、スケーラブルで可用性の高いレプリケート・キャッシュの実装を実現します。

図12-5は、レプリケート・キャッシュのget操作の際の概念図です。

図12-5 レプリケート・キャッシュでのget操作

put操作では、レプリケートされたキャッシュの更新には、他のすべてのクラスタ・ノードに新しいバージョンのデータをプッシュすることが要求されます。図12-6は、レプリケート・キャッシュのput操作の際の概念図です。

図12-6 レプリケート・キャッシュでのput操作

Coherenceにおけるレプリケート・キャッシュ・サービスの実装は、読取り専用操作をすべてローカルで実行する、並行処理制御操作に使用する他のクラスタ・ノードは最大1つとする、他のすべてのクラスタ・ノードとの通信が要求される操作を更新にのみ制限する、という方法で行われます。これにより、スケーラビリティに優れたパフォーマンスが実現し、すべてのCoherenceサービスと同様に、レプリケート・キャッシュ・サービスからも透過的で完全なフェイルオーバーおよびフェイルバックが提供されます。

次のレプリケート・キャッシュ・サービスの制限事項にも十分な留意が必要です。

- データは、サービスに参加しているすべてのクラスタ・ノード上でレプリケート・キャッシュ・サービスによって管理されます。したがって、メモリー使用量(Javaヒープ・サイズ)はクラスタ・ノードごとに増加し、パフォーマンスに影響する可能性があります。

- 更新頻度の高いレプリケート・キャッシュは、クラスタの拡大に比例して変化しません。クラスタ・ノードが追加されるに従って、クラスタでは返されるデータが減少します。

- レプリケート・キャッシュでは、エントリごとの期限切れはサポートされていません。期限はキャッシュ・レベルで設定する必要があります。バッキング・マップによって、失効およびエビクションがローカルで強制されるため、データは各ノードで失効する可能性があります。エントリは多少異なる時間に失効する可能性があり、別のノードでは多少長く使用可能である可能性があります。失効およびエビクションを使用する場合、アプリケーションは部分的なデータ・セットに対応するように設計されている必要があります。記録システム(データベースなど)が使用されている場合、項目が失効または削除されているどうかはアプリケーションとは無関係である必要があります。

12.3 オプティミスティック・キャッシュの理解

オプティミスティック・キャッシュは、レプリケート・キャッシュと同様のクラスタ化されたキャッシュの実装になりますが、並行処理制御は行われません。この実装では、レプリケート・キャッシュより、書込みのスループットが高くなります。また、MRU/MFUベースのキャッシュなどのキャッシュ・データの格納に、代替の基礎となるストアを使用できます。ただし、2つのクラスタ・メンバーが基礎となるローカル・ストアの削除やパージを個別に実行すると、それぞれのメンバーが保持している格納済の内容が異なる可能性があります。

12.4 ニア・キャッシュの理解

ニア・キャッシュはハイブリッドなキャッシュであり、一般に分散キャッシュまたはリモート・キャッシュとローカル・キャッシュを組み合せた役割を果たします。ニア・キャッシュでは、構成済の無効化戦略を使用してフロント・キャッシュ・エントリを無効にし、優れたパフォーマンスおよび同期化を実現します。パーティション・キャッシュによってバッキングされたニア・キャッシュでは、反復的なデータ・アクセスにおいて0ミリ秒のローカル・アクセスが可能になります。同時実行性が可能になり、整合性およびフェイルオーバーが保証されるのみでなく、レプリケート・キャッシュとパーティション・キャッシュの長所が効率的に結合されます。

ニア・キャッシュの目的は、最後に使用した(MRU: Most Recently Used)データと最も頻繁に使用する(MFU: Most Frequently Used)データの読取りアクセスの速度を上げて、レプリケーション・キャッシュの長所である最大のパフォーマンスと分散キャッシュの長所である最大のスケーラビリティの両方を最大限に実現することです。そのため、ニア・キャッシュの実装にはフロント・キャッシュとバック・キャッシュの2つのキャッシュが含まれています。これらはリードスルー/ライトスルー方式を使用することにより、互いに自動的および透過的に通信します。

フロント・キャッシュは、ローカル・キャッシュ・アクセスを提供します。高速でサイズも限られていることから、低コストといえます。バック・キャッシュは、ローカル・キャッシュが使用不能な場合に必要に応じてロードできる、集中型のキャッシュまたは複数層構成のキャッシュにすることができます。バック・キャッシュは、非常に容量が大きいという点で完璧かつ適切ですが、アクセス速度の点では割高といえます。

この設計により、ニア・キャッシュでは、最も基本的な有効期間ベースのキャッシュや無効化ベースのキャッシュから、データのバージョニングおよび整合性の保証が可能な高度なキャッシュまでの、キャッシュの整合性を様々に構成できます。その結果、ローカル・メモリー・リソースを維持するという点と、真のローカル・キャッシュのパフォーマンス上の利点を活用するという点のバランスを調整できます。

一般的なデプロイメントでは、フロント・キャッシュにローカル・キャッシュが使用されます。ローカル・キャッシュは、スレッド・セーフである、並行性が高い、サイズ制限がある、自動的に失効する、データがオブジェクト形式で保存される、などの点から妥当な選択といえます。バック・キャッシュには、パーティション・キャッシュが使用されます。

次の図は、ニア・キャッシュのデータ・フローを示しています。クライアントがオブジェクトDをグリッドに書き込むと、このオブジェクトは、ローカルJVM内のローカル・キャッシュ、およびそれをバックアップする(バックアップ・コピーを含む)パーティション・キャッシュに配置されます。クライアントがオブジェクトをリクエストすると、オブジェクトはローカル、すなわちフロント・キャッシュからオブジェクト形式で待機することなく取得されます。

注意:
ニア・キャッシュのフロント層ではエントリがオブジェクト形式で格納されているため、同じJVM内における複数のスレッドのアクセスの同期化はアプリケーションが担当する必要があります。たとえば、あるスレッドがニア・キャッシュのフロント層から取得したエントリを変更した場合は、同じJVM内の他のスレッドもその変更をすぐに参照できる必要があります。

図12-7は、ニア・キャッシュのput操作の際の概念図です。

図12-7 ニア・キャッシュでのput操作

フロント・キャッシュで失効しているオブジェクトまたは無効化されているオブジェクトがクライアントからリクエストされた場合、Coherenceは自動的にパーティション・キャッシュからそのオブジェクトを取得します。フロント・キャッシュは、クライアントに配信される前にオブジェクトが保存される場所です。

図12-8は、ニア・キャッシュのget操作の際の概念図です。

図12-8 ニア・キャッシュでのget操作

12.5 ローカル・キャッシュの理解

クラスタ化サービスではありませんが、ローカル・キャッシュ実装は、各種クラスタ化キャッシュ・サービスと組み合せてニア・キャッシュの一部として使用されることがよくあります。

注意:
ニア・キャッシュの一部としてローカル・キャッシュを使用するアプリケーションでは、キーが不変である必要があります。可変であるキーが原因で、スレッドがハングしたり、デッドロックが発生する可能性があります。
特に、ニア・キャッシュの実装ではキー・オブジェクトを使用してローカル・キャッシュ(フロント・マップ)の同期化を行うため、キーが内部マップにキャッシュされることもあります。そのため、get()メソッドに渡されたキー・オブジェクトはロックして使用されます。スレッドがロックを維持している間にキー・オブジェクトが変更された場合、スレッドはキーのロック解除に失敗する可能性があります。さらに、ロックされているキー・オブジェクトの解放を待機している他のスレッドが存在したり、変更されたキーのロックを取得しようとするスレッドが存在した場合、スレッドがハングしてデッドロックが発生する可能性があります。キーの使用の詳細は、java.util.Map APIのドキュメントを参照してください。

ローカル・キャッシュは、特定のクラスタ・ノード内に完全に含まれます。ローカル・キャッシュの特に興味深い属性について、次に示します。

- ローカル・キャッシュはクラスタ化キャッシュと同じ標準のコレクション・インタフェースを実装します。つまり、ローカル・キャッシュを使用することとクラスタ化キャッシュを使用することにプログラミング上の違いはありません。クラスタ化キャッシュ同様、ローカル・キャッシュではJCache APIまで追跡しています。このAPI自体は、ローカル・キャッシュがベースとする同じ標準のコレクションAPIをベースとしています。

- ローカル・キャッシュのサイズは制限できます。ローカル・キャッシュでは、キャッシュするエントリ数を制限し、キャッシュが一杯になったらエントリを自動的に削除できます。さらに、エントリのサイジングとエビクション・ポリシーの両方のカスタマイズが可能です。たとえば、キャッシュされたエントリで使用されるメモリー量を基準にしてキャッシュのサイズを制限できます。デフォルトのエビクション・ポリシーでは、対数曲線で測定された、最も頻繁に使用する(MFU)情報と最後に使用した(MRU)情報の組合せを使用して削除するキャッシュ項目が決定されます。このアルゴリズムは、短期キャッシュと長期キャッシュの両方に対して十分に機能し、頻度と新しさのバランスをとってキャッシュ・スラッシングを回避するため、最適な汎用エビクション・アルゴリズムであるといえます。また、ピュアLRUアルゴリズムおよびピュアLFUアルゴリズムがサポートされ、カスタム・エビクション・ポリシーのプラグイン機能もサポートされています。

- ローカル・キャッシュはキャッシュ・エントリの自動失効をサポートしています。つまり、キャッシュ内の各キャッシュ・エントリに有効時間を割り当てることができます。

- ローカル・キャッシュはスレッド・セーフで並行性が高いため、数多くのスレッドがローカル・キャッシュの複数のエントリに同時にアクセスしたり、エントリを更新したりできます。

- ローカル・キャッシュはキャッシュ通知をサポートしています。キャッシュ通知は、追加(クライアントによって追加されたりキャッシュへ自動的にロードされたエントリ)、変更(クライアントによって追加されたり自動的にリロードされたエントリ)、および削除(クライアントによって削除されたり、自動的に失効、フラッシュ、または削除されたエントリ)を処理するために送信されます。これらは、クラスタ化キャッシュでサポートされているキャッシュ・イベントと同じです。

- ローカル・キャッシュには、キャッシュ・ヒットおよびキャッシュ・ミスの統計情報が保持されます。これらの実行時統計を使用すれば、キャッシュの有効性を正確に推定できるため、キャッシュ実行時にサイズ制限や自動失効の設定を適宜調整できます。

Coherenceのニア・キャッシュ・テクノロジの一部として機能したり、モジュールで構成されたバッキング・マップ・アーキテクチャで使用されるなど、ローカル・キャッシュはクラスタ化キャッシュ・サービスにおいて重要な役割を果たします。

12.6 リモート・キャッシュの理解

リモート・キャッシュは、Coherence*Extendクライアントによりアクセスされるアウトオブプロセス・キャッシュを表します。キャッシュ・リクエストはすべてCoherenceプロキシに送られ、そこでキャッシュ(レプリケート、オプティミスティック、パーティション)に委任されます。リモート・キャッシュの使用方法の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

12.7 キャッシュ・タイプのサマリー

数値に関する用語

- JVMs = JVMの数

- DataSize = キャッシュ・データの合計サイズ(冗長性を除く)

- Redundancy = 保持されているデータのコピー数

- LocalCache = ローカル・キャッシュ・サイズ(ニア・キャッシュの場合)

表12-1 キャッシュのタイプと特性のサマリー

レプリケート・キャッシュ

オプティミスティック・キャッシュ

パーティション・キャッシュ

ニア・キャッシュ(パーティション・キャッシュによるバッキング)

ローカル・キャッシュ(非クラスタ)

トポロジ

レプリケート

レプリケート

パーティション・キャッシュ

ローカル・キャッシュ+パーティション・キャッシュ

ローカル・キャッシュ

読取りパフォーマンス

即時5

即時5

ローカル・キャッシュ: 即時5 リモート: ネットワーク速度 1

ローカル・キャッシュ: 即時5 リモート: ネットワーク速度 1

即時5

フォルト・トレランス性

非常に高い

非常に高い

構成可能 4 (0から非常に高い)

構成可能 4 (0から非常に高い)

0

書込みパフォーマンス

高速 2

高速 2

非常に高速 3

非常に高速 3

即時5

メモリー使用量(JVM別)

DataSize

DataSize

DataSize/JVMs x Redundancy

LocalCache + [DataSize / JVMs]

DataSize

整合性

完全な整合性あり

完全な整合性あり

完全な整合性あり

完全な整合性あり6

N/A

メモリー使用量(合計)

JVMs x DataSize

JVMs x DataSize

Redundancy x DataSize

[Redundancy x DataSize] + [JVMs x LocalCache]

N/A

ロック機能

完全に機能

なし

完全に機能

完全に機能

完全に機能

一般的な用途

メタデータ

N/A(ニア・キャッシュを参照)

読取り/書込みキャッシュ

アクセス・アフィニティのある読取り頻度の高いキャッシュ

ローカル・データ

注意:

1. 概算では、100Mbイーサネットの場合、ネットワークで100KBのオブジェクトを1つ読み取るのに最大20ミリ秒を通常必要とします。ギガビット・イーサネットでは一般に、1KBの複数オブジェクトのネットワークでの読取りが1ミリ秒未満になります。

2. JVMの数に応じて、UDPマルチキャスト操作、またはいくつかのUDPユニキャスト操作が必要です。

3. 冗長性のレベルに応じて、いくつかのUDPユニキャスト操作が必要です。

4. パーティション・キャッシュでは、バックアップのレベルを必要な数だけ構成することも、まったく構成しないこともできます。ほとんどのインストールでは、バックアップ・コピーを1つ使用します(合計で2コピー)。

5. ごくわずかな処理を必要とする(一般にはミリ秒未満のパフォーマンス)、ローカルのCPUまたはメモリーのパフォーマンスによって制限されます。

6. リスナーベースのニア・キャッシュには整合性が確保されています。失効ベースのニア・キャッシュでは、非トランザクション読取りについては部分的な整合性が確保され、トランザクション・アクセスについては整合性が確保されています。

13 キャッシュの構成

この章では、Coherenceキャッシュ構成のデプロイメント・ディスクリプタを使用してアプリケーションが使用するキャッシュを定義および構成する方法について詳しく説明します。キャッシュ構成デプロイメント・ディスクリプタのすべての使用可能な要素の完全なリファレンスについては、付録B「キャッシュ構成の要素」を参照してください。また、様々なサンプルのキャッシュの構成については、第18章「キャッシュの構成例」を参照してください。

この章には次の項が含まれます:

- 概要

- キャッシュ・マッピングの定義

- キャッシュ・スキームの定義

- スキームの継承の使用

- キャッシュ・スキーム・プロパティの使用

- パラメータ・マクロの使用

13.1 概要

キャッシュは、Coherenceキャッシュ構成デプロイメント・ディスクリプタで構成されます。デフォルトでは、クラスパスで最初に検出されたcoherence-cache-config.xmlデプロイメント・ディスクリプタ・ファイルがロードされます。Coherenceのcoherence.jarライブラリには、サンプルのcoherence-cache-config.xmlファイルがあります。別のcoherence-cache-config.xmlファイルを使用するには、そのファイルをクラスパスに配置し、coherence.jarライブラリの前にそのファイルがロードされるようにする必要があります。そうしないと、サンプルのキャッシュ構成デプロイメント・ディスクリプタが使用されます。キャッシュ構成デプロイメント・ディスクリプタを指定するためのその他の方法については、「キャッシュ構成ファイルの指定」を参照してください。

キャッシュ構成ディスクリプタでは、アプリケーション・コードに依存せずにキャッシュを定義できます。実行時に、アプリケーションではディスクリプタで定義された名前を使用してキャッシュを参照し、キャッシュのインスタンスを取得します。それによって、キャッシュの定義に依存することなくアプリケーション・コードを作成できるようになります。この方法では、キャッシュ定義の変更時にアプリケーション・コードを変更する必要がありません。また、キャッシュ定義の再利用性が最大限に高められます。

キャッシュ構成ディスクリプタのスキーマは、coherence-cache-config.xsdファイルで定義されます。このファイルにより、coherence-cache-config-base.xsdファイルがインポートされ、これによりさらに暗黙的にcoherence-config-base.xsdファイルがインポートされます。このファイルは、coherence.jarファイルのルートにあります。キャッシュ構成デプロイメント・ディスクリプタは、<caching-scheme-mapping>要素と<caching-schemes>要素という2つの主要要素で構成されます。これらの要素の詳細は、この章で後述します。これらの要素は、キャッシュ・スキームの定義、およびキャッシュ・スキームにマップされるキャッシュ名の定義に使用されます。

13.2 キャッシュ・マッピングの定義

キャッシュ・マッピングでは、キャッシュ名がキャッシュ・スキーム定義にマップされます。このマッピングによって、アプリケーションと基礎となるキャッシュ定義が、ある程度分離されます。この分離により、アプリケーション・コードを変更せずに、キャッシュの実装を必要に応じて変更できるようになります。キャッシュ・マッピングは、基礎となるキャッシュ・スキーム定義に適用される初期化パラメータの設定にも使用できます。

また、<cache-scheme-mapping>ノード内の<cache-mapping>要素を使用して定義されます。キャッシュ・マッピングは必要な数だけ作成できます。キャッシュ・マッピングには、キャッシュ名とキャッシュ名のマップ先のスキーム名を含める必要があります。<cache-mappings>要素の詳細なリファレンスについては、「cache-mapping」を参照してください。

13.2.1 正確なキャッシュ・マッピングの使用

正確なキャッシュ・マッピングでは、個別のキャッシュ名がキャッシュ・スキーム定義にマップされます。アプリケーションでキャッシュを使用するには、マッピングで指定されたとおりの名前で指定する必要があります。例13-1では、キャッシュ名exampleをdistributedというスキーム名の分散キャッシュ・スキーム定義にマップする、単一キャッシュのマッピングを作成します。

例13-1 正確なキャッシュ・マッピングのサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
</distributed-scheme>
</caching-schemes>
</cache-config>

13.2.2 名前パターン・キャッシュ・マッピングの使用方法

名前パターン・キャッシュ・マッピングを使用すると、アプリケーションでキャッシュ名を指定する際にパターンを使用できます。パターンではアスタリスク(*)ワイルドカードを使用できます。名前パターンを使用することで、アプリケーションでキャッシュの正確な名前を認識する必要がなくなります。例13-2では、キャッシュ・マッピングを2つ作成します。最初のマッピングでは、ワイルドカード(*)を使用して、任意のキャッシュ名をdistributedというスキーム名の分散キャッシュ・スキーム定義にマップします。2番目のマッピングでは、名前パターンaccount-*をaccount-distributedというスキーム名のキャッシュ・スキーム定義にマップします。

例13-2 キャッシュ名パターン・マッピングのサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>account-*</cache-name>
<scheme-name>account-distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
</distributed-scheme>
<distributed-scheme>
<scheme-name>account-distributed</scheme-name>
</distributed-scheme>
</caching-schemes>
</cache-config>

最初のマッピングでは、アプリケーションでのキャッシュの作成時に任意の名前が使用可能であり、その名前がdistributedというスキーム名のキャッシュ・スキーム定義にマップされます。2番目のマッピングでは、アプリケーションでキャッシュ名を指定する際に、パターンを使用する必要があります。この例の場合は、名前の前に接頭辞account-を付ける必要があります。たとえば、アプリケーションでキャッシュ名としてaccount-overdueを指定し、account-distributedというスキーム名のキャッシュ・スキーム定義を使用します。

例13-2に示されているように、複数のキャッシュ・マッピングに一致するキャッシュ名(たとえば、account-overdue)を持つことが可能です。このような場合、正確なキャッシュ・マッピングで定義されているものがあると、それがワイルドカードの一致よりも優先されて常に選択されます。複数のワイルドカードの一致の中で、最後に一致したワイルドカード・マッピング(ファイルで定義された順番に基づく)が選択されます。そのため、あまり限定的でないワイルドカード・パターンをファイルの先に定義し、ファイル後方のより限定的なワイルドカード・パターンでオーバーライドされるようにするのが一般的です。

13.3 キャッシュ・スキームの定義

キャッシュ・スキームは、アプリケーションで使用可能なキャッシュの定義に使用されます。キャッシュ・スキームによって宣言メカニズムが指定されます。これにより、キャッシュを使用するアプリケーションに依存せずにキャッシュを定義できるようになります。そのため、アプリケーションでキャッシュを定義する必要がなくなり、アプリケーションのコードを変更せずにキャッシュを変更できるようになります。キャッシュ・スキームにより、多数のアプリケーションで同一のキャッシュ定義が使用可能となり、キャッシュ定義の再利用も促進されます。

キャッシュ・スキームは<caching-schemes>要素で定義されます。キャッシュ・タイプ(分散、レプリケートなど)ごとに、対応するスキーム要素と、そのタイプのキャッシュ定義に使用されるプロパティがあります。キャッシュ・スキームはネストも可能であり、ニア・キャッシュのように高度にカスタマイズされた複合キャッシュも使用できます。<caching-schemes>要素の詳細なリファレンスについては、「caching-schemes」を参照してください。

この項では、最も使用頻度の高いキャッシュ・タイプのキャッシュ・スキームの定義方法を説明しますが、Coherenceで用意されているすべてのキャッシュ・タイプを網羅しているわけではありません。その他のキャッシュ・タイプのキャッシュ・スキームを定義する手順については、このガイド全体を通して、そのスキームがサポートする機能の説明の一部として記載されています。この項には次のトピックが含まれます:

- 分散キャッシュ・スキームの定義

- レプリケート・キャッシュ・スキームの定義

- オプティミスティック・キャッシュ・スキームの定義

- ローカル・キャッシュ・スキームの定義

- ニア・キャッシュ・スキームの定義

13.3.1 分散キャッシュ・スキームの定義

<distributed-scheme>要素は、分散キャッシュの定義に使用されます。分散キャッシュでは、分散(パーティション)キャッシュ・サービス・インスタンスを使用します。キャッシュ構成ファイルで、分散キャッシュを必要な数だけ定義できます。<distributed-scheme>要素の詳細なリファレンスについては、「distributed-scheme」を参照してください。

例13-3では、スキーム名としてdistributedを使用し、キャッシュ名exampleにマップされる、基本的な分散キャッシュを定義します。<autostart>要素をtrueに設定すると、キャッシュ・サーバー・ノード上でサービスを開始します。

例13-3 分散キャッシュ定義のサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

この例では、分散キャッシュによって、バッキング・マップとして使用されるローカル・キャッシュが定義されます。バッキング・マップの構成の詳細は、第14章「記憶域およびバッキング・マップの実装」を参照してください。

13.3.2 レプリケート・キャッシュ・スキームの定義

<replicated-scheme>要素は、レプリケート・キャッシュの定義に使用されます。レプリケート・キャッシュでは、レプリケート・キャッシュ・サービス・インスタンスを使用します。キャッシュ構成ファイルで、レプリケート・キャッシュを必要な数だけ定義できます。<replicated-scheme>要素の詳細なリファレンスについては、「replicated-scheme」を参照してください。

例13-4では、スキーム名としてreplicatedを使用し、キャッシュ名exampleにマップされる、基本的なレプリケート・キャッシュを定義します。<autostart>要素をtrueに設定すると、キャッシュ・サーバー・ノード上でサービスを開始します。

例13-4 レプリケート・キャッシュ定義のサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>replicated</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<replicated-scheme>
<scheme-name>replicated</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</replicated-scheme>
</caching-schemes>
</cache-config>

この例では、レプリケート・キャッシュによって、バッキング・マップとして使用されるローカル・キャッシュが定義されます。バッキング・マップの構成の詳細は、第14章「記憶域およびバッキング・マップの実装」を参照してください。

13.3.3 オプティミスティック・キャッシュ・スキームの定義

<optimistic-scheme>要素は、オプティミスティック・キャッシュの定義に使用されます。オプティミスティック・キャッシュでは、オプティミスティック・キャッシュ・サービス・インスタンスを使用します。キャッシュ構成ファイルで、オプティミスティック・キャッシュを必要な数だけ定義できます。<optimistic-scheme>要素の詳細なリファレンスについては、「optimistic-scheme」を参照してください。

例13-5では、スキーム名としてoptimisticを使用し、キャッシュ名exampleにマップされる、基本的なオプティミスティック・キャッシュを定義します。<autostart>要素をtrueに設定すると、キャッシュ・サーバー・ノード上でサービスを開始します。

例13-5 オプティミスティック・キャッシュ定義のサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>optimistic</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<optimistic-scheme>
<scheme-name>optimistic</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</optimistic-scheme>
</caching-schemes>
</cache-config>

この例では、オプティミスティック・キャッシュによって、バッキング・マップとして使用されるローカル・キャッシュが定義されます。バッキング・マップの構成の詳細は、第14章「記憶域およびバッキング・マップの実装」を参照してください。

13.3.4 ローカル・キャッシュ・スキームの定義

<local-scheme>要素は、ローカル・キャッシュの定義に使用されます。一般にローカル・キャッシュは、別のキャッシュ・スキームにネストされます(たとえば、ニア・キャッシュのフロント層として)。このため、この要素は、<caching-schemes>、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<near-scheme>、<overflow-scheme>、<read-write-backing-map-scheme>および<backing-map-scheme>の各要素のサブ要素として使用できます。<local-scheme>要素の詳細なリファレンスについては、「local-scheme」を参照してください。

例13-6では、スキーム名としてlocalを使用しキャッシュ名exampleにマップされる、ローカル・キャッシュを定義します。

注意:
一般にローカル・キャッシュは、キャッシュ・サーバー上のスタンドアロン・キャッシュとしては使用されません、また、キャッシュ構成ファイル内のキャッシュ定義がローカル・キャッシュのみの場合、クラスタリング・キャッシュ・サーバー分散は起動しません。

例13-6 ローカル・キャッシュ定義のサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>local</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<local-scheme>
<scheme-name>local</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>32000</high-units>
<low-units>10</low-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>10ms</expiry-delay>
</local-scheme>
</caching-schemes>
</cache-config>

Coherence*Extendを使用する場合は、『Oracle Coherenceリモート・クライアントの開発』のC++クライアント用ローカル・キャッシュの定義に関する項と.NETクライアント用ローカル・キャッシュの構成に関する項を参照してください。

13.3.4.1 ローカル・キャッシュの拡大の制御

表13-0に示すように、<local-scheme>には、キャッシュの拡大を制御するためのオプションのサブ要素がいくつか用意されています。たとえば、サブ要素<low-units>および<high-units>は、キャッシュのサイズを制限します。キャッシュが最大許容サイズに達すると、指定されたエビクション・ポリシー(<eviction-policy>)に従って削除対象エントリが決定され、指定されたより小さなサイズに戻ります。エントリおよびサイズの制限は、該当するスキームの単位換算カリキュレータ(<unit-calculator>)で計算される単位で測定されます。

ローカル・キャッシュに関しては、キャッシュ構成要素<expiry-delay>を使用して、キャッシュに保持されていたアイテムが期限切れになるまでの時間長を構成します。クライアント・スレッドは、キャッシュへのアクセス時にこれらのアクションを開始します。そのため、<expiry-delay>に達していても、クライアント・スレッドがキャッシュにアクセスするまではアクションが開始されません。たとえば、<expiry-delay>値が10秒(10s)に設定されていて、クライアントがキャッシュにアクセスするのが15秒後である場合は、15秒後に有効期限切れになります。

注意:
エビクションを実行するのはクライアント・スレッドであり、バックグラウンド・スレッドではありません。さらに、expiry-delayのパラメータ(cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

13.3.4.2 カスタム・エビクション・ポリシーの指定

LocalCacheクラスは、サイズの制限されたキャッシュに使用されます。これは、ヒープ上のオブジェクトのキャッシュ(ローカル・キャッシュやニア・キャッシュのフロント部分など)、およびパーティション・キャッシュのバッキング・マップの両方に使用されます。アプリケーションでは、LocalCacheで使用するカスタム・エビクション・ポリシーを指定できます。

Coherenceのデフォルトのエビクション・ポリシーは大半のワークロードに対して非常に効率的であり、ほとんどのアプリケーションでカスタム・ポリシーを提供する必要がなくなります。一般的に、エビクション・ポリシーを使用するのは、削除されたデータがバッキング・システム(ニア・キャッシュのバック部分またはデータベース)に存在する場合に限定することをお薦めします。エビクションは、論理操作(エンティティの削除)ではなく、物理操作(メモリーの解放)として扱ってください。

例13-7は、単純なカスタム・エビクション・ポリシーの実装を示しています。

例13-7 カスタム・エビクション・ポリシーの実装

package com.tangosol.examples.eviction;

import com.tangosol.net.cache.AbstractEvictionPolicy;
import com.tangosol.net.cache.ConfigurableCacheMap;
import com.tangosol.net.cache.LocalCache;
import com.tangosol.net.BackingMapManagerContext;
import com.tangosol.util.ConverterCollections;
import java.util.Iterator;
import java.util.Map;

/**
* Custom eviction policy that evicts items randomly (or more specifically,
* based on the natural order provided by the map's iterator.)
* This example may be used in cases where fast eviction is required
* with as little processing as possible.
*/
public class SimpleEvictionPolicy
extends AbstractEvictionPolicy
{
/**
* Default constructor; typically used with local caches or the front
* parts of near caches.
*/
public SimpleEvictionPolicy()
{
}

/**
* Constructor that accepts {@link BackingMapManagerContext}; should
* be used with partitioned cache backing maps.
*
* @param ctx  backing map context
*/
public SimpleEvictionPolicy(BackingMapManagerContext ctx)
{
m_ctx = ctx;
}

/**
* {@inheritDoc}
*/
public void entryUpdated(ConfigurableCacheMap.Entry entry)
{
}

/**
* {@inheritDoc}
*/
public void entryTouched(ConfigurableCacheMap.Entry entry)
{
}

/**
* {@inheritDoc}
*/
public void requestEviction(int cMaximum)
{
ConfigurableCacheMap cache = getCache();
Iterator iter  = cache.entrySet().iterator();

for (int i = 0, c = cache.getUnits() - cMaximum; i < c && iter.hasNext();
i++)
{
ConfigurableCacheMap.Entry entry  = (ConfigurableCacheMap.Entry)
iter.next();
StringBuffer               buffer = new StringBuffer();

// If the contents of the entry (for example the key/value) need
// to be examined, invoke convertEntry(entry) in case
// the entry must be deserialized
Map.Entry convertedEntry = convertEntry(entry);
buffer.append("Entry: ").append(convertedEntry);

// Here's how to get metadata about creation/last touched
// timestamps for entries.  This information might be used
// in determining what gets evicted.
if (entry instanceof LocalCache.Entry)
{
buffer.append(", create millis=");
buffer.append(((LocalCache.Entry) entry).getCreatedMillis());
}
buffer.append(", last touch millis=");
buffer.append(entry.getLastTouchMillis());

// This output is for illustrative purposes; this may generate
// excessive output in a production system
System.out.println(buffer);

// iterate and remove items
// from the cache until below the maximum.  Note that
// the non converted entry key is passed to the evict method
cache.evict(entry.getKey());
}
}

/**
* If a {@link BackingMapManagerContext} is configured, wrap the
* Entry with {@link ConverterCollections.ConverterEntry} in order
* to deserialize the entry.
*
* @see ConverterCollections.ConverterEntry
* @see BackingMapManagerContext
*
* @param entry  entry to convert if necessary
*
* @return an entry that deserializes its key and value if necessary
*/
protected Map.Entry convertEntry(Map.Entry entry)
{
BackingMapManagerContext ctx = m_ctx;
return ctx == null ? entry :
new ConverterCollections.ConverterEntry(entry,
ctx.getKeyFromInternalConverter(),
ctx.getValueFromInternalConverter(),
ctx.getValueToInternalConverter());
}

private BackingMapManagerContext m_ctx;
}

例13-8は、エビクション・ポリシーが指定されているCoherenceキャッシュ構成ファイルを示しています。

例13-8 coherence-cache-config.xmlファイル内のカスタム・エビクション・ポリシー

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>example-near</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<near-scheme>
<scheme-name>example-near</scheme-name>
<front-scheme>
<local-scheme>
<eviction-policy>
<class-scheme>
<class-name>
com.tangosol.examples.eviction.SimpleEvictionPolicy
</class-name>
</class-scheme>
</eviction-policy>
<high-units>1000</high-units>
</local-scheme>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-ref>example-distributed</scheme-ref>
</distributed-scheme>
</back-scheme>
<invalidation-strategy>all</invalidation-strategy>
<autostart>true</autostart>
</near-scheme>

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme>
<eviction-policy>
<class-scheme>
<class-name>
com.tangosol.examples.eviction.SimpleEvictionPolicy
</class-name>
<init-params>
<!--
Passing the BackingMapManagerContext to the eviction policy;
this is required for deserializing entries
-->
<init-param>
<param-type>
com.tangosol.net.BackingMapManagerContext</param-type>
<param-value>{manager-context}</param-value>
</init-param>
</init-params>
</class-scheme>
</eviction-policy>
<high-units>20</high-units>
<unit-calculator>binary</unit-calculator>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

13.3.5 ニア・キャッシュ・スキームの定義

<near-scheme>要素は、ニア・キャッシュの定義に使用されます。ニア・キャッシュは、2つのキャッシュを含む複合キャッシュです。<front-scheme>要素は、ローカル(フロント層)キャッシュの定義に使用され、<back-scheme>要素は(バック層)キャッシュの定義に使用されます。一般に、ローカル・キャッシュはフロント層に使用されますが、フロント層は、Javaオブジェクトをベースとするスキーム(<class-scheme>を使用)およびJVMヒープ以外をベースとするキャッシュ(<external-scheme>または <paged-external-scheme>を使用)も使用できます。バック層のキャッシュは、<back-scheme>要素によって記述されます。バック層キャッシュには、任意のクラスタ化キャッシュ・タイプおよび任意のスタンドアロンのキャッシュ・タイプを使用できます。<near-scheme>要素の詳細なリファレンスについては、「near-scheme」を参照してください。

例13-9では、スキーム名としてnearを使用し、キャッシュ名exampleにマップされるニア・キャッシュを定義します。フロント層はローカル・キャッシュでバック層は分散キャッシュです。

注意:
ニア・キャッシュはキャッシュ・クライアントに使用され、一般にキャッシュ・サーバーでは使用されません。また、キャッシュ構成ファイル内のキャッシュ定義がニア・キャッシュのみの場合、キャッシュ・サーバーは起動しません。

例13-9 ニア・キャッシュ定義のサンプル

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>near</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<near-scheme>
<scheme-name>near</scheme-name>
<front-scheme>
<local-scheme/>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-name>near-distributed</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</back-scheme>
</near-scheme>
</caching-schemes>
</cache-config>

Coherence*Extendを使用する場合は、『Oracle Coherenceリモート・クライアントの開発』のC++クライアント用ニア・キャッシュの定義に関する項と.NETクライアント用ニア・キャッシュの定義に関する項を参照してください。

13.3.5.1 ニア・キャッシュの無効化戦略

<invalidation-strategy>は、ニア・キャッシュのオプションのサブ要素です。フロント層およびバック層のオブジェクトの同期を保つ戦略を指定するには、無効化戦略が使用されます。ニア・キャッシュでは、バック・キャッシュの特定のイベントをリスニングして、フロント・キャッシュ内のエントリを自動的に更新または無効化するように構成できます。ニア・キャッシュでは、バック・キャッシュの他のプロセスによって変更されたフロント・キャッシュのエントリの無効化戦略が5通りあり、バック・キャッシュで実装されるインタフェースに応じた戦略を選択できます。

注意:
allの無効化戦略を使用する際に多数のエントリを変更するキャッシュ操作(クリア操作など)が存在する場合、イベントが大量に発生してネットワークが飽和状態になるおそれがあります。

表13-1は、これらの無効化戦略についてまとめたものです。無効化戦略、およびリードスルー/ライトスルー戦略の詳細は、第15章「データ・ソースのキャッシュ」を参照してください。

表13-1 ニア・キャッシュの無効化戦略

戦略名

説明

自動

戦略が指定されていない場合のデフォルトの戦略。この戦略は、present戦略とまったく同じです。

存在

この戦略は、現在フロント・キャッシュに存在しているアイテムのみに関連するバック・キャッシュのイベントがニア・キャッシュでリスニングされるように指定します。この戦略は、フロント・キャッシュの各インスタンスに、フロント・キャッシュの他のインスタンス(スティッキーなデータ・アクセス・パターンなど)に関連するデータの個別のサブセットが含まれている場合に最適です。

すべて

この戦略は、バック・キャッシュのすべてのイベントがニア・キャッシュでリスニングされるように指定します。この戦略は、フロント・キャッシュの様々なインスタンス間に著しい重複が存在する、読取り頻度の高い段階的なアクセス・パターンに最適です。

論理

この戦略は、統合削除でないすべてのバッキング・マップ・イベントがニア・キャッシュでリスニングされるように指示します。統合削除イベントは、エビクションまたは期限切れの結果として出力されることがあります。この無効化戦略では、バッキング・マップから統合的に削除されたキャッシュ・エントリをフロント・マップに含めることができます。その後にバッキング・マップにこれらのエントリを再挿入すると、フロント・マップの対応するエントリは無効化されます。

なし

この戦略は、無効化イベントを一切リスニングしないようにキャッシュに指示します。これは、パフォーマンスとスケーラビリティが低く、現在値ではない可能性があるデータの使用がビジネス要件で許可されている場合に最適です。データの鮮度は、フロント・キャッシュに対する十分に簡潔なエビクション・ポリシーを使用することで保証できます。

13.4 スキームの継承の使用

スキームの継承を使用すると、別のスキームを継承し、継承したスキームのプロパティを必要に応じて選択的にオーバーライドすることにより、キャッシュ・スキームを作成できます。こうした柔軟性によって、キャッシュ・スキームの管理が容易になり、キャッシュ・スキームの再利用が促進されます。キャッシュ・スキーム定義で<scheme-ref>要素を使用して、継承元のキャッシュ・スキームの名前を指定します。

例13-10では、同等の分散キャッシュ・スキームを2つ作成します。最初の定義では、バッキング・マップに使用されるローカル・スキームを明示的に構成します。2番目の定義では、<scheme-ref>要素を使用して、LocalSizeLimitedという名前のローカル・スキームを継承します。

例13-10 キャッシュ・スキーム参照の使用

<distributed-scheme>
<scheme-name>DistributedInMemoryCache</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme>
<eviction-policy>LRU</eviction-policy>
<high-units>1000</high-units>
<expiry-delay>1h</expiry-delay>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>

<distributed-scheme>
<scheme-name>DistributedInMemoryCache</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>LocalSizeLimited</scheme-ref>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>

<local-scheme>
<scheme-name>LocalSizeLimited</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>1000</high-units>
<expiry-delay>1h</expiry-delay>
</local-scheme>

例13-10では、最初の分散スキーム定義の方が簡潔ですが、2番目の定義ではLocalSizeLimitedスキームを複数のスキームで容易に再利用できます。例13-11では、複数のスキームで同じLocalSizeLimitedベース定義が再利用され、expiry-delayプロパティがオーバーライドされます。

例13-11 複数のキャッシュ・スキームでのスキーム継承の使用

<distributed-scheme>
<scheme-name>DistributedInMemoryCache</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>LocalSizeLimited</scheme-ref>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>

<replicated-scheme>
<scheme-name>ReplicatedInMemoryCache</scheme-name>
<service-name>ReplicatedCache</service-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>LocalSizeLimited</scheme-ref>
<expiry-delay>10m</expiry-delay>
</local-scheme>
</backing-map-scheme>
</replicated-scheme>

<local-scheme>
<scheme-name>LocalSizeLimited</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>1000</high-units>
<expiry-delay>1h</expiry-delay>
</local-scheme>

13.5 キャッシュ・スキーム・プロパティの使用

キャッシュ・スキーム・プロパティは、必要に応じて特定のアプリケーションにおけるキャッシュの動作を変更します。それぞれのキャッシュ・スキーム・タイプには、そのキャッシュで有効な独自のプロパティ・セットがあります。キャッシュのプロパティは、キャッシュ・スキーム定義内で、それぞれのプロパティの要素を使用して設定されます。各キャッシュ・スキーム・タイプでサポートされるすべてのプロパティのリファレンスについては、付録B「キャッシュ構成の要素」を参照してください。

キャッシュ・スキーム定義で別の値が明示的に指定されている場合を除き、キャッシュ・プロパティでは多くの場合にデフォルト値が使用されます。クラスタ化キャッシュ(分散、レプリケートおよびオプティミスティック)では、それぞれのキャッシュ・サービス定義の指定に従ってデフォルト値が使用されます。キャッシュ・サービスは、オペレーション・デプロイメント・ディスクリプタで定義されます。オペレーション・オーバーライド・ファイルを使用してプロパティ値を変更することはできますが、一般にキャッシュのプロパティはキャッシュ・スキーム定義で設定されます。

例13-12では、サービス・スレッド・カウント・プロパティとリクエスト・タイムアウト・プロパティを設定する基本的な分散キャッシュ・スキームを作成します。さらに、バッキング・マップに使用されるローカル・スキームによって、ローカル・キャッシュのサイズを制限するプロパティが設定されます。キャッシュ・スキーム・プロパティを使用する手順については、このガイド全体を通して、そのスキームがサポートする機能の説明の一部として記載されています。

例13-12 キャッシュ・プロパティの設定

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>DistributedInMemoryCache</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>DistributedInMemoryCache</scheme-name>
<service-name>DistributedCache</service-name>
<thread-count>4</thread-count>
<request-timeout>60s</request-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>LocalSizeLimited</scheme-ref>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>

<local-scheme>
<scheme-name>LocalSizeLimited</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>1000</high-units>
<expiry-delay>1h</expiry-delay>
</local-scheme>
</caching-schemes>
</cache-config>

13.6 パラメータ・マクロの使用

キャッシュ構成デプロイメント・ディスクリプタは、パラメータ・マクロの使用をサポートしています。パラメータ・マクロは、実行時に実際の値で置換されるリテラル文字列です。Coherenceには事前定義済のマクロが含まれ、ユーザー定義のマクロも許可されています。この項には次のトピックが含まれます:

- ユーザー定義パラメータ・マクロの使用

- 事前定義済パラメータ・マクロの使用

13.6.1 ユーザー定義パラメータ・マクロの使用

ユーザー定義パラメータ・マクロによって、スキーム内のプロパティ値は、実行時にキャッシュ・マッピング初期化パラメータ内で構成された値で置換されます。ユーザー定義パラメータ・マクロによってキャッシュ・スキーム定義は最大限再利用され、キャッシュ構成ファイルのサイズは大幅に削減できます。

注意:
パラメータ・マクロは、スレッド・カウント、パーティション・カウント、サービス名など、サービスにスコープが設定された(同じサービスのすべてのキャッシュで共有する)アイテムでは使用しないでください。パラメータ・マクロは、有効期限、high units、キャッシュ・ストアなど、キャッシュにスコープが設定されたアイテムで使用する必要があります。

ユーザー定義パラメータ・マクロを定義するには、リテラル文字列をプロパティ値として中カッコの中に入れます。文字列の最後に前にスペースを付けた値を置くことによって、パラメータ・マクロにオプションのデフォルト値も含めることもできます。ユーザー定義パラメータ・マクロの形式は、次のとおりです:

{user-defined-name default_value}

次の例は、back-size-limitというユーザー定義マクロを作成します。マクロはバッキング・マップの<high-units>プロパティとして使用され、プロパティ値は実行時に置換されます。マクロは、<high-units>プロパティのデフォルト値として500を指定しています。

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<backing-map-scheme>
<local-scheme>
<high-units>{back-size-limit 500}</high-units>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>

実行時に、<high-units>の値はキャッシュ・マッピング定義で定義される初期化パラメータを使用して置換されます。次の例では、<init-param>要素を使用し、<param-name>要素をback-size-limitに、<param-value>要素を1000に設定することによって、デフォルト値の500を1000でオーバーライドしています。<init-param>要素の詳細なリファレンスについては、「init-param」を参照してください。

<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>
<caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<backing-map-scheme>
<local-scheme>
<high-units>{back-size-limit 500}</high-units>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>

ユーザー定義パラメータ・マクロの使用の利点は、複数のキャッシュ・マッピングで同じキャッシュ・スキームを使用でき、必要に応じて異なるプロパティ値を設定できることです。例13-13は、同じキャッシュ・スキームを再利用する2つのキャッシュ・マッピングを示しています。ただし、マッピングは<high-units>要素に異なる値を持つキャッシュとなります。

例13-13 キャッシュ・マッピングからのユーザー定義マクロのオーバーライド

...
<caching-scheme-mapping>
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>
<caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<backing-map-scheme>
<local-scheme>
<high-units>{back-size-limit 500}</high-units>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>

13.6.2 事前定義済パラメータ・マクロの使用

Coherenceには事前定義済のパラメータ・マクロが含まれているため、カスタム・コーディングを最小限に抑えて、一般的に使用される属性をクラス・コンストラクタ・パラメータの構成時に指定することができます。マクロは中カッコに入れる必要があり、param-typeまたはparam-valueのどちらか要素に固有です。

表13-2では、指定可能な事前定義済パラメータ・マクロについて説明しています。

表13-2 キャッシュ構成の事前定義済パラメータ・マクロ

<param-type>

<param-value>

説明

java.lang.String

{cache-name}

現在のキャッシュ名をコンストラクタ・パラメータとして渡すために使用します。例:

<class-name>com.mycompany.cache.CustomCacheLoader
</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>

java.lang.ClassLoader

{class-loader}

現在のクラスローダーをコンストラクタ・パラメータとして渡すために使用します。例:

<class-name>com.mycompany.cache.CustomCacheLoader
</class-name>
<init-params>
<init-param>
<param-type>java.lang.ClassLoader</param-type>
<param-value>{class-loader}</param-value>
</init-param>
</init-params>

com.tangosol.net.BackingMapManagerContext

{manager-context}

現在のBackingMapManagerContextオブジェクトをコンストラクタ・パラメータとして渡すために使用します。例:

<class-name>com.mycompany.cache.CustomCacheLoader
</class-name>
<init-params>
<init-param>
<param-type>
com.tangosol.net.BackingMapManagerContext
</param-type>
<param-value>{manager-context}</param-value>
</init-param>
</init-params>

{scheme-ref}

local-scheme

<class-scheme>、<local-scheme>または<file-scheme>によって定義されるオブジェクトを、指定した<scheme-name>値でインスタンス化して、コンストラクタ・パラメータとして使用します。例:

<class-scheme>
<scheme-name>dbconnection</scheme-name>
<class-name>com.mycompany.dbConnection</class-name>
<init-params>
<init-param>
<param-name>driver</param-name>
<param-type>String</param-type>
<param-value>org.gjt.mm.mysql.Driver
</param-value>
</init-param>
<init-param>
<param-name>url</param-name>
<param-type>String</param-type>
<param-value>
jdbc:mysql://dbserver:3306/companydb
</param-value>
</init-param>
<init-param>
<param-name>user</param-name>
<param-type>String</param-type>
<param-value>default</param-value>
</init-param>
<init-param>
<param-name>password</param-name>
<param-type>String</param-type>
<param-value>default</param-value>
</init-param>
</init-params>
</class-scheme>
...
<class-name>com.mycompany.cache.CustomCacheLoader
</class-name>
<init-params>
<init-param>
<param-type>{scheme-ref}</param-type>
<param-value>dbconnection</param-value>
</init-param>
</init-params>

{cache-ref}

キャッシュ名

指定したキャッシュ名に対するNamedCache参照を取得するために使用します。次の構成例を参照してください。

<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>boston-*</cache-name>
<scheme-name>wrapper</scheme-name>
<init-params>
<init-param>
<param-name>delegate-cache-name</param-name>
<param-value>london-*</param-value>
</init-param>
</init-params>
</cache-mapping>
<cache-mapping>
<cache-name>london-*</cache-name>
<scheme-name>partitioned</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<class-scheme>
<scheme-name>wrapper</scheme-name>
<class-name>
com.tangosol.net.cache.WrapperNamedCache
</class-name>
<init-params>
<init-param>
<param-type>{cache-ref}</param-type>
<param-value>{delegate-cache-name}
</param-value>
</init-param>
<init-param>
<param-type>string</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
<distributed-scheme>
<scheme-name>partitioned</scheme-name>
<service-name>partitioned</service-name>
<backing-map-scheme>
<local-scheme>
<unit-calculator>BINARY</unit-calculator>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

CacheFactory.getCache("london-test")のコールによって、パーティション化された標準のキャッシュ参照が生成されます。一方、CacheFactory.getCache("boston-test")のコールでは、delegate-cache-nameパラメータの値をlondon-testにして、CacheFactory.getCache("london-test")のコールによって返されるNamedCacheに委任するWrapperNamedCacheのインスタンスを構築します。

14 記憶域およびバッキング・マップの実装

この章では、Coherenceにおける記憶域の実装方法と、Coherenceバッキング・マップの構成方法について説明します。

この章には次の項が含まれます:

- キャッシュ・レイヤー

- ローカル記憶域

- 操作

- キャパシティ・プランニング

- パーティション・バッキング・マップの使用

- エラスティック・データ機能を使用したデータの保存

- 非同期バックアップの使用

- デルタ・バックアップの使用

14.1 キャッシュ・レイヤー

Coherenceのパーティション(分散)キャッシュ・サービスは、次の3つのレイヤーに分かれています。

- クライアント・ビュー - 基礎となるパーティション化されたデータへのアクセスを可能にする仮想レイヤー。この層へのアクセスには、 NamedCacheインタフェースが使用されます。このレイヤーでは、NearCacheやContinuousQueryCacheなどの統合データ構造も作成できます。

- ストレージ・マネージャ - クライアント層からのキャッシュ関連リクエストを処理するサーバー側の層です。実際のキャッシュ・データ(プライマリ・コピーおよびバックアップ・コピー)、およびロック、イベント・リスナー、マップ・トリガーなどに関する情報を格納するデータ構造を管理します。

- バッキング・マップ - 実際のデータを格納するサーバー側のデータ構造。

Coherenceでは、即時利用可能なバッキング・マップ実装およびカスタム実装を構成できます。マップ実装における唯一の制約は、ストレージ・マネージャではキーと値がすべて内部(バイナリ)形式で指定されるという点を理解することです。内部データとオブジェクト形式との間の変換を処理するため、ストレージ・マネージャでは、BackingMapManagerContext参照によるバッキング・マップの実装が可能です。

図14-1はバッキング・マップの概念図です。

図14-1 バッキング・マップの記憶域

14.2 ローカル記憶域

ローカル記憶域は、Coherenceで管理されるデータを実際に保存またはキャッシュするデータ構造です。ローカル記憶域を提供するオブジェクトは、同じ標準のコレクション・インタフェースであるjava.util.Mapをサポートする必要があります。Coherenceのローカル記憶域の実装を使用して、レプリケートされたデータや分散データを保存する場合、その機能をバッキング・マップと呼びます。これは、Coherenceがローカル記憶域の実装によって実際に支援(バックアップ)されるためです。その他、ローカル記憶域の一般的な使用法としては、分散キャッシュの前に配置したり、分散キャッシュの後方でバックアップを行うことがあります。

注意:
データをヒープに格納しないバッキング・マップを使用する際には注意してください。特に、実際にヒープに収めるには格納データが多すぎる場合が当てはまります。あるキャッシュ操作(索引なしの問合せなど)では、多数のエントリが横断される可能性があります。これにより、バッキング・マップがそれらのエントリをヒープに格納するようになります。また、パーティション転送(バックアップからのリストアや新規メンバーが参加した場合のパーティション所有権の転送など)によって、バッキング・マップが多数のエントリをヒープに格納するようになります。これは、GC問題とOutOfMemoryエラーの発生の原因になる可能性があります。

Coherenceは、次のローカル記憶域の実装をサポートします。

- セーフなHashMap: デフォルトのロスレス実装です。ロスレス実装には、JavaのHashtableクラス同様、サイズ制限も自動失効もありません。つまり、自身に含まれるキャッシュ項目を削除する(損失する)ことのない実装です。この特殊なHashMap実装は、非常に高度なスレッドレベルの並行性にあわせて最適化されていますデフォルト実装にはcom.tangosol.util.SafeHashMapクラスを、キャッシュ・イベントの送信が必要な実装にはcom.tangosol.util.ObservableHashMapを使用します。これらの実装はスレッドセーフです。

- ローカル・キャッシュ: デフォルトのサイズ制限および自動失効の実装です。構成の詳細は、「キャパシティ・プランニング」を参照してください。ローカル・キャッシュでは、キャッシュのサイズが制限されており、特定の期間の経過後にキャッシュ・アイテムが自動的に期限切れします。デフォルト実装にはcom.tangosol.net.cache.LocalCacheを使用します。この実装はスレッド・セーフであり、キャッシュ・イベント、com.tangosol.net.CacheLoader、CacheStore、および構成可能でプラガブルなエビクション・ポリシーがサポートされます。

- 読取り/書込みバッキング・マップ: これは、キャッシュ・ミスの際にバッキング・ストア(データベースなど)からロードする、キャッシュのデフォルトのバッキング・マップの実装です。これは、読取り専用キャッシュ(コンシューマ・モデル)として構成することも、ライトスルーまたはライトビハインド・キャッシュ(コンシューマ/プロデューサ・モデル)として構成することもできます。ライトスルーおよびライトビハインド・モードは、分散キャッシュ・サービスで使用することのみを目的としています。ニア・キャッシュとともに使用する場合、ニア・キャッシュと分散キャッシュの同期を維持する必要があるのであれば、(ニア・キャッシュを無効化する目的で)このバッキング・マップをSeppukuベースのニア・キャッシュと組み合せて使用できます。デフォルト実装にはcom.tangosol.net.cache.ReadWriteBackingMapクラスを使用します。

- バイナリ・マップ(Java NIO): 自身の情報をメモリー内(ただしJavaヒープ外)に保存したり、メモリー・マップ・ファイルにも保存できるバッキング・マップ実装です。つまり、Javaヒープ・サイズには影響せず、アプリケーションの一時停止の原因となり得る関連したJVMガベージ・コレクションのパフォーマンスにも影響しないことを意味します。この実装はまた、分散キャッシュのバックアップにも使用できます。これは高可用性を実現するためにバックアップを必要とする、読取り専用(または読取りを主体とする)キャッシュで特に有用です。このバックアップがJavaヒープ・サイズに影響しないにもかかわらず、フェイルオーバー時には瞬時に使用できるためです。

- シリアライズ・マップ: これは、ディスクに保存できる形式にデータを変換するバッキング・マップの実装です。この形式は、シリアライズされた形式と呼ばれています。これには、シリアライズ形式のデータを格納する別個のcom.tangosol.io.BinaryStoreオブジェクトが必要です。シリアライズ・マップは、BinaryStoreのすべてのカスタム実装をサポートします。シリアライズ・マップのデフォルト実装にはcom.tangosol.net.cache.SerializationMapを使用します。

- シリアライズ・キャッシュ: LRUエビクション・ポリシーをサポートするSerializationMapの拡張機能です。たとえば、シリアライズ・キャッシュによって、ディスク・ファイルのサイズを制限できます。シリアライズ・キャッシュのデフォルト実装にはcom.tangosol.net.cache.SerializationCacheを使用します。

- ジャーナル: これは、RAM、ディスクのいずれかまたは両方にデータを格納するバッキング・マップの実装です。ジャーナルには、com.tangosol.io.journal.JournalBinaryStoreクラスが使用されます。ジャーナルの詳細は、「エラスティック・データ機能を使用したデータの保存」を参照してください。

- オーバーフロー・マップ: オーバーフロー・マップは実際には記憶域を提供しませんが、2つのローカル記憶域の実装を結合し、最初の記憶域が一杯になると、オーバーフローを行って次の記憶域にデータを保存することから、この項で紹介していますOverflowMapのデフォルト実装にはcom.tangosol.net.cache.OverflowMapを使用します。

14.3 操作

バッキング・マップに対して実行される操作にはいくつかのタイプがあります。

- アプリケーションの使用によって必然的に発生するアクセスおよび更新操作。たとえば、NamedCache.get()コールでは対応するバッキング・マップに対するMap.get()コールが発生します。また、NamedCache.invoke()コールではMap.get()とそれに続くMap.put()が発生する場合があり、NamedCache.keySet(filter)コールではMap.entrySet().iterator()ループが発生する場合があります。

- 時間ベースの有効期限またはサイズ・ベースのエビクションによって発生する削除操作。たとえば、クライアント層からのNamedCache.get()コールまたはNamedCache.size()コールでは、エントリの有効期限切れによるMap.remove()コールが発生する場合があります。また、NamedCache.put()コールでは、バッキング・マップの合計データ量が構成済の高水位標値に達した場合に、複数のMap.remove()コールが(複数のキーに対して)発生する場合があります。

- CacheStore.load()操作によって発生する挿入操作(リードスルー機能またはリードアヘッド機能が構成されたバッキング・マップの場合)

- パーティション分散によって発生する統合アクセスおよび更新(クラスタ・ノードのフェイルオーバーまたはフェイルバックから発生する場合もあります)。この場合は、アプリケーション層のコールがなくても、バッキング・マップのいくつかのエントリが挿入または削除されることがあります。

14.4 キャパシティ・プランニング

バッキング・マップでは、実際の実装方法に応じて、次の方法でキャッシュ・データが格納されます。

- ヒープ上メモリー

- ヒープ外メモリー

- ディスク(メモリーマップ・ファイルまたはインプロセスDB)

- ソリッド・ステート・デバイス(ジャーナル・ファイル)

- 上述のいずれかの組合せ

データをメモリーに格納することで、アクセスおよび更新の待機時間が大幅に短縮されます。また、これは最も一般的に使用される方法でもあります。

たいていの場合、アプリケーションでは、データ・グリッドに配置されるデータの合計量が事前設定されたメモリー量を超えないようにする必要があります。これは、アプリケーション層ロジックによって直接制御することも、サイズ・ベースまたは有効期限ベースのエビクションによって自動的に制御することもできます。その結果、Coherenceのキャッシュに保持されるデータの合計量は、対応するすべてのバッキング・マップ(対応するパーティション・キャッシュ・サービスを記憶域有効モードで実行するクラスタ・ノードごとに1つ)のデータの合計量と等しくなります。

次のキャッシュ構成の抜粋について検討してみましょう。

<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>

このバッキング・マップはcom.tangosol.net.cache.LocalCacheのインスタンスであり、事前設定されたサイズの制約がなく、明示的に制御する必要があります。制御できない場合は、JVMがメモリー不足になります。次の例では、バッキング・マップのサイズの制約を構成します。

<backing-map-scheme>
<local-scheme>
<eviction-policy>LRU</eviction-policy>
<high-units>100</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</local-scheme>
</backing-map-scheme>

このバッキング・マップもcom.tangosol.net.cache.LocalCacheですが、100MBの容量制限があります。このバッキング・マップで保持されるデータの合計量が高水位標を超えると、バッキング・マップから一部のエントリが削除され、データの量が低水位標値(<low-units>構成要素、デフォルトでは<high-units>の80%)まで減少します。削除されるエントリの選択方法は、LRU(最低使用頻度)エビクション・ポリシーに従います。その他のオプションには、LFU(最低アクセス頻度)および混合(LRUとLFUの組合せ)があります。<high-units>の値はInteger.MAX_VALUE (約2GB)に制限されます。この制限を解除するため(ただし後方互換性は保持)、Coherenceでは<unit-factor>要素が使用されます。たとえば、<high-units>値が8192で<unit-factor>が1048576の場合、高水位標値は8GBになります。

次のバッキング・マップは、未更新の状態のまま1時間を超えたエントリを自動的に削除します。ただし、これは「安易な」削除方法であり、最終更新から1時間以上経過していればいつでも発生する可能性があります。保証されるのは、1時間を超過したエントリがコール元に返されないことのみです。

<backing-map-scheme>
<local-scheme>
<expiry-delay>1h</expiry-delay>
</local-scheme>
</backing-map-scheme>

次のバッキング・マップは、com.tangosol.net.cache.SerializationCacheのインスタンスであり、拡張(nio)メモリーに値を格納しますが、100MB (100*1048576)の容量制限があります。

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

<backing-map-scheme>
<external-scheme>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>100MB</maximum-size>
</nio-memory-manager>
<high-units>100</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</external-scheme>
</backing-map-scheme>

このキャッシュのバックアップ記憶域は、off-heap(またはfile-mapped)で構成します。

<backup-storage>
<type>off-heap</type>
<initial-size>1MB</initial-size>
<maximum-size>100MB</maximum-size>
</backup-storage>

14.5 パーティション・バッキング・マップの使用

従来のバッキング・マップの実装には、対応するノードが所有するすべてのパーティションのエントリが含まれていました。(パーティション送信時に、クライアントから見て一時的に所有者の存在しない「未完了」エントリも保持されることがありました)。

図14-2は、従来のバッキング・マップ実装の概念図です。

図14-2 従来のバッキング・マップの実装

パーティション・バッキング・マップは、基本的には実際のマップ実装の多重化であり、それぞれのマップには同じパーティションに属するエントリのみが格納されるようになりました。

図14-3は、パーティション・バッキング・マップ実装の概念図です。

図14-3 パーティション・バッキング・マップの実装

パーティション・バッキング・マップを構成するには、<partitioned>要素を、値をtrueに設定して追加します。例:

<backing-map-scheme>
<partitioned>true</partitioned>
<external-scheme>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>50MB</maximum-size>
</nio-memory-manager>
<high-units>8192</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</external-scheme>
</backing-map-scheme>

このバッキング・マップはcom.tangosol.net.partition.PartitionSplittingBackingMapのインスタンスであり、マップを保持する個別のパーティションであるcom.tangosol.net.cache.SerializationCacheのインスタンスから構成され、各パーティションの拡張(nio)メモリーに値が格納されます。nioバッファにはそれぞれ50MBの制限がありますが、バッキング・マップ全体の容量制限は8GB (8192*1048576)です。

14.6 エラスティック・データ機能を使用したデータの保存

エラスティック・データ機能は、メモリーとディスクベースのデバイス間で、シームレスにデータを保存するために使用されます。この機能は、特にSSD (Solid State Disk)などの高速ディスクベースのデバイスを使用する場合に調整され、SSDからデータを読書きする際にメモリーと同等の速度でアクセスできるようにします。エラスティック・データ機能では、ジャーナルという技術を使用して、メモリーとディスク間の保存操作を最適化します。

エラスティック・データには、メモリー内にデータを保存するRAMジャーナルと、ディスクベースのデバイスにデータを保存するフラッシュ・ジャーナルという2つのコンポーネントが含まれます。これらを様々に組み合せ、一般的にはバッキング・マップやバックアップ記憶域に使用しますが、複合キャッシュにも使用できます(たとえば、ニア・キャッシュなど)。RAMジャーナルは、常にフラッシュ・ジャーナルとともに機能し、ディスクへのシームレスなオーバーフローを実現します。

RAMジャーナルおよびフラッシュ・ジャーナルを使用するキャッシュは、キャッシュ構成ファイル内にキャッシュ・スキーム定義の一部として構成されます。必要に応じて、オペレーション・オーバーライド・ファイルを使用して初期状態の構成をオーバーライドし、ジャーナルの動作を構成します。

この項には次のトピックが含まれます:

- ジャーナルの概要

- ジャーナル・スキームの定義

- ジャーナルの動作の変更

14.6.1 ジャーナルの概要

ジャーナル機能とは、ジャーナルと呼ばれる一連の変更において状態の変化を記録する技術です。変更が発生すると、ジャーナルは特定のキーの各値を記録し、メモリー内に保存されるツリー構造により、特定のキーの現在の値を含むジャーナル・エントリが追跡されます。エントリの値を検索するには、最新の値を含むジャーナル・エントリへのポインタを含むツリーでキーを検索します。

キーに新しい値が書き込まれることによりジャーナルの変更情報が古くなると、ジャーナルには古い値が累積されます。一定の間隔で古い値を削除すると、新しい値をジャーナルに書き込むスペースができます。

エラスティック・データ機能には、RAMジャーナル実装とフラッシュ・ジャーナル実装が含まれ、相互にシームレスに機能します。たとえば、RAMジャーナルでメモリーを使用し尽くした場合、フラッシュ・ジャーナルがRAMジャーナルからのオーバーフローを自動的に受け入れることで、キャッシュをRAMのサイズより格段に大きなサイズにまで拡張できます。

注意:
エラスティック・データはキーベース操作を実行する際には理想的ですが、一般的に大規模なフィルタベース操作での使用はお薦めしません。ジャーナルを有効にした場合、大きな結果セットでデータ・グリッド操作(問合せや集計など)を実行する際に追加のキャパシティ・プランニングが必要になります。詳細は、『Oracle Coherenceの管理』を参照してください。

リソース・マネージャはジャーナルを制御します。リソース・マネージャはバイナリ・ストアを作成および使用して、ジャーナルの操作を実行します。バイナリ・ストアは、JournalBinaryStoreクラスで実装されます。バイナリ・ストアを介したすべての読書きは、リソース・マネージャで処理されます。RAMジャーナル用のリソース・マネージャ(RamJournalRM)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM)があります。これらのAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

14.6.2 ジャーナル・スキームの定義

キャッシュ構成ファイルでは、<ramjournal-scheme>および<flashjournal-scheme>要素を使用して、それぞれRAMジャーナルおよびフラッシュ・ジャーナルを構成します。これらのスキーム・タイプの詳細な構成オプションについては、「ramjournal-scheme」および「flashjournal-scheme」を参照してください。

この項には次のトピックが含まれます:

- RAMジャーナル・バッキング・マップの構成

- フラッシュ・ジャーナル・バッキング・マップの構成

- ジャーナル・スキームの参照

- ジャーナルの失効およびエビクションの使用

- バックアップ記憶域でのジャーナル・スキームの使用

- ジャーナル・スキームでのカスタム・マップ実装の有効化

14.6.2.1 RAMジャーナル・バッキング・マップの構成

RAMジャーナル・バッキング・マップを構成するには、キャッシュ定義の<backing-map-scheme>要素の中に<ramjournal-scheme>要素を追加します。次の例では、バッキング・マップにRAMジャーナルを使用する分散キャッシュを作成します。RAMジャーナルは、構成されたメモリー・サイズを超えると、自動的にフラッシュ・ジャーナルに委任します。メモリー設定の変更については、「ジャーナルの動作の変更」を参照してください。

<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheRAMJournal</service-name>
<backing-map-scheme>
<ramjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

14.6.2.2 フラッシュ・ジャーナル・バッキング・マップの構成

フラッシュ・ジャーナル・バッキング・マップを構成するには、キャッシュ定義の<backing-map-scheme>要素の中に<flashjournal-scheme>要素を追加します。次の例では、バッキング・マップにフラッシュ・ジャーナルを使用する分散スキームを作成します。

<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheFlashJournal</service-name>
<backing-map-scheme>
<flashjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

14.6.2.3 ジャーナル・スキームの参照

RAMジャーナル・スキームおよびフラッシュ・ジャーナル・スキームでは、スキーム定義を再利用するためのスキーム参照の使用をサポートします。次の例では、default-ramというRAMスキーム定義を参照することで、分散キャッシュを作成して、RAMジャーナル・バッキング・マップを構成しています。

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheJournal</service-name>
<backing-map-scheme>
<ramjournal-scheme>
<scheme-ref>default-ram</scheme-ref>
</ramjournal-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<ramjournal-scheme>
<scheme-name>default-ram</scheme-name>
</ramjournal-scheme>
</caching-schemes>

14.6.2.4 ジャーナルの失効およびエビクションの使用

RAMジャーナルおよびフラッシュ・ジャーナルはサイズを制限できます。保存するエントリ数を制限し、ジャーナルが一杯になったらエントリを自動的に削除できます。さらに、エントリのサイジングとエビクション・ポリシーの両方のカスタマイズが可能です。次の例では、RAMジャーナルの失効およびエビクション設定を定義しています。

<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheFlashJournal</service-name>
<backing-map-scheme>
<ramjournal-scheme>
<eviction-policy>LFU</eviction-policy>
<high-units>100</high-units>
<low-units>80</low-units>
<unit-calculator>Binary</unit-calculator>
<unit-factor>1</unit-factor>
<expiry-delay>0</expiry-delay>
</ramjournal-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

14.6.2.5 バックアップ記憶域でのジャーナル・スキームの使用

ジャーナル・スキームは、バックアップ記憶域およびバッキング・マップに使用されます。デフォルトでは、バッキング記憶域としてフラッシュ・ジャーナルが使用されます。このデフォルトの動作は、<backup-storage>要素の中のストレージ・タイプを明示的に指定することで、変更できます。次の構成ではバッキング・マップにRAMジャーナルを使用し、明示的にバックアップ記憶域にRAMジャーナルを構成しています。

<caching-schemes>
<distributed-scheme>
<scheme-name>default-distributed-journal</scheme-name>
<service-name>DistributedCacheJournal</service-name>
<backup-storage>
<type>scheme</type>
<scheme-name>example-ram</scheme-name>
</backup-storage>
<backing-map-scheme>
<ramjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<ramjournal-scheme>
<scheme-name>example-ram</scheme-name>
</ramjournal-scheme>
</caching-schemes>

14.6.2.6 ジャーナル・スキームでのカスタム・マップ実装の有効化

必要に応じて、カスタム・バッキング・マップを使用するようにジャーナル・スキームを構成できます。カスタム・マップ実装では、CompactSerializationCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。このAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

カスタム実装を有効にするには、<class-scheme>要素を追加し、その値をカスタム・クラスの完全修飾名に指定します。カスタム・クラスに必要な任意のパラメータは、<init-params>要素を使用して定義できます。次の例では、MyCompactSerializationCacheというカスタム・マップ実装を有効にします。

<flashjournal-scheme>
<scheme-name>example-flash</scheme-name>
<class-name>package.MyCompactSerializationCache</class-name>
</flashjournal-scheme>

14.6.3 ジャーナルの動作の変更

リソース・マネージャはジャーナルの動作を制御します。RAMジャーナル用のリソース・マネージャ(RamJournalRM)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM)があります。クラスタのリソース・マネージャは、tangosol-coherence-override.xmlオペレーション・オーバーライド・ファイルで構成されます。構成オーバーライドが設定されていないと、リソース・マネージャのデフォルトの即時利用可能な設定が使用されます。

この項には次のトピックが含まれます:

- RAMジャーナル・リソース・マネージャの構成

- フラッシュ・ジャーナル・リソース・マネージャの構成

14.6.3.1 RAMジャーナル・リソース・マネージャの構成

<ramjournal-manager>要素は、RAMジャーナルの動作を構成するために使用されます。次のリストは、RAMジャーナルのデフォルト特性を示しています。すべての使用可能な設定およびそのデフォルト値の詳細は、「ramjournal-manager」を参照してください。

- バイナリ値は、デフォルトでは64KBに制限されています(最大は4MB)。フラッシュ・ジャーナルは、バイナリ値が構成済制限を超えると自動的に使用されます。

- 個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2MBに制限されています(最大は2GB)。最大ファイル・サイズは変更しないでください。

- ジャーナルは最大512個のファイルで構成されています。511個のファイルは使用可能なファイルで、1個のファイルはデプリート状態ために予約されています。

- ジャーナルで使用される合計メモリーは、デフォルトでは1GBに制限されています(最大は64GB)。フラッシュ・ジャーナルは、ジャーナルの合計メモリーが構成済制限を超えると自動的に使用されます。

RAMジャーナル・リソース・マネージャを構成するには、<ramjournal-manager>要素を<journaling-config>要素の中に追加して、オーバーライドするサブ要素を定義します。次の例では、RAMジャーナル・サブ要素のオーバーライドを示しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<journaling-config>
<ramjournal-manager>
<maximum-value-size>64K</maximum-value-size>
<maximum-size system-property="tangosol.coherence.ramjournal.size">
2G</maximum-size>
</ramjournal-manager>
</journaling-config>
</cluster-config>
</coherence>

14.6.3.2 フラッシュ・ジャーナル・リソース・マネージャの構成

<flashjournal-manager>要素は、フラッシュ・ジャーナルの動作を構成するために使用されます。次のリストは、フラッシュ・ジャーナルのデフォルト特性を示しています。すべての使用可能な設定およびそのデフォルト値の詳細は、「flashjournal-manager」を参照してください。

- バイナリ値は、デフォルトでは64MBに制限されています。

- 個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2GBに制限されています(最大は4GB)。

- ジャーナルは最大512個のファイルで構成されています。511個のファイルは使用可能なファイルで、1個のファイルはデプリート状態ために予約されています。ジャーナルはデフォルトでは1TBに制限され、理論上最大2TBとなります。

- ジャーナルには、デフォルトで11GBの高いジャーナル・サイズが設定されています。この高いサイズによって、ジャーナルから失効した値の削除を開始するタイミングが決定されます。これは、ジャーナル・サイズの強い制限ではなく、依然として最大ファイル数(512)まで大きくなることができます。

- キーは、圧縮された形式でメモリー内に残ります。値については、書き込まれていない(キューに入れられているか非同期に書き込まれる)データのみがメモリーに残ります。ヒープのサイズを決定するときの合理的な見積りは、キー・データを保持するエントリごとに50バイトを許可し(これは、RAMとフラッシュの両方のジャーナルに当てはまります)、バッファ用の追加の容量(16MB)を含めることです。失効またはエビクションを構成すると、エントリ・サイズは増加します。

フラッシュ・ジャーナル・リソース・マネージャを構成するには、<flashjournal-manager>要素を<journaling-config>要素の中に追加して、オーバーライドするサブ要素を定義します。次の例では、フラッシュ・ジャーナル・サブ要素のオーバーライドを示しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<journaling-config>
<flashjournal-manager>
<maximum-value-size>64K</maximum-value-size>
<maximum-file-size>8M</maximum-file-size>
<block-size>512K</block-size>
<maximum-pool-size>32M</maximum-pool-size>
<directory>/coherence_storage</directory>
<async-limit>32M</async-limit>
<high-journal-size
system-property="tangosol.coherence.flashjournal.highjournalsize">
11GB</high-journal-size>
</flashjournal-manager>
</journaling-config>
</cluster-config>
</coherence>

注意:
ジャーナル・ファイルを保存するために指定されたディレクトリが存在する必要があります。ディレクトリが存在しない場合、警告がログに記録され、JVMで指定されたデフォルトの一時ファイル・ディレクトリが使用されます。

14.7 非同期バックアップの使用

分散キャッシュでは、同期と非同期の両方のバックアップがサポートされています。同期バックアップでは、バックアップ操作が完了するまでクライアントはブロックされます。非同期バックアップでは、バックアップ操作中にクライアントはリクエストへの応答を続行します。バックアップは、非同期バックアップが明示的に有効化されていないかぎり、同期で実行されます。

非同期バックアップは、通常、クライアントのパフォーマンスを向上させるために使用されます。ただし、非同期バックアップを使用するアプリケーションは、データの整合性に対して発生しうる影響に対処する必要があります。特に、バックアップ操作が(成功または失敗して)完了する前にキャッシュ操作が完了する場合があり、バックアップ操作の完了順序は決まっていません。アプリケーションでバックアップが不要な場合(つまり、損失したデータを記録システムからリストアできる場合)は、非同期バックアップの使用を検討してください。しかし、この場合でも、ノード障害の発生時における迅速なリカバリをアプリケーションで提供する必要があります。

分散キャッシュの非同期バックアップを有効化するには、trueに設定した<async-backup>要素を<distributed-scheme>要素内に追加します。例:

<distributed-scheme>
...
<async-backup>true</async-backup>
...
</distributed-scheme>

分散キャッシュ・サービス・タイプのすべてのインスタンスに対して非同期バックアップを有効にするには、オペレーション・オーバーライド・ファイルで、パーティション・キャッシュ・サービスのasync-backup初期化パラメータをオーバーライドします。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="27">
<param-name>async-backup</param-name>
<param-value
system-property="tangosol.coherence.distributed.asyncbackup">
false
</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.distributed.asyncbackupシステム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスに対して非同期バックアップを有効にすることもできます。例:

-Dtangosol.coherence.distributed.asyncbackup=true

14.8 デルタ・バックアップの使用

デルタ・バックアップとは、プライマリ・エントリが変更されたときに、エントリ全体を置き換えるのではなく、バックアップ・バイナリ・エントリに変更を適用するために使用される技術です。デルタ・バックアップは、更新されるエントリは大きいが変更は小さい場合に最適です。そのような場合、エントリ全体の書換えに関するコストよりエントリの一部分のみを変更するコストの方が一般的には小さいので、パフォーマンスが向上します。ただし、一般的に、エントリに50%を超える変更があると、パフォーマンスの向上はほとんどまたはまったくありません。この場合、パフォーマンスの低下が検出されないときにのみデルタ・バックアップを使用してください。

デルタ・バックアップでは、新旧の値を持つ2つのインメモリー・バッファを比較するコンプレッサを使用し、古い値に適用して新しい値を作成できる結果(デルタといいます)を生成します。Coherenceでは、POFおよび非POF形式の標準のデルタ・コンプレッサを備えています。必要に応じて、カスタム・コンプレッサを作成することもできます。

14.8.1 デルタ・バックアップの有効化

デルタ・バックアップは分散キャッシュでのみ使用可能で、デフォルトでは無効です。デルタ・バックアップは、それぞれの分散キャッシュで個別に有効にするか、分散キャッシュ・サービス・タイプのすべてのインスタンスに有効にします。

分散キャッシュでデルタ・バックアップを有効にするには、<compressor>要素を<distributed-scheme>要素の中に追加して、standardに設定します。例:

<distributed-scheme>
...
<compressor>standard</compressor>
...
</distributed-scheme>

分散キャッシュ・サービス・タイプのすべてのインスタンスにデルタ・バックアップを有効にするには、オペレーション・オーバーライド・ファイルで、パーティション・キャッシュ・サービスのcompressor初期化パラメータをオーバーライドします。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="22">
<param-name>compressor</param-name>
<param-value
system-property="tangosol.coherence.distributed.compressor">
standard</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.distributed.compressorシステム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスにデルタ・バックアップを有効にすることもできます。例:

-Dtangosol.coherence.distributed.compressor=standard

14.8.2 カスタム・デルタ・バックアップ・コンプレッサの有効化

カスタム・コンプレッサを使用してデルタ・バックアップを実行するには、<instance>サブ要素を追加して、DeltaCompressorインタフェースを実装するクラスの完全修飾名を指定します。<instance>要素の使用の詳細は、「instance」を参照してください。次の例では、MyDeltaCompressorクラスに実装されているカスタム・コンプレッサが有効になります。

<distributed-scheme>
...
<compressor>
<instance>
<class-name>package.MyDeltaCompressor</class-name>
</instance>
</compressor>
...
</distributed-scheme>

代替案として、<instance>要素では、DeltaCompressorインスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次の例では、MyCompressorFactoryクラスのgetCompressorメソッドを使用するカスタム・コンプレッサ・インスタンスを取得します。

<distributed-scheme>
...
<compressor>
<instance>
<class-factory-name>package.MyCompressorFactory</class-factory-name>
<method-name>getCompressor</method-name>
</instance>
</compressor>
...
</distributed-scheme>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、iMaxTimeパラメータが2000に設定されます。

<distributed-scheme>
...
<compressor>
<instance>
<class-name>package.MyDeltaCompressor</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</instance>
</compressor>
...
</distributed-scheme>

15 データ・ソースのキャッシュ

この章では、データ・ソースをキャッシュする方法と一時的な記録システムとしてのCoherenceの使用方法について説明します。また、サンプルや実装に関する考慮事項についても解説します。

この章には次の項が含まれます:

- データ・ソースのキャッシュの概要

- キャッシュ戦略の選択

- キャッシュ・ストアの実装の作成

- キャッシュ・ストアの実装のプラグイン

- キャッシュ・ストアの実装のサンプル

- 制御可能なキャッシュ・ストアの実装のサンプル

- 実装に関する考慮事項

15.1 データ・ソースのキャッシュの概要

Coherenceでは、データベース、Webサービス、パッケージ化されたアプリケーション、ファイル・システムなど、任意のデータ・ソースの透過的な読取りまたは書込みのキャッシングがサポートされますが、データベースが最も一般的に使用されます。ここでは、任意のバックエンド・データ・ソースのことを、簡単にデータベースと呼びます。効率的なキャッシュでは、集中的な読取り専用操作および読取り/書込み操作をサポートし、読取り/書込み操作の際には、キャッシュとデータベースは完全に同期化されている必要があります。データ・ソースのキャッシュを実現するために、Coherenceではリードスルー、ライトスルー、リフレッシュアヘッドおよびライトビハインド・キャッシュをサポートします。

注意:
リードスルー/ライトスルー・キャッシング(および他の類似するキャッシング形態)は、パーティション(分散)キャッシュ(ニア・キャッシュも含む)トポロジで使用することのみを目的としています。ローカル・キャッシュでは、この機能のサブセットがサポートされます。レプリケート・キャッシュとオプティミスティック・キャッシュは使用しないでください。

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

- プラガブル・キャッシュ・ストア

- リードスルー・キャッシング

- ライトスルー・キャッシング

- ライトビハインド・キャッシング

- リフレッシュアヘッド・キャッシング

15.1.1 プラガブル・キャッシュ・ストア

キャッシュ・ストアは、キャッシュと基礎となるデータ・ソースの接続に使用されるアプリケーション固有のアダプタです。キャッシュ・ストア実装では、データ・アクセス・メカニズム(Hibernate、Toplink、JPA、アプリケーション固有のJDBCコール、他のアプリケーション、メインフレーム、他のキャッシュなど)を使用してデータ・ソースにアクセスします。キャッシュ・ストアでは、データ・ソースからの取得データを使用したJavaオブジェクトの作成方法、データ・ソースへのオブジェクトのマッピング方法や書込み方法、およびデータ・ソースからのオブジェクトの削除方法が認識されます。

データ・ソース接続戦略およびデータ・ソース-アプリケーション・オブジェクトのマッピング情報は、データ・ソース・スキーマ、アプリケーション・クラス・レイアウト、および操作環境に固有です。そのため、このマッピング情報は、アプリケーション開発者がキャッシュ・ストアの実装で用意する必要があります。詳細は、「キャッシュ・ストアの実装の作成」を参照してください。

15.1.2 リードスルー・キャッシング

アプリケーションから、たとえばkey Xのキャッシュ・エントリが要求されたときに、キャッシュにXがなかった場合、CoherenceはCacheStoreへの委任を自動的に実行し、基礎となるデータソースからXをロードするようにCacheStoreに要求します。データ・ソースにXが存在している場合、CacheStoreはそれをロードしてCoherenceに返し、Coherenceは将来の使用に備えてそれをキャッシュに置き、最終的にXを要求したアプリケーションに返します。これをリードスルー・キャッシングと呼びます。リフレッシュアヘッド・キャッシュ機能を使用すると、(認識されている待機時間を削減することにより)読取りパフォーマンスがさらに向上します。詳細は、「リフレッシュアヘッド・キャッシング」を参照してください。

図15-1 リードスルー・キャッシング

15.1.3 ライトスルー・キャッシング

Coherenceでは、2つの異なる方法でデータ・ソースの更新を処理できます。1つ目の方法は、ライトスルーです。この場合、アプリケーションでキャッシュのデータが更新されると(つまり、put(...)をコールしてキャッシュ・エントリを変更すると)、キャッシュ・ストアを介して基礎となるデータ・ソースにデータが正常に保存されるまで操作は完了しません(つまり、putは返されません)。このままでは、データ・ソースへの書込みにおいて待機時間が生じるため、書込みパフォーマンスはまったく向上しません。書き込みパフォーマンスを向上させるには、ライトビハインド・キャッシュ機能を使用します。詳細は、「ライトビハインド・キャッシング」を参照してください。

図15-2 ライトスルー・キャッシング

15.1.4 ライトビハインド・キャッシング

ライトビハインドのシナリオでは、構成された遅延(10秒、20分、1日、1週間、またはそれ以上)の経過後に、変更されたキャッシュ・エントリが非同期でデータ・ソースに書き込まれます。これは、キャッシュの挿入と更新にのみ適用されることに注意する必要があります。キャッシュ・エントリの削除は、データ・ソースと同期して実行されます。ライトビハインド・キャッシングでは、データ・ソースで更新する必要のあるデータのライトビハインド・キューが保持されます。アプリケーションでキャッシュのXが更新されると、Xはライトビハインド・キューに追加され(Xがない場合。ある場合は置き換えられる)、指定されたライトビハインド遅延の経過後、CoherenceはCacheStoreをコールして基礎となるデータ・ソースのXを最新の状態に更新します。ライトビハインド遅延は、一連の変更が始まる時点を基準としています。つまり、データ・ソースのデータは、キャッシュのライトビハインド遅延を超えて遅れることはありません。

このため、一度読み取って構成された間隔で書き込む(つまり、更新頻度が少ない)シナリオになります。このアーキテクチャ・タイプには、主に4つの利点があります。

- 基礎となるデータ・ソースへのデータ書込みを待つ必要がないため、アプリケーションのパフォーマンスが向上します。(データは後で、別の実行スレッドによって書き込まれます。)

- アプリケーションにおけるデータベース負荷が大幅に削減されます。読取り操作と書込み操作の量が両方とも減るため、データベース負荷も削減されます。他のキャッシング・アプローチと同様、キャッシングによって読取りが削減されます。一般的に、書込みはより負荷の高い操作ですが、多くの場合、その回数が減ります。ライトビハインド間隔の間における同一オブジェクトへの複数の変更操作が結合され、基礎となるデータ・ソースに一度だけ書き込まれるからです(書込み結合)。また、複数のキャッシュ・エントリへの書込みは、CacheStore.storeAll()メソッドを使用して単一のデータベース・トランザクションにまとめることができます(書込み組合せ)。

- アプリケーションは、データベース障害からある程度保護されます。書込みの失敗時にオブジェクトが書込みキューに再度配置されるように、ライトビハインド機能を構成できるからです。アプリケーションの使用データがCoherenceキャッシュにある場合、データベースを稼働せずに操作を継続できます。これは、Coherenceパーティション・キャッシュを使用すると、容易に実現できます。Coherenceパーティション・キャッシュでは、(ローカル記憶域が有効な)すべての参加クラスタ・ノードでキャッシュ全体をパーティション化できるため、巨大なキャッシュ・メモリーを使用できます。

- 線形スケーラビリティ: アプリケーションでより多くの同時ユーザー数を処理するには、クラスタ内のノード数を増加するだけで済みます。データベース負荷への影響は、ライトビハインド間隔を長くすることで調整できます。

図15-3 ライトビハインド・キャッシング

15.1.4.1 ライトビハンドの要件

ライトビハインド・キャッシングは、1つの構成設定を調整するだけで有効化できますが、ライトビハインドを期待どおりに動作させるのはより困難です。特に、アプリケーション設計では、いくつかの設計上の問題に前もって対処しておく必要があります。

データベースの更新がキャッシュ・トランザクションの外側で発生するため、そこにライトビハインド・キャッシングが最も作用します。つまり、キャッシュ・トランザクションはほとんどの場合、データベース・トランザクションが開始される前に完了します。これは、データベース・トランザクションが失敗してはならないことを意味します。これが保証できない場合、ロールバック機能を採用する必要があります。

ライトビハインドはデータベース更新の順序を並べ替えることができるため、参照整合性制約で順不同の更新をできるようにする必要があります。概念的には、これはデータベースをISAMスタイル(更新競合がないことが保証された主キー・ベースのアクセス)の記憶域として使用するようなものです。他のアプリケーションとデータベースを共有すると、新たな困難に直面します。つまり、ライトビハインド・トランザクションが外部の更新と競合しないことを保証する手段がなくなります。これは、ライトビハインドの競合がヒューリスティックに処理されるか、オペレータが手動で調整する必要があることを意味します。

通常は、論理データベース・トランザクションに各キャッシュ・エントリの更新をマッピングすると、最も単純なデータベース・トランザクションが保証されるため理想的です。

ライトビハインドは、(ライトビハインド・キューがディスクに書き込まれるまで)キャッシュを効率的に記録システムで保持するため、ビジネス規則ではクラスタに永続可能な(ディスクへの永続可能ではなく)データおよびトランザクションの記憶域を許可する必要があります。

15.1.5 リフレッシュアヘッド・キャッシング

リフレッシュアヘッドのシナリオでは、キャッシュ・ローダーから最近アクセスされた任意のキャッシュ・エントリを、失効する前に自動的かつ非同期的にリロード(リフレッシュ)するようにキャッシュを構成できます。その結果、アクセス頻度の高いエントリがキャッシュに入ると、失効後にエントリがリロードされるときに、アプリケーションは潜在的に低速なキャッシュ・ストアに対する読取りの影響を受けません。非同期リフレッシュは、有効期限が近いオブジェクトへのアクセスが発生したときにのみトリガーされます。オブジェクトへのアクセスが期限切れ後の場合、キャッシュ・ストアからの読取りが同期的に行われ、その値がリフレッシュされます。

リフレッシュアヘッド期限は、エントリの有効期間の割合として表されます。たとえば、キャッシュ・エントリの有効期間が60秒に設定されており、リフレッシュアヘッド係数が0.5に設定されているとします。キャッシュされたオブジェクトを60秒後にアクセスすると、キャッシュ・ストアから同期読取りが実行され、その値がリフレッシュされます。ただし、30秒を超える60秒未満のエントリに対するリクエストを実行すると、キャッシュの現在の値が返され、キャッシュ・ストアから非同期のリロードがスケジュールされます。

リフレッシュアヘッドは、多数のユーザーがオブジェクトにアクセスする場合に有用です。値はキャッシュで最新の状態に維持され、キャッシュ・ストアの大量のリロードに起因する待機時間が回避されます。

リフレッシュアヘッド係数の値は、coherence-cache-config.xmlファイルの<read-write-backing-map-scheme要素の<refresh-ahead-factorサブ要素で指定します。リフレッシュアヘッドでは、キャッシュのエントリの有効期間(<expiry-delay)も設定されていることを前提としています。

例15-1では、ローカル・キャッシュのエントリのリフレッシュアヘッド係数を0.5で、有効期間を20秒で構成しています。エントリが有効期間の10秒以内にアクセスされると、キャッシュ・ストアから非同期にリロードされるようにスケジュールされます。

例15-1 リフレッシュアヘッド係数の指定

<distributed-scheme>
<scheme-name>categories-cache-all-scheme</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>

<read-write-backing-map-scheme>
<scheme-name>categoriesLoaderScheme</scheme-name>
<internal-cache-scheme>
<local-scheme>
<scheme-ref>categories-eviction</scheme-ref>
</local-scheme>
</internal-cache-scheme>

<cachestore-scheme>
<class-scheme>
<class-name>
com.demo.cache.coherence.categories.CategoryCacheLoader
</class-name>
</class-scheme>
</cachestore-scheme>
<refresh-ahead-factor>0.5</refresh-ahead-factor>
</read-write-backing-map-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<local-scheme>
<scheme-name>categories-eviction</scheme-name>
<expiry-delay>20s</expiry-delay>
</local-scheme>

15.2 キャッシュ戦略の選択

この項では、いくつかのキャッシング戦略の利点を比較します。

- リードスルー/ライトスルーとキャッシュアサイドの比較

- リフレッシュアヘッドとリードスルーの比較

- ライトビハインドとライトスルーの比較

15.2.1 リードスルー/ライトスルーとキャッシュアサイドの比較

クラスタ化環境のキャッシュアサイド・パターンには、一般的に2つのアプローチがあります。1つ目のアプローチでは、キャッシュ・ミスをチェックし、データベースに問い合せ、キャッシュに移入して、アプリケーション処理を継続します。この場合、様々なアプリケーション・スレッドがこの処理を同時に実行すると、多数のデータベース・アクセスが発生することになります。もう1つのアプローチでは、アプリケーションでロックを再確認します(これは、チェックがキャッシュ・エントリに対する原子性を持っているため機能します)。ただし、キャッシュ・ミスまたはデータベース更新(クラスタ化されたロック、追加の読取り、およびクラスタ化されたロック解除 - 最大10の追加ネットワーク・ホップ、または一般的なギガビット・イーサネット接続で6から8ミリ秒、さらに追加処理のオーバーヘッドおよびキャッシュ・エントリのロック継続期間の増加)の際に大量のオーバーヘッドが生じます。

インライン・キャッシングを使用すると、(フォルト・トレランスを確保するためにデータがバックアップ・サーバーにコピーされている間)エントリは2つのネットワーク・ホップでのみロックされます。また、ロックはパーティション所有者によりローカルで維持されます。さらに、アプリケーション・コードは完全にキャッシュ・サーバーで管理されます。つまり、ノードの管理下にあるサブセットのみが直接データベースにアクセスします(そのため、負荷とセキュリティが予測可能になる)。加えて、これによりデータベース・ロジックからキャッシュ・クライアントが切り離されます。

15.2.2 リフレッシュアヘッドとリードスルーの比較

リフレッシュアヘッドでは、リードスルーと比べて待機時間が減りますが、それは将来必要とされるキャッシュ・アイテムをキャッシュが正確に予測できる場合のみです。これらの予測が完全に正確であれば、リフレッシュアヘッドにより待機時間が削減され、余分なオーバーヘッドはありません。予測の正確性が低下すると、データベースに送信される不要なリクエストが増加するため、スループットへの影響も大きくなります。データベースのリクエスト処理が遅れ始めると、待機時間が長くなる可能性もあります。

15.2.3 ライトビハインドとライトスルーの比較

ライトビハインド・キャッシングの要件が満たされると、ライトスルー・キャッシュと比較して非常に高いスループットが得られ、待機時間が削減されます。また、ライトビハインド・キャッシングによりデータベース(書込みの減少)およびキャッシュ・サーバー(キャッシュ値のデシリアライズの削減)の負荷が低減されます。

15.3 キャッシュ・ストアの実装の作成

キャッシュ・ストアの実装はプラガブルで、データ・ソースのキャッシュの使用状況に応じて、次のいずれかのインタフェースを実装する必要があります。

- CacheLoader - 読取り専用キャッシュ

- CacheStore - 読取り/書込みキャッシュ

- BinaryEntryStore - バイナリ・エントリ・オブジェクトの読取り/書込み。

これらのインタフェースは、com.tangosol.net.cacheパッケージにあります。CacheLoaderインタフェースには、load(Object key)およびloadAll(Collection keys)の2つのメイン・メソッドがあります。またCacheStoreインタフェースには、store(Object key, Object value)、storeAll(Map mapEntries)、erase(Object key)およびeraseAll(Collection colKeys)メソッドが追加されました。BinaryEntryStoreインタフェースでは他のインタフェースと同じメソッドが提供されますが、このインタフェースは直接バイナリ・オブジェクトに対して機能します。

CacheStoreの実装の例については、「キャッシュ・ストアの実装のサンプル」および「制御可能なキャッシュ・ストアの実装のサンプル」を参照してください。

15.4 キャッシュ・ストアの実装のプラグイン

キャッシュ・ストアの実装をプラグインするには、distributed-scheme、backing-map-scheme、cachestore-scheme、またはread-write-backing-map-schemeキャッシュ構成要素内で実装クラス名を指定します。

read-write-backing-map-schemeでは、com.tangosol.net.cache.ReadWriteBackingMapが構成されます。このバッキング・マップは、実際にデータをキャッシュする内部マップ(internal-cache-schemeを参照)と、データベースと相互作用するキャッシュ・ストア実装(cachestore-schemeを参照)という2つの主要な要素で構成されます。

例15-2は、キャッシュ・ストアの実装を指定するキャッシュ構成を示しています。<init-params>要素には、コンストラクタに渡されるパラメータの順序付けられたリストが含まれます。{cache-name}構成マクロを使用してキャッシュ名を実装に渡すことにより、これがデータベース表にマップされます。使用可能なすべてのマクロの一覧は、「パラメータ・マクロの使用」を参照してください。

ライトビハインドおよびリフレッシュアヘッドの構成方法の詳細は、read-write-backing-map-schemeを参照してください。その際には、write-batch-factor、refresh-ahead-factor、write-requeue-thresholdおよびrollback-cachestore-failures要素に注意してください。

例15-2 Cachestoreモジュールの例

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>com.company.dto.*</cache-name>
<scheme-name>distributed-rwbm</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed-rwbm</scheme-name>
<backing-map-scheme>
<read-write-backing-map-scheme>

<internal-cache-scheme>
<local-scheme/>
</internal-cache-scheme>

<cachestore-scheme>
<class-scheme>
<class-name>com.example.MyCacheStore</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
</read-write-backing-map-scheme>
</backing-map-scheme>
</distributed-scheme>
</caching-schemes>
</cache-config>

注意:
キャッシュ・ストアの実装を使用すると、キャッシュ・サービス・スレッドの消費が著しく増加します(最速のデータベースを選択しても、インメモリー構造の更新より桁違いに処理が遅くなります)。そのため、キャッシュ・サービスのスレッド・カウントを増加する必要があります(通常は、10 - 100の範囲)。スレッド・プールが不十分な場合の最も顕著な症状は、(背後にあるデータベースの処理が増加せずに)キャッシュ・リクエストの待機時間が増加することです。

15.5 キャッシュ・ストアの実装のサンプル

この項では、com.tangosol.net.cache.CacheStoreインタフェースの非常に基本的な実装について説明します。例15-3の実装では、JDBCによる単一のデータベース接続が使用され、バルク操作は使用されません。完全な実装では接続プールが使用されます。また、ライトビハインドが使用される場合は、CacheStore.storeAll()を実装してJDBCのバルク挿入およびバルク更新を行います。データベースのキャッシュ構成の例は、「データベースのキャッシュ」を参照してください。

ヒント:
キャッシュをバルク・ロードすることによって、処理作業を軽減できます。次の例では、putメソッドを使用して、キャッシュ・ストアに値を書き込みます。多くの場合、putAllメソッドを使用してバルク・ロードを実行すると、処理作業およびネットワーク・トラフィックが軽減されます。バルク・ロードの詳細は、第21章「キャッシュの事前ロード」を参照してください。

例15-3 CacheStoreインタフェースの実装

package com.tangosol.examples.coherence;

import com.tangosol.net.cache.CacheStore;
import com.tangosol.util.Base;

import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import java.util.Collection;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;

/**
* An example implementation of CacheStore
* interface.
*
* @author erm 2003.05.01
*/
public class DBCacheStore
extends Base
implements CacheStore
{
// ----- constructors ---------------------------------------------------
/**
* Constructs DBCacheStore for a given database table.
*
* @param sTableName the db table name
*/
public DBCacheStore(String sTableName)
{
m_sTableName = sTableName;
configureConnection();
}

/**
* Set up the DB connection.
*/
protected void configureConnection()
{
try
{
Class.forName("org.gjt.mm.mysql.Driver");
m_con = DriverManager.getConnection(DB_URL, DB_USERNAME, DB_PASSWORD);
m_con.setAutoCommit(true);
}
catch (Exception e)
{
throw ensureRuntimeException(e, "Connection failed");
}
}

// ---- accessors -------------------------------------------------------

/**
* Obtain the name of the table this CacheStore is persisting to.
*
* @return the name of the table this CacheStore is persisting to
*/
public String getTableName()
{
return m_sTableName;
}

/**
* Obtain the connection being used to connect to the database.
*
* @return the connection used to connect to the database
*/
public Connection getConnection()
{
return m_con;
}

// ----- CacheStore Interface --------------------------------------------

/**
* Return the value associated with the specified key, or null if the
* key does not have an associated value in the underlying store.
*
* @param oKey  key whose associated value is to be returned
*
* @return the value associated with the specified key, or
*         <tt>null</tt> if no value is available for that key
*/
public Object load(Object oKey)
{
Object     oValue = null;
Connection con    = getConnection();
String     sSQL   = "SELECT id, value FROM " + getTableName()
+ " WHERE id = ?";
try
{
PreparedStatement stmt = con.prepareStatement(sSQL);

stmt.setString(1, String.valueOf(oKey));

ResultSet rslt = stmt.executeQuery();
if (rslt.next())
{
oValue = rslt.getString(2);
if (rslt.next())
{
throw new SQLException("Not a unique key: " + oKey);
}
}
stmt.close();
}
catch (SQLException e)
{
throw ensureRuntimeException(e, "Load failed: key=" + oKey);
}
return oValue;
}

/**
* Store the specified value under the specific key in the underlying
* store. This method is intended to support both key/value creation
* and value update for a specific key.
*
* @param oKey    key to store the value under
* @param oValue  value to be stored
*
* @throws UnsupportedOperationException  if this implementation or the
*         underlying store is read-only
*/
public void store(Object oKey, Object oValue)
{
Connection con     = getConnection();
String     sTable  = getTableName();
String     sSQL;

// the following is very inefficient; it is recommended to use DB
// specific functionality that is, REPLACE for MySQL or MERGE for Oracle
if (load(oKey) != null)
{
// key exists - update
sSQL = "UPDATE " + sTable + " SET value = ? where id = ?";
}
else
{
// new key - insert
sSQL = "INSERT INTO " + sTable + " (value, id) VALUES (?,?)";
}
try
{
PreparedStatement stmt = con.prepareStatement(sSQL);
int i = 0;
stmt.setString(++i, String.valueOf(oValue));
stmt.setString(++i, String.valueOf(oKey));
stmt.executeUpdate();
stmt.close();
}
catch (SQLException e)
{
throw ensureRuntimeException(e, "Store failed: key=" + oKey);
}
}

/**
* Remove the specified key from the underlying store if present.
*
* @param oKey key whose mapping is to be removed from the map
*
* @throws UnsupportedOperationException  if this implementation or the
*         underlying store is read-only
*/
public void erase(Object oKey)
{
Connection con  = getConnection();
String     sSQL = "DELETE FROM " + getTableName() + " WHERE id=?";
try
{
PreparedStatement stmt = con.prepareStatement(sSQL);

stmt.setString(1, String.valueOf(oKey));
stmt.executeUpdate();
stmt.close();
}
catch (SQLException e)
{
throw ensureRuntimeException(e, "Erase failed: key=" + oKey);
}
}

/**
* Remove the specified keys from the underlying store if present.
*
* @param colKeys  keys whose mappings are being removed from the cache
*
* @throws UnsupportedOperationException  if this implementation or the
*         underlying store is read-only
*/
public void eraseAll(Collection colKeys)
{
throw new UnsupportedOperationException();
}

/**
* Return the values associated with each the specified keys in the
* passed collection. If a key does not have an associated value in
* the underlying store, then the return map does not have an entry
* for that key.
*
* @param colKeys  a collection of keys to load
*
* @return a Map of keys to associated values for the specified keys
*/
public Map loadAll(Collection colKeys)
{
throw new UnsupportedOperationException();
}

/**
* Store the specified values under the specified keys in the underlying
* store. This method is intended to support both key/value creation
* and value update for the specified keys.
*
* @param mapEntries   a Map of any number of keys and values to store
*
* @throws UnsupportedOperationException  if this implementation or the
*         underlying store is read-only
*/
public void storeAll(Map mapEntries)
{
throw new UnsupportedOperationException();
}

/**
* Iterate all keys in the underlying store.
*
* @return a read-only iterator of the keys in the underlying store
*/
public Iterator keys()
{
Connection con  = getConnection();
String     sSQL = "SELECT id FROM " + getTableName();
List       list = new LinkedList();

try
{
PreparedStatement stmt = con.prepareStatement(sSQL);
ResultSet         rslt = stmt.executeQuery();
while (rslt.next())
{
Object oKey = rslt.getString(1);
list.add(oKey);
}
stmt.close();
}
catch (SQLException e)
{
throw ensureRuntimeException(e, "Iterator failed");
}

return list.iterator();
}

// ----- data members ---------------------------------------------------

/**
* The connection.
*/
protected Connection m_con;

/**
* The db table name.
*/
protected String m_sTableName;

/**
* Driver class name.
*/
private static final String DB_DRIVER = "org.gjt.mm.mysql.Driver";

/**
* Connection URL.
*/
private static final String DB_URL = "jdbc:mysql://localhost:3306/CacheStore";

/**
* User name.
*/
private static final String DB_USERNAME = "root";

/**
* Password.
*/
private static final String DB_PASSWORD = null;
}

15.6 制御可能なキャッシュ・ストアの実装のサンプル

この項では、制御可能なキャッシュ・ストアの実装を紹介します。このシナリオでは、更新された値をデータ・ストアに書き込む時点をアプリケーションによって制御できます。このシナリオは、起動時にデータ・ストアからキャッシュへの初期移入を行う際に最も一般的に使用されます。起動時には、キャッシュの値を元のデータ・ストアに書き込む必要がありません。このような書込みはリソースの浪費になります。

例15-4のMain.javaファイルは、次のような制御可能なキャッシュ・ストアの2種類の操作方法を示しています。

- 制御可能なキャッシュ(別のサービスに配置されている必要があります)を使用して、キャッシュ・ストアの有効化または無効化を行います。これは、ControllableCacheStore1クラスで示されます。

- CacheStoreAwareインタフェースを使用して、キャッシュに追加されたオブジェクトで記憶域が不要なことを示します。これは、ControllableCacheStore2クラスで示されます。

ControllableCacheStore1とControllableCacheStore2は両方とも、com.tangosol.net.cache.AbstractCacheStoreクラスを拡張します。このヘルパー・クラスによって、storeAll操作およびeraseAll操作の非最適実装が行われます。

CacheStoreAwareインタフェースを使用して、キャッシュに追加されるオブジェクトをデータベースに格納する必要がないことを示すことができます。

キャッシュ構成のサンプルについては、「データベースのキャッシュ」を参照してください。

例15-4は、Main.javaインタフェースの一覧を示しています。

例15-4 Main.java: 制御可能なCacheStoreとの相互作用

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;
import com.tangosol.net.cache.AbstractCacheStore;
import com.tangosol.util.Base;

import java.io.Serializable;
import java.util.Date;

public class Main extends Base
{

/**
* A cache controlled CacheStore implementation
*/
public static class ControllableCacheStore1 extends AbstractCacheStore
{
public static final String CONTROL_CACHE = "cachestorecontrol";

String m_sName;

public static void enable(String sName)
{
CacheFactory.getCache(CONTROL_CACHE).put(sName, Boolean.TRUE);
}

public static void disable(String sName)
{
CacheFactory.getCache(CONTROL_CACHE).put(sName, Boolean.FALSE);
}

public void store(Object oKey, Object oValue)
{
Boolean isEnabled = (Boolean) CacheFactory.getCache(CONTROL_CACHE).get(m_sName);
if (isEnabled != null && isEnabled.booleanValue())
{
log("controllablecachestore1: enabled " + oKey + " = " + oValue);
}
else
{
log("controllablecachestore1: disabled " + oKey + " = " + oValue);
}
}

public Object load(Object oKey)
{
log("controllablecachestore1: load:" + oKey);
return new MyValue1(oKey);
}

public ControllableCacheStore1(String sName)
{
m_sName = sName;
}

}

/**
* a valued controlled CacheStore implementation that
* implements the CacheStoreAware interface
*/
public static class ControllableCacheStore2 extends AbstractCacheStore
{

public void store(Object oKey, Object oValue)
{
boolean isEnabled = oValue instanceof CacheStoreAware ? !((CacheStoreAware) oValue).isSkipStore() : true;
if (isEnabled)
{
log("controllablecachestore2: enabled " + oKey + " = " + oValue);
}
else
{
log("controllablecachestore2: disabled " + oKey + " = " + oValue);
}
}

public Object load(Object oKey)
{
log("controllablecachestore2: load:" + oKey);
return new MyValue2(oKey);
}

}

public static class MyValue1 implements Serializable
{
String m_sValue;

public String getValue()
{
return m_sValue;
}

public String toString()
{
return "MyValue1[" + getValue() + "]";
}

public MyValue1(Object obj)
{
m_sValue = "value:" + obj;
}
}

public static class MyValue2 extends MyValue1 implements CacheStoreAware
{
boolean m_isSkipStore = false;

public boolean isSkipStore()
{
return m_isSkipStore;
}

public void skipStore()
{
m_isSkipStore = true;
}

public String toString()
{
return "MyValue2[" + getValue() + "]";
}

public MyValue2(Object obj)
{
super(obj);
}

}

public static void main(String[] args)
{
try
{

// example 1

NamedCache cache1 = CacheFactory.getCache("cache1");

// disable cachestore
ControllableCacheStore1.disable("cache1");
for(int i = 0; i < 5; i++)
{
cache1.put(new Integer(i), new MyValue1(new Date()));
}

// enable cachestore
ControllableCacheStore1.enable("cache1");
for(int i = 0; i < 5; i++)
{
cache1.put(new Integer(i), new MyValue1(new Date()));
}

// example 2

NamedCache cache2 = CacheFactory.getCache("cache2");

// add some values with cachestore disabled
for(int i = 0; i < 5; i++)
{
MyValue2 value = new MyValue2(new Date());
value.skipStore();
cache2.put(new Integer(i), value);
}

// add some values with cachestore enabled
for(int i = 0; i < 5; i++)
{
cache2.put(new Integer(i), new MyValue2(new Date()));
}

}
catch(Throwable oops)
{
err(oops);
}
finally
{
CacheFactory.shutdown();
}
}

}

15.7 実装に関する考慮事項

キャッシュ・ストアの実装を作成する場合は、次の点に注意してください。

15.7.1 冪等性

すべての操作は、冪等になるように(つまり、望ましくない副作用なしに繰り返し処理できるように)設計する必要があります。ライトスルーおよびライトビハインド・キャッシュの場合、フェイルオーバー処理時にキャッシュ更新のデータベース部分を再試行することにより、低コストのフォルト・トレランスを提供できます。ライトビハインド・キャッシングの場合、冪等性によって、データ整合性に影響を与えずに、複数のキャッシュ更新を単一の起動にまとめることができます。

アプリケーションにライトビハインド・キャッシングの要件があっても、書込み組合せを回避する必要がある場合(たとえば、監査のため)、バージョニングされたキャッシュ・キーを作成する必要があります(たとえば、シーケンスIDを持つ通常の主キーを組み合せて)。

15.7.2 ライトスルーの制限

Coherenceでは、複数のキャッシュ・ストア・インスタンス間での2フェーズの操作はサポートされません。つまり、2つのキャッシュ・エントリが更新され、別々のキャッシュ・サーバーにあるキャッシュ・ストア実装へのコールがトリガーされる場合、片方のデータベース更新は成功し、もう一方は失敗する可能性があります。この場合、アプリケーション・サーバーのトランザクション・マネージャで、キャッシュアサイド・アーキテクチャ(キャッシュとデータベースを、単一トランザクション内の2つの別個のコンポーネントとして更新する)を使用することをお薦めします。多くの場合、論理コミットの失敗がないように(当然、サーバー障害が発生しないようにもする)データベース・スキーマを設計することは可能です。ライトビハインド・キャッシングでは、データベースの動作によりputが影響を受けないため、この問題は回避されます(根本的な問題は設計プロセスの初期段階で解決しておく必要があります)。

15.7.3 キャッシュ問合せ

キャッシュ問合せでは、キャッシュに格納されているデータのみを操作し、欠落(または欠落する可能性のある)データをロードするためにキャッシュ・ストアの実装をトリガーすることはありません。そのため、キャッシュ・ストアでバックアップされたキャッシュに問い合せるアプリケーションは、その問合せに必要なすべてのデータがあらかじめロードされていることを確認する必要があります。効率性を考慮して、アプリケーションの起動時にデータ・セットをデータベースから直接キャッシュに送信して、ほとんどのバルク・ロード操作を実行しておく必要があります(NamedCache.putAll()を使用して、データのブロックをキャッシュにまとめる)。ローダー処理は、制御可能なCachestoreパターンを使用して、データベースにバックアップされた循環更新を無効にする必要があります。キャッシュ・ストアを制御するには、起動サービスを使用するか(クラスタ全体にエージェントを送信して各JVMのローカル・フラグを変更します)、レプリケート・キャッシュ(別のキャッシュ・サービス)に値を設定して、すべてのキャッシュ・ストア実装のメソッド呼出しでその値を読み取ります(一般的なデータベース操作に比べて最小限のオーバーヘッドで済みます)。Coherenceのクラスタ化されたJMX機能により、カスタムMBeanも簡単に実装できます。

15.7.4 リエントラント・コール

キャッシュ・ストアの実装では、ホスティングしているキャッシュ・サービスをコールバックしないでください。これには、内部的にCoherenceキャッシュ・サービスを参照するORMソリューションも含まれます。別のキャッシュ・サービス・インスタンスをコールすることも可能ですが、深くネストされたコールは避けるように注意する必要があります。コールのそれぞれがキャッシュ・サービス・スレッドを消費するため、キャッシュ・サービス・スレッド・プールを使用し尽くすと、デッドロックが発生する可能性があります。

15.7.5 キャッシュ・サーバー・クラスパス

キャッシュ・エントリのクラス(値オブジェクト、データ転送オブジェクトとも呼ばれる)は、キャッシュ・サーバー・クラスパスに置く必要があります(キャッシュ・サーバーは、キャッシュ・エントリをシリアライズ/デシリアライズしてキャッシュ・ストアと相互作用する必要があるため)。

15.7.6 CacheStoreのコレクション操作

キャッシュがライトビハインドとして構成され、<write-batch-factorが構成されている場合に使用される可能性が最も高いのは、CacheStore.storeAllメソッドです。Coherenceでは、CacheLoader.loadAllメソッドも使用されます。同様の理由により、その最初の使用にはリフレッシュアヘッドを有効にする必要がある場合があります。

15.7.7 接続プール

データベース接続は、コンテナ接続プール(またはサード・パーティの接続プール)から取得するか、スレッドローカルの遅延初期化パターンを使用して取得する必要があります。専用キャッシュ・サーバーは、多くの場合、管理コンテナなしでデプロイされるため、後者が最も魅力的な選択になります。ただし、過度な同時データベース接続を回避するように、キャッシュ・サービスのスレッド・プール・サイズは制限する必要があります。

16 シリアライズ・ページ・キャッシュ

この章では、大量のバイナリ・データのヒープ外のキャッシュに関する一般情報について説明します。

この章には次の項が含まれます:

- シリアライズ・ページ・キャッシュの理解

- シリアライズ・ページ・キャッシュの構成

- パーティション・キャッシュ・サービスの最適化

- 高可用性の構成

- ロード・バランシングおよびフェイルオーバーの構成

- 巨大なキャッシュのサポート

16.1 シリアライズ・ページ・キャッシュの理解

Coherenceは、ディスク・ファイルなどの潜在的に待機時間の長い記憶域メカニズムを使用して、自動的に失効する大量のデータのキャッシュ処理の効率化を確実にサポートします。利点としては、メモリー内では管理できないほど大量のデータ・セットをサポートできるのみでなく、そのデータの管理のタイムアウトの失効メカニズムの効率性が保持されること(および管理に関連するリソースが自動的に解放されること)などが挙げられます。最適な使用シナリオとしては、キャッシュされたデータがディスクにページングされている場合に、アクセス頻度が非常に低いか、待機時間が長くてもアクセスが可能なラージ・オブジェクト、XMLドキュメントまたはコンテンツを数多く格納できることなどがあります。第14章「記憶域およびバッキング・マップの実装」を参照してください。

シリアライズ・ページ・キャッシュは、次のように定義されます。

- シリアライズは、キャッシュに格納されたオブジェクトがシリアライズされ、バイナリ・ストアに格納されることを意味します。既存の機能であるシリアライズ・マップおよびシリアライズ・キャッシュを参照してください。

- ページは、キャッシュに格納されたオブジェクトをセグメント化して管理を効率化することを意味します。

- キャッシュは、キャッシュのサイズに指定された制限が存在することを意味し、この制限はキャッシュが同時に管理するページの最大数で、この最大限度を超えると最も古いページから失効します。

これらをまとめると、データがキャッシュに格納された時刻を基準にしてデータをキャッシュ内に配列してから、ページ全体を単位として効率的にキャッシュ内のデータを失効させる機能ということになり、通常はディスクからデータをリロードする必要はありません。

16.2 シリアライズ・ページ・キャッシュの構成

シリアライズ・ページ・キャッシュの主な構成は、キャッシュで管理するページ数とページがアクティブな時間長の2つのパラメータで成り立っています。たとえば、1日のデータをキャッシュに格納する場合、それぞれが1時間に相当する24のページで構成したり、それぞれが15分に相当する96のページで構成できます。

キャッシュ内のデータの各ページは、別々のバイナリ・ストアで管理されます。キャッシュにはバイナリ・ストア・マネージャが必要です。これによってバイナリ・ストアの作成および破棄が可能になります。Coherenceでは、Berkley DB(「BDB」とします)など、組込みのバイナリ・ストア実装のすべてに対してバイナリ・ストア・マネージャが提供されます。

シリアライズ・ページ・キャッシュは、キャッシュ構成ファイルの<external-scheme>および<paged-external-scheme>要素の中で構成されます。詳細は、「external-scheme」および「paged-external-scheme」を参照してください。

16.3 パーティション・キャッシュ・サービスの最適化

Coherenceをパーティション・キャッシュのバッキングに使用した場合は、シリアライズ・マップおよびシリアライズ・キャッシュのいずれかに格納されるデータのすべてがバイナリ形式になるため、パーティション・キャッシュ・サービスを最適化できます。これはバイナリ・マップの最適化と呼ばれ、有効にした場合は、シリアライズ・マップ、シリアライズ・キャッシュおよびシリアライズ・ページ・キャッシュに権限が付与され、キャッシュに格納されるすべてのデータがバイナリであると見なされます。この最適化の結果、CPUおよびメモリーの使用量が減少し、パフォーマンスもやや向上します。キャッシュ構成要素<external-scheme>および<paged-external-scheme>を参照してください。

16.4 高可用性の構成

シリアライズ・ページ・キャッシュには、データのプライマリ記憶域に使用可能な構成およびデータのバックアップ記憶域向けに最適化された構成があり、パーティション・キャッシュ・サービスの高可用性機能も明確にサポートされます。バックアップ記憶域の構成は、パッシブ・モデルと呼ばれています。これは記憶域内のデータをアクティブに失効させるのではなく、プライマリ・キャッシュ記憶域で発生する失効が反映されるためです。パーティション・キャッシュ・サービスに高可用性データ機能(1つ以上のバックアップ数、デフォルト値は1)を使用し、シリアライズ・ページ・キャッシュをそのサービスの主要バッキング記憶域に使用する場合は、シリアライズ・ページ・キャッシュをバックアップ・ストアとしても使用し、passiveオプションを指定してバックアップを構成することをお薦めします。<paged-external-scheme>のキャッシュ構成要素の説明を参照してください。

16.5 ロード・バランシングおよびフェイルオーバーの構成

分散キャッシュ・サービスで使用する場合は、ロード・バランシングおよびフェイルオーバーに特に注意が必要です。キャッシュ・データが大量にある場合は、分散キャッシュ・サービスのpartition-countパラメータを通常より大きく設定します。パーティション数が大きいと、キャッシュ全体が小さなチャンクに分割されて、ロード・バランシングおよびフェイルオーバーによるリカバリ処理が行われます。たとえば、キャッシュのサイズが1TBと予測され、2万個のパーティションがあるとすると、キャッシュは平均で約50MBの単位に分割されます。単位(パーティションのサイズ)が大きすぎると、キャッシュのロード・バランシング時にメモリー不足状態が発生します。(パーティション数が素数であることを必ず確認してください。使用可能な素数のリストについては、http://primes.utm.edu/lists/small/を参照してください。)

16.6 巨大なキャッシュのサポート

失効データの巨大なキャッシュ(たとえばテラバイト単位)をサポートするため、失効処理はキャッシュ処理への割込みを発生することなく、デーモン・スレッド上で同時実行されます。このため、単一のキャッシュ・ページに何千または何百万ものオブジェクトが存在し、これらを非同期で失効させることができ、これによってサービスの中断を回避できます。デーモン・スレッドは、デフォルトで有効に設定されたオプションですが、無効にすることもできます。キャッシュ構成要素<external-scheme>および<paged-external-scheme>を参照してください。

大量のデータに対してキャッシュが使用される場合、通常はページがディスクによってバッキングされます。キャッシュは最終的に各ページを失効させてディスク・リソースを解放するため、キャッシュはデフォルトでは仮想削除の最適化を使用します。このため、キャッシュから明示的に削除されたデータや失効したデータは、実際には基礎となるバイナリ・ストアから削除されず、ページ(バイナリ・ストア)が完全に空になったときにすべてが消去されます。これによって、特にクラスタ内の大量のデータの再分散が必要な失効処理およびロード・バランシングなどの操作の際に、I/Oが大幅に減少します。この最適化の代償として、ディスク・ファイル(ディスクベースのバイナリ・ストア・オプションを使用する場合)が、それらが管理しているデータが示唆するよりも大きくなる傾向があります。ディスク領域は応答時間などの他の要素と比較して安価と見なされるため、仮想削除の最適化はデフォルトで有効になっていますが、無効にすることもできます。一般に、ディスク領域はローカルで各サーバーに割り当てられ、テラバイトのキャッシュも100台以上のサーバーでパーティション化されるため、使用されるディスク領域はサーバー1台当たり約20GBにすぎません(プライマリ・ストアに10GB、バックアップのレベルが1とした場合にバックアップ・ストアに10GB。)

17 クォーラムの使用

この章では、クラスタの適切なプロビジョニングを確保するためにクラスタ内で特定のサービス・アクションが許可されるタイミングを制御するクォーラム・ポリシーの使用方法と構成方法について説明します。

この章には次の項が含まれます:

- クォーラムの使用の概要

- クラスタ・クォーラムの使用

- パーティション・キャッシュ・クォーラムの使用

- プロキシ・クォーラムの使用

- カスタムのアクション・ポリシーの使用

17.1 クォーラムの使用の概要

Coherenceでは、クォーラムとは、サービス・アクションを許可または禁止する前にクラスタに必要なサービス・メンバーの最小数のことです。クォーラムを使用すると、メンバー数がしきい値に達したときにクラスタが予測どおりに動作することが自動的に保証されるため、クォーラムは有用です。たとえば、パーティション・キャッシュのバックアップのクォーラムには、パーティション・キャッシュ・サービスがパーティションのバックアップを許可される前に、記憶域が有効なメンバーが5つ以上必要となる場合があります。

クォーラムはサービス固有で、クォーラム・ポリシー内で定義されます。クラスタ・サービスのクラスタ・クォーラム・ポリシー、パーティション・キャッシュ・サービスのパーティション・クォーラム・ポリシーおよびプロキシ・サービスのプロキシ・クォーラム・ポリシーがあります。クォーラムのしきい値は、キャッシュ構成ファイルを使用してポリシーに設定されます。

各クォーラムには、それぞれの特定のサービスに関する利点があります。ただし、一般的にクォーラムは次のとおりです。

- 様々なサービス・メンバー・レベルでサービスの動作を制御します。

- サービスの操作に必要な最小限のサービス・メンバー・レベルを指定する必要があります。

- 特定のアプリケーションまたはソリューションに最適なクラスタおよびキャッシュ環境を保証します。

17.2 クラスタ・クォーラムの使用

クラスタ・クォーラム・ポリシーによって、クラスタ・サービスに1つのクォーラム(タイムアウト・サバイバ・クォーラム)が定義されます。タイムアウト・サバイバ・クォーラムでは、疑いのあるメンバーをクラスタ・サービスが終了するときに、クラスタに保持しておく必要があるクラスタ・メンバーの最小数を指定する必要があります。メンバーは、ネットワーク通信に応答しておらず、クラスタから切断される危険が迫っている場合に、疑いがあると見なされます。クォーラムをすべてのメンバーに汎用的に指定することも、クライアント・メンバーやサーバー・メンバーなどクラスタ内で特定のロールを持っているメンバーに制約することもできます。クラスタ・メンバーのロール名の定義の詳細は、「member-identity」の<role-name>要素を参照してください。

このクォーラムは通常、ネットワーク・パフォーマンスが変化する環境で使用されます。たとえば、断続的なネットワーク停止によって多くのクラスタ・メンバーがクラスタから削除されてしまう場合があります。このクォーラムを使用すると、一定の数のメンバーが停止時に保持され、ネットワークの回復時に使用可能になります。また、この動作によって、メンバーの再起動に必要な手動の介在が最小限に抑えられます。当然ながら、応答していないノードからの協調関係を必要とするリクエストは完了できず、停止時間中はブロックされるか、またはタイムアウトになります。

17.2.1 クラスタ・クォーラム・ポリシーの構成

タイムアウト・サバイバ・クォーラムのしきい値は、<timeout-survivor-quorum>要素とオプションでrole属性を使用して、オペレーション・オーバーライド・ファイルに構成します。この要素は、<cluster-quorum-policy>要素内で使用する必要があります。次の例では、疑いのあるメンバーを削除するときに、serverロールが付与された5つのクラスタ・メンバーが常にクラスタに保持されるように、タイムアウト・サバイバ・クォーラムのしきい値が構成されます。

<cluster-config>
<member-identity>
<role-name>server</role-name>
</member-identity>
<cluster-quorum-policy>
<timeout-survivor-quorum role="Server">5</timeout-survivor-quorum>
</cluster-quorum-policy>
</cluster-config>

17.3 パーティション・キャッシュ・クォーラムの使用

パーティション・キャッシュ・クォーラム・ポリシーでは、様々なパーティション・キャッシュ・サービス操作の実行を許可する前に、必要なサービス・メンバーの数を指定する必要がある4つのクォーラムがパーティション・キャッシュ・サービス(DistributedCache)に定義されます。

- 分散クォーラム - このクォーラムでは、パーティション・キャッシュ・サービスによるパーティション分散の実行を許可する前に、存在している必要のある、パーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定する必要があります。

- リストア・クォーラム - このクォーラムでは、失われたプライマリ・パーティションをバックアップからリストアするパーティション・キャッシュ・サービスによる操作を許可する前に、存在している必要のある、パーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定する必要があります。

- 読取りクォーラム - このクォーラムでは、読取りリクエストを処理するために存在している必要のあるパーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定します。読取りリクエストとは、キャッシュの状態や内容を変化させないリクエストです。

- 書込みクォーラム - このクォーラムでは、書込みリクエストを処理するために存在している必要のあるパーティション・キャッシュ・サービスの記憶域が有効なメンバーの最小数を指定します。書込みリクエストとは、キャッシュの状態や内容を変化させる可能性のあるリクエストです。

これらのクォーラムは通常、分散キャッシュを意図された使用方法と要件で使用する場合に、様々なサービス操作が最適に実行されるサービス・メンバー・レベルを示すために使用されます。たとえば、小さな分散キャッシュで、適切にデータを格納し、予想されるリクエスト量を処理するために、記憶域が有効なメンバーが3つのみ必要な場合があります。一方、大きな分散キャッシュで、適切にデータを格納し、予想されるリクエスト量を処理するために、記憶域が有効なメンバーが10以上必要な場合があります。最適なメンバー・レベルは、開発時にテストし、それに合わせて本番環境で最小のサービス・メンバー・レベルが使用できるように設定します。

サービスを実行する、記憶域が有効なノードの数が、読取りまたは書込みクォーラムの構成レベルを下回った場合は、com.tangosol.net.RequestPolicyExceptionのスローによって対応するクライアント操作が拒否されます。記憶域が有効なノードの数が分散クォーラムの構成レベルを下回った場合は、クォーラムに達するまで一部のデータが消失の危険がある状態(バックアップがない)になることがあります。リストア・クォーラムを下回った場合は、クォーラムに達するかタイムアウトになるまで一部の操作がブロックされることがあります。

17.3.1 パーティション・キャッシュ・クォーラム・ポリシーの構成

パーティション・キャッシュ・クォーラムは、キャッシュ構成ファイルの<partitioned-quorum-policy-scheme>要素内で構成します。この要素は、<distributed-scheme>要素内で使用する必要があります。次の例では、パーティション・キャッシュ・クォーラムにしきい値を構成しています。しきい値には、操作の実行に必要なサービス・メンバーの最小数を指定することをお薦めします。

<distributed-scheme>
<scheme-name>partitioned-cache-with-quorum</scheme-name>
<service-name>PartitionedCacheWithQuorum</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<distribution-quorum>4</distribution-quorum>
<restore-quorum>3</restore-quorum>
<read-quorum>3</read-quorum>
<write-quorum>5</write-quorum>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

<partitioned-quorum-policy-scheme>要素では、スキーム参照の使用もサポートされています。次の例では、partitioned-cache-quorumという名前の<partitioned-quorum-policy-scheme>が、<distributed-scheme>要素内から参照されます。

<distributed-scheme>
<scheme-name>partitioned-cache-with-quorum</scheme-name>
<service-name>PartitionedCacheWithQuorum</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<scheme-ref>partitioned-cache-quorum</scheme-ref>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

<distributed-scheme>
<scheme-name>dist-example</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<scheme-name>partitioned-cache-quorum</scheme-name>
<distribution-quorum>4</distribution-quorum>
<restore-quorum>3</restore-quorum>
<read-quorum>3</read-quorum>
<write-quorum>5</write-quorum>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

17.4 プロキシ・クォーラムの使用

プロキシ・クォーラム・ポリシーによって、プロキシ・サービスに1つのクォーラム(接続クォーラム)が定義されます。接続クォーラムでは、プロキシ・サービスでクライアント接続が許可される前に使用可能にしておく必要のあるプロキシ・サービス・メンバーの最小数を指定する必要があります。

このクォーラムは通常、指定のTCPクライアント・セットを最適にサポートするために十分なプロキシ・サービス・メンバーが使用可能であることを保証するために使用します。たとえば、少数のクライアントから2つのプロキシ・サービスを使用してクラスタに効率的に接続する場合があります。一方、多数のクライアントで、クラスタに効率的に接続するには3つ以上のプロキシ・サービスが必要な場合があります。最適なレベルは、開発時にテストし、それに合わせて本番環境で最小のサービス・メンバー・レベルが使用できるように設定します。

17.4.1 プロキシ・クォーラム・ポリシーの構成

接続クォーラムのしきい値は、キャッシュ構成ファイルの<proxy-quorum-policy-scheme>要素内で構成します。この要素は、<proxy-scheme>要素内で使用する必要があります。次の例では、プロキシ・サービスでTCPクライアント接続の受入れが許可される前にクラスタに必ず3つのプロキシ・サービス・メンバーが存在するように接続クォーラムのしきい値を構成しています。

<proxy-scheme>
<scheme-name>proxy-with-quorum</scheme-name>
<service-name>TcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>localhost</address>
<port>32000</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<proxy-quorum-policy-scheme>
<connect-quorum>3</connect-quorum>
</proxy-quorum-policy-scheme>
<autostart>true</autostart>
</proxy-scheme>

<proxy-quorum-policy-scheme>要素では、スキーム参照の使用もサポートされています。次の例では、proxy-quorumという名前の<proxy-quorum-policy-scheme>が、<proxy-scheme>要素内から参照されます。

<proxy-scheme>
<scheme-name>proxy-with-quorum</scheme-name>
<service-name>TcpProxyService</service-name>
...
<proxy-quorum-policy-scheme>
<scheme-ref>proxy-quorum</scheme-ref>
</proxy-quorum-policy-scheme>
<autostart>true</autostart>
</proxy-scheme>
<proxy-scheme>
<scheme-name>proxy-example</scheme-name>
<service-name>TcpProxyService</service-name>
...
<proxy-quorum-policy-scheme>
<scheme-name>proxy-quorum</scheme-name>
<connect-quorum>3</connect-quorum>
</proxy-quorum-policy-scheme>
<autostart>true</autostart>
</proxy-scheme>

17.5 カスタムのアクション・ポリシーの使用

カスタムのアクション・ポリシーは、クラスタ・サービス、パーティション・キャッシュ・サービスおよびプロキシ・サービスのデフォルトのクォーラム・ポリシーのかわりに使用できます。カスタムのアクション・ポリシーは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。

この項には次のトピックが含まれます:

- カスタムのアクション・ポリシーの有効化

- カスタム・フェイルオーバー・アクセス・ポリシーの有効化

17.5.1 カスタムのアクション・ポリシーの有効化

カスタムのポリシーを有効にするには、実装クラスの完全修飾名が含まれるクォーラム・ポリシー・スキーム要素に<class-name>要素を追加します。次の例では、分散キャッシュ・スキーム定義のパーティション・クォーラム・ポリシーにカスタムのアクション・ポリシーが追加されます。

<distributed-scheme>
<scheme-name>partitioned-cache-with-quorum</scheme-name>
<service-name>PartitionedCacheWithQuorum</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<class-name>package.MyCustomAction</class-name>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

代替案として、ファクトリ・クラスでカスタム・アクション・ポリシー・インスタンスを作成できます。ファクトリ・クラスを定義するには、<class-factory-name>要素を使用して、完全修飾クラス名と<method-name>要素を入力し、オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定します。次に例を示します。

<distributed-scheme>
<scheme-name>partitioned-cache-with-quorum</scheme-name>
<service-name>PartitionedCacheWithQuorum</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<class-factory-name>package.Myfactory</class-factory-name>
<method-name>createPolicy</method-name>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

17.5.2 カスタム・フェイルオーバー・アクセス・ポリシーの有効化

Coherenceは、キャッシュ・サーバーがパーティション・バックアップを適切に再確立できるよう、フェイルオーバー・イベント中にクライアント・リクエストの負荷を軽減する事前定義済カスタム・アクション・ポリシーを提供します。このポリシーは、長待機時間のリクエストによる高い負荷によって、キャッシュ・サーバーが、転送またはバックアップする必要があるパーティションへの排他アクセスを妨げたり、大幅に遅延させる可能性がある場合に使用します。

カスタム・フェイルオーバー・アクセス・ポリシーを有効化するには、フェイルオーバー・アクセス・ポリシー(com.tangosol.net.partition.FailoverAccessPolicy)の完全修飾名を含む<class-name>要素を<partition-quorum-policy-scheme>要素内に追加します。このポリシーが受け入れるパラメータは次のとおりです。

- cThresholdMillis - 危険な状態になった後にポリシーによってリクエストの保留が開始されるまでの遅延を指定します。デフォルト値は5000ミリ秒です。

- cLimitMillis - 危険な状態になった後にポリシーによってリクエストを保留するための最大限の取組みが行われるまでの遅延を指定します。デフォルト値は、60000ミリ秒です。

- cMaxDelayMillis - リクエストを保留する時間の最大の長さを指定します。デフォルト値は5000ミリ秒です。

次の例では、カスタム・フェイルオーバー・アクセス・ポリシーを有効化し、各パラメータを設定します。

<distributed-scheme>
<scheme-name>partitioned-cache-with-quorum</scheme-name>
<service-name>PartitionedCacheWithQuorum</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<class-name>com.tangosol.net.partition.FailoverAccessPolicy/class-name>
<init-params>
<init-param>
<param-name>cThresholdMillis</param-name>
<param-value>7000</param-value>
</init-param>
<init-param>
<param-name>cLimitMillis</param-name>
<param-value>30000</param-value>
</init-param>
<init-param>
<param-name>cMaxDelayMillis</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

18 キャッシュの構成例

この章では、一連の基本的なキャッシュ・スキーム定義について説明します。これらの定義は必要に応じて使用または変更できます。キャッシュの構成方法の詳細は、第13章「キャッシュの構成」を参照してください。また、この章で紹介するサンプルのビルドは相互に依存しており、他のサンプルをネスト・スキームとして再使用する際は、多くの場合<scheme-ref>要素が使用されます。<scheme-ref>要素の使用方法の詳細は、「スキームの継承の使用」を参照してください。紹介するサンプルでは、最小数の設定のみを指定しています。すべてのオプションを参照するには、スキームのドキュメントへの埋込みリンクを使用してください。

この章には次の項が含まれます:

- ローカル・キャッシュ(単一のJVMからアクセス可能)

- クラスタ化キャッシュ(複数のJVMからアクセス可能)

18.1 ローカル・キャッシュ(単一のJVMからアクセス可能)

この項では、一連のローカル・キャッシュ・スキームを定義します。ここでいうローカルとは、キャッシュに直接アクセスできるJVMが1つのみであることを意味します。このドキュメントの後述部分で、ローカル・キャッシュはクラスタ化キャッシュの構成要素として使用されます。「クラスタ化キャッシュ(複数のJVMからアクセス可能)」を参照してください。

この項には次のトピックが含まれます:

- インメモリー・キャッシュ

- サイズ制限があるインメモリー・キャッシュ

- エントリの期限切れが設定されたインメモリー・キャッシュ

- ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ

- NIOインメモリー・キャッシュ

- オンディスク・キャッシュ

- サイズ制限があるオンディスク・キャッシュ

- オンディスク永続キャッシュ

- データベースのキャッシュ

18.1.1 インメモリー・キャッシュ

例18-1では、local-schemeを使用して、インメモリー・キャッシュを定義します。キャッシュには、JVMヒープで可能なかぎりの容量が保存されます。

例18-1 ローカルのインメモリー・キャッシュの構成

<local-scheme>
<scheme-name>SampleMemoryScheme</scheme-name>
</local-scheme>

18.1.2 サイズ制限があるインメモリー・キャッシュ

<local-scheme>に<high-units>サブ要素を追加すると、キャッシュのサイズが制限されます。この例では、キャッシュのサイズが1000エントリに制限されます。制限を超えると、スキームの<eviction-policy>によって、キャッシュからの削除対象となる要素が決定されます。

例18-2 サイズ制限があるインメモリー・ローカル・キャッシュの構成

<local-scheme>
<scheme-name>SampleMemoryLimitedScheme</scheme-name>
<high-units>1000</high-units>
</local-scheme>

18.1.3 エントリの期限切れが設定されたインメモリー・キャッシュ

<local-scheme>に<expiry-delay>サブ要素を追加すると、指定した期間内に更新されなかったキャッシュ・エントリが自動的に期限切れになります。期限切れになるとそのエントリは無効化され、キャッシュから削除されます。

例18-3 エントリの期限切れが設定されたインメモリー・キャッシュの構成

<local-scheme>
<scheme-name>SampleMemoryExpirationScheme</scheme-name>
<expiry-delay>5m</expiry-delay>
</local-scheme>

18.1.4 ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ

例18-4では、overflow-schemeを使用して、サイズが制限されたインメモリー・キャッシュを定義します。インメモリー(<front-scheme>)のサイズの上限に達すると、キャッシュの内容の一部がディスク(<back-scheme>)に移動されます。front-schemeの<eviction-policy>によって、フロントからバックへの移動対象となる要素が決定されます。

この例では、キャッシュのフロントおよびバックの実装に「サイズ制限があるオンディスク・キャッシュ」と「オンディスク・キャッシュ」の例が再利用されています。

例18-4 ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュの構成

<overflow-scheme>
<scheme-name>SampleOverflowScheme</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>SampleMemoryLimitedScheme</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<external-scheme>
<scheme-ref>SampleDiskScheme</scheme-ref>
</external-scheme>
</back-scheme>
</overflow-scheme>

18.1.5 NIOインメモリー・キャッシュ

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

例18-5では、external-schemeを使用して、nio-memory-managerによるインメモリー・キャッシュを定義します。NIOメモリー・ベース・キャッシュの利点は、JVMのGC回数に悪影響を与えずに、大きなインメモリー・キャッシュ記憶域に対応できることです。キャッシュのサイズは、NIOメモリー・リージョンの最大サイズによって制限されます。nio-memory-managerの<maximum-size>サブ要素を参照してください。

例18-5 NIOインメモリー・キャッシュの構成

<external-scheme>
<scheme-name>SampleNioMemoryScheme</scheme-name>
<nio-memory-manager/>
</external-scheme>

18.1.6 オンディスク・キャッシュ

例18-6では、external-schemeを使用して、オンディスク・キャッシュを定義します。

注意:
この例では、bdb-store-manager (Berkeley Database)を使用して、そのオンディスク記憶域を実装します。これ以外の外部記憶域オプションについては、「external-scheme」を参照してください。

例18-6 オンディスク・キャッシュを定義する構成

<external-scheme>
<scheme-name>SampleDiskScheme</scheme-name>
<bdb-store-manager/>
</external-scheme>

18.1.7 サイズ制限があるオンディスク・キャッシュ

external-schemeに<high-units>サブ要素を追加すると、キャッシュのサイズが制限されます。この例では、キャッシュのサイズが100万エントリに制限されます。制限を超えると、LRUエビクションが使用され、キャッシュからの削除対象となる要素が決定されます。これ以外のサイズ制限がある外部キャッシング方法については、「paged-external-scheme」を参照してください。

例18-7 サイズ制限があるオンディスク・キャッシュの構成

<external-scheme>
<scheme-name>SampleDiskLimitedScheme</scheme-name>
<bdb-store-manager/>
<high-units>1000000</high-units>
</external-scheme>

18.1.8 オンディスク永続キャッシュ

例18-8では、external-schemeを使用して、単一のJVMの長期記憶域としての使用に適したキャッシュを実装します。

外部キャッシュは一般的に、大きなデータ・セットの一時記憶域に使用され、JVMのシャットダウン時に自動的に削除されます。bdb-store-managerストレージ・マネージャを使用した場合は、非クラスタ化キャッシュで外部キャッシュを長期記憶域として使用できます(「永続性(長期記憶域)」を参照)。クラスタ化の永続性については、「データベースのパーティション・キャッシュ」にあるサンプルを参照してください。

データが格納されるファイルの名前を指定するには、{cache-name}マクロを使用します。このマクロの詳細は、「パラメータ・マクロの使用」を参照してください。

例18-8 Berkeley DBによるオンディスク永続キャッシュの構成

<external-scheme>
<scheme-name>SampleDiskPersistentScheme</scheme-name>
<bdb-store-manager>
<directory>/my/storage/directory</directory>
<store-name>{cache-name}.store</store-name>
</bdb-store-manager>
</external-scheme>

18.1.9 データベースのキャッシュ

例18-9では、read-write-backing-map-schemeを使用して、データベースのキャッシュを定義します。このスキームでは、データベースの内容の一部であるローカル・キャッシュが保持されます。キャッシュ・ミスによってデータベース全体が読み取られ、元のデータベースにキャッシュが書き込まれます。

cachestore-scheme要素は、com.tangosol.net.cache.CacheLoaderまたはcom.tangosol.net.cache.CacheStoreのいずれかのインタフェースを実装するカスタム・クラスによって構成されます。このクラスは、キャッシュ・エントリの読取りや書込みなど、データベースに対するすべての操作を担当します。キャッシュ・ストアの書込みの例については、「キャッシュ・ストアの実装のサンプル」を参照してください。

キャッシュ・ストアの実装に対して、バッキングされるキャッシュの名前を通知するには、{cache-name}マクロを使用します。このマクロの詳細は、「パラメータ・マクロの使用」を参照してください。

例18-9 データベースのキャッシュの構成

<read-write-backing-map-scheme>
<scheme-name>SampleDatabaseScheme</scheme-name>
<internal-cache-scheme>
<local-scheme>
<scheme-ref>SampleMemoryScheme</scheme-ref>
</local-scheme>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<class-name>com.tangosol.examples.coherence.DBCacheStore</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
</read-write-backing-map-scheme>

18.2 クラスタ化キャッシュ(複数のJVMからアクセス可能)

この項では、一連のクラスタ化キャッシュのサンプルを定義します。クラスタ化キャッシュは、複数のJVM(同じキャッシュ・サービスを実行する任意のクラスタ・ノード)からアクセスできます。各クラスタ・ノード上の内部キャッシュ記憶域(backing-map)は、ローカル・キャッシュを使用して定義します(「ローカル・キャッシュ(単一のJVMからアクセス可能)」を参照)。キャッシュ・サービスには、他のクラスタ・ノードのローカル・キャッシュにアクセスする機能があります。

この項には次のトピックが含まれます:

- パーティション・キャッシュ

- オーバーフローが設定されたパーティション・キャッシュ

- ジャーナル記憶域が設定されたパーティション・キャッシュ

- データベースのパーティション・キャッシュ

- シリアライザが設定されたパーティション・キャッシュ

- ニア・キャッシュ

- レプリケート・キャッシュ

- オーバーフローが設定されたレプリケート・キャッシュ

18.2.1 パーティション・キャッシュ

例18-10では、distributed-schemeを使用して、クラスタ化キャッシュを定義します。このキャッシュでは、キャッシュ記憶域がクラスタ・ノード全体にわたってパーティション化されます。

「インメモリー・キャッシュ」を使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュの記憶域の合計容量は、パーティション・キャッシュ・サービスを実行する、記憶域が有効なクラスタ・ノードの合計です。「distributed-scheme」の<local-storage>サブ要素を参照してください。

例18-10 パーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedScheme</scheme-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>SampleMemoryScheme</scheme-ref>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>

18.2.2 オーバーフローが設定されたパーティション・キャッシュ

backing-map-scheme要素では、スキーム参照を使用して、他のローカル・キャッシュの任意のサンプルを指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、記憶域が有効なクラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。キャッシュのバックアップ記憶域も同じオーバーフロー・スキームを使用するため、バックアップ・データをディスクにオーバーフローできます。

例18-11 オーバーフローが設定されたパーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedOverflowScheme</scheme-name>
<backing-map-scheme>
<overflow-scheme>
<scheme-ref>SampleOverflowScheme</scheme-ref>
</overflow-scheme>
</backing-map-scheme>
<backup-storage>
<type>scheme</type>
<scheme-name>SampleOverflowScheme</scheme-name>
</backup-storage>
</distributed-scheme>

18.2.3 ジャーナル記憶域が設定されたパーティション・キャッシュ

例18-12では、backing-map-scheme要素を使用して、バッキング・マップにRAMジャーナルを使用するパーティション・キャッシュを定義します。RAMジャーナルは、構成されたメモリー・サイズを超えると、自動的にフラッシュ・ジャーナルに委任します。RAMジャーナルおよびフラッシュ・ジャーナルの構成の詳細は、「ジャーナル・スキームの定義」を参照してください。

例18-12 RAMジャーナルが設定されたパーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedJournalScheme</scheme-name>
<backing-map-scheme>
<ramjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

例18-13では、バッキング・マップにフラッシュ・ジャーナルを直接使用するパーティション・キャッシュを定義します。

例18-13 フラッシュ・ジャーナルが設定されたパーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedJournalScheme</scheme-name>
<backing-map-scheme>
<flashjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

18.2.4 データベースのパーティション・キャッシュ

backing-map-scheme要素を切り替えてread-write-backing-map-schemeを使用すると、キャッシュでの、データベースなどの外部ソースに対するエントリのロードおよび格納が可能になります。

例18-14では、「データベースのキャッシュ」を再利用して、データベース・アクセスを定義しています。

例18-14 データベースのパーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedDatabaseScheme</scheme-name>
<backing-map-scheme>
<read-write-backing-map-scheme>
<scheme-ref>SampleDatabaseScheme</scheme-ref>
<internal-cache-scheme>
<local-scheme>
<scheme-ref>SampleMemoryScheme</scheme-ref>
</local-scheme>
</internal-cache-scheme>
</read-write-backing-map-scheme>
</backing-map-scheme>
</distributed-scheme>

18.2.5 シリアライザが設定されたパーティション・キャッシュ

例18-15では、distributed-schemeのシリアライザ要素を使用して、ユーザー定義型のシリアライズおよびデシリアライズに使用されるシリアライザを定義します。この場合、パーティション・キャッシュはPOF (ConfigurablePofContext)をシリアライズ形式として使用します。POFを使用し、アプリケーションでカスタムのユーザー定義型クラスを使用する場合は、そのクラス用にカスタムのPOF構成も定義する必要があります。POFの要素の詳細は、付録C「POFユーザー定義型の構成要素」を参照してください。

例18-15 シリアライザが設定されたパーティション・キャッシュの構成

<distributed-scheme>
<scheme-name>SamplePartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
</instance>
</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

tangosol-coherence.xmlデプロイメント・ディスクリプタで定義されるシリアライザも参照できます。

例18-16 シリアライザを参照するパーティション・キャッシュ

<distributed-scheme>
<scheme-name>SamplePartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>pof</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

最後に、すべてのスキームにデフォルトのシリアライザを定義することで、それぞれのキャッシュ・スキーム定義に明示的に<serializer>要素を含める必要がなくなります。グローバル・シリアライザの定義により、tangosol-coherence.xmlデプロイメント・ディスクリプタで定義されたシリアライザを参照することもできます。

例18-17 デフォルト・シリアライザの定義

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<serializer>pof</serializer>
</defaults>
...

18.2.6 ニア・キャッシュ

例18-18では、near-schemeを使用して、パーティション・キャッシュのサブセットのローカル・インメモリー・キャッシュを定義します。この定義によって、パーティション・キャッシュにアクセスするクラスタ・ノードに、アクセス頻度の高い要素のローカル・コピーが保持されます。その結果、読取りパフォーマンスはreplicated-schemeベースのキャッシュに近づき、distributed-schemeベースのキャッシュと同様の高いスケーラビリティも得られます。

ニア(<front-scheme>)キャッシュの定義には「サイズ制限があるインメモリー・キャッシュ」のサンプルが再利用され、near-schemeの定義には「パーティション・キャッシュ」のサンプルが再利用されます。

front-schemeのサイズ制限付きの構成によって、back-schemeキャッシュがローカルにキャッシュされる量の制限が指定されます。

例18-18 パーティション・キャッシュのローカル・キャッシュの構成

<near-scheme>
<scheme-name>SampleNearScheme</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>SampleLimitedMemoryScheme</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-ref>SamplePartitionedScheme</scheme-ref>
</distributed-scheme>
</back-scheme>
</near-scheme>

18.2.7 レプリケート・キャッシュ

例18-19では、replicated-scheme要素を使用してクラスタ化キャッシュを定義します。このキャッシュでは、各キャッシュ・エントリのコピーがすべてのクラスタ・ノードに格納されます。

「インメモリー・キャッシュ」のサンプルを使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュのサイズは、JVMヒープが最小のクラスタ・ノードによってのみ制限されます。

例18-19 レプリケート・キャッシュの構成

<replicated-scheme>
<scheme-name>SampleReplicatedScheme</scheme-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>SampleMemoryScheme</scheme-ref>
</local-scheme>
</backing-map-scheme>
</replicated-scheme>

18.2.8 オーバーフローが設定されたレプリケート・キャッシュ

backing-map-scheme要素では、他のローカル・キャッシュのサンプルのいずれでも簡単に指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、クラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。

例18-20 オーバーフローが設定されたレプリケート・キャッシュの構成

<replicated-scheme>
<scheme-name>SampleReplicatedOverflowScheme</scheme-name>
<backing-map-scheme>
<overflow-scheme>
<scheme-ref>SampleOverflowScheme</scheme-ref>
</overflow-scheme>
</backing-map-scheme>
</replicated-scheme>

19 キャッシュ構成ファイルの拡張

この章では、XMLネームスペースおよびネームスペース・ハンドラ・クラスを使用して、Coherenceキャッシュ構成ファイルを拡張する詳細な手順について説明します。この章の手順では、XMLネームスペースおよびXML処理について一般的な知識を持っていることを前提としています。

この章には次の項が含まれます:

- キャッシュ構成ファイルの拡張の概要

- XMLネームスペースの宣言

- ネームスペース・ハンドラの作成

- 例: JNDIリソース・ネームスペース・ハンドラ

19.1 キャッシュ構成ファイルの拡張の概要

キャッシュ構成ファイルには、ユーザー定義のXML要素および属性を含めることができます。要素および属性はXMLネームスペース内で宣言され、実行時にネームスペース・ハンドラによって処理されます。ネームスペース・ハンドラを使用すると、要素および属性の処理に基づいてアプリケーション・ロジックを実行できます。

次の例では、RunNamespaceHandlerネームスペース・ハンドラ・クラスに関連付けられたrunネームスペースを宣言して、キャッシュ構成ファイルを拡張します。実行時に、このハンドラ・クラスは<run:runnable>要素とその属性を処理し、必要に応じてクラスタ・メンバー上でロジックを実行します。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-cache-config coherence-cache-config.xsd"
xmlns:run="class://com.examples.RunNamespaceHandler">
<run:runnable classname="MyRunnable" every="10m"/>
...
</cache-config>

通常は、キャッシュ構成ファイルを拡張して、アプリケーションがカスタムの初期化、バックグラウンド・タスクを実行したり、クラスタ内のキャッシュのモニタリングおよび保守を実行できるようにします。たとえば、アプリケーションで次のことを実行できます。

- ドメイン固有のキャッシュ・エントリ索引の構築

- キャッシュされている情報の事前ロード

- クラスタへの構成のロード

- クラスタに対するバックグラウンド・タスクの実行またはスケジュール

- 外部システムとの統合

キャッシュ構成ファイルを拡張すると、共通で統合的な構成の場所がアプリケーションに提供されます。また、アプリケーション・ロジックは、可用性およびスケーラビリティに優れた環境であるクラスタに埋め込まれて管理され、必要な場合は、障害が発生したアプリケーション・ロジックの自動リカバリを提供することもできます。

19.2 XMLネームスペースの宣言

ネームスペース宣言を使用して、キャッシュ構成ファイル内でネームスペースを宣言します。XMLネームスペースの使用はXML仕様に準拠している必要があります。実行時に、XML構文およびXMLネームスペースが検証され、ネームスペースの接頭辞に対応するxmlnsの宣言が存在することを確認するチェックが実行されます。キャッシュ構成ファイル内でエラーが発生した場合、Coherenceのメンバーは起動に失敗します。次の例では、接頭辞exを使用したネームスペースを宣言しています。

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd"
xmlns:ex="URI">
...

ネームスペースのURI値は、class://FullyQualifiedClassNameの形式である必要があります。正しくない形式が指定された場合は、障害が発生し、Coherenceのメンバーは起動に失敗します。宣言で指定されたハンドラ・クラスは、NamespaceHandlerインタフェースを実装するクラスである必要があります。ハンドラ・クラスの作成の詳細は、「ネームスペース・ハンドラの作成」を参照してください。

ハンドラ・クラスは、関連付けられたXML要素および属性がキャッシュ構成ファイル内に出現したときに処理できる必要があります。さらに具体的に言うと、キャッシュ構成のXML DOMの処理中にネームスペース内に出現したすべてのXML要素および属性は、関連付けられたハンドラ・インスタンスに渡されて処理されます。次の例では、MyNamespaceHandlerを使用して、exのネームスペース接頭辞を使用するすべての要素を処理します。

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd"
xmlns:ex="class://MyNamespaceHandler">

<ex:myelement/>
...

XMLネームスペースの宣言のガイドライン

XMLネームスペースを宣言する際は、次のガイドラインを使用します。

- URIクラスはNamespaceHandlerインタフェースを実装する必要があります。そうしない場合、キャッシュ構成ファイルの処理は失敗します。

- XML要素および属性で、宣言されていないネームスペース接頭辞を使用しないでください。そうしない場合、キャッシュ構成ファイルの処理は失敗します。

- Coherenceの要素および属性に使用されるデフォルト・ハンドラはオーバーライドできません。そうした場合、キャッシュ構成ファイルの処理は失敗します。デフォルトのネームスペースはCoherence用に予約されています。

19.3 ネームスペース・ハンドラの作成

ネームスペース・ハンドラは、特定のXMLネームスペースに属するXML要素および属性を処理するために使用されます。キャッシュ構成ファイル内で使用される一意の各ネームスペースには、ネームスペース・ハンドラが必要です。ネームスペース・ハンドラは、NamespaceHandlerインタフェースを実装する必要があります。通常、ネームスペース・ハンドラはベースのAbstractNamespaceHandler実装クラスを拡張し、それにより、複雑なネームスペースの処理を容易化できる便利なメソッドが提供されます。この項で説明するこれらのAPIはいずれもcom.tangosol.config.xmlパッケージに含まれています。これらのAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

この項には次のトピックが含まれます:

- ネームスペース・ハンドラ・インタフェースの実装

- ネームスペース・ハンドラ抽象クラスの拡張

19.3.1 ネームスペース・ハンドラ・インタフェースの実装

ネームスペース・ハンドラは、XMLネームスペース内で使用される要素および属性を処理します。ネームスペース・ハンドラは、NamespaceHandlerインタフェースを直接実装できます。このインタフェースは、DocumentPreprocessor、ElementProcessorおよびAttributeProcessorの各インタフェースに依存します。XMLの処理は、ProcessingContextインタフェースで定義された処理コンテキスト内で実行されます。

ネームスペースに出現する要素および属性は、プロセッサ実装で処理する必要があります。要素および属性のプロセッサは、処理、解析および型変換のロジックを担当します。ドキュメント・プロセッサは、必要であれば処理する前に要素を変化させるために使用します。

例19-1に、基本的なNamespaceHandlerの実装を示します。GreetingNamespaceHandler実装は、内部クラスとして含まれるElementProcessor実装(MessageProcessor)を使用して、<message>要素を処理します。たとえば、次のXMLがあると想定します。

<?xml version="1.0"><cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd"
xmlns:ex="class://com.examples.GreetingNamespaceHandler">

<ex:message>hello</ex:message>
...

例19-1 NamespaceHandlerインタフェースを使用したハンドラの実装

import com.tangosol.config.ConfigurationException;
import com.tangosol.config.xml.AttributeProcessor;
import com.tangosol.config.xml.DocumentPreprocessor;
import com.tangosol.config.xml.ElementProcessor;
import com.tangosol.config.xml.NamespaceHandler;
import com.tangosol.config.xml.ProcessingContext;
import com.tangosol.run.xml.XmlAttribute;
import com.tangosol.run.xml.XmlElement;
import java.net.URI;

public class GreetingNamespaceHandler implements NamespaceHandler
{
public AttributeProcessor getAttributeProcessor(XmlAttribute xmlAttribute)
{
return null;
}

public DocumentPreprocessor getDocumentPreprocessor()
{
return null;
}

public ElementProcessor getElementProcessor(XmlElement xmlElement)
{
if (xmlElement.getName().equals("ex:message"))
{
MessageProcessor  mp = new MessageProcessor();
return mp;
}
else
{
throw new RuntimeException("Unknown element type " +
xmlElement.getQualifiedName());
}
}

public void onEndNamespace(ProcessingContext processingContext,
XmlElement xmlElement, String string, URI uRI)
{
}

public void onStartNamespace(ProcessingContext processingContext,
XmlElement xmlElement, String string, URI uRI)
{
}

public class MessageProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
System.out.println("Greeting is: " + xmlElement.getString());
return null;
}
}
}

前述のクラスは、<ex:message>要素の内容を処理します。ただし、異なるタイプの要素が出現してもそれらは区別されません。デフォルトのXMLネームスペース内に出現したすべての要素は、同じprocessメソッドに渡されます。各タイプのXML要素を処理するには、processメソッド内に条件文が必要です。単純なXMLコンテンツの場合はこのテクニックで十分ですが、複雑なXMLコンテンツでは多くの条件文が必要となって、非常にわかりにくくなることがあります。より宣言的な方法は、AbstractNamespaceHandlerクラスで提供されます。

ネームスペース・ハンドラのコールバック・メソッド

NamespaceHandlerインタフェースには、onStartNamespaceおよびonEndNamespaceのコールバック・メソッドが用意されています。これらのメソッドを使用すると、キャッシュ構成ファイル内で最初および最後に出現したネームスペースに対して追加の処理を実行できます。

19.3.2 ネームスペース・ハンドラ抽象クラスの拡張

AbstractNamespaceHandlerクラスでは、便利で拡張可能なNamespaceHandler、ElementProcessorおよびAttributeProcessorの各インタフェースのベース実装と、特定の名前が付いた要素および属性のためのプロセッサを登録するメカニズムが提供されます。このクラスは要素および属性の処理を容易化し、多くの場合、要素および属性のプロセッサのインタフェースを直接実装する必要性をなくすことができます。

この項には次のトピックが含まれます:

- プロセッサの登録

- プロセスの要素内容への注入の使用

19.3.2.1 プロセッサの登録

AbstractNamespaceHandlerクラスには、要素および属性のプロセッサを宣言で登録するメソッドが用意されています。このメソッドにより、要素の名前および型をチェックする必要がなくなります。明示的な登録と暗黙的な登録の2つの登録メカニズムがあります。

明示的なプロセッサ登録

明示的なプロセッサ登録を使用するには、サブクラス・コンストラクタ内でregisterProcessorメソッドをコールし、要素と属性の両方のプロセッサを手動で登録します。例19-2では、例19-1を再実装し、registerProcessorメソッドを使用してMessageProcessor要素のプロセッサを登録します。

例19-2 明示的な登録を使用したAbstractNamespaceHandlerの実装

import com.tangosol.config.ConfigurationException;
import com.tangosol.config.xml.AbstractNamespaceHandler;
import com.tangosol.config.xml.ElementProcessor;
import com.tangosol.config.xml.ProcessingContext;
import com.tangosol.run.xml.XmlElement;

public class GreetingNamespaceHandler extends AbstractNamespaceHandler
{
public GreetingNamespaceHandler()
{
registerProcessor("message", new MessageProcessor());
}

public class MessageProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
System.out.println("Greeting is: " + xmlElement.getString());
return null;
}
}
}

暗黙的なプロセッサ登録

暗黙的なプロセッサ登録を使用するには、プロセッサ・クラスに@XmlSimpleName注釈を付けます。これらのプロセッサは、関連付けられたネームスペース内で使用するように自動的に登録されます。@XmlSimpleName注釈は、XML DOMの処理中に出現したXMLコンテンツの処理にどのプロセッサ実装が適切であるかを判断するために使用されます。定義済のプロセッサが存在しないXML要素または属性が出現した場合は、onUnknownElementまたはonUnknownAttributeのメソッドがそれぞれコールされます。これらのメソッドにより、可能な場合は修正処置を実行できます。処理中に不明なXMLコンテンツが見つかった場合、デフォルトでは、ConfigurationException例外が発生します。

例19-3では、例19-1を再実装し、@XmlSimpleName注釈を使用してMessageProcessor要素のプロセッサを登録します。

例19-3 暗黙的な登録を使用したAbstractNamespaceHandlerの実装

import com.tangosol.config.ConfigurationException;
import com.tangosol.config.xml.AbstractNamespaceHandler;
import com.tangosol.config.xml.ElementProcessor;
import com.tangosol.config.xml.ProcessingContext;
import com.tangosol.config.xml.XmlSimpleName;
import com.tangosol.run.xml.XmlElement;

public class GreetingNamespaceHandler extends AbstractNamespaceHandler
{
public GreetingNamespaceHandler()
{
}

@XmlSimpleName("message")
public class MessageProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
System.out.println("Greeting is: " + xmlElement.getString());
return null;
}
}
}

19.3.2.2 プロセスの要素内容への注入の使用

要素および属性のプロセッサは、XMLコンテンツの処理を手動でコーディングするために使用されます。ただし、複雑なネームスペースの場合、これは繰返しの作業になることがあります。この作業を自動化するため、ProcessingContext.injectメソッドは、特定のXML要素に使用できる識別可能なsetterメソッドと値に基づいて、強い型付き値を指定されたオブジェクトに注入できます。

たとえば、次のXMLがあるとします。

<ex:message>
<ex:english>hello</ex:english>
</ex:message>

要素プロセッサを使用して、<english>要素の処理を手動でコーディングできます。

import com.tangosol.config.ConfigurationException;
import com.tangosol.config.xml.AbstractNamespaceHandler;
import com.tangosol.config.xml.ElementProcessor;
import com.tangosol.config.xml.ProcessingContext;
import com.tangosol.config.xml.XmlSimpleName;
import com.tangosol.run.xml.XmlElement;

public class GreetingNamespaceHandler extends AbstractNamespaceHandler
{
public GreetingNamespaceHandler()
{
}

@XmlSimpleName("message")
public class MessageProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
String engMsg = processingContext.getMandatoryProperty("english",
String.class, xmlElement);
Message message = new Message();
message.setEnglish(engMsg);
System.out.println("Greeting is: "+ message.getEnglish());

return message;
}
}
}

別の方法として、injectメソッドで処理を実行できます。

@XmlSimpleName("message")
public class MessageProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
return processingContext.inject(new Message(), xmlElement);
}
}

injectメソッドは、構成されるオブジェクトはJava beanの命名規則に従うという想定のもとにJavaリフレクションを使用します。最初に、injectメソッドは、Java beanでコールできる適切なsetterメソッドを識別します。通常、これは、@Injectable注釈が付けられたsetterメソッドを特定することによって行います。次に、setterメソッドで必要な適切な値の型を判別します。最後に、指定されたXmlElementを使用して検索、解析、変換、強制変換し、その後に使用可能なsetterメソッドを使用してオブジェクト内で適切な型付き値を設定します。injectメソッドでは、プリミティブ、列挙、書式設定された値、複雑なユーザー定義の型、およびコレクション型(セット、リストおよびマップ)をサポートしています。injectメソッドが失敗した場合は、ConfigurationException例外がスローされます。たとえば、予想される型に値を形式設定するのに失敗した場合などです。

次の例は、前述の例用のMessageクラスを示しており、injectメソッドによる注入をサポートしています。

import com.tangosol.config.annotation.Injectable;

public class Message
{

private String m_sEnglish = "a greeting";
public Message()
{
}

@Injectable("english")
public void setEnglish (String sEnglish)
{
m_sEnglish = sEnglish;
}

public String getEnglish()
{
return m_sEnglish;
}
}

注意:
@Injectable注釈プロパティが省略されている場合、injectメソッドはsetterメソッドのJava bean名を使用しようとします。前述の例の場合、@injectable("")はenglishを使用することになります。

通常、要素および属性のプロセッサは、injectメソッドを使用する場合と同じパターンに従います。例:

@XmlSimpleName("element")
public class XProcessor implements ElementProcessor
{
public Object process(ProcessingContext processingContext,
XmlElement xmlElement) throws ConfigurationException
{
return processingContext.inject(new X(), xmlElement);
}
}

このような実装の宣言および登録は、要素および属性のそれぞれにつき、registerElementTypeおよびregisterAttributeTypeメソッドを使用して自動化できます。これらのメソッドはAbstractNamespaceHandlerクラスで使用可能で、多くの場合はAbstractNamespaceHandlerサブクラスのコンストラクタで使用されます。次の例はregisterElementTypeメソッドの使用を示しており、この場合、プロセッサの実装は必要ありません。

注意:
型ベースのクラスの登録をサポートするには、指定されたクラスで引数なしのコンストラクタを用意する必要があります。

import com.tangosol.config.xml.AbstractNamespaceHandler;

public class GreetingNamespaceHandler extends AbstractNamespaceHandler
{

public GreetingNamespaceHandler()
{
registerElementType("message", Message.class);
}
}

19.4 例: JNDIリソース・ネームスペース・ハンドラ

ここでは、java.net (http://java.net/projects/cohinc)がホストしているCoherence Incubatorプロジェクトから、JNDIリソース・ネームスペース・ハンドラを再作成します。Incubatorには、いくつかのネームスペース・ハンドラの実装が含まれており、それらは共通パッケージ・モジュール内で見つかります。

JNDIリソース・ネームスペース・ハンドラでは、JNDIコンテキストで定義されたリソースをルックアップおよび参照できます。ネームスペース・ハンドラの使用は、キャッシュ構成ファイル内の<class-scheme>または<instance>要素を使用してリソースを静的に作成する必要性をなくすためによく使用されます。

この項には次のトピックが含まれます:

- JNDIリソース・ネームスペース・ハンドラの作成

- JNDIネームスペース・ハンドラの宣言

- JNDIリソース・ネームスペース・ハンドラの使用

19.4.1 JNDIリソース・ネームスペース・ハンドラの作成

JNDIリソース・ネームスペース・ハンドラは、実行時に、キャッシュ構成ファイル内に見つかる<resource>要素を処理するために使用されます。このハンドラは、AbstractNamespaceHandlerクラスを拡張し、<resource>要素のためのJndiBasedParameterizedBuilderクラスを登録します。次の例は、ネームスペース・ハンドラの定義を示しています。

import com.tangosol.coherence.config.builder.ParameterizedBuilder;
import com.tangosol.config.xml.AbstractNamespaceHandler;

public class JndiNamespaceHandler extends AbstractNamespaceHandler
{
public JndiNamespaceHandler()
{
registerElementType("resource", JndiBasedParameterizedBuilder.class);
}
}

JndiBasedParameterizedBuilderクラスは、<resource-name>および<init-parms>要素にそれぞれ指定された名前と初期化パラメータを使用して、JNDIコンテキストのルックアップを実行し、オブジェクトを特定して作成します。これらの要素のsetterメソッド(setResourceNameExpressionおよびsetParameterList)は、@Injectable注釈を使用して、キャッシュ構成ファイル内に構成された値を引き渡します。

import com.tangosol.coherence.config.ParameterList;
import com.tangosol.coherence.config.SimpleParameterList;
import com.tangosol.coherence.config.builder.ParameterizedBuilder;
import com.tangosol.coherence.config.builder.ParameterizedBuilder.
ReflectionSupport;
import com.tangosol.config.annotation.Injectable;
import com.tangosol.config.expression.Expression;
import com.tangosol.config.expression.LiteralExpression;
import com.tangosol.config.expression.Parameter;
import com.tangosol.config.expression.ParameterResolver;
import com.tangosol.util.Base;
import java.util.Hashtable;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class JndiBasedParameterizedBuilder implements
ParameterizedBuilder<Object>, ReflectionSupport
{   private static final Logger logger =
Logger.getLogger(JndiBasedParameterizedBuilder.class.getName());

private Expression<String> m_exprResourceName;

private ParameterList m_parameterList;

public JndiBasedParameterizedBuilder()
{
m_exprResourceName = new LiteralExpression<String>("");
m_parameterList = new SimpleParameterList();
}

public Expression<String> getResourceNameExpression()
{
return m_exprResourceName;
}

@Injectable("resource-name")
public void setResourceNameExpression(Expression<String> exprResourceName)
{
m_exprResourceName = exprResourceName;
}

public ParameterList getParameterList()
{
return m_parameterList;
}

@Injectable("init-params")
public void setParameterList(ParameterList parameterList)
{
m_parameterList = parameterList;
}

public boolean realizes(Class<?> clazz,
ParameterResolver parameterResolver,
ClassLoader classLoader)
{
return clazz.isAssignableFrom(realize(parameterResolver, classLoader,
null).getClass());
}

public Object realize(ParameterResolver parameterResolver,
ClassLoader classLoader,
ParameterList parameterList)
{
InitialContext initialContext;
try
{
String sResourceName = m_exprResourceName.evaluate(parameterResolver);
Hashtable<String, Object> env = new Hashtable<String, Object>();

for (Parameter parameter : m_parameterList)
{
env.put(parameter.getName(), parameter.evaluate(parameterResolver));
}

initialContext = new InitialContext(env);

if (logger.isLoggable(Level.FINE))
{
logger.log(Level.FINE,
"Looking up {0} using JNDI with the environment {1}",
new Object[] {sResourceName, env});
}

Object resource = initialContext.lookup(sResourceName);

if (logger.isLoggable(Level.FINE))
{
logger.log(Level.FINE, "Found {0} using JNDI", resource);
}

return resource;
}
catch (NamingException e)
{
throw Base.ensureRuntimeException(e, "Unable to resolve the JNDI
resource: " + m_exprResourceName.toString());
}
}

public String toString()
{
return String.format("%s{resourceName=%s, parameters=%s}",
this.getClass().getName(), m_exprResourceName,
m_parameterList);
}
}

19.4.2 JNDIネームスペース・ハンドラの宣言

JNDIリソース・ネームスペース・ハンドラは、キャッシュ構成ファイル内で宣言する必要があります。ハンドラ・クラスへのURIを指定し、ネームスペースの接頭辞を割り当てて、ネームスペースを宣言します。任意の接頭辞を使用できます。次の例では、jndiを接頭辞として使用しています。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-cache-config coherence-cache-config.xsd"
xmlns:jndi="class://com.examples.JndiNamespaceHandler">
...

19.4.3 JNDIリソース・ネームスペース・ハンドラの使用

アプリケーションでリソースを特定して作成する必要がある場合はいつでもJNDIリソース・ネームスペース・ハンドラを使用できます。また、<class-scheme>または<instance>要素を使用してカスタム実装を定義する場合、ネームスペースを使用できます。ハンドラの実装に基づいて、<resource>および<resource-name>要素は必須、<init-params>要素はオプションです。

次の例では、分散スキームを定義する際にキャッシュ・ストアにJNDIリソースを使用します。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-cache-config coherence-cache-config.xsd"
xmlns:jndi="class://com.examples.JndiNamespaceHandler">
...

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed-rwbm</scheme-name>
<backing-map-scheme>
<read-write-backing-map-scheme>
<internal-cache-scheme>
<local-scheme/>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<jndi:resource>
<jndi:resource-name>MyCacheStore</jndi:resource-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</jndi:resource>
</class-scheme>
</cachestore-scheme>
</read-write-backing-map-scheme>
</backing-map-scheme>
</distributed-scheme>
<caching-schemes>
</cache-config>

次の例では、JNDIリソースを使用してDNSレコードを解決します。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-cache-config coherence-cache-config.xsd"
xmlns:jndi="class://com.examples.JndiNamespaceHandler">
...
<jndi:resource>
<jndi:resource-name>dns:///www.oracle.com</jndi:resource-name>
</jndi:resource>

次の例では、JNDIリソースを使用してJMS接続ファクトリを解決します。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-cache-config coherence-cache-config.xsd"
xmlns:jndi="class://com.examples.JndiNamespaceHandler">
...

<jndi:resource>
<jndi:resource-name>ConnectionFactory</jndi:resource-name>
<init-params>
<init-param>
<param-name>java.naming.factory.initial</param-name>
<param-value>org.apache.activemq.jndi.ActiveMQInitialContextFactory
</param-value>
</init-param>
<init-param>
<param-name>java.naming.provider.url</param-name>
<param-value system-property="java.naming.provider.url"></param-value>
</init-param>
</init-params>
</jndi:resource>

第IV部

データ・グリッド操作の実行

第IV部は次の章で構成されています。

- 第20章「Portable Object Formatの使用」

- 第21章「キャッシュの事前ロード」

- 第22章「キャッシュ内のデータの問合せ」

- 第23章「連続問合せキャッシングの使用」

- 第24章「キャッシュ内のデータの処理」

- 第25章「マップ・イベントの使用」

- 第26章「トリガーを使用したマップ操作の制御」

- 第27章「ライブ・イベントの使用」

- 第28章「Coherenceの問合せ言語の使用」

- 第29章「トランザクションの実行」

- 第30章「パーティションの処理」

- 第31章「スレッド実行の管理」

- 第32章「リエントラント・コールに対する制約」

20 Portable Object Formatの使用

この章では、CoherenceのオブジェクトをシリアライズするためのPortable Object Format (POF)の使用方法について説明します。この説明は、Javaクライアントに対するPOFの使用方法に固有のものです。.NET拡張クライアントを構築する際のPOFの操作方法の詳細は、『Oracle Coherenceリモート・クライアントの開発』の.NETクライアントの統合オブジェクトの構築に関する項を参照してください。C++拡張クライアントを構築する際のPOFの操作方法の詳細は、『Oracle Coherenceリモート・クライアントの開発』のC++クライアントの統合オブジェクトの構築に関する項を参照してください。

この章には次の項が含まれます:

- Coherenceでのシリアライズの理解

- POFシリアライズの概要

- オブジェクトをシリアライズするためのPOF APIの使用

- オブジェクトをシリアライズするためのPOF注釈の使用

- POFエクストラクタとPOFアップデータの使用

- POFを使用したキーのシリアライズ

20.1 Coherenceでのシリアライズの理解

Coherenceは値オブジェクトをキャッシュします。これらのオブジェクトは、(セッション・データや一時データなどの)内部ソースのデータ、または(データベースやメインフレームなどの)外部ソースのデータのいずれでもかまいません。

キャッシュに配置されたオブジェクトはシリアライズ可能である必要があります。シリアライズは、多くの場合、クラスタ化されたデータ管理における最も費用を要する部分になるため、Coherenceではデータのシリアライズ/デシリアライズ用に様々なオプションを用意しています。

- com.tangosol.io.pof.PofSerializer - Portable Object Format (POF)は言語に依存しないバイナリ形式です。POFは領域と時間の両面で効率を向上させるように設計された、Coherenceの推奨シリアライズ・オプションです。「オブジェクトをシリアライズするためのPOF APIの使用」を参照してください。

- java.io.Serializable - 最も単純で処理の遅いオプション。

- java.io.Externalizable - 開発者が手動でシリアライズを実装する必要がありますが、パフォーマンスの大幅な向上が見込めます。java.io.Serializableと比べて、シリアライズされたデータのサイズを2倍以上削減できます(分散キャッシュでは、一般的にデータがシリアライズされた形式でキャッシュされるため特に有用です)。最も重要なのは、CPU使用率が劇的に削減されるということです。

- com.tangosol.io.ExternalizableLite - java.io.Externalizableと非常によく似ていますが、より効率的なI/Oストリームの実装を使用することで、パフォーマンスの向上とメモリー使用量の削減を図れます。

- com.tangosol.run.xml.XmlBean - ExternalizableLiteのデフォルトの実装(詳細は、API JavadocでXmlBeanを参照してください)。

注意:
オブジェクトをシリアライズする場合は、Javaのシリアライズ機能によって、すべての参照可能オブジェクトが自動的に(MapやListなどのコレクションを含むオブジェクト参照を使用して)クロールされます。したがって、キャッシュされたオブジェクトは親オブジェクトを直接参照してはなりません(整数のような特定の値を保持することは許されます)。独自のシリアライズ・ルーチンを実装するオブジェクトは影響を受けません。

20.2 POFシリアライズの概要

シリアライズとは、オブジェクトをバイナリ形式にエンコードするプロセスです。これは、Coherenceを使用してデータをネットワーク上で移動させることが必要になった場合に重要となる機能です。POFは言語に依存しないバイナリ形式です。POFは領域と時間の両面で効率を向上させるように設計されており、Coherenceの使用時に不可欠なものとなっています。POFバイナリ・ストリームの詳細は、付録E「PIF-POFバイナリ形式」を参照してください。

シリアライズで使用可能なオプションには、標準Javaシリアライズ、POF、独自のカスタム・シリアライズ・ルーチンなどいくつかあります。各オプションには、それぞれトレードオフがあります。標準Javaシリアライズは簡単に実装可能であり、循環オブジェクト・グラフをサポートし、オブジェクトIDを保持します。ただし、比較的動作が低速で、冗長なバイナリ形式が使用され、Javaオブジェクトのみが処理対象となります。

POFには、次の利点があります。

- 現在はJava、.NETおよびC++をサポートしており、言語に依存しません。

- 非常に効率的です。1つのString、1つのlongおよび3つのintsを備えた簡単なテスト・クラスでは、標準のJavaシリアライズと比較して、シリアライズおよびデシリアライズが7倍高速化され、生成されるバイナリのサイズが1/6になります。

- バージョニングが可能です。オブジェクトの向上を図ることが可能であり、上位および下位の互換性があります。

- シリアライズ・ロジックを外部化できます。

- 索引付けされ、オブジェクト全体をデシリアライズせずに値を抽出できます。「POFエクストラクタとPOFアップデータの使用」を参照してください。

20.3 オブジェクトをシリアライズするためのPOF APIの使用

POFには、オブジェクトのシリアライズおよびデシリアライズの方法を認識するシリアライズ・ルーチンの実装が必要です。オブジェクトのシリアライズには、com.tangosol.io.pof.PortableObjectインタフェースとcom.tangosol.io.pof.PofSerializerインタフェースという2つのインタフェースが使用可能です。POFは、PortableObjectまたはPofSerializerインタフェースを実装せずにシリアライズを自動的に実装する注釈もサポートしています。詳細は、「オブジェクトをシリアライズするためのPOF注釈の使用」を参照してください。

この項には次のトピックが含まれます:

- PortableObjectインタフェースの実装

- PofSerializerインタフェースの実装

- POF索引の割当てのガイドライン

- POFオブジェクト参照の使用

- POFオブジェクトの登録

- ConfigurablePofContextクラスを使用するためのCoherenceの構成

20.3.1 PortableObjectインタフェースの実装

PortableObjectインタフェースは、次の2つのメソッドで構成されるインタフェースです。

- public void readExternal(PofReader reader)

- public void writeExternal(PofWriter writer)

POFストリームに対する書込みまたは読取りを行う各要素に数値を指定することで、POF要素に索引が付けられます。索引はPOFストリームにおいて書込みと読取りが実行される各要素に対して一意である必要があります。索引はスーパー・クラスと派生クラスの間で一意である必要があるため、派生タイプが存在する場合には特に注意が必要です。次の例では、PortableObjectインタフェースの実装を示します。

public void readExternal(PofReader in)
throws IOException
{
m_symbol    = (Symbol) in.readObject(0);
m_ldtPlaced = in.readLong(1);
m_fClosed   = in.readBoolean(2);
}

public void writeExternal(PofWriter out)
throws IOException
{
out.writeObject(0, m_symbol);
out.writeLong(1, m_ldtPlaced);
out.writeBoolean(2, m_fClosed);
}

20.3.2 PofSerializerインタフェースの実装

PofSerializerインタフェースには、シリアライズ・ロジックをシリアライズするクラスから外部化する手段が用意されています。これは、CoherenceでPOFを使用する場合に、クラスの構造を変更したくないときには特に役立ちます。PofSerializerインタフェースは、次の2つのメソッドで構成されています。

- public Object deserialize(PofReader in)

- public void serialize(PofWriter out, Object o)

PortableObjectインタフェース同様、POFストリームに対して書込みまたは読取りが実行される要素はすべて一意に索引付けされている必要があります。PofSerializerインタフェースの実装例を、次に示します。

例20-1 PofSerializerインタフェースの実装

public Object deserialize(PofReader in)
throws IOException
{
Symbol symbol    = (Symbol)in.readObject(0);
long   ldtPlaced = in.readLong(1);
bool   fClosed   = in.readBoolean(2);

// mark that reading the object is done
in.readRemainder(null);

return new Trade(symbol, ldtPlaced, fClosed);
}

public void serialize(PofWriter out, Object o)
throws IOException
{
Trade trade = (Trade) o;
out.writeObject(0, trade.getSymbol());
out.writeLong(1, trade.getTimePlaced());
out.writeBoolean(2, trade.isClosed());

// mark that writing the object is done
out.writeRemainder(null);
}

20.3.3 POF索引の割当てのガイドライン

POFの索引をオブジェクトの属性に割り当てるときには、次のガイドラインに従ってください。

- 読取りと書込みの順序: シリアライズ・ルーチンの最低索引値から開始して、最高索引値で終了します。値をデシリアライズする場合には、書込みと同じ順序で読取りを実行します。

- 非連続の索引を指定することはできますが、読取りまたは書込みが連続して実行される必要があります。

- サブクラス作成時に索引の範囲を予約する場合: 索引は派生タイプ間で累積されます。そのため、各派生タイプがそのスーパークラスで予約されたPOF索引範囲を認識する必要があります。

- 索引を他の目的に使用しない: 進化をサポートするためには、クラス・リビジョン全体で属性の索引を他の目的に使用しないようにすることが必須です。

- ラベルの索引: public static final intでラベル付けされている索引は、さらに簡単に使用できます。特に、POFエクストラクタとPOFアップデータを使用する場合には簡単です。「POFエクストラクタとPOFアップデータの使用」を参照してください。ラベル付けされた索引の読取りおよび書込みも、上述の説明と同じ順序で実行される必要があります。

20.3.4 POFオブジェクト参照の使用

POFは、POFストリーム内で複数回出現するオブジェクトに対するオブジェクトIDおよび参照の使用をサポートします。オブジェクトにはIDのラベルが付けられ、同じPOFストリーム内の2回目以降に出現するラベル付きオブジェクトのインスタンスはそのIDで参照されます。

参照を使用すると、同じオブジェクトを複数回エンコードしないで済み、データ・サイズの削減に役立ちます。参照は通常、かなりサイズが大きい多数のオブジェクトが複数回作成される場合、またはネストされたデータ構造か循環データ構造をオブジェクトが使用する場合に使用されます。ただし、大量のデータを含むが繰り返しはほとんどないアプリケーションの場合、オブジェクトIDおよび参照の追跡で発生するオーバーヘッドが原因で、オブジェクト参照の使用により得られる利点はわずかなものになります。

オブジェクトIDおよび参照の使用には、次の制限があります。

- オブジェクト参照は、ユーザー定義のオブジェクト・タイプに対してのみサポートされています。

- オブジェクト参照は、Evolvableオブジェクトに対してはサポートされません。

- オブジェクト参照は、キーに対してはサポートされません。

- 参照をサポートしていないPOFコンテキストで書き出されたオブジェクトは、参照をサポートしているPOFコンテキストで読み取ることはできません。この逆も当てはまります。

- POFエクストラクタを使用して、オブジェクトIDおよび参照を使用するPOFオブジェクトを問い合せることはできません。かわりに、ValueExtractor APIを使用してオブジェクト値を問い合せるか、オブジェクト参照を無効にしてください。

- PofNavigatorおよびPofValue APIには、オブジェクト参照を使用する際に次の制限があります:

- 読取り操作のみが許可されています。書込み操作を行うと、UnsupportedOperationExceptionが発生します。

- 非一様なコレクションではユーザー・オブジェクトにアクセスできますが、一様なコレクションではできません。

- 読取り操作でオブジェクトが複数回データ・ストリームに出現した場合、そのオブジェクトは後続のデータに読み込まれる前に、最初に出現した場所で読み込まれる必要があります。それ以外の場合、IOException: missing identity: <ID>がスローされる可能性があります。たとえば、3つのリストがあり、すべてが同じpersonオブジェクトpを含んでいるとします。pオブジェクトは、2番目や3番目のリストで読み込まれる前に、最初のリストで読み込む必要があります。

この項には次のトピックが含まれます:

- POFオブジェクト参照の有効化

- 循環オブジェクトおよびネストされたオブジェクトのためのPOFオブジェクトIDの登録

20.3.4.1 POFオブジェクト参照の有効化

オブジェクト参照は、デフォルトでは有効になっておらず、pof-config.xml構成ファイル内で有効にするか、またはSimplePofContextクラスの使用時にプログラムによって有効にする必要があります。

POF構成ファイルでオブジェクト参照を有効にするには、<pof-config>要素内に<enable-references>要素を含めて、値をtrueに設定します。例:

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
...
<enable-references>true</enable-references>
</pof-config>

SimplePofContextクラスの使用時にオブジェクト参照を有効にするには、プロパティをtrueに設定してsetReferenceEnabledメソッドをコールします。例:

SimplePofContext ctx = new SimplePofContext();
ctx.setReferenceEnabled(true);

20.3.4.2 循環オブジェクトおよびネストされたオブジェクトのためのPOFオブジェクトIDの登録

循環オブジェクトまたはネストされたオブジェクトは、オブジェクトの作成時に手動でIDを登録する必要があります。そうしないと、親オブジェクトを参照する子オブジェクトは、参照マップ内で親のIDを見つけることができません。オブジェクトIDは、com.tangosol.io.pof.PofReader.registerIdentityメソッドを使用して、デシリアライズ・ルーチン中にシリアライザから登録できます。

次の例は、循環参照を含む2つのオブジェクト(CustomerとProduct)、およびCustomerオブジェクトのIDを登録するシリアライザの実装を示しています。

Customerオブジェクトの定義は次のとおりです。

public class Customer
{
private String m_sName;
private Product m_product;

public Customer(String sName)
{
m_sName = sName;
}

public Customer(String sName, Product product)
{
m_sName = sName;
m_product = product;
}

public String getName()
{
return m_sName;
}

public Product getProduct()
{
return m_product;
}

public void setProduct(Product product)
{
m_product = product;
}
}

Productオブジェクトの定義は次のとおりです。

public class Product
{
private Customer m_customer;

public Product(Customer customer)
{
m_customer = customer;
}

public Customer getCustomer()
{
return m_customer;
}
}

デシリアライズの間にIDを登録するシリアライザ実装の定義は次のとおりです。

public class CustomerSerializer implements PofSerializer
{
@Override
public void serialize(PofWriter pofWriter, Object o) throws IOException
{
Customer customer = (Customer) o;
pofWriter.writeString(0, customer.getName());
pofWriter.writeObject(1, customer.getProduct());
pofWriter.writeRemainder(null);
}

@Override
public Object deserialize(PofReader pofReader) throws IOException
{
String sName = pofReader.readString(0);
Customer customer = new Customer(sName);

pofReader.registerIdentity(customer);
customer.setProduct((Product) pofReader.readObject(1));
pofReader.readRemainder();
return customer;
}
}

20.3.5 POFオブジェクトの登録

Coherenceには、com.tangosol.io.pof.ConfigurablePofContextシリアライザ・クラスが用意されていて、それによりPOFのシリアライズ・オブジェクトが適切なシリアライズ・ルーチン(PofSerializer実装、またはPortableObjectインタフェースを介した呼び出しによる)にマップされます。

クラスにシリアライズ・ルーチンが指定されると、そのクラスはpof-config.xml構成ファイルを使用してConfigurablePofContextクラスに登録されます。POF構成ファイルには<user-type-list要素があり、それにはPortableObjectを実装するクラスまたはそれらに関連付けられているPofSerializerを持つクラスのリストが記載されています。各クラスに対する<type-idは一意である必要があり、すべてのクラスタ・インスタンス(拡張クライアントを含む)で一致している必要があります。POFの構成要素の詳細は、付録C「POFユーザー定義型の構成要素」を参照してください。

POF構成ファイルの例を次に示します。

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>

<!-- User types must be above 1000 -->
<user-type>
<type-id>1001</type-id>
<class-name>com.examples.MyTrade</class-name>
<serializer>
<class-name>com.examples.MyTradeSerializer</class-name>
</serializer>
</user-type>

<user-type>
<type-id>1002</type-id>
<class-name>com.examples.MyPortableTrade</class-name>
</user-type>
</user-type-list>
</pof-config>

注意:
Coherenceでは、最初の1000個のtype-idは内部使用のために予約されています。上の例に示されているように、<user-type-list>にはcoherence.jarファイルのルートにあるcoherence-pof-config.xmlファイルが含まれます。このリストにはCoherence固有のユーザー型が定義されており、それらのユーザー型はすべてのPOF構成ファイルに含まれている必要があります。

20.3.6 ConfigurablePofContextクラスを使用するためのCoherenceの構成

CoherenceでConfigurablePofContextシリアライザ・クラスを使用する場合には、必要な精度のレベルに基づいた、次の3通りの構成が可能です。

- サービスごと - 各サービスには、ConfigurablePofContextシリアライザ・クラスの完全な構成が用意されており、オペレーション構成ファイルにある事前定義済の構成が参照されます。

- すべてのサービス - すべてのサービスでグローバルConfigurablePofContextシリアライザ・クラスの構成が使用されます。独自の構成を提供するサービスによってグローバルな構成がオーバーライドされます。グローバル構成を完全構成にして、オペレーション構成ファイルに含まれる事前定義済の構成を参照することも可能です。

- JVM - ConfigurablePofContextシリアライザ・クラスはJVM全体に対して有効化されます。

20.3.6.1 ConfigurablePofContextクラスのサービスごとの構成

ConfigurablePofContextクラスを使用するようにサービスを構成するには、キャッシュ構成ファイルのキャッシュ・スキームに<serializer>要素を追加します。<serializer>要素の完全なリファレンスは、「serializer」を参照してください。

次の例では、ConfigurablePofContextクラスを使用するように構成された分散キャッシュを示しており、カスタムPOF構成ファイルを定義しています。

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>my-pof-config.xml</param-value>
</init-param>
</init-params>
</instance>
</serializer>
</distributed-scheme>

次の例では、オペレーション構成ファイルのデフォルトの定義を参照します。デフォルトのConfigurablePofContextシリアライザ定義を確認するには、「serializer」を参照してください。

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<serializer>pof</serializer>
</distributed-scheme>

20.3.6.2 すべてのサービスに対するConfigurablePofContextクラスの構成

ConfigurablePofContextクラスをすべてのサービスに対してグローバルに構成するには、キャッシュ構成ファイルの<defaults>要素内に<serializer>要素を追加します。次の例は両方とも、シリアライザをすべてのキャッシュ・スキームの定義に対してグローバルに構成するものであり、個々のキャッシュ・スキームの定義内にその他の構成を追加する必要はありません。<defaults>要素の完全なリファレンスは、「defaults」を参照してください。

次の例では、ConfigurablePofContextクラスに対するグローバルな構成を示しており、カスタムPOF構成ファイルを定義しています。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>my-pof-config.xml</param-value>
</init-param>
</init-params>
</instance>
</serializer>
</defaults>
...

次の例では、オペレーション構成ファイルのデフォルトの定義を参照します。デフォルトのConfigurablePofContextシリアライザ定義を確認するには、「serializer」を参照してください。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<serializer>pof</serializer>
</defaults>
...

20.3.6.3 JVMに対するConfigurablePofContextクラスの構成

次のシステム・プロパティを使用して、POFを使用するようにJVMインスタンス全体を構成できます。

- tangosol.pof.enabled=true - JVMインスタンス全体でPOFを有効化します。

- tangosol.pof.config=CONFIG_FILE_PATH - 使用するPOF構成ファイルへのパスです。このファイルがクラスパスにない場合には、ファイル・リソースとして存在するはずです(例: file:///opt/home/coherence/mycustom-pof-config.xml)。

20.4 オブジェクトをシリアライズするためのPOF注釈の使用

POF注釈は、オブジェクトに対するシリアライズおよびデシリアライズ・ルーチンを自動的に実装する方法を提供します。POF注釈は、PofSerializerインタフェースの実装であるPofAnnotationSerializerクラスを使用して、シリアライズおよびデシリアライズされます。注釈は、PortableObjectおよびPofSerializerインタフェースの使用に代わる手段を提供し、オブジェクトをシリアライズ可能なものにするために必要な時間とコードを削減します。

この項には次のトピックが含まれます:

- POFシリアライズのためのオブジェクトの注釈付け

- POF注釈付きオブジェクトの登録

- POF構成ファイルの生成

- 自動索引付けの有効化

- カスタム・コーディックの提供

20.4.1 POFシリアライズのためのオブジェクトの注釈付け

クラスとそのプロパティがPOFシリアライズ可能であることを示すには、次の2つの注釈を使用できます。

- @Portable – クラスをPOFシリアライズ可能としてマークします。注釈は、クラス・レベルでのみ許可され、メンバーを持ちません。

- @PortableProperty – メンバー変数またはメソッド・アクセッサをPOFシリアライズ可能属性としてマークします。注釈付きのメソッドは、アクセッサの表記法(get、set、is)に従う必要があります。メンバーを使用して、POF索引だけでなく、シリアライズまたはデシリアライズの前後に実行されるカスタム・コーディックを指定できます。索引値を省略し、自動的に割り当てることができます。カスタム・コーディックが入力されない場合は、デフォルトのコーディックが使用されます。

次の例では、クラス、メソッドおよびプロパティの注釈付け、およびプロパティの索引値の明示的な割当てを示します。POF索引付けの詳細は、「POF索引の割当てのガイドライン」を参照してください。

@Portable
public class Person
{
@PortableProperty(0)
public String getFirstName()
{
return m_firstName;
}

private String m_firstName;

@PortableProperty(1)
private String m_lastName;

@PortableProperty(2)
private int m_age;
}

20.4.2 POF注釈付きオブジェクトの登録

POF注釈付きオブジェクト(すべてのPOFオブジェクトなど)は、pof-config.xmlファイルの<user-type>要素内に登録されている必要があります。POFの構成要素の詳細は、付録C「POFユーザー定義型の構成要素」を参照してください。POF構成ファイルを手動で作成するかわりに、POF構成ジェネレータ・ツールを使用して、@Portable注釈を使用するオブジェクトに基づいて自動的にPOF構成ファイルを作成できます。POF構成ジェネレータ・ツールの詳細は、「POF構成ファイルの生成」を参照してください。

POF注釈付きオブジェクトは、オブジェクトがPortableObjectを実装しておらず、Portableとして注釈が付けられている場合は、PofAnnotationSerializerシリアライザを使用します。ただし、オブジェクトに注釈が付けられており、ユーザー定義型の定義に含める必要がない場合は、自動的にシリアライザが使用されます。次の例では、注釈付きのPersonオブジェクトに対するユーザー定義型を登録します。

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>

<!-- User types must be above 1000 -->
<user-type>
<type-id>1001</type-id>
<class-name>com.examples.Person</class-name>
</user-type>
</user-type-list>
</pof-config>

20.4.3 POF構成ファイルの生成

POF構成ジェネレータ・コマンド行ツールは、@Portable注釈が含まれるクラスのユーザー定義型エントリを含むPOF構成ファイルを自動的に作成します。このツールは、POF構成ファイルを手動で作成するかわりとなり、ビルド・プロセスの一部として最適です。

POF構成ジェネレータ・コマンド行ツールを起動するには、COHERENCE_HOME/bin/pof-config-genスクリプト(.cmdまたは.sh)を使用するか、com.tangosol.io.pof.generator.Executorクラスを直接実行します。詳細な使用方法を確認するには、-help引数を使用します。使用方法を次に示します。

pof-config-gen [OPTIONS] -root

-root引数は必須で、POF注釈付きのクラスをスキャンする場所(別々のディレクトリ、JARファイルまたはGARファイル)をリストします。見つかった注釈付きのクラスのそれぞれにつき、ユーザー定義型のエントリおよびIDが生成され、結果として生成されたpof-config.xmlファイルが現在の作業ディレクトリに書き込まれます。例:

pof-config-gen.cmd -root c:\src\myPofClasses.jar

注意:
GARファイルをルートとして指定した場合、出力はカウント接尾辞の付いた新しいGARファイル(filename-n.gar)で、このファイルに生成されたPOF構成ファイルが含まれます。

次のオプションの引数を指定できます。

- -out: -out引数を使用して、出力ディレクトリのパス、またはパスとファイル名を指定します。デフォルトの出力ディレクトリは作業ディレクトリです。ディレクトリのみを指定した場合のデフォルトのファイル名は、pof-config.xmlです。ディレクトリを指定した場合にpof-config.xmlファイルがすでに存在する場合は、カウント接尾辞の付いた新しいファイルが作成されます(pof-config-n.xml)。パスとファイル名を指定した場合にそのファイルが現在存在する場合は、ファイルが上書きされます。

- -config: -config引数を使用して、既存のPOF構成ファイルのパスとファイル名を指定し、そのファイルに含まれる既存のユーザー定義型を生成されるPOF構成ファイルに追加します。既存のユーザー定義型のIDは、生成されたファイルで保持されます。POF構成ファイルを複数回生成する場合、この引数を使用して後方互換性をサポートできます。

- -include: -include引数を使用して、生成されるPOF構成ファイル内で(-config引数で指定された)既存のPOF構成ファイルの参照のみを行うかどうかを指定します。この引数を使用すると、既存のファイルを参照する<include>要素が生成されます。既存のユーザー定義型およびIDは、生成されるファイルに再作成されません。実行時には、クラスパスに参照先のファイルを配置する必要があります。

注意:
既存のPOF構成ファイル内にCoherence固有のPOF構成ファイル(coherence-pof-config.xml)への参照が見つからない場合は、-include引数の使用によって、生成されるPOF構成ファイルにこの参照を追加する必要がなくても、この参照は自動的に追加されます。

- -packages: -packages引数を使用して、クラスのスキャンを特定のパッケージに制限します。パッケージはカンマ区切りリストで入力します。

- -startTypeId: -startTypeId引数を使用して、ユーザー定義型のIDの割当てを開始する際のID番号を指定します。1000までのIDは、Coherence固有のタイプ用に予約されているため、使用できません。

次の例では、c:\classes\pofディレクトリをスキャンし、新しいPOF構成ファイルをmy-pof-config.xmlという名前でc:\tmpディレクトリに作成しますが、このファイルには(参照によって)既存のc:\tmp\pof-config.xmlファイルがインクルードされます。

pof-config-gen.cmd -out c:\tmp\my-pof-config.xml -config c:\tmp\pof-config.xml
-include -root c:\classes\pof

20.4.4 自動索引付けの有効化

POF注釈は、索引値を明示的に割り当てて管理する必要性を軽減する自動索引付けをサポートしています。@PortableProperty注釈を定義する場合は、索引値を省略します。索引割当ては、プロパティ名によって決定されます。明示的な索引値を割り当てるプロパティには、自動索引値は割り当てられません。次の表は、自動索引付けアルゴリズムの順序付けセマンティックを示しています。自動索引付けは(プロパティcに示すように)明示的に定義された索引を保持しており、索引が省略されている場合は索引値を割り当てます。

プロパティ名

明示的な索引

決定された索引

c

1

1

a

省略

0

b

省略

2

注意:
自動索引付けは現在、Evolvableクラスをサポートしていません。

自動索引付けを有効にするには、POF構成ファイルでオブジェクトをユーザー定義型として登録するときに、PofAnnotationSerializerシリアライザ・クラスを明示的に定義する必要があります。コンストラクタ内のfAutoIndexブール・パラメータは、自動索引付けを有効にするもので、trueに設定する必要があります。例:

<user-type>
<type-id>1001</type-id>
<class-name>com.examples.Person</class-name>
<serializer>
<class-name>com.tangosol.io.pof.PofAnnotationSerializer</class-name>
<init-params>
<init-param>
<param-type>int</param-type>
<param-value>{type-id}</param-value>
</init-param>
<init-param>
<param-type>class</param-type>
<param-value>{class}</param-value>
</init-param>
<init-param>
<param-type>boolean</param-type>
<param-value>true</param-value>
</init-param>
</init-params>
</serializer>
</user-type>

20.4.5 カスタム・コーディックの提供

コーディックにより、シリアライズまたはデシリアライズの前後にコードを実行できます。コーディックでは、PofWriterおよびPofReaderインタフェースを使用して、ポータブル・プロパティをエンコードおよびデコードする方法を定義します。コーディックは通常、デシリアライズの際に失われる可能性がある具体的な実装に対して、またはオブジェクトのシリアライズの前にPofWriterインタフェースで特定のメソッドを明示的にコールするために使用されます。

コーディックを作成するには、com.tangosol.io.pof.reflect.Codecインタフェースを実装するクラスを作成します。次の例では、リンクされているリスト・タイプの具体的な実装を定義するコーディックを示します。

public static class LinkedListCodec implements Codec
{
public Object decode(PofReader in, int index) throws IOException
{
return (List<String>) in.readCollection(index, new LinkedList<String>());
}
public void encode(PofWriter out, int index, Object value) throws IOException
{
out.writeCollection(index, (Collection) value);
{
}

プロパティにコーディックを割り当てるには、コーディックを@PortableProperty注釈のメンバーとして入力します。コーディックが指定されない場合、デフォルトのコーディック(DefaultCodec)が使用されます。次の例では、上記のLinkedListCodecコーディックの割当てを示します。

@PortableProperty(codec = LinkedListCodec.class)
private List<String> m_aliases;

20.5 POFエクストラクタとPOFアップデータの使用

Coherenceでは、ValueExtractorインスタンスとValueUpdaterインスタンスを使用して、キャッシュに格納されたオブジェクトの値が抽出および更新されます。PofExtractorインスタンスとPofUpdaterインスタンスは、POFの索引付けされた状態を利用して、シリアライズ・ルーチンまたはデシリアライズ・ルーチン全体を実行せずにオブジェクトを抽出または更新します。

PofExtractorとPofUpdaterにより、Coherenceの非プリミティブ・タイプを使用するときの柔軟性が向上します。多くの拡張クライアントの場合、グリッド内に対応するJavaクラスは不要です。POFエクストラクタとPOFアップデータはバイナリをナビゲートできるため、キーおよび値全体をオブジェクト形式にデシリアライズする必要はありません。これは、索引付けする値をPOFエクストラクタを使用してプルするだけで索引付けできることを意味します。ただし、キャッシュ・ストアを使用している場合は、対応するJavaクラスが必要です。この場合、キーと値のデシリアライズ・バージョンがキャッシュ・ストアに渡され、バックエンドに書き込まれます。

20.5.1 POFオブジェクトの移動

POFは索引付けされているため、バイナリを抽出用または更新用の特定の要素まで迅速に横断できます。POF値オブジェクトを横断し、目的のPOF値オブジェクトを返すのは、PofNavigatorインタフェースの役目です。Coherenceには、初期状態で、整数索引に基づいてPOF値を移動できるSimplePofPathクラスが用意されています。最も簡単な形式では、抽出または更新する属性の索引を提供します。次の例を参照してください。

public class Contact
implements PortableObject
{
...
// ----- PortableObject interface ---------------------------------------

public void readExternal(PofReader reader)
throws IOException
{
m_sFirstName     = reader.readString(FIRSTNAME);
m_sLastName      = reader.readString(LASTNAME);
m_addrHome       = (Address) reader.readObject(HOME_ADDRESS);
m_addrWork       = (Address) reader.readObject(WORK_ADDRESS);
m_mapPhoneNumber = reader.readMap(PHONE_NUMBERS, null);
}

public void writeExternal(PofWriter writer)
throws IOException
{
writer.writeString(FIRSTNAME, m_sFirstName);
writer.writeString(LASTNAME, m_sLastName);
writer.writeObject(HOME_ADDRESS, m_addrHome);
writer.writeObject(WORK_ADDRESS, m_addrWork);
writer.writeMap(PHONE_NUMBERS, m_mapPhoneNumber);
}

....

// ----- constants -------------------------------------------------------

public static final int FIRSTNAME = 0;
public static final int LASTNAME = 1;
public static final int HOME_ADDRESS = 2;
public static final int WORK_ADDRESS = 3;
public static final int PHONE_NUMBERS = 4;

...
}

POFストリームへの書込みまたはPOFストリームからの書込みを実行中の各データ・メンバーに対する定数が存在することに注意してください。この方法に従えば、POFエクストラクタとPOFアップデータを容易に使用できてシリアライズ・ルーチンの書込みも簡素化されるという、優れた利点が得られます。各索引にラベルを付けることで、索引の操作はさらに容易になります。前述のように、最も簡単な場合では、WORK_ADDRESS索引を使用して連絡先から勤務先のアドレスを抽出できます。SimplePofPathにより、intsのArrayを使用してPofValuesを横断できるようになります。たとえば、勤務先のアドレスの郵便番号を取得するには、[WORK_ADDRESS, ZIP]を使用します。次の例で、詳細を示します。

20.5.2 POFエクストラクタの使用

POFエクストラクタは通常、キャッシュに問い合せる場合に使用され、問合せのパフォーマンスを向上させます。たとえば、上記で示したクラスを使用して、姓がJonesであるすべての連絡先のキャッシュに問い合せる場合、問合せは次のとおりです。

ValueExtractor veName = new PofExtractor(String.class, Contact.LASTNAME);
Filter         filter = new EqualsFilter(veName, "Jones");

// find all entries that have a last name of Jones
Set setEntries = cache.entrySet(filter);

この例では、PofExtractorには便利なコンストラクタがあり、SimplePofPathを使用して1つの索引(この例ではContact.LASTNAMEの索引)を取得します。地域コードが01803であるすべての連絡先を検索する場合、問合せは次のとおりです。

ValueExtractor veZip = new PofExtractor(
String.class, new SimplePofPath(new int[] {Contact.WORK_ADDRESS, Address.ZIP}));

Filter filter = new EqualsFilter(veZip, "01803");

// find all entries that have a work address in the 01803 zip code
Set setEntries  = cache.entrySet(filter);

前述の例では、PofExtractorコンストラクタには抽出された値またはnullのクラスを持つ最初の引数があります。型情報を渡すのは、POFがシリアライズされた値で圧縮形式を使用するからです(使用可能な場合)。たとえば、一部の数値は、型が値を暗示する特殊なPOF固有型として示されています。その結果、POFの値を受け取る側では、その型を暗黙的に認識できることが必要になります。PofExtractorは、コンストラクタで提供されたクラスを型情報のソースとして使用します。このクラスがnullの場合、PofExtractorはシリアライズされた状態から型を推測しますが、抽出される型は予想した型と異なることがあります。実際には、String型はPOFストリームから適切に推測されるので、前述の例ではnullを使用すれば十分です。ただし、通常はnullを使用しないでください。

20.5.3 POFアップデータの使用

POFアップデータは、オブジェクトの値を抽出するのではなく、更新するという点を除いて、POFエクストラクタと同じ方法で動作します。姓がJonesであるすべてのエントリをSmithに変更するには、次のようにUpdaterProcessorクラスを使用します。

ValueExtractor veName  = new PofExtractor(String.class, Contact.LASTNAME);
Filter         filter  = new EqualsFilter(veName, "Jones");
ValueUpdater   updater = new PofUpdater(Contact.LASTNAME);

// find all Contacts with the last name Jones and change them to have the last
// name "Smith"

cache.invokeAll(filter, new UpdaterProcessor(updater, "Smith"));

注意:
この機能は、これらの例ではStringベースの値で動作していますが、POFのエンコードされた値でも動作します。

20.6 POFを使用したキーのシリアライズ

値オブジェクトのようなキー・オブジェクトは、POFを使用してシリアライズできます。ただし、次の問題について考慮する必要があります。

- POFではクロス・プラットフォームのオブジェクト形式を定義しますが、必ずしも対称的な変換を提供できるわけではありません。すなわち、シリアライズ・オブジェクトをデシリアライズすると、オブジェクトの型は元の型と異なります。これは、Javaの一部のデータ型は、.NETおよびC++プラットフォームに相当するものが存在しないために発生します。結果として、非対称のPOF変換を持つ可能性があるクラスは、キャッシュおよび他のJavaコレクションのキー(またはキーの一部)として使用しないでください。

- java.util.Date型は使用しないようにしてください。POFは、(java.util.Dateを拡張した)java.sql.Timestampにシリアライズするように設計されています。それらの2つのクラスのワイヤ・フォーマットは同一であり、それらのワイヤ表現をデシリアライズすると、必ずjava.sql.Timestampインスタンスになります。残念ながら、それらの2つのベース・クラスのequalsメソッドでは、Javaコレクションのキーの対称要件は破壊されます。つまり、D (java.util.Date)とT (java.sql.Timestamp)という2つのオブジェクトがあり、これらのオブジェクトがPOFワイヤ・フォーマットの観点から等しい場合に、D.equals(T)はtrueになりますが、T.equals(D)はfalseになります。そのため、java.util.Dateは使用しないでください。キーの対称要件を破壊しないようにするには、日付のLong表現かjava.sql.Timestamp型を使用します。

- POFオブジェクト参照を使用しているキーはシリアライズできません。また、POFオブジェクト参照では循環参照がサポートされます。そのため、キー・クラスに循環参照が含まれないようにする必要があります。

21 キャッシュの事前ロード

この章では、バルク・ロードおよび分散ロード・パターンを使用してキャッシュにデータを事前ロードする方法について説明します。

この章には次の項が含まれます:

- キャッシュへのデータのバルク・ロード

- 分散バルク・ロードの実行

21.1 キャッシュへのデータのバルク・ロード

Coherenceを使用する際の一般的なシナリオでは、データはアプリケーションで使用される前にキャッシュに事前移入します。例21-1は、putメソッドを使用したデータのロードを示しています。このテクニックは有益ですが、特にパーティション・キャッシュおよびレプリケート・キャッシュでは、putをコールするたびにネットワーク・トラフィックが発生する場合があります。また、putをコールするたびにキャッシュで置換されたばかりのオブジェクトが返され(java.util.Mapインタフェースで定義されている)、不要なオーバーヘッドが追加されます。

例21-1 キャッシュの事前ロード

public static void bulkLoad(NamedCache cache, Connection conn)
{
Statement s;
ResultSet rs;

try
{
s = conn.createStatement();
rs = s.executeQuery("select key, value from table");
while (rs.next())
{
Integer key   = new Integer(rs.getInt(1));
String  value = rs.getString(2);
cache.put(key, value);
}
...
}
catch (SQLException e)
{...}
}

かわりに、ConcurrentMap.putAllメソッドを使用すると、キャッシュのロードを大幅に効率化できます。これを例21-2に示します。

例21-2 ConcurrentMap.putAllを使用したキャッシュの事前ロード

public static void bulkLoad(NamedCache cache, Connection conn)
{
Statement s;
ResultSet rs;
Map       buffer = new HashMap();

try
{
int count = 0;
s = conn.createStatement();
rs = s.executeQuery("select key, value from table");
while (rs.next())
{
Integer key   = new Integer(rs.getInt(1));
String  value = rs.getString(2);
buffer.put(key, value);

// this loads 1000 items at a time into the cache
if ((count++ % 1000) == 0)
{
cache.putAll(buffer);
buffer.clear();
}
}
if (!buffer.isEmpty())
{
cache.putAll(buffer);
}
...
}
catch (SQLException e)
{...}
}

21.2 分散バルク・ロードの実行

Coherenceのパーティション・キャッシュに大量のデータ・セットを事前移入する際は、Coherenceのクラスタ・メンバーに作業を分散すると効率が向上する可能性があります。分散ロードを使用すると、クラスタのネットワーク帯域幅およびCPU処理能力の集積を活用することによって、データ・スループット率を高めることができます。分散ロードの実行時には、アプリケーションで次の事項を決定する必要があります。

- ロードを実行するクラスタのメンバー

- メンバー間でのデータ・セットの分割方法

メンバーの選択および作業の分割時は、基礎となるデータ・ソース(データベースやファイル・システムなど)に対する負荷をアプリケーションで考慮する必要があります。たとえば、問合せを同時に実行するメンバーが多すぎると、1つのデータベースでは対応しきれなくなる場合があります。

21.2.1 分散バルク・ロードの例

この項では、簡単な分散ロードを実行する一般的な手順の概要について説明します。この例では、データがファイルに保存されていて、クラスタ内で記憶域が有効なすべてのメンバーに分散されることを前提としています。

1. 記憶域が有効なメンバーのセットを取得します。たとえば、次の方法ではgetStorageEnabledMembersメソッドを使用して、分散キャッシュ内で記憶域が有効なメンバーを取得します。

例21-3 キャッシュ内で記憶域が有効なメンバーの取得

protected Set getStorageMembers(NamedCache cache)
{
return ((PartitionedService) cache.getCacheService())
.getOwnershipEnabledMembers();
}

2. 記憶域が有効なクラスタのメンバー間で作業を分割します。たとえば、次のルーチンでは、メンバーに割り当てられたファイルの一覧が含まれるマップが、メンバーをキーとして返されます。

例21-4 キャッシュのメンバーに割り当てられたファイルの一覧を取得するルーチン

protected Map<Member, List<String>> divideWork(Set members, List<String> fileNames)
{
Iterator i = members.iterator();
Map<Member, List<String>> mapWork = new HashMap(members.size());
for (String sFileName : fileNames)
{
Member member = (Member) i.next();
List<String> memberFileNames = mapWork.get(member);
if (memberFileNames == null)
{
memberFileNames = new ArrayList();
mapWork.put(member, memberFileNames);
}
memberFileNames.add(sFileName);

// recycle through the members
if (!i.hasNext())
{
i = members.iterator();
}
}
return mapWork;
}

3. 各メンバーへのロードを実行するタスクを起動します。たとえば、タスクの起動にはCoherenceのInvocationServiceなどを使用します。この場合、LoaderInvocableの実装では、memberFileNamesを反復して各ファイルを処理し、その内容をキャッシュにロードする必要があります。通常、クライアント上で実行されるキャッシュ処理は、LoaderInvocableを使用して実行する必要があります。

例21-5 キャッシュの各メンバーをロードするクラス

public void load()
{
NamedCache cache = getCache();

Set members = getStorageMembers(cache);

List<String> fileNames = getFileNames();

Map<Member, List<String>> mapWork = divideWork(members, fileNames);

InvocationService service = (InvocationService)
CacheFactory.getService("InvocationService");

for (Map.Entry<Member, List<String>> entry : mapWork.entrySet())
{
Member member = entry.getKey();
List<String> memberFileNames = entry.getValue();

LoaderInvocable task = new LoaderInvocable(memberFileNames, cache.getCacheName());
service.execute(task, Collections.singleton(member), this);
}
}

22 キャッシュ内のデータの問合せ

この章では、キャッシュ内の特定の基準を満たすデータを取得するための問合せの実行方法および索引の使用方法について説明します。問合せと索引は、Coherence付属のフィルタを採用した単純なものにするか、またはコレクションや配列などの複数値属性に対して実行できます。

この章には次の項が含まれます:

- 問合せの概要

- 問合せの実行

- 問合せ索引の使用

- バッチ問合せの実行

- 複数値属性での問合せの実行

- 連鎖エクストラクタの使用

- 問合せのコストと効果の評価

22.1 問合せの概要

Coherenceでは、指定された一連の基準を満たすキャッシュ・エントリを検索できます。結果セットは必要に応じてソートできます。問合せは、コミット読取り分離を使用して評価されます。

問合せは、キャッシュされたデータにしか適用されません(CacheLoaderインタフェースを使用して、問合せに適合するデータが追加で取得されることもありません)。このため、問合せが実行される前にデータ・セット全体をキャッシュにロードする必要があります。データ・セットが大きすぎて使用可能なメモリーに収まらない場合は、特定のディメンション(日付など)でキャッシュ・コンテンツを制限し、問合せの構造に基づいてキャッシュ問合せとデータベース問合せの間を手動で切り替えることができます。保守性の面から、通常はキャッシュ対応のデータ・アクセス・オブジェクト(DAO)の内部にこの処理を実装するのが最適です。

索引を付けるには、各パーティション・キャッシュ・ノードで属性を抽出できることが必要です。専用のキャッシュ・サーバー・インスタンスの場合は、これを実現するために(通常は)アプリケーション・クラスをキャッシュ・サーバーのクラスパスにインストールする必要があります。

ローカル・キャッシュおよびレプリケート・キャッシュの場合は、索引なしのデータまたは索引付きのデータに対して問合せをローカルで評価できます。パーティション・キャッシュの場合は、通常、索引を使用して問合せがクラスタ全体でパラレルに実行されます。索引のない属性にアクセスするには、オブジェクトをデシリアライズする必要があります(ただし、他の属性に索引を付けると、評価が必要なオブジェクトを減らすことができます)。最後に、Coherenceにはコストベース・オプティマイザ(CBO)が用意されており、問合せの効率化を支援するトレースおよび実行レポートもサポートされます。

22.1.1 問合せの概念

問合せ処理の概念は、ValueExtractorインタフェースに基づいています。値エクストラクタは、問合せで指定のオブジェクトから属性を抽出するために使用されます(索引付けの場合も同様)。ほとんどの開発者に必要なのは、このインタフェースのReflectionExtractor実装のみです。実装は、リフレクションを使用してメソッド名(通常はgetterメソッド)を参照することにより、値オブジェクトから属性を抽出します。例:

ValueExtractor extractor = new ReflectionExtractor("getName");

toString()のようなObjectメソッドをはじめとする任意のvoid引数メソッドを使用できます(プロトタイプ/デバッグに有用)。索引には、従来のフィールド索引(オブジェクトのフィールドに付けられた索引)または機能ベースの索引(仮想のオブジェクト属性に付けられた索引)を使用できます。たとえば、クラスにフィールド・アクセッサgetFirstNameおよびgetLastNameがある場合、そのクラスではこれらの名前を連結する関数getFullNameを定義し、その関数に索引を付けることができます。索引の詳細は、「問合せ索引の使用」を参照してください。

getName属性を持つオブジェクトが含まれているキャッシュに問合せを実行するには、Filterを使用する必要があります。フィルタには、指定したオブジェクトが基準を満たしているかどうかを判別するメソッドが1つあります。

Filter filter = new EqualsFilter(extractor, "Bob Smith");

フィルタには、メソッド名を受け入れてReflectionExtractorを内部で構成する、便利なコンストラクタも含まれています。

Filter filter = new EqualsFilter("getName", "Bob Smith");

次の例は、特定のフィルタ基準を満たすキャッシュ・エントリを選択するルーチンを示しています。

for (Iterator iter = cache.entrySet(filter).iterator(); iter.hasNext(); )
{
Map.Entry entry = (Map.Entry)iter.next();
Integer key = (Integer)entry.getKey();
Person person = (Person)entry.getValue();
System.out.println("key=" + key + " person=" + person);
}

次の例では、キャッシュ・エントリを選択してソートするフィルタを使用します。

// entrySet(Filter filter, Comparator comparator)
Iterator iter = cache.entrySet(filter, null).iterator();

追加したnull引数は、キャッシュ内のComparableオブジェクトの自然な順序を使用して結果セットをソートする必要があることを指定します。クライアントでは、Comparatorの実装を用意することによって、結果セットの順序を明示的に指定する場合があります。ソート処理を行う場合は、ソートの前に結果セット全体を取得しておく必要があるために、Coherenceで適用できる最適化が著しく制限されるので注意してください。

22.2 問合せの実行

例22-1は、問合せを作成してGreaterEqualsFilterフィルタを使用する方法を示しています。Coherenceでは、com.tangosol.util.filterパッケージに多数の事前作成フィルタが含まれています。すべての事前作成済フィルタの完全なリストについては、Oracle Coherence Java APIリファレンスを参照してください。

例22-1 フィルタを指定したキャッシュの問合せ

Filter filter = new GreaterEqualsFilter("getAge", 18);

for (Iterator iter = cache.entrySet(filter).iterator(); iter.hasNext(); )
{
Map.Entry entry = (Map.Entry) iter.next();
Integer key = (Integer) entry.getKey();
Person person = (Person) entry.getValue();
System.out.println("key=" + key + " person=" + person);
}

Coherenceでは、com.tangosol.util.filterパッケージに幅広いフィルタが用意されています。

注意:
ニア・キャッシュを通じて問合せを実行することは可能ですが、問合せではニア・キャッシュのフロント部分が使用されません。問合せでニア・キャッシュを使用する場合は、次のシーケンスを使用するのが最適のアプローチです。

Set setKeys = cache.key set(filter);
Map mapResult = cache.getAll(setKeys);

22.2.1 フィルタ結果の効率的な処理

例22-1は、小さなデータ・セットには便利ですが、データ・セットが大きすぎる場合は、ヒープ領域不足などの問題が発生することがあります。例22-2は、大きなデータ・セットを使用する場合に問合せ結果を処理するパターンを示しています。この例では、フィルタに一致するエントリのすべてのキーが返されますが、一度にキャッシュから取得されるエントリ数はBUFFER_SIZE(この例では100)のみです。

注意:
LimitFilter APIは、次の例と同様に、結果を別々に処理できます。ただし、LimitFilterは、ユーザー・インタフェースのように結果がページングされるシナリオに適しています。問合せ結果のデータをすべて処理する場合には効率的な方法ではありません。

例22-2 問合せ結果のバッチ処理

public static void performQuery()
{
NamedCache c = CacheFactory.getCache("test");

// Search for entries that start with 'c'
Filter query = new LikeFilter(IdentityExtractor.INSTANCE, "c%", '\\', true);

// Perform query, return keys of entries that match
Set keys = c.keySet(query);

// The amount of objects to process at a time
final int BUFFER_SIZE = 100;

// Object buffer
Set buffer = new HashSet(BUFFER_SIZE);

for (Iterator i = keys.iterator(); i.hasNext();)
{
buffer.add(i.next());

if (buffer.size() >= BUFFER_SIZE)
{
// Bulk load BUFFER_SIZE number of objects from cache
Map entries = c.getAll(buffer);

// Process each entry
process(entries);

// Done processing these keys, clear buffer
buffer.clear();
}
}
// Handle the last partial chunk (if any)
if (!buffer.isEmpty())
{
process(c.getAll(buffer));
}
}

public static void process(Map map)
{
for (Iterator ie = map.entrySet().iterator(); ie.hasNext();)
{

Map.Entry e = (Map.Entry) ie.next();
out("key: "+e.getKey() + ", value: "+e.getValue());
}
}

22.3 問合せ索引の使用

問合せ索引によって、値(またはそれらの値の属性)と対応するキーをQueryMap内に関連付けて問合せのパフォーマンスを向上させることができます。

この項には次のトピックが含まれます:

- 索引の作成

- ユーザー定義索引の作成

22.3.1 索引の作成

QueryMapクラスのaddIndexメソッドを使用して、索引を作成します。問合せ可能な属性であれば、このメソッドを使用して索引を付けることができます。このメソッドには、次の3つのパラメータが含まれています。

addIndex(ValueExtractor extractor, boolean fOrdered, Comparator comparator)

例22-3は、索引の作成方法を示しています。

例22-3 索引を作成するサンプル・コード

NamedCache cache = CacheFactory.getCache("MyCache");
ValueExtractor extractor = new ReflectionExtractor("getAttribute");
cache.addIndex(extractor, true, null);

fOrdered引数では、索引構造をソートするかどうかを指定します。ソートされた索引は、「2つの日付の間に収まるエントリをすべて選択」や「姓がSで始まる従業員をすべて選択」などの範囲問合せに役立ちます。等価問合せの場合は、順序付けられていない索引を使用できます。この索引を使用すると、領域と時間の面で効率が向上することがあります。

comparator引数では、索引の順序付け用にカスタムのjava.util.Comparatorを指定できます。

addIndexメソッドは、単にキャッシュ実装のヒントとして示したものであり、索引がサポートされていない場合や目的の索引(またはそれに類似した索引)が存在する場合は、キャッシュによって無視されることがあります。アプリケーションでは、確実に索引が提示されるようにするために、索引が存在する場合でもこのメソッドをコールして索引を提示することが求められます。たとえば、分散環境では、各サーバーが起動時に同じ索引セットを推奨する可能性が高いため、別のサーバーが同じ索引をリクエストしたかどうかにかかわらず、これらの索引を無条件にリクエストしたとしても、アプリケーションにとってマイナス面はありません。

Coherenceでは必要に応じて問合せを結合できます。またCoherenceには、索引の使用優先度を決めるコストベース・オプティマイザ(CBO)が搭載されています。索引を利用するには、問合せで使用されているものと等価のエクストラクタ((Object.equals())を使用する必要があります。

適用された索引のリストは、JMXを使用してStorageManagerMBeanから取得できます。CoherenceでのJMXの使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

22.3.2 ユーザー定義索引の作成

アプリケーションを選択してユーザー定義索引を作成し、索引に追加されるエントリを管理できます。ユーザー定義索引は、通常、索引の保守に必要なメモリーや処理のオーバーヘッドの削減に使用されます。ユーザー定義索引を作成するには、アプリケーションでMapIndexインタフェースとIndexAwareExtractorインタフェースを実装する必要があります。この項では、条件付き索引を作成するためのインタフェースの実装を提供するConditionalIndexクラスとConditionalExtractorクラスについても説明します。条件付き索引は関連付けられたフィルタを使用して、エントリに索引を付ける必要があるかどうかを評価します。

22.3.2.1 MapIndexインタフェースの実装

MapIndexインタフェースは、索引付けされたMap(またはその値の属性)に格納されている値を、索引付けされたMapの対応キーに関連付けるために使用されます。アプリケーションは、このインタフェースを実装してカスタム索引を提供します。

次の例の実装では、null以外の値を持つエントリを追加するのみの索引が定義されています。これは、大量のエントリを持つキャッシュがあり、小さなサブセットにのみ意味のあるnull以外の値が格納されている場合に特に便利です。

public class CustomMapIndex implements MapIndex
{
public void insert(Map.Entry entry)
{
if (entry.getValue()!= null)
{
...
}
}
...
}

この例では、エントリの値を抽出する前にその値がnullかどうかが確認されますが、これは後でも実行できます。エントリの値がnullの場合、索引には何も挿入されません。nullに関する類似の確認は、MapIndex updateメソッドでも必要です。残りのMapIndexメソッドも、適切に実装される必要があります。

22.3.2.2 IndexAwareExtractorインタフェースの実装

IndexAwareExtractorインタフェースは、MapIndex索引の作成と破棄をサポートするValueExtractorインタフェースの拡張機能です。このインタフェースのインスタンスは、QueryMap APIとともに使用してカスタム索引の作成をサポートすることを目的としたものです。次の例は、このインタフェースの実装方法を示しており、先程作成したCustomMapIndexクラスの例に対するものです。

public class CustomIndexAwareExtractor
implements IndexAwareExtractor, ExternalizableLite, PortableObject
{
public CustomIndexAwareExtractor(ValueExtractor extractor)
{
m_extractor = extractor;
}

public MapIndex createIndex(boolean fOrdered, Comparator comparator,
Map mapIndex)
{
ValueExtractor extractor = m_extractor;
MapIndex       index     = (MapIndex) mapIndex.get(extractor);

if (index != null)
{
throw new IllegalArgumentException(
"Repetitive addIndex call for " + this);
}

index = new CustomMapIndex(extractor, fOrdered, comparator);
mapIndex.put(extractor, index);
return index;
}

public MapIndex destroyIndex(Map mapIndex)
{
return (MapIndex) mapIndex.remove(m_extractor);
}
...
}

この例では、基礎となるエクストラクタを実際に使用して索引を作成し、最終的にキャッシュ・エントリから値を抽出しています。IndexAwareExtractor実装は、既存のQueryMapインタフェースを保持しながら、カスタムのMapIndex実装の作成と破棄を管理するために使用されます。

IndexAwareExtractorは、QueryMap.addIndexコールとQueryMap.removeIndexコールに渡されます。これに対して、CoherenceはIndexAwareExtractorのcreateIndexとdestroyIndexをコールします。IndexAwareExtractorは、createIndexとdestroyIndexに渡される、エクストラクタと索引を関連付けるMapを保持します。

22.3.2.3 条件付き索引の使用

条件付き索引はカスタム索引であり、上述のとおりMapIndexインタフェースとIndexAwareExtractorインタフェースの両方を実装し、関連付けられたフィルタを使用してエントリに索引を付ける必要があるかどうかを評価します。エントリの抽出された値は、そのフィルタがtrueに評価されている場合、索引に追加されます。実装クラスは、それぞれConditionalIndexとConditionalExtractorです。

ConditionalIndexはConditionalExtractorによって作成されます。ConditionalIndexで使用されるフィルタとエクストラクタは、ConditionalExtractorで設定され、QueryMap.addIndexコールの間にConditionalIndexコンストラクタに渡されます。

ConditionalExtractorは、ConditionalIndexの作成のみに使用されるIndexAwareExtractor実装です。基礎となるValueExtractorは、索引の作成時の値の抽出に使用され、指定された索引マップで作成されたConditionalIndexに関連付けられているエクストラクタです。値を抽出するConditionalExtractorの使用はサポートされていません。例:

ValueExtractor extractor = new ReflectionExtractor("getLastName");
Filter filter = new NotEqualsFilter("getId", null);
ValueExtractor condExtractor = new ConditionalExtractor(filter, extractor, true);

// add the conditional index which should only contain the last name values for the
// entries with non-null Ids
cache.addIndex(condExtractor, true, null);

22.4 バッチ問合せの実行

問合せを発行するクライアント上にメモリーを保持するために、問合せ結果をバッチで取得できる様々なテクニックがあります。

key set形式の問合せをgetAll()と組み合せると、エントリ・セット全体がクライアント上で同時にデシリアライズされないため、メモリーの消費が削減されます。また、ニア・キャッシュも利用されます。例:

例22-4 key set問合せ形式の使用

// key set(Filter filter)
Set setKeys = cache.keySet(filter);
Set setPageKeys = new HashSet();
int PAGE_SIZE = 100;
for (Iterator iter = setKeys.iterator(); iter.hasNext();)
{
setPageKeys.add(iter.next());
if (setPageKeys.size() == PAGE_SIZE || !iter.hasNext())
{
// get a block of values
Map mapResult = cache.getAll(setPageKeys);

// process the block
// ...

setPageKeys.clear();
}
}

LimitFilterを使用すると、クライアントに送信するデータ量が制限されると同時に、ページングが使用可能になります。例22-5は、LimitFilterの使用方法を示しています。

例22-5 制限フィルタの使用

int pageSize = 25;
Filter filter = new GreaterEqualsFilter("getAge", 18);
// get entries 1-25
Filter limitFilter = new LimitFilter(filter, pageSize);
Set entries = cache.entrySet(limitFilter);

// get entries 26-50
limitFilter.nextPage();
entries = cache.entrySet(limitFilter);

分散/パーティション・キャッシュを使用するときには、問合せでPartitionedFilterを使用してパーティションとキャッシュ・サーバーをターゲットにすることができます。各問合せのリクエストは単一のキャッシュ・サーバーをターゲットとしているため、これは、問合せ結果をバッチ処理するための最も効率的な方法であり、リクエストに応答する必要のあるサーバーの数を減らし、ネットワークを最も効率的に使用できるようにします。

注意:
PartitionedFilterの使用はクラスタ・メンバーに制限されています。Coherence*Extendのクライアントは使用できません。Coherence*Extendクライアントは、上述の2つのテクニックを使用できます。また、これらの問合せをInvocableとして実装し、リモートでCoherence*Extendクライアントが実行することも可能です。

パーティションで問合せパーティションを実行するには:

DistributedCacheService service =
(DistributedCacheService) cache.getCacheService();
int cPartitions = service.getPartitionCount();

PartitionSet parts = new PartitionSet(cPartitions);
for (int iPartition = 0; iPartition < cPartitions; iPartition++)
{
parts.add(iPartition);
Filter filterPart = new PartitionedFilter(filter, parts);
Set setEntriesPart = cache.entrySet(filterPart);

// process the entries ...
parts.remove(iPartition);
}

問合せは、サーバー・ベースでサーバー上で実行することもできます。

DistributedCacheService service =
(DistributedCacheService) cache.getCacheService();
int cPartitions = service.getPartitionCount();

PartitionSet partsProcessed = new PartitionSet(cPartitions);
for (Iterator iter = service.getStorageEnabledMembers().iterator();
iter.hasNext();)
{
Member member = (Member) iter.next();
PartitionSet partsMember = service.getOwnedPartitions(member);

// due to a redistribution some partitions may have been processed
partsMember.remove(partsProcessed);
Filter filterPart = new PartitionedFilter(filter, partsMember);
Set setEntriesPart = cache.entrySet(filterPart);

// process the entries ...
partsProcessed.add(partsMember);
}

// due to a possible redistribution, some partitions may have been skipped
if (!partsProcessed.isFull())
{
partsProcessed.invert();
Filter filter = new PartitionedFilter(filter, partsProcessed);

// process the remaining entries ...
}

22.5 複数値属性での問合せの実行

Coherenceでは、コレクションや配列を含めた複数値属性の索引付けおよび問合せがサポートされています。オブジェクトに索引を付けるときには、そのオブジェクトが複数値タイプかどうかがチェックされてから、シングルトンでなくコレクションとして索引が付けられます。このようなコレクションに対する問合せには、ContainsAllFilter、ContainsAnyFilterおよびContainsFilterが使用されます。

例22-6 複数値属性の問合せ

Set searchTerms = new HashSet();
searchTerms.add("java");
searchTerms.add("clustering");
searchTerms.add("books");

// The cache contains instances of a class "Document" which has a method
// "getWords" which returns a Collection<String> containing the set of
// words that appear in the document.
Filter filter = new ContainsAllFilter("getWords", searchTerms);

Set entrySet = cache.entrySet(filter);

// iterate through the search results
// ...

22.6 連鎖エクストラクタの使用

ChainedExtractorを実装すると、ゼロ引数(アクセッサ)メソッドの連鎖起動が可能になります。例22-7では、まずエクストラクタがリフレクションを使用して、キャッシュされているPersonオブジェクトごとにgetName()をコールします。その後、リフレクションを使用して、返されるStringでlengthメソッドをコールします。

例22-7 連鎖起動メソッド

ValueExtractor extractor = new ChainedExtractor("getName.length");

このエクストラクタを問合せに渡し、(たとえば)名前が10文字以内の人をすべて、問合せで選択することができます。メソッドの起動は、getName.trim.lengthのように無限に連鎖できます。

POFエクストラクタおよびPOFアップデータは、SimplePofPathクラスによってChainedExtractorsと同じ機能を提供しています。POFエクストラクタおよびPOFアップデータの詳細は、「POFエクストラクタとPOFアップデータの使用」を参照してください。

22.7 問合せのコストと効果の評価

この項では、問合せ内の各フィルタの見積もりコストと実際の効果をそれぞれ表示するために、問合せの実行計画レコードおよび問合せトレース・レコードを作成する手順について説明します。レコードは、Coherenceがどのように問合せを実行しているかを評価し、問合せが適切に実行されない理由または問合せをより適切に実行するためにどのように修正できるかを判断するために使用されます。問合せベースの統計の表示の詳細は、『Oracle Coherenceのマネージメント』のStorageManagerMBeanリファレンスも参照してください。

この項には次のトピックが含まれます:

- 問合せレコードの作成

- 問合せレコードの解析

- 問合せレコードの実行の例

22.7.1 問合せレコードの作成

com.tangosol.util.aggregator.QueryRecorderクラスは、特定のフィルタの実行レコードまたはトレース・レコードを生成します。このクラスは、クラスタ内のすべてのノードに問い合せて、結果を集計できるパラレル集計の実装です。このクラスは、問合せ内のフィルタに関する見積もりコストを示すEXPLAINレコードと、問合せ内の各フィルタの実際の効果を示すTRACEレコードの2つのレコード・タイプをサポートしています。

問合せレコードを作成するには、RecordTypeパラメータを指定する新しいQueryRecorderインスタンスを作成します。aggregateメソッドのパラメータとしてテストされるインスタンスとフィルタを含めます。次の例では、実行レコードを作成します。

NamedCache cache = CacheFactory.getCache("mycache");
cache.addIndex(new ReflectionExtractor("getAge"), true, null);

AllFilter filter = new AllFilter(new Filter[]
{
new OrFilter(
new EqualsFilter(new ReflectionExtractor("getAge"), 16),
new EqualsFilter(new ReflectionExtractor("getAge"), 19)),
new EqualsFilter(new ReflectionExtractor("getLastName"), "Smith"),
new EqualsFilter(new ReflectionExtractor("getFirstName"), "Bob"),
});

QueryRecorder agent = new QueryRecorder(RecordType.EXPLAIN);
Object resultsExplain = cache.aggregate(filter, agent);

System.out.println("\n" + resultsExplain + "\n");

トレース・レコードを作成するには、RecordTypeパラメータをTRACEに変更します。

QueryRecorder agent = new QueryRecorder(RecordType.TRACE);

22.7.2 問合せレコードの解析

問合せレコードは、問合せを構成するフィルタと索引の評価に使用されます。実行計画レコードは、フィルタの適用に関連する見積もりコストの評価に使用されます。トレース・レコードは、キー・セットの削減に対するフィルタの効果の評価に使用されます。

この項では、サンプルの実行計画レコードおよびサンプルのトレース・レコードを示し、レコードの読取りおよび解析方法について説明します。レコードは、記憶域が有効な4つのノードのクラスタにある1500エントリのサンプル問合せに基づいています。問合せは、16歳または19歳で、姓がSmith、名がBobである人を検索するフィルタで構成されています。最後に、getAgeに対する索引が追加されます。完全な例を実行するには、「問合せレコードの実行の例」を参照してください。

NamedCache cache = CacheFactory.getCache("mycache");
cache.addIndex(new ReflectionExtractor("getAge"), true, null);

AllFilter filter = new AllFilter(new Filter[]
{
new OrFilter(
new EqualsFilter(new ReflectionExtractor("getAge"), 16),
new EqualsFilter(new ReflectionExtractor("getAge"), 19)),
new EqualsFilter(new ReflectionExtractor("getLastName"), "Smith"),
new EqualsFilter(new ReflectionExtractor("getFirstName"), "Bob"),
});

22.7.2.1 問合せの実行計画レコード

問合せの実行レコードは、問合せ操作の一部としてフィルタの評価の見積もりコストを提供します。コストでは、フィルタで索引を使用できるかどうかが考慮されます。コスト評価は、問合せの実行時にフィルタが適用される順序の決定に使用されます。索引を使用するフィルタは、コストが最も低く、最初に適用されます。

例22-8では、一般的な問合せ実行計画レコードを示します。レコードには、問合せ内の各フィルタを評価するための実行計画表、およびフィルタで使用できる各索引が記載されている索引ルックアップ表が含まれています。これらの列は、次のように示されます。

- 名前 – この列は、問合せ内の各フィルタの名前を示します。複合フィルタの場合は、複合フィルタ内の各フィルタの情報が示されます。

- 索引 – この列は、指定のフィルタで索引を使用できるかどうかを示します。索引が見つかった場合、表示された番号が索引ルックアップ表の索引番号に対応します。例では、getAge()に対して、順序付けられた単純なマップ索引(0)が見つかりました。

- コスト – この列は、フィルタの適用に関する見積もりコストを示します。索引が使用可能な場合、コストは1となります。索引の適用操作では、索引コンテンツに1回だけアクセスすれば済むので、値1が使用されます。例では、記憶域が有効な4つのクラスタ・メンバーがあり、したがって、コストには4つのメンバーすべての索引へのアクセスが反映されます。索引が存在しない場合、コストはEVAL_COST * number of keysとして計算されます。EVAL_COST値は、定数値(1000)です。これは、フィルタを使用してキー・セットを削減するために全体スキャンを実行する相対的なコストを示します。例では、評価が必要な1500のキャッシュ・エントリがあります。索引付きのエントリへの問合せは常に、索引付きでないエントリと比べると安価ですが、効果が保証されているわけではありません。

例22-8のレコードは、getAge()の等価フィルタはコストが低いことを示しています。これは、そのフィルタが、関連付けられた索引を持ち、getLastName()およびgetFirstName()の前に適用されるためです。ただし、getAge()フィルタは、安価ですが、すべてのエントリが16か19のいずれかであり、BobおよびSmithに一致するエントリがほとんどない場合、あまり効果的ではないこともあります。この場合、getLastName()およびgetFirstName()に索引を追加するほうがより効果的です。さらに、索引でキー・セットの削減がうまく行われていない場合、索引の作成に関連するコスト(主にメモリー消費)は無駄になります。

例22-8 サンプルの問合せ実行計画レコード

Explain Plan
Name                                  Index        Cost
==================================================================================
com.tangosol.util.filter.AllFilter  | ----       | 0
com.tangosol.util.filter.OrFilter | ----       | 0
EqualsFilter(.getAge(), 16)     | 0          | 4
EqualsFilter(.getAge(), 19)     | 0          | 4
EqualsFilter(.getLastName(), Smit | 1          | 1500000
EqualsFilter(.getFirstName(), Bob | 2          | 1500000

Index Lookups
Index  Description                               Extractor             Ordered
==================================================================================
0      SimpleMapIndex: Extractor=.getAge(), Ord  .getAge()             true
1      No index found                            .getLastName()        false
2      No index found                            .getFirstName()       false

22.7.2.2 問合せのトレース・レコード

問合せのトレース・レコードは、問合せ操作の一部としてフィルタの評価の実コストを提供します。コストでは、フィルタで索引を使用できるかどうかが考慮されます。問合せが実際に実行され、キー・セットの削減に関する各フィルタの効果が示されます。

例22-9では、一般的な問合せトレース・レコードを示します。レコードには、問合せ内の各フィルタの効果を示すトレース表、およびフィルタで使用できる各索引が記載されている索引ルックアップ表が含まれています。これらの列は、次のように示されます。

- 名前 – この列は、問合せ内の各フィルタの名前を示します。複合フィルタの場合は、複合フィルタ内の各フィルタの情報が示されます。

- 索引 – この列は、指定のフィルタで索引を使用できるかどうかを示します。索引が見つかった場合、表示された番号が索引ルックアップ表の索引番号に対応します。例では、getAge()に対して、順序付けられた単純なマップ索引(0)が見つかりました。

- 有効性 – この列は、各フィルタの結果として実際に削減されたキー・セットの量を示します。値は、prefilter_key_set_size | postfilter_key_set_sizeとして示され、パーセンテージでも表されます。prefilter_key_set_size値は、フィルタの評価または索引の適用前のキー・セット・サイズを表します。postfilter_key_set_size値は、フィルタの評価または索引の適用後に残っているキー・セット・サイズを表します。複合フィルタ・エントリの場合、この値は、含まれているフィルタ全体の結果です。索引に基づいてキー・セット・サイズを削減することができなくなると、結果のキー・セットはデシリアライズされ、索引フィルタ以外のフィルタが適用されます。

- 期間 – この列は、フィルタの評価または索引の適用にかかった時間をミリ秒で示します。値0は、記録された時間がレポートのしきい値を下回ったことを示します。次の例で、63ミリ秒は、最初のフィルタgetLastName()で発生したキー・セットのデシリアライズのみが必要な結果です。

例22-9のレコードは、1500エントリを、姓がSmithで名がBob、年齢が16歳か19歳の100件のエントリに絞り込むのに約63ミリ秒かかったことを示しています。1500エントリのキー・セットは、まず、getAge()の索引を使用して300に削減されました。その結果としての300エントリ(索引を使用してこれ以上削減することはできません)は、デシリアライズされ、getLastName()に基づいて150エントリに削減され、getFirstName()に基づいて100に削減されました。この例では、getAge()の索引は、実質1200エントリのキー・セットを削減できたので、消費したリソースに値する価値があります。getLastNameおよびgetFirstNameの索引は、問合せ全体のパフォーマンスを高めますが、索引の作成に必要な追加のリソースに値する価値がない場合もあります。

例22-9 サンプルの問合せトレース・レコード

Trace
Name                                  Index        Effectiveness          Duration
==================================================================================
com.tangosol.util.filter.AllFilter  | ----       | 1500|300(80%)        | 0
com.tangosol.util.filter.OrFilter | ----       | 1500|300(80%)        | 0
EqualsFilter(.getAge(), 16)     | 0          | 1500|150(90%)        | 0
EqualsFilter(.getAge(), 19)     | 0          | 1350|150(88%)        | 0
EqualsFilter(.getLastName(), Smit | 1          | 300|300(0%)          | 0
EqualsFilter(.getFirstName(), Bob | 2          | 300|300(0%)          | 0
com.tangosol.util.filter.AllFilter  | ----       | 300|100(66%)         | 63
EqualsFilter(.getLastName(), Smit | ----       | 300|150(50%)         | 63
EqualsFilter(.getFirstName(), Bob | ----       | 150|100(33%)         | 0

Index Lookups
Index  Description                               Extractor             Ordered
==================================================================================
0      SimpleMapIndex: Extractor=.getAge(), Ord  .getAge()             true
1      No index found                            .getLastName()        false
2      No index found                            .getFirstName()       false

22.7.3 問合せレコードの実行の例

次の例は、問合せレコードの作成を示す単純なクラスです。このクラスは、分散キャッシュ(mycache)を1500 Personオブジェクトとともにロードし、属性の索引を作成し、問合せを実行し、クラスが終了する前にコンソールに出力される問合せ実行計画レコードと問合せトレース・レコードの両方を作成します。

例22-10 問合せレコードの例

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;
import com.tangosol.util.Filter;
import com.tangosol.util.aggregator.QueryRecorder;
import static com.tangosol.util.aggregator.QueryRecorder.RecordType;
import com.tangosol.util.extractor.ReflectionExtractor;
import com.tangosol.util.filter.AllFilter;
import com.tangosol.util.filter.EqualsFilter;
import com.tangosol.util.filter.OrFilter;
import java.io.Serializable;
import java.util.Properties;

public class QueryRecordExanple
{
public static void main(String[] args) {

testExplain();
testTrace();
}

public static void testExplain()
{
NamedCache cache = CacheFactory.getCache("mycache");
cache.addIndex(new ReflectionExtractor("getAge"), true, null);
PopulateCache(cache);

AllFilter filter = new AllFilter(new Filter[]
{
new OrFilter(
new EqualsFilter(new ReflectionExtractor("getAge"), 16),
new EqualsFilter(new ReflectionExtractor("getAge"), 19)),
new EqualsFilter(new ReflectionExtractor("getLastName"), "Smith"),
new EqualsFilter(new ReflectionExtractor("getFirstName"), "Bob"),
});

QueryRecorder agent = new QueryRecorder(RecordType.EXPLAIN);
Object resultsExplain = cache.aggregate(filter, agent);
System.out.println("\nExplain Plan=\n" + resultsExplain + "\n");
}

public static void testTrace()
{
NamedCache cache = CacheFactory.getCache("hello-example");
cache.addIndex(new ReflectionExtractor("getAge"), true, null);
PopulateCache(cache);

AllFilter filter = new AllFilter(new Filter[]
{
new OrFilter(
new EqualsFilter(new ReflectionExtractor("getAge"), 16),
new EqualsFilter(new ReflectionExtractor("getAge"), 19)),
new EqualsFilter(new ReflectionExtractor("getLastName"), "Smith"),
new EqualsFilter(new ReflectionExtractor("getFirstName"), "Bob"),
});

QueryRecorder agent = new QueryRecorder(RecordType.TRACE);
Object resultsExplain = cache.aggregate(filter, agent);
System.out.println("\nTrace =\n" + resultsExplain + "\n");
}

private static void PopulateCache(NamedCache cache)
{
for (int i = 0; i < 1500; ++i)
{
Person person = new Person(i % 3 == 0 ? "Joe" : "Bob",
i % 2 == 0 ? "Smith" : "Jones", 15 + i % 10);
cache.put("key" + i, person);
}
}

public static class Person implements Serializable
{
public Person(String sFirstName, String sLastName, int nAge)
{
m_sFirstName = sFirstName;
m_sLastName = sLastName;
m_nAge = nAge;
}

public String getFirstName()
{
return m_sFirstName;
}

public String getLastName()
{
return m_sLastName;
}
public int getAge()
{
return m_nAge;
}

public String toString()
{
return "Person( " +m_sFirstName + " " + m_sLastName + " : " +

m_nAge + ")";
}
private String m_sFirstName;
private String m_sLastName;
private int m_nAge;
}
}

23 連続問合せキャッシングの使用

この章では、問合せで常にリアルタイムでキャッシュから最新の結果が取得されるようにするための連続問合せキャッシングの使用方法について説明します。

この章には次の項が含まれます:

- 連続問合せキャッシングの使用の概要

- 連続問合せキャッシュの実装の理解

- 連続問合せキャッシュの構成

- キーのみのキャッシュまたはキーと値のキャッシュ

- ContinuousQueryCacheのリスニング

- ContinuousQueryCacheを読取り専用にする設定

23.1 連続問合せキャッシングの使用の概要

問合せは、Coherenceキャッシュからポイント・イン・タイムの問合せ結果を取得する機能を提供し、その問合せの結果を変更する可能性があるイベントを受信することが可能です。しかし、連続問合せ機能では、問合せ結果を、関連するイベントの連続的なストリームと結合することでリアルタイム方式で最新の問合せ結果が保持されます。目的の問合せの待機時間が0である場合と同じ効果を持ち、 問合せがミリ秒ごとに数回繰り返されるため、この機能は連続問合せと呼ばれています。ポイント・イン・タイムの問合せ結果およびイベントの詳細は、第22章「キャッシュ内のデータの問合せ」を参照してください。

連続問合せは、問合せの結果を連続問合せキャッシュにマテリアライズし、問合せでイベント・リスナーを使用してリアルタイムでキャッシュを最新の状態に保つことにより実装されます。つまり、連続問合せは、決して古くなることのない、キャッシュされた問合せ結果になります。

23.1.1 連続問合せキャッシングの用途の理解

連続問合せキャッシングには、いくつかの異なる一般的な用途があります。

- 連続問合せキャッシュは、複合イベント処理(CEP: Complex Event Processing)システムやイベント相関エンジンにおける有用な構成要素です。

- アプリケーションが特定の問合せを繰り返し実行し、その問合せの最新の結果に常に即座にアクセスできることが有益である状況では、連続問合せキャッシュの使用が効果的です。

- 連続問合せキャッシュはマテリアライズド・ビューに類似しており、標準のNamedCache APIを使用して問合せの結果にアクセスし、操作する場合およびその問合せに関連するイベントの現行ストリームを受信する場合に役立ちます。

- 連続問合せキャッシュは、最新のデータ・セットを使用場所(特定のサーバー・ノードやクライアント・デスクトップなど)でローカルに保持できるため、ニア・キャッシュと同様の方法で使用できます。ニア・キャッシュは無効化ベースですが、連続問合せキャッシュでは実際にデータが最新の状態で保持されます。

使用例の1つにトレーディング・システム・デスクトップがあります。このデスクトップには、トレーダーの未処理の注文とすべての関連情報が常に最新の状態で保持されている必要があります。Coherence*Extend機能を連続問合せキャッシングと組み合せることにより、アプリケーションで文字どおり何万もの同時ユーザーをサポートできます。

注意:
連続問合せキャッシュは、分散される可能性のあるより大きなキャッシュ・データ・セットの特定のサブセットについて、その最新のローカル・コピーを非常に簡単かつ効果的に維持する機能を提供します。そのため、クライアントベースおよびサーバーベースのアプリケーションを含め、ほとんどすべてのタイプのアプリケーションに有用です。

23.2 連続問合せキャッシュの実装の理解

Coherenceでの連続問合せの実装には、com.tangosol.net.cache.ContinuousQueryCacheクラスを使用します。このクラスは、Coherenceのすべてのキャッシュと同様、次の機能を備えた標準のNamedCacheインタフェースを実装します。

- Mapインタフェースを使用したキャッシュのアクセスおよび操作: NamedCacheは、Java Collections Frameworkの標準的なMapインタフェースを拡張します。これは、JavaのHashMapクラスとHashtableクラスで実装されているものと同じインタフェースです。

- キャッシュ内で発生するすべてのオブジェクト変更に対するイベント: NamedCacheはObservableMapインタフェースを拡張します。

- IDをベースとしたクラスタ全体でのキャッシュ内オブジェクトのロック: NamedCacheはConcurrentMapインタフェースを拡張します。

- キャッシュ内オブジェクトの問合せ: NamedCacheはQueryMapインタフェースを拡張します。

- キャッシュ内オブジェクトの分散パラレル処理および集約: NamedCacheはInvocableMapインタフェースを拡張します。

ContinuousQueryCacheは、Coherenceのすべてのキャッシュで提供されるAPIであるNamedCacheインタフェースを実装しているため、非常に使いやすく、その機能が必要になった場合に別のキャッシュと簡単に置き換えることができます。

23.3 連続問合せキャッシュの構成

連続問合せキャッシュは、次の2つの項目で定義されます。

1. 基礎となるキャッシュ

2. 連続問合せキャッシュでキャッシュされるサブセットを構成する、基礎となるキャッシュの問合せ

基礎となるキャッシュには、別の連続問合せキャッシュを含めた任意のCoherenceキャッシュを使用できます。キャッシュは一般にCacheFactoryで取得されます。これにより開発者は、次の例に示すように、キャッシュの名前を指定するだけでアプリケーションのキャッシュ構成情報に基づいて自動的にキャッシュを構成できます。

NamedCache cache = CacheFactory.getCache("orders");

キャッシュ構成情報の指定方法の詳細は、付録B「キャッシュ構成の要素」を参照してください。

この問合せは、データのフィルタリングに使用される問合せと同じタイプになります。例:

例23-1 連続問合せキャッシュの問合せ

Filter filter = new AndFilter(new EqualsFilter("getTrader", traderid),
new EqualsFilter("getStatus", Status.OPEN));

問合せの詳細は、第22章「キャッシュ内のデータの問合せ」を参照してください。

通常、キャッシュを問い合せるには、QueryMapのメソッドを使用します。たとえば、トレーダー・オブジェクトの未決済ポジションすべてのスナップショットを取得するには、次のようにします。

例23-2 連続問合せキャッシュのデータの取得

Set setOpenTrades = cache.entrySet(filter);

同様に、連続問合せキャッシュは、次に示す同じ2つの要素で構成されます。

例23-3 連続問合せキャッシュの構成

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);

23.3.1 ContinuousQueryCacheに関連付けられているリソースのクリーンアップ

連続問合せキャッシュでは、その基礎となるキャッシュに1つ以上のイベント・リスナーが配置されます。連続問合せキャッシュがアプリケーションの継続期間を通して使用される場合、リソースはそのノードがシャットダウンされたか、または別の原因で停止したときにクリーンアップされます。ただし、連続問合せキャッシュを一定の期間のみ使用する場合は、アプリケーションによる連続問合せキャッシュの使用が終了した時点で、ContinuousQueryCacheでrelease()メソッドがコールされる必要があります。

23.4 キーのみのキャッシュまたはキーと値のキャッシュ

連続問合せキャッシュを構成する際、問合せで取得されたキーのみをキャッシュで追跡し、要求された場合にのみ、その値を基礎となるキャッシュから取得するように指定できます。この機能は、問合せの結果セットが非常に膨大になる連続問合せキャッシュを作成する場合、または値をリクエストされることがないかほとんどない場合に役立ちます。キーのみをキャッシュするように指定するには、CacheValuesプロパティを構成できるコンストラクタを使用します。例:

例23-4 CacheValuesプロパティを構成できるコンストラクタ

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, false);

必要に応じて、CacheValuesプロパティはキャッシュがインスタンス化された後で変更することもできます。

例23-5 CacheValuesプロパティの設定

cacheOpenTrades.setCacheValues(true);

23.4.1 CacheValuesプロパティとイベント・リスナー

連続問合せキャッシュに標準の(非Lite)イベント・リスナーがある場合、またはイベント・リスナーのいずれかがフィルタリングされる場合は、CacheValuesプロパティが自動的にtrueに設定されます。これは、イベントをフィルタリングする際、および発生させたイベントに古い値と新しい値を提供する際に、ローカルにキャッシュされた値を連続問合せキャッシュが使用するためです。

23.5 ContinuousQueryCacheのリスニング

連続問合せキャッシュ自体は監視可能であるため、クライアントが連続問合せキャッシュに1つ以上のイベント・リスナーを配置することが可能です。例:

例23-6 連続問合せキャッシュへのリスナーの追加

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.addMapListener(listener);

キャッシュに格納されているすべてのアイテムとキャッシュに追加されるすべてのアイテムに対してなんらかの処理を実行する必要がある場合、その方法は2つあります。1つは、処理を実行した後、以降の追加に対処するリスナーを追加する方法です。

例23-7 連続問合せキャッシュ・エントリの処理とリスナーの追加

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
for (Iterator iter = cacheOpenTrades.entrySet().iterator(); iter.hasNext(); )
{
Map.Entry entry = (Map.Entry) iter.next();
// .. process the cache entry
}
cacheOpenTrades.addMapListener(listener);

ただし、このコードは正しくありません。これでは、反復処理が終了してリスナーが追加されるまでのわずかの時間に発生したイベントを見逃すことになります。別の方法では、イベントを見逃さないように、まずリスナーを追加し、その後で処理を実行します。

例23-8 リスナー追加後の連続問合せキャッシュ・エントリの処理

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.addMapListener(listener);
for (Iterator iter = cacheOpenTrades.entrySet().iterator(); iter.hasNext(); )
{
Map.Entry entry = (Map.Entry) iter.next();
// .. process the cache entry
}

ただし、同じエントリがイベント内とIterator内の両方に出現し、イベントが非同期になる可能性があるため、操作の順序が正しいことは保証できません。

解決策は、構成時にリスナーを指定することです。そうすることで、既存の(問合せに含まれていた)項目であるか、キャッシュの構成時または構成後に追加された項目かどうかに関係なく、連続問合せキャッシュ内の項目ごとにイベントが1つずつリスナーに送信されます。

例23-9 連続問合せキャッシュ構成時のリスナーの指定

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, listener);

23.5.1 安定したマテリアライズド・ビューの実現

ContinuousQueryCache実装にも同じ課題がありました。同じキャッシュから変更イベントのストリームを受信しながら、基礎となるキャッシュの正確なポイント・イン・タイム・スナップショットをいかにアセンブルするかということです。その解決法は、いくつかの部分に分かれています。まず、Coherenceでは同期イベントのオプションがサポートされており、これによって順序付けが保証されます。このオプションの詳細は、第25章「マップ・イベントの使用」を参照してください。

また、ContinuousQueryCacheには初期移入の2フェーズ実装があります。これにより、基礎となるキャッシュを問い合せてから、第1フェーズで発生したすべてのイベントを解決できます。このようにイベントを見逃したり重複させたりすることなくデータの可視性を保証する操作はかなり複雑であるため、ContinuousQueryCacheでは、アプリケーション開発者が作成時にリスナーを渡すことで、この複雑さに対処しなくても済むようにしています。

23.5.2 同期および非同期リスナーのサポート

デフォルトでは、ContinuousQueryCacheのリスナーにはイベントが非同期で配信されます。ただし、ContinuousQueryCacheでは、SynchronousListenerインタフェースで提供されている同期イベントのオプションも対応しています。このオプションの詳細は、第23章「連続問合せキャッシングの使用」を参照してください。

23.6 ContinuousQueryCacheを読取り専用にする設定

ContinuousQueryCacheは、次のように読取り専用キャッシュにすることができます。

例23-10 ContinuousQueryCacheを読取り専用にする設定

cacheOpenTrades.setReadOnly(true);

読取り専用のContinuousQueryCacheでは、キャッシュ内でのオブジェクトの追加、変更、削除またはロックができません。

読取り専用に設定したContinuousQueryCacheを、読取り/書込みに戻すことはできません。

24 キャッシュ内のデータの処理

この章では、クラスタ全体にわたってデータ・グリッド処理を実行するためのエントリ・プロセッサおよびアグリゲータの使用方法について説明します。これらのデータ・グリッド機能は、他のmap-reduceパターンと類似した方法で実行され、非常に短い待機時間で大量のデータを処理できます。

この章には次の項が含まれます:

- キャッシュ内のデータの処理の概要

- ターゲット、パラレルおよび問合せベースの処理のためのエージェントの使用

- データ・グリッドの集計の実行

- ノードベースの処理の実行

- ワーク・マネージャの使用

24.1 キャッシュ内のデータの処理の概要

Coherenceでは、データ・グリッド・サービスおよびデータ・グリッドを使用するクライアントベースおよびサーバーベースのアプリケーションの構築に適したインフラストラクチャを提供します。Coherenceの基本的なレベルでは、グリッド内の多数のサーバーにわたる膨大なデータ量を管理できます。また、そのデータをほぼ待機時間なしでアクセスできます。さらに、マップ・リデュースな方法でのデータ間のパラレル問合せや、そのデータの記録システムとして動作するデータベースおよびEISシステムとの統合もサポートされます。

24.1.1 ターゲット処理の実行

Coherenceでは、データ・グリッドの管理対象である任意のデータ・マップ・エントリに対してエージェントを実行する機能を提供します。

map.invoke(key, agent);

パーティション化されたデータの場合、データを所有しているグリッド・ノード上でエージェントが実行されます。キューイング、並行性の管理、エージェントの実行、エージェントによるデータ・アクセス、およびエージェントによるデータ変更は、すべてそのグリッド・ノード上で発生します。(結果のデータ変更の同期バックアップがある場合にのみ、追加的なネットワーク・トラフィックが必要になります。)様々な処理用途で、分散された並行処理制御、整合性およびデータ更新を処理するよりも、エージェントのシリアライズされた形式(最大で数百バイト)を移動するほうがずっと効率的です。

リクエストおよびレスポンス処理の場合、エージェントは次のような結果を返します。

Object oResult = map.invoke(key, agent);

Coherenceはデータ・グリッドとして、データ・トポロジの構成に基づいてエージェントを実行する場所を決定します。決定した場所にエージェントを移動して、エージェントを実行し(エージェントの実行中は項目の並行処理制御を自動的に処理します)、変更をバックアップして(存在する場合)、結果を返します。

24.1.2 パラレル処理の実行

Coherenceでは、グリッド内のすべてのノードにわたって、エントリのコレクションに対してエージェントをパラレル実行できるようにするmap-reduce機能が提供されます。パラレル実行により、グリッド全体で作業のバランスを取ることで大量のデータを処理することが可能になります。invokeAllメソッドは、次のように使用されます。

map.invokeAll(collectionKeys, agent);

リクエストおよびレスポンス処理の場合、エージェントは各キーで1つの結果を返します。

Map mapResults = map.invokeAll(collectionKeys, agent);

Coherenceは、データ・トポロジの構成に基づいてエージェントを実行する最適な場所を決定します。次に、決定した場所にエージェントを移動して、エージェントを実行し(エージェントの実行中は項目の並行処理制御を自動的に処理します)、変更をバックアップして(存在する場合)、結合した結果を返します。結果セットに対して集計を実行する手順については、「データ・グリッドの集計の実行」を参照してください。

24.1.3 問合せベースの処理の実行

Coherenceは、データ・グリッド全体にわたる問合せ機能をサポートしています。問合せの作成の詳細は、第22章「キャッシュ内のデータの問合せ」を参照してください。たとえば、トレーディング・システムでは、特定のトレーダーのすべての未決済のOrderオブジェクトについて問い合せることができます。

例24-1 データ・グリッド全域の問合せ

NamedCache map    = CacheFactory.getCache("trades");
Filter     filter = new AndFilter(new EqualsFilter("getTrader", traderid),
new EqualsFilter("getStatus", Status.OPEN));
Set setOpenTradeIds = mapTrades.keySet(filter);

この機能をデータ・グリッドのパラレル実行の使用と組み合せることで、問合せに対するエージェントの実行機能を実現します。前項のとおり、実行はパラレルで行われるため、問合せに適合するIDまたはエントリを返すかわりに、エントリに対するエージェントが実行されます。

map.invokeAll(filter, agent);

リクエストおよびレスポンス処理の場合、エージェントは各キーで1つの結果を返します。

Map mapResults = map.invokeAll(filter, agent);

パラレル問合せとパラレル実行を組み合せることで、データ・グリッドに対する問合せベースのエージェント起動が実現されます。

24.1.4 データ・グリッド全体の処理の実行

AlwaysFilterのインスタンス(またはnull)をinvokeAllメソッドに渡すと、渡されたエージェントがInvocableMapのすべてのエントリに対して実行されます。

map.invokeAll((Filter) null, agent);

その他のタイプのエージェント起動と同様の方法で、リクエストおよびレスポンス処理がサポートされます。

Map mapResults = map.invokeAll((Filter) null, agent);

アプリケーションでは、データ・グリッド内の特定のマップで展開されているすべてのデータを1行のコードで処理できます。

24.2 ターゲット、パラレルおよび問合せベースの処理のためのエージェントの使用

エージェントは、通常、AbstractProcessorクラスを拡張してEntryProcessorインタフェースを実装します。

Coherenceには、次のようなエージェントが含まれます。

- AbstractProcessor - EntryProcessorを作成するための抽象ベース・クラス

- ExtractorProcessor - InvocableMapに保存されたオブジェクトから値(プロパティ値など)を抽出して返します

- CompositeProcessor - 同じエントリに対して順番に起動されるEntryProcessorオブジェクトのコレクションをバンドルします

- ConditionalProcessor - エントリ-プロセスに対するFilterがtrueに評価された場合、EntryProcessorを起動します

- PropertyProcessor - PropertyManipulatorに依存するEntryProcessor実装の抽象ベース・クラス

- NumberIncrementor - 基本形の整数型や、Byte、Short、Integer、Long、Float、Double、BigInteger、BigDecimalの任意のプロパティを実行前後に増分します

- NumberMultiplier - 基本形の整数型や、Byte、Short、Integer、Long、Float、Double、BigInteger、BigDecimalの任意のプロパティを乗算した後で前の値または新しい値を返します

InvocableMapインタフェース内のEntryProcessorインタフェースには、processとprocessAllの2つのメソッドのみが含まれます。AbstractProcessorは、processAllメソッドのデフォルト実装を提供します。複数のキーを処理する場合は、すべてのキーに単一のEntryProcessorオブジェクトが再利用され、その状態は変化しません。

注意:
processAllのコールで例外がスローされた場合、変更は、setEntriesから削除されたエントリの基礎となるMapに対してのみ行われます。残りのエントリに対して行う変更は処理されません。

EntryProcessorに渡されるInvocableMap.Entryは、Map.Entryインタフェースを拡張したものです。これにより、EntryProcessor実装でエントリに関する必要な情報を取得して、必要な変更を最も効率的な方法で実行できます。

24.2.1 複数のキャッシュのエントリの処理

エントリ・プロセッサでは、1つのprocessまたはprocessAll操作で複数のキャッシュ内のキャッシュ・エントリを更新できます。これらのキャッシュは同じサービスによって管理され、エントリは同じパーティションに存在する必要があります。エントリを同じパーティションに存在させる方法の詳細は、「データ・アフィニティの指定」を参照してください。

processおよびprocessAllの操作は、キャッシュ・エントリのアクセス、挿入、更新、変更または削除の際に暗黙的ロックを使用するというトランザクションに類似した方法で実行されます。エントリの処理中に例外がスローされた場合、エントリはロール・バックされ、基礎となる値はいずれも変更されません。processAllの操作は、個々のエントリやリクエスト全体ではなく、単一のパーティション内のすべてのエントリ(または、サービス・スレッドが構成されていない場合のメンバー)に対して原子性を持ちます。

注意:
別のスレッドでの順序の競合でエントリがロックされている場合、暗黙的ロックによってデッドロックが作成されることがあります。アプリケーションでは、デッドロックが発生しない方式でキャッシュ・エントリにアクセス(をロック)するようにしておく必要があります。デッドロックが検出された場合、例外がスローされますが、基礎となるサービスは停止しません。

com.tangosol.net.BackingMapContext APIは、複数のキャッシュ内のエントリを処理するために使用され、キャッシュのバッキング・マップのエントリに直接アクセスする手段を提供します。パッキング・マップは(アプリケーションによって通常使用されるキャッシュの論理表現とは反対に)エントリが格納されている実際のMap実装です。パッキング・マップ内のエントリはバイナリ形式で格納されるため、アプリケーションではエントリをシリアライズ形式で処理することが必要です。パッキング・マップの詳細は、第14章「記憶域およびバッキング・マップの実装」を参照してください。

com.tangosol.util.BinaryEntry APIは、パッキング・マップ・コンテキストへの容易なアクセスを提供し、アプリケーションによって通常使用されます。次のコード・サンプルは、BinaryEntry APIを使用してエントリ・プロセッサのprocessメソッド内で2つの異なるキャッシュ内のエントリを更新する方法を示しています。

public Object process(Entry entry) {
BinaryEntry binEntry = (BinaryEntry) entry;
Binary binKey = binEntry.getBinaryKey();
Trade trade = (Trade) binEntry.getValue();

// Update a Trade object in cache1

trade.setPrice(trade.getPrice() + factor);
binEntry.setValue(trade);

// update a Trade object in cache2

BackingMapManagerContext ctx = binEntry.getContext();
BinaryEntry binEntry2 =
(BinaryEntry) ctx.getBackingMapContext("cache2").getBackingMapEntry(binKey);
Trade trade2 = (Trade) binEntry2.getValue();
trade2.setPrice(trade2.getPrice() + factor);
binEntry2.setValue(trade2);

return null;
}

注意:
getBackingMapEntryメソッドは、エントリ・プロセッサ呼出しのコンテキスト内でのみコールできます。エントリに対して行われる変更はすべて、外側の呼出しによって行われたものと同じライフサイクルで保持されます。返されるエントリは、包含呼出しの期間のみ有効であり、同じ呼出しコンテキスト内におけるこのメソッドへの複数のコールは同じエントリ・オブジェクトを返します。

24.2.2 エントリ・プロセッサの結果の無視

AbstractProcessorクラスのprocessAllメソッドは、結果のマップをクライアント・アプリケーションに返します。マップには、処理されたすべてのエントリのキーと値が含まれています。多くの場合、エントリ・プロセッサはクライアントが使用する結果を返します。ただし、いくつかの結果をクライアントが使用できない場合もあります。さらに重要なことには、プロセッサがキャッシュ内のすべてのエントリを評価することが必要な場合があります。そのようなときは、返されたマップにキャッシュ内のすべてのキーが含まれています。どちらの場合も、不要な結果を無視するようにエージェントを設計する必要があります。

次のような理由により、必要な結果のみを返すようにエージェントを設計することは、優れたパターンであり、ベスト・プラクティスです。

- クライアントのメモリー・フットプリントが、キャッシュのサイズに依存しなくなります。

- クライアントへの影響を受けるすべてのキーの転送(キャッシュが大きすぎる場合にクライアント上でOutOfMemoryError例外が発生する可能性がある)が回避されます。

- クライアントにおけるすべてのキーのデシリアライズ・コストが回避されます。

- プロキシ・ノードを介したマップおよびすべてのキーの転送が回避されます(拡張クライアントの場合)。

エントリ・プロセッサの結果を無視するには、プロセッサのprocessAllメソッドをオーバーライドし、空のMapまたはnullを返すようにします。次の例は、エントリを処理した後に常にnullを返す単純なエントリ・プロセッサ・エージェントを示しています。この例は、あまり現実的ではありませんが、processAllメソッドのオーバーライド方法を示しています。

public static class Agent
implements InvocableMap.EntryProcessor
{
private static final long serialVersionUID = 1L;

@Override
public Object process(Entry entry)
{
return null;
}

@Override
public Map processAll(Set set)
{
for (Entry entry : (Set<Entry>) set)
{
process(entry);
}
return null;
}

24.2.3 エントリの非同期処理

エントリ・プロセッサは、AsynchronousProcessorクラスを使用して非同期に起動できます。クラスはJava標準のFutureインタフェースを実装し、大量のバックログを回避するCoherence固有のフロー制御メカニズムも含んでいます。

AsynchronousProcessorクラスは、エントリ・プロセッサの実装をラップするために使用されます。例:

UpdaterProcessor up = new UpdaterProcessor(null, value);
AsynchronousProcessor ap = new AsynchronousProcessor(up);

cache.invokeAll(filter, ap);
ap.getResult();

前述の例は、基礎となるエントリ・プロセッサを起動し、(基礎となるサービスのフロー制御ロジックで定義されているように)自動フロー制御および(スレッドのリクエストは当然順番に実行されることが期待されるため、コール元スレッドのhashCodeに割り当てられた)デフォルトの順序単位IDを使用します。順番は、フェイルオーバー中である場合でも各パーティションに対して保証されます。手動でリクエスト・フローを制御し、必要に応じて順序単位IDを割り当てるために、追加のコンストラクタが使用可能です。

高度なユースケースのために、AsynchronousProcessorクラスを拡張してカスタム非同期機能を定義することが可能です。次の例では、AsynchrounousProcessorクラスを拡張し、onResult、onCompleteおよびonExceptionメソッドをオーバーライドしています。AsynchrounousProcessorクラスおよびそのメソッドの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

注意:
onComplete、onResultおよびonExceptionメソッド呼出しはクライアントのサービス・スレッドで実行され、他のスレッドのレスポンスの処理をブロックするため、これらのメソッドのオーバーライドの実装は、非ブロックで短時間で完了する必要があります。

AsynchronousProcessor processor = new AsynchronousProcessor(null)
{

public synchronized void onResult(Entry entry)
{
super.onResult(entry);

// process the result
}

public void onComplete()
{
super.onComplete();

if (m_eReason == null)
{

// process the result
}
else
{

// process the (potentially partial) failure
}
}

public void onException(Throwable eReason)
{
super.onException(eReason);

// process the observed exception
}
};

24.3 データ・グリッドの集計の実行

scalarエージェントに加えて、InvocableMapインタフェースも、エントリのサブセットに対して単一の結果を取得するための操作を実行するエントリ集計をサポートしています。エントリ集計は、グリッド全体でパラレルに行われ、大量のデータを処理する際のmap-reduceサポートを提供します。

例24-2 InvocableMap APIの集計

/**
* Perform an aggregating operation against the entries specified by the
* passed keys.
*
* @param collKeys  the Collection of keys that specify the entries within
*                  this Map to aggregate across
* @param agent     the EntryAggregator that is used to aggregate across
*                  the specified entries of this Map
*
* @return the result of the aggregation
*/
public Object aggregate(Collection collKeys, EntryAggregator agent);

/**
* Perform an aggregating operation against the set of entries that are
* selected by the given Filter.
* <p/>
* <b>Note:</b> calling this method on partitioned caches requires a
* Coherence Enterprise Edition (or higher) license.
*
* @param filter  the Filter that is used to select entries within this
*                Map to aggregate across
* @param agent   the EntryAggregator that is used to aggregate across
*                the selected entries of this Map
*
* @return the result of the aggregation
*/
public Object aggregate(Filter filter, EntryAggregator agent);

単純なEntryAggregatorは、InvocableMap.Entryオブジェクトのセットを処理して結果を得ます。

例24-3 EntryAggregator API

/**
* An EntryAggregator represents processing that can be directed to occur
* against some subset of the entries in an InvocableMap, resulting in a
* aggregated result. Common examples of aggregation include functions
* such as min(), max() and avg(). However, the concept of aggregation
* applies to any process that must evaluate a group of entries to
* come up with a single answer.
*/
public interface EntryAggregator
extends Serializable
{
/**
* Process a set of InvocableMap Entry objects to produce an
* aggregated result.
*
* @param setEntries  a Set of read-only InvocableMap Entry objects to
*                    aggregate
*
* @return the aggregated result from processing the entries
*/
public Object aggregate(Set setEntries);
}

データ・グリッド内での効果的な実行には、集計処理のパラレル実行の設計が不可欠です。

例24-4 集計をパラレル実行するParallelAwareAggregator API

/**
* A ParallelAwareAggregator is an advanced extension to EntryAggregator
* that is explicitly capable of being run in parallel, for example in a
* distributed environment.
*/
public interface ParallelAwareAggregator
extends EntryAggregator
{
/**
* Get an aggregator that can take the place of this aggregator in
* situations in which the InvocableMap can aggregate in parallel.
*
* @return the aggregator that is run in parallel
*/
public EntryAggregator getParallelAggregator();

/**
* Aggregate the results of the parallel aggregations.
*
* @return the aggregation of the parallel aggregation results
*/
public Object aggregateResults(Collection collResults);
}

Coherenceには、次のような通常の集計関数がすべて備わっています。

- Count

- DistinctValues

- DoubleAverage

- DoubleMax

- DoubleMin

- DoubleSum

- LongMax

- LongMin

- LongSum

注意:
Coherenceに付属するすべてのアグリゲータは、パラレル実行に対応しています。

Coherenceアグリゲータの一覧は、com.tangosol.util.aggregatorパッケージを参照してください。独自のアグリゲータを実装する場合、AbstractAggregator抽象ベース・クラスを参照してください。

24.4 ノードベースの処理の実行

Coherenceには、グリッド内の任意の場所で単一パスのエージェント(起動可能なオブジェクトと呼ばれる)を実行できる起動サービスが用意されています。エージェントは、グリッドの特定のノードで実行したり、グリッドの特定のノード・セットでパラレル実行することができます。また、グリッドのすべてのノードでパラレル実行することもできます。

起動サービスは、キャッシュ構成ファイル<invocation-scheme要素を使用して構成します。サービスの名前を使用すると、アプリケーションはサービスへの参照を容易に取得できます。

InvocationService service = (InvocationService)CacheFactory.getService
("MyService");

エージェントは、アプリケーションの一部である簡単な実行可能クラスです。単純なエージェントの例は、JVMからGCをリクエストするように設計されたものです。

例24-5 ガベージ・コレクションをリクエストする単純なエージェント

/**
* Agent that issues a garbage collection.
*/
public class GCAgent
extends AbstractInvocable
{
public void run()
{
System.gc();
}
}

次のように、クラスタ全体でそのエージェントを実行するコードは1行で済みます。

service.execute(new GCAgent(), null, null);

次に、グリッド全体のリクエスト/レスポンス・モデルをサポートするエージェントの例を示します。

例24-6 グリッド全体のリクエスト・モデルおよびレスポンス・モデルをサポートするエージェント

/**
* Agent that determines how much free memory a grid node has.
*/
public class FreeMemAgent
extends AbstractInvocable
{
public void run()
{
Runtime runtime = Runtime.getRuntime();
int cbFree  = runtime.freeMemory();
int cbTotal = runtime.totalMemory();
setResult(new int[] {cbFree, cbTotal});
}
}

グリッド全体でそのエージェントを実行して、すべての結果を取得するのに必要なのも、次の1行のコードのみです。

Map map = service.query(new FreeMemAgent(), null);

グリッド全体のリクエストまたはレスポンスを実行するのは容易ですが、その結果を出力するには、より多くのコーディングが必要です。

例24-7 グリッド全体のリクエストまたはレスポンスからの結果の出力

Iterator iter = map.entrySet().iterator();
while (iter.hasNext())
{
Map.Entry entry  = (Map.Entry) iter.next();
Member    member = (Member) entry.getKey();
int[]     anInfo = (int[]) entry.getValue();
if (anInfo != null) // nullif member died
System.out.println("Member " + member + " has "
+ anInfo[0] + " bytes free out of "
+ anInfo[1] + " bytes total");
}

エージェントの操作はステートフルにすることができます。つまり、その起動状態をシリアライズして、エージェントを実行するグリッド・ノードに転送します。

例24-8 ステートフル・エージェントの操作

/**
* Agent that carries some state with it.
*/
public class StatefulAgent
extends AbstractInvocable
{
public StatefulAgent(String sKey)
{
m_sKey = sKey;
}

public void run()
{
// the agent has the key that it was constructed with
String sKey = m_sKey;
// ...
}

private String m_sKey;
}

24.5 ワーク・マネージャの使用

Coherenceは、CommonJワーク・マネージャのグリッド対応の実装を提供します。ワーク・マネージャを使用すると、アプリケーションで実行する必要がある作業コレクションを送信できます。ワーク・マネージャは、その作業がパラレル実行されるように分散します(通常は、グリッド全体に分散します)。つまり、送信された作業アイテムが10個あり、グリッドに10台のサーバーがあるとすると、各サーバーは1つの作業アイテムを処理することになります。さらに、グリッド内の作業アイテムの分散処理は調整できます。そのため、データの効率性および局所性を考慮して、特定の作業が指定したサーバー(たとえば、特定のメインフレーム・サービスのゲートウェイとして動作するサーバーなど)で最初に実行されるように選択できます。

アプリケーションは作業の完了を待機できますが、その待機時間のタイムアウトを設定することもできます。そのためのAPIは非常に強力なため、アプリケーションで最初の作業アイテムが完了するのを待機したり、指定された作業アイテム・セットが完了するのを待機することができます。このAPIのメソッドを組み合せると、たとえば「実行するアイテムが10個あり、その中の7個は重要でないため最大5秒間待機し、残りの3個の重要なアイテムは最大30秒間待機する」という処理が可能になります。

例24-9 ワーク・マネージャの使用

Work[] aWork = ...
Collection collBigItems = new ArrayList();
Collection collAllItems = new ArrayList();
for (int i = 0, c = aWork.length; i < c; ++i)
{
WorkItem item = manager.schedule(aWork[i]);

if (i < 3)
{
// the first three work items are the important ones
collBigItems.add(item);
}

collAllItems.add(item);
}

Collection collDone = manager.waitForAll(collAllItems, 5000L);
if (!collDone.containsAll(collBigItems))
{
// wait the remainder of 30 seconds for the important work to finish
manager.waitForAll(collBigItems, 25000L);
}

25 マップ・イベントの使用

この章では、マップ・イベント・リスナーを使用して、キャッシュ・イベントおよびCoherenceのObservableMapインタフェースを実装するいずれかのクラスからのイベントを受信する方法について説明します。

この章には次の項が含まれます:

- マップ・イベントの概要

- すべてのイベントのサインアップ

- MapListenerとしての内部クラスの使用

- キャッシュ用のMapListenerの構成

- 特定のIDのイベントのサインアップ

- イベントのフィルタリング

- Liteイベントの使用

- 問合せのリスニング

- 統合イベントの使用

- バッキング・マップ・イベントの使用

- 同期イベント・リスナーの使用

25.1 マップ・イベントの概要

Coherenceでは、JavaBeanイベント・モデルを使用してキャッシュ・イベントが提供されます。この実装によって、実際にクラスタ内のどこで変更が行われたのかに関係なく、アプリケーションはそれらが必要としているタイミングと場所でイベントを受信できます。JavaBeanモデルに精通している開発者であれば、複雑なクラスタであってもイベントに難無く対応できるはずです。

注意:
Coherenceには、ライブ・イベント・プログラミング・モデルも用意されています。ライブ・イベントでは、一般的なイベント・タイプのサポートが提供され、マップ・イベントのかわりに使用できます。ライブ・イベントの使用の詳細は、「ライブ・イベントの使用」を参照してください。

25.1.1 リスナー・インタフェースおよびイベント・オブジェクト

JavaBeansイベント・モデルには、すべてのリスナーで拡張する必要があるEventListenerインタフェースがあります。Coherenceには、MapListenerインタフェースが用意されており、これによりCoherenceキャッシュのデータが追加、変更または削除されたときにアプリケーション・ロジックでイベントを受信できます。

MapListenerインタフェースを実装するアプリケーション・オブジェクトは、アプリケーションのMapListener実装のインスタンスをaddMapListener()メソッドに渡すだけで、ObservableMapインタフェースを実装する任意のCoherenceキャッシュまたはクラスからイベントにサインアップできます。

MapListenerに渡されるMapEventオブジェクトは、イベントの発生元になったソース(ObservableMap)、イベントに関連付けられたID(キー)、そのIDに対するアクション(挿入、更新、削除)、古い値と新しい値など、発生したイベントについて必要なすべての情報を保持します。

MapListenerインタフェースとMapEventクラスの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

25.1.2 イベントの保証の理解

パーティション・キャッシュ・サービスは、通常の状況ではイベントが1回だけ配信されることを保証します。ただし、これが保証されない可能性のあるシナリオが2つあります。

- データ損失を引き起こすクラスタの突発障害(データを保持している2台のマシンの同時クラッシュなど)。この場合、PARTITION_LOSTイベントが、サーバー側のすべての登録済PartitionListenerインスタンスに出力されます。

- クライアントの切断。この場合、MEMBER_LEFTイベントが、クライアント側のすべての登録済MemberListenerインスタンスに出力されます。

25.1.3 イベントをサポートするキャッシュとクラス

すべてのCoherenceキャッシュには、ObservableMapが実装されます。実際に、すべてのCoherenceキャッシュで実装されるNamedCacheインタフェースは、ObservableMapインタフェースを拡張します。つまり、キャッシュが、ローカル、パーティション、ニア、レプリケートであるかどうか、また、リードスルー、ライトスルー、ライトビハインド、オーバーフロー、ディスク記憶域などを使用しているかどうかに関係なく、アプリケーションはサインアップして任意のキャッシュからイベントを受信できます。

注意:
キャッシュ・トポロジやサーバーの数に関係なく、また他のサーバーが変更している場合でも、これらのイベントはアプリケーションのリスナーに配信されます。

Coherenceキャッシュ(Coherenceキャッシュ・ファクトリを介して取得されたオブジェクト)に加えて、次のように、Coherenceでサポートされる他のいくつかのクラスでもObservableMapインタフェースが実装されます。

- ObservableHashMap

- LocalCache

- OverflowMap

- NearCache

- ReadWriteBackingMap

- AbstractSerializationCache、SerializationCacheおよびSerializationPagedCache

- WrapperObservableMap、WrapperConcurrentMapおよびWrapperNamedCache

25.2 すべてのイベントのサインアップ

イベントにサインアップするには、MapListenerインタフェースを実装するオブジェクトをObservableMapのaddMapListenerメソッドに渡します。例25-1は、addMapListenerメソッドを示しています。

例25-1 ObservableMap APIのメソッド

public void addMapListener(MapListener listener);
public void addMapListener(MapListener listener, Object oKey, boolean fLite);
public void addMapListener(MapListener listener, Filter filter, boolean fLite);

MapListener実装のサンプルを作成してみましょう。例25-2は、イベントを受信したときにそれぞれのイベントを出力するMapListener実装のサンプルを示しています。

例25-2 MapListener実装のサンプル

/**
* A MapListener implementation that prints each event as it receives
* them.
*/
public static class EventPrinter
extends Base
implements MapListener
{
public void entryInserted(MapEvent evt)
{
out(evt);
}

public void entryUpdated(MapEvent evt)
{
out(evt);
}

public void entryDeleted(MapEvent evt)
{
out(evt);
}
}

この実装を使用すると、任意のキャッシュからすべてのイベントを非常に簡単に出力できます(すべてのキャッシュでObservableMapインタフェースが実装されているため)。

cache.addMapListener(new EventPrinter());

ただし、後でリスナーを削除できるように、リスナーへの参照を保持する必要があります。

例25-3 リスナーへの参照の保持

Listener listener = new EventPrinter();
cache.addMapListener(listener);
m_listener = listener; // store the listener in a field

後でリスナーを削除するには、次のように処理します。

例25-4 リスナーの削除

Listener listener = m_listener;
if (listener != null)
{
cache.removeMapListener(listener);
m_listener = null; // clean up the listener field
}

ObservableMapインタフェースの各addMapListenerメソッドには、対応するremoveMapListenerメソッドがあります。リスナーを削除するには、そのリスナーの追加に使用したaddMapListenerメソッドに対応するremoveMapListenerメソッドを使用します。

25.3 MapListenerとしての内部クラスの使用

MapListenerとして使用する内部クラスを作成する場合、または1つか2つのイベント・タイプ(挿入、更新、または削除)のみをリスニングするMapListenerを実装する場合、AbstractMapListenerベース・クラスを使用できます。たとえば、例25-5の無名の内部クラスでは、キャッシュの挿入イベントのみを出力します。

例25-5 キャッシュの挿入イベントのみを出力する内部クラス

cache.addMapListener(new AbstractMapListener()
{
public void entryInserted(MapEvent evt)
{
out(evt);
}
});

MapListenerの作成に役立つもう1つのベース・クラスは、MultiplexingMapListenerです。これは、すべてのイベントを1つのメソッドにルーティングして処理します。このクラスを使用すると、EventPrinterのサンプルを例25-6のコードのように簡略化できます。1つのメソッドを実装するだけですべてのイベントを取得できるため、MultiplexingMapListenerは、MapListenerとして使用する内部クラスを作成する際にも非常に便利です。

例25-6 単一の処理メソッドへの全イベントのルーティング

public static class EventPrinter
extends MultiplexingMapListener
{
public void onMapEvent(MapEvent evt)
{
out(evt);
}
}

25.4 キャッシュ用のMapListenerの構成

特定のキャッシュにリスナーを常駐させる必要がある場合、<listener要素を使用して、それをキャッシュ構成に配置します。キャッシュ構成の際に、リスナーは自動的に追加されます。

25.5 特定のIDのイベントのサインアップ

特定のID(キー)に対して発生したイベントのサインアップは非常に簡単です。たとえば、整数キー5に対して発生したすべてのイベントを出力するには、次のように処理します。

cache.addMapListener(new EventPrinter(), new Integer(5), false);

そのため、例25-7のコードでは、整数キー5が挿入または更新された場合にのみイベントがトリガーされます。

例25-7 特定の整数キーが挿入または更新された場合のイベントのトリガー

for (int i = 0; i < 10; ++i)
{
Integer key   = new Integer(i);
String  value = "test value for key " + i;
cache.put(key, value);
}

25.6 イベントのフィルタリング

特定のキーのリスニングと同様に、特定のイベントをリスニングすることもできます。例25-8では、削除イベントのみを受信できるフィルタが指定されたリスナーがキャッシュに追加されます。

例25-8 削除されたイベントのフィルタを指定したリスナーの追加

// Filters used with partitioned caches must be
// Serializable, Externalizable or ExternalizableLite
public class DeletedFilter
implements Filter, Serializable
{
public boolean evaluate(Object o)
{
MapEvent evt = (MapEvent) o;
return evt.getId() == MapEvent.ENTRY_DELETED;
}
}

cache.addMapListener(new EventPrinter(), new DeletedFilter(), false);

注意:
イベントのフィルタリングとキャッシュされたデータのフィルタリングの比較
問合せのフィルタを作成する場合、Filterのevaluateメソッドに渡すオブジェクトはキャッシュからの値です。または、フィルタでEntryFilterインタフェースを実装する場合は、キャッシュからのMap.Entry全体です。MapListenerのイベントをフィルタリングするフィルタを作成する場合、フィルタのevaluateメソッドに渡すオブジェクトはMapEvent型です。

問合せフィルタを使用してキャッシュ・イベントをリスニングする方法の詳細は、「問合せのリスニング」を参照してください。

次の一連のコールを実行すると、

cache.put("hello", "world");
cache.put("hello", "again");
cache.remove("hello");

次のような結果になります。

CacheEvent{LocalCache deleted: key=hello, value=again}

詳細は、「問合せのリスニング」を参照してください。

25.7 Liteイベントの使用

デフォルトでは、イベントの一部として古い値と新しい値が両方とも提供されます。次の例があります。

例25-9 キャッシュにおける値の挿入、更新、削除

MapListener listener = new MultiplexingMapListener()
{
public void onMapEvent(MapEvent evt)
{
out("event has occurred: " + evt);
out("(the wire-size of the event would have been "
+ ExternalizableHelper.toBinary(evt).length()
+ " bytes.)");
}
};
cache.addMapListener(listener);

// insert a 1KB value
cache.put("test", new byte[1024]);

// update with a 2KB value
cache.put("test", new byte[2048]);

// remove the 2KB value
cache.remove("test");

例25-10に示すテストの実行結果の出力では、1つ目のイベントは挿入される値(1KB)を保持し、2つ目のイベントは置換前の値(1KB)と新しい値(2KB)を保持しています。3つ目のイベントは、削除される値(2KB)を保持しています。

例25-10 サンプル出力

event has occurred: CacheEvent{LocalCache added: key=test, value=[B@a470b8}
(the wire-size of the event would have been 1283 bytes.)
event has occurred: CacheEvent{LocalCache updated: key=test, old value=[B@a470b8, new value=[B@1c6f579}
(the wire-size of the event would have been 3340 bytes.)
event has occurred: CacheEvent{LocalCache deleted: key=test, value=[B@1c6f579}
(the wire-size of the event would have been 2307 bytes.)

アプリケーションでイベントに古い値と新しい値を両方とも含める必要がない場合、Liteイベントのみをリクエストして、そのように指定することができます。リスナーの追加時にLiteイベントをリクエストするには、追加のブール・パラメータfLiteを使用するaddMapListenerメソッドを使用できます。例25-9の場合は、次の箇所のみを変更します。

cache.addMapListener(listener, (Filter) null, true);

注意:
Liteイベントの古い値と新しい値は、NULLにすることができます。ただし、Liteイベントをリクエストしても、イベントの生成と配信に余分な負荷がかからない場合は、古い値と新しい値が含まれることがあります。つまり、MapListenerでLiteイベントを受信するようにリクエストしても、それは単にシステムにMapListenerがイベントの古い値と新しい値を認識する必要がないことを知らせているだけになります。

25.8 問合せのリスニング

すべてのCoherenceキャッシュはどの基準による問合せもサポートしています。アプリケーションがキャッシュのデータを問い合せると、その結果は一連の識別子(keySet)または一連の識別子と値の組合せ(entrySet)のいずれかとして、ポイント・イン・タイム・スナップショットで返されます。結果セットの内容を判断するメカニズムは、フィルタリングと呼ばれ、これによりアプリケーションの開発者は即時利用可能なフィルタ(equals、less-than、like、betweenなど)の豊富なセットを使用してどのように複雑な問合せも構築でき、また独自のカスタム・フィルタ(XPathなど)を提供できるようになります。

キャッシュの問合せに使用するフィルタと同じフィルタで、キャッシュからのイベントをリスニングできます。たとえば、取引システムにおいて、特定のトレーダーが受け持つ未決済のOrderオブジェクトをすべて問い合せることができます。

例25-11 キャッシュからのイベントのリスニング

NamedCache mapTrades = ...
Filter filter = new AndFilter(new EqualsFilter("getTrader", traderid),
new EqualsFilter("getStatus", Status.OPEN));
Set setOpenTrades = mapTrades.entrySet(filter);

そのトレーダーが新しいポジションを建てた、そのトレーダーがポジションを決済した、トレーダー間でポジションを付け替えた、という情報を受信するために、アプリケーションで同じフィルタを使用できます。

例25-12 オブジェクトのイベントのリスニング

// receive events for all trade IDs that this trader is interested in
mapTrades.addMapListener(listener, new MapEventFilter(filter), true);

MapEventFilterは、問合せフィルタをイベント・フィルタに変換します。

MapEventFilterには、いくつもの非常に強力なオプションがあります。これにより、アプリケーション・リスナーは特に関心のあるイベントのみを受信できます。スケーラビリティとパフォーマンスの観点からさらに重要なこととして、必要なイベントのみがネットワーク上で通信されるため、それらの特定イベントを対象とするサーバーとクライアントにのみ配信されます。例25-13は、これらのシナリオを示しています。

例25-13 MapEventFilterを使用した様々なイベントのフィルタリング

// receive all events for all trades that this trader is interested in
nMask = MapEventFilter.E_ALL;
mapTrades.addMapListener(listener, new MapEventFilter(nMask, filter), true);

// receive events for all this trader's trades that are closed or
// re-assigned to a different trader
nMask = MapEventFilter.E_UPDATED_LEFT | MapEventFilter.E_DELETED;
mapTrades.addMapListener(listener, new MapEventFilter(nMask, filter), true);

// receive events for all trades as they are assigned to this trader
nMask = MapEventFilter.E_INSERTED | MapEventFilter.E_UPDATED_ENTERED;
mapTrades.addMapListener(listener, new MapEventFilter(nMask, filter), true);

// receive events only fornew trades assigned to this trader
nMask = MapEventFilter.E_INSERTED;
mapTrades.addMapListener(listener, new MapEventFilter(nMask, filter), true);

サポートされる各種オプションの詳細は、MapEventFilterのAPIドキュメントを参照してください。

25.8.1 イベントのフィルタリングとキャッシュされたデータのフィルタリングの比較

問合せのFilterを作成する場合、Filterのevaluateメソッドに渡すオブジェクトはキャッシュからの値です。または、FilterでEntryFilterインタフェースを実装する場合は、キャッシュからのMap.Entry全体です。MapListenerのイベントをフィルタリングするFilterを作成する場合、Filterのevaluateメソッドに渡すオブジェクトはMapEvent型です。

MapEventFilterは、問合せに使用するFilterをMapListenerのイベントのフィルタリングに使用するFilterに変換します。つまり、MapEventFilterはキャッシュを問い合せるFilterから作成されますが、作成されたMapEventFilterは、問合せFilterが期待するオブジェクトに変換することによってMapEventオブジェクトを評価するフィルタになります。

25.9 統合イベントの使用

イベントは通常、キャッシュに対する変更を反映します。たとえば、あるサーバーがキャッシュ内の1つのエントリを変更し、別のサーバーがキャッシュに複数のアイテムを追加し、3つ目のサーバーが同じキャッシュから1つのアイテムを削除している間に、クラスタ内の各サーバーで50個のスレッドが同じキャッシュのデータにアクセスすることがあります。すべての変更操作によりイベントが生成されますが、それをクラスタ内の任意のサーバーで受信するように選択できます。これらの操作をクライアント・アクションと呼び、そのイベントは、クライアントにディスパッチされた状態にあります(この場合の「クライアント」が実際には「サーバー」であっても)。これはCoherenceクラスタなどの、真のpeer-to-peerアーキテクチャでは自然の概念です。いずれのピアもクライアントでありサーバーでもあるので、他のピアからサービスを受け、他のピアにサービスを提供します。一般的なJava Enterpriseアプリケーションでは、ピアはアプリケーションのコンテナとして動作するアプリケーション・サーバー・インスタンスで、クライアントは直接キャッシュに対してアクセスおよび変更を行い、キャッシュからのイベントをリスニングするアプリケーションの一部です。

イベントの中には、キャッシュ内部で起動されるものもあります。多くの例がありますが、最も一般的なケースは次のとおりです。

- キャッシュのエントリが自動失効した場合

- キャッシュの最大サイズに達したため、エントリがキャッシュから削除された場合

- リードスルー操作の結果としてエントリが透過的にキャッシュに追加された場合

- リードアヘッドまたはリフレッシュアヘッド操作の結果としてキャッシュ内のエントリが透過的に更新された場合

これらはそれぞれ変更の例ですが、この場合の変更とはキャッシュ内部での自然な(通常は自動的な)操作を表します。このようなイベントは統合イベントと呼ばれます。

必要に応じて、アプリケーションはイベントに問い合せて、それがクライアントに起因するイベントか、または統合イベントかを区別できます。この情報は、CacheEventというMapEventのサブクラスで保持されます。前述のEventPrinterの例を使用して、統合イベントのみを出力できます。

例25-14 統合イベントの判断

public static class EventPrinter
extends MultiplexingMapListener
{
public void onMapEvent(MapEvent evt)
{
if (evt instanceof CacheEvent && ((CacheEvent) evt).isSynthetic())
{
out(evt);
)
}
}

この機能の詳細は、CacheEventのAPIドキュメントを参照してください。

25.10 バッキング・マップ・イベントの使用

Coherenceキャッシュのイベントをリスニングし、データに関して分散、パーティション、レプリケート、ニア・キャッシュ、連続問合せ、リードスルー/ライトスルー、ライトビハインドのローカル表示を確認できる一方で、いわば「こっそりのぞき見る」こともできます。

いくつかの応用例の中には、サービスの背後でマップをリスニングする必要がある場合があります。分散環境でのレプリケーション、パーティション、およびその他のデータ管理方式は、いずれも分散サービスです。このサービスにはさらに実際にデータを管理するための機能が必要です。それが「バッキング・マップ」と呼ばれるものです。

バッキング・マップを構成できます。特定のキャッシュのすべてのデータを、ヒープのオブジェクト形式で保持する必要がある場合、無制限で失効期限のないLocalCache(統計が不要な場合はSafeHashMap)を使用します。メモリーに保持するアイテムの数が少ない場合は、LocalCacheを使用します。データを必要に応じてデータベースから読み取る場合は、ReadWriteBackingMapを使用します(アプリケーションのDAO実装を介した読取りおよび書込み方法を指定します)。ReadWriteBackingMapに、SafeHashMapやLocalCacheなどのバッキング・マップを提供してデータを保存します。

バッキング・マップの中には監視可能なものがあります。これらのバッキング・マップから取得されたイベントは、一般的にはアプリケーションに直接関係がありません。かわりに、Coherenceではそれらを(Coherenceで)実行する必要があるアクションに変換してデータを同期的に保持し正しくバックアップを行い、またアプリケーション・リスナーでのリクエストに応じてそれをクラスタ全体に配信されるクラスタ化されたイベントに変換します。たとえば、パーティション・キャッシュにバッキング・マップとしてLocalCacheがあり、ローカル・キャッシュでエントリが失効した場合、そのイベントによってエントリのすべてのバックアップ・コピーが失効します。さらに、リスナーがパーティション・キャッシュに登録されている場合、イベントがイベント・フィルタに適合すると、そのイベントはそのリスナーが登録されているサーバーのリスナーに配信されます。

応用例の中には、データが保持されているサーバー上のイベントをアプリケーションで処理する必要があるものや、それを実際にデータを管理している構造(バッキング・マップ)で行う必要があるものがあります。そのような場合、バッキング・マップが監視可能なマップであれば、リスナーをバッキング・マップに構成したり、プログラムによってリスナーをバッキング・マップに追加することができます。(バッキング・マップが監視可能でない場合、WrapperObservableMapでラップすることにより監視可能になります。)

各バッキング・マップ・イベントは、1回だけディスパッチされます。ただし、1つのputから複数のバッキング・マップ・イベントが生成されることがあります。たとえば、putからのエントリを再分散する必要がある場合、分散イベント(元のノードから削除され、新しいノードに挿入されるイベント)が作成されます。この場合、1つのputに対してバッキング・マップ・リスナーが複数回コールされます。

最後に、バッキング・マップ・リスナーは常に同期されます。バッキング・マップ・リスナーは、バッキング・マップ自身の同期化モニターを保持しつつ、変更操作を行うスレッドで起動されます。内部バッキング・マップ・リスナーでは多くの場合、イベントは即座には処理されませんが、キューに配置され、後で非同期に処理されます。

この機能の詳細は、BackingMapManagerのAPIドキュメントを参照してください。

25.10.1 分散キャッシュからの読取り可能なバッキングMapListenerイベントの生成

バッキングMapListenerイベントは、読取り可能なJavaフォーマットでレプリケート・キャッシュから返されます。ただし、分散キャッシュから返されたバッキングMapListenerイベントは、Coherenceの内部フォーマットになります。Coherence Incubator Commonプロジェクトには、分散キャッシュから読取り可能なバッキングMapListenerイベントから取得できるAbstractMultiplexingBackingMapListenerクラスが用意されています。Coherence Commonライブラリをダウンロードするには、http://coherence.oracle.com/display/INCUBATOR/Coherence+Commonを参照してください。

分散キャッシュからの読取り可能なバッキングMapListenerイベントを生成するには:

1. AbstractMultiplexingBackingMapListenerクラスを実装します。

2. cache-configファイルのbacking-map-schemeの<listener>セクションに実装を登録します。

3. Javaプロパティのcacheconfigで、キャッシュ・サーバー・アプリケーション・ファイルおよびクライアント・ファイルを開始します。

-Dtangosol.coherence.cacheconfig="cache-config.xml"

AbstractMultiplexingBackingMapListenerクラスには、onBackingMapEventメソッドが用意されています。これをオーバーライドしてイベントが返される方法を指定できます。

次のVerboseBackingMapListenerクラスの一覧は、AbstractMultiplexingBackingMapListenerのサンプルの実装です。onBackingMapEventメソッドは、結果を標準出力に送信するように上書きされています。

例25-15 AbstractMultiplexingBackingMapListener実装

import com.tangosol.net.BackingMapManagerContext;
import com.tangosol.util.MapEvent;

public class VerboseBackingMapListener extends AbstractMultiplexingBackingMapListener {

public VerboseBackingMapListener(BackingMapManagerContext context) {
super(context);
}

@Override
protected void onBackingMapEvent(MapEvent mapEvent, Cause cause) {

System.out.printf("Thread: %s Cause: %s Event: %s\n",
Thread.currentThread().getName(), cause, mapEvent);
}
}

例25-16は、分散スキーム定義の例です。ファイルの<listener>セクションで、VerboseBackingMapListenerは、com.tangosol.net.BackingMapManagerContextタイプとして識別されます。

例25-16 詳細バッキング・マップ・リスナーを指定する分散スキーム

<distributed-scheme>
<scheme-name>my-dist-scheme</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<read-write-backing-map-scheme>
<internal-cache-scheme>
<local-scheme>
<high-units>0</high-units>
<expiry-delay>0</expiry-delay>
</local-scheme>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<class-name>CustomCacheStore</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
<listener>
<class-scheme>
<class-name>VerboseBackingMapListener</class-name>
<init-params>
<init-param>
<param-type>com.tangosol.net.BackingMapManagerContext
</param-type>
<param-value>{manager-context}</param-value>
</init-param>
</init-params>
</class-scheme>
</listener>
</read-write-backing-map-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

25.11 同期イベント・リスナーの使用

イベントの中には、アプリケーション・リスナーがイベントを生成するキャッシュ・サービスを妨害しないように、非同期に配信されるものがあります。まれなケースですが、非同期配信では進行している処理の結果に比べてイベントの順序があいまいになる場合があります。クラスタ化システムのローカル表示が単一スレッドであるかのようにキャッシュAPI操作およびイベントの順序を保証するには、MapListenerでSynchronousListenerマーカー・インタフェースを実装する必要があります。

Coherence自体で同期リスナーを使用する例にニア・キャッシュがあります。これにより、ローカルでキャッシュされたデータを、イベントを使用して無効化できます(通称、Seppuku)。

この機能の詳細は、MapListenerSupport.SynchronousListenerのAPIドキュメントを参照してください。

26 トリガーを使用したマップ操作の制御

この章では、マップ・エントリに変更をコミットする前にマップ操作を検証、却下または変更するためのマップ・トリガーの使用方法について説明します。

この章には次の項が含まれます:

- マップ・トリガーの概要

- マップ・トリガーの例

26.1 マップ・トリガーの概要

マップ・トリガーは、Coherenceの標準機能を補助するもので、高度にカスタマイズされたキャッシュ管理システムを提供します。マップ・トリガーを使用すると、無効なトランザクションを回避したり、複雑なセキュリティ認証または複雑なビジネス・ルールを施行できます。また、透過的なイベント・ロギングや監査、データ変更の統計収集を行えます。トリガーのその他の用途には、キャッシュに対する操作を、アプリケーションの再デプロイメント時に発行されたものに制限することなどが挙げられます。

たとえば、NamedCacheの処理コードがあり、あるエントリの動作やコンテンツを、そのエントリがマップに挿入される前に変更するとします。マップ・トリガーを追加すると、既存のコードをすべて変更せずに、この変更を行うことができます。

マップ・トリガーは、アップグレード・プロセスの一環としても使用できます。マップ・トリガーを追加すると、挿入したエントリをキャッシュからキャッシュへ転用できます。

Coherenceキャッシュのマップ・トリガーは、データベースに適用されるトリガーに類似しています。これは、対応するマップ・エントリの保留中の変更(または削除)に応じて機能するMapTriggerインタフェースで表される機能エージェントです。保留中の変更は、MapTrigger.Entryインタフェースで表されます。このインタフェースは、InvocableMap.Entryインタフェースから継承され、基礎となるマップの値を取得、更新および削除するためのメソッドを提供します。

MapTriggerインタフェースには、マップ内の保留中の変更を検証、却下または変更する際に使用するprocessメソッドが備わっています。このメソッドは、基礎となるマップ・コンテンツの変更操作がコミットされる前にコールされます。このメソッドを実装すると、元の値と新しい値を分析することによって保留中の変更を評価し、次のいずれかの結果を得ることができます。

- リクエストされた変更を別の値でオーバーライドします。

- 元の値をリセットすることによって保留中の変更を元に戻します。

- 基礎となるマップからエントリを削除します。

- ランタイム例外をスローすることで保留中の変更を却下します。

- 何もせずに、保留中の変更のコミットを許可します。

MapTrigger機能は通常、アプリケーション起動プロセスの一環として追加されます。MapTrigger APIで説明しているようにプログラムで追加できるほか、coherence-cache-config.xml構成ファイルでclass-factoryメカニズムを使用して構成することもできます。この場合、MapTriggerは、対応するキャッシュの最初のCacheFactory.getCache(...)コール時に登録されます。例26-1は、createMapTriggerメソッドが新しいMapTriggerListener(new MyCustomTrigger());を返すことを前提としています。

例26-1 MapTriggerListener構成の例

<distributed-scheme>
...
<listener>
<class-scheme>
<class-factory-name>package.MyFactory</class-factory-name>
<method-name>createTriggerListener</method-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</listener>
</distributed-scheme>

Coherenceには、MapTrigger.EntryインタフェースとMapTriggerインタフェースの他に、FilterTriggerクラスとMapTriggerListenerクラスが用意されています。FilterTriggerは、汎用のMapTrigger実装であり、関連付けられているFilterによって保留中の変更が却下された場合に、事前定義された処理を実行します。FilterTriggerは、保留中の操作を却下するか、変更を無視してエントリの元の値をリストアするか、またはエントリ自体を基礎となるマップから削除します。

MapTriggerListenerは、特別な目的に使用するMapListener実装であり、MapTriggerを対応するNamedCacheに登録する際に使用します。例26-2では、MapTriggerListenerを使用してPersonMapTriggerを名前付きキャッシュPeopleに登録します。

例26-2 MapTriggerListenerでMapTriggerを名前付きキャッシュに登録

NamedCache person = CacheFactory.getCache("People");
MapTrigger trigger = new PersonMapTrigger();
person.addMapListener(new MapTriggerListener(trigger));

これらのAPIはcom.tangosol.utilパッケージ内にあります。これらのAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

26.2 マップ・トリガーの例

例26-3のコードは、マップ・トリガーとそのコール方法を示しています。PersonMapTriggerクラスでは、processメソッドを実装して、マップに配置する前のエントリが変更されています。この場合、Personオブジェクトの姓の属性が大文字に変換されます。その後、オブジェクトはエントリに返されます。

例26-3 MapTriggerクラス

...

public class PersonMapTrigger implements MapTrigger
{
public PersonMapTrigger()
{
}

public void process(MapTrigger.Entry entry)
{
Person person  = (Person) entry.getValue();
String sName   = person.getLastName();
String sNameUC = sName.toUpperCase();

if (!sNameUC.equals(sName))
{
person.setLastName(sNameUC);

System.out.println("Changed last name of [" + sName + "] to [" + person.getLastName() + "]");

entry.setValue(person);
}
}

// ---- hashCode() and equals() must be implemented

public boolean equals(Object o)
{
return o != null && o.getClass() == this.getClass();
}
public int hashCode()
{
return getClass().getName().hashCode();
}
}

例26-4のMapTriggerは、PersonMapTriggerをコールします。新しいMapTriggerListenerは、PersonMapTriggerをPeople NamedCacheに渡します。

例26-4 MapTriggerコールと名前付きキャッシュへの引渡し

...

public class MyFactory
{
/**
* Instantiate a MapTriggerListener for a given NamedCache
*/
public static MapTriggerListener createTriggerListener(String sCacheName)
{
MapTrigger trigger;
if ("People".equals(sCacheName))
{
trigger = new PersonMapTrigger();
}
else
{
throw IllegalArgumentException("Unknown cache name " + sCacheName);
}

System.out.println("Creating MapTrigger for cache " + sCacheName);

return new MapTriggerListener(trigger);
}

public static void main(String[] args)
{
NamedCache cache = CacheFactory.getCache("People");
cache.addMapListener(createTriggerListener("People"));

System.out.println("Installed MapTrigger into cache People");
}
}

27 ライブ・イベントの使用

この章では、ライブ・イベントについて説明し、イベント・インターセプタを使用してイベントが通知されるようにする方法を説明します。アプリケーションはライブ・イベントを使用して、クラスタ操作に対する反応をアプリケーション・ロジックで返します。

この章には次の項が含まれます:

- ライブ・イベントの概要

- ライブ・イベント・タイプの理解

- ライブ・イベントの処理

27.1 ライブ・イベントの概要

Coherenceでは、データ・グリッドに対する操作を実行する際にクラスタ内での拡張を可能にするイベント・プログラミング・モデルが提供されます。このモデルでは、監視可能なクラスタ操作の発生を表すイベントを使用します。現在サポートされているイベントは次のとおりです。

- パーティション・キャッシュ・イベント - キャッシュ内の一連のエントリに対して実行されている操作を表す一連のイベント。パーティション・キャッシュ・イベントには、エントリ・イベントとエントリ・プロセッサ・イベントの両方が含まれます。エントリ・イベントは、キャッシュのエントリの挿入、削除および更新に関連しています。エントリ・プロセッサ・イベントは、エントリ・プロセッサの実行に関連しています。

- パーティション・サービス・イベント - パーティション・サービスによって実行されている操作を表す一連のイベント。パーティション・サービス・イベントには、パーティション転送イベントとパーティション・トランザクション・イベントの両方が含まれます。パーティション転送イベントは、クラスタ・メンバー間のパーティションの移動に関連しています。パーティション・トランザクション・イベントは、複数のキャッシュにまたがる可能性がある変更に関連し、単一のリクエストのコンテキスト内で実行されます。

- ライフサイクル・イベント - ConfigurableCacheFactoryインスタンスのアクティブ化および破棄を表す一連のイベント。

アプリケーションは、イベントを使用するためにイベント・インターセプタを作成および登録します。イベント・インターセプタは、イベントを処理し、必要に応じて任意のカスタム・ロジックを実装します。イベントには、そのイベントの受信時に可変アクションを実行できるかどうかを制御する様々なルールがあります。

27.2 ライブ・イベント・タイプの理解

イベント・タイプは、クラスタ操作の監視可能な発生を表します。アプリケーションは、イベント・インターセプタを使用してイベントを処理し、イベント・タイプに基づいてどのアクションを実行するのかを決定します。この項では、サポートされている各イベント・タイプを、イベントが発生する機能領域に従って分類して説明します。

この項には、次のトピックが含まれます:

- パーティション・キャッシュ・イベントの理解

- パーティション・サービス・イベントの理解

- ライフサイクル・イベントの理解

27.2.1 パーティション・キャッシュ・イベントの理解

パーティション・キャッシュ・イベントは、キャッシュ内の一連のエントリに対して実行される操作を表します。パーティション・キャッシュ・イベントには、エントリ・イベント(EntryEvent)とエントリ・プロセッサ・イベント(EntryProcessorEvent)が含まれます。これらのイベントは、com.tangosol.net.events.partition.cacheパッケージ内で定義されます。

27.2.1.1 エントリ・イベント

エントリ・イベントは、キャッシュのエントリの挿入、削除および更新の操作を表します。プリコミット・エントリ・イベント(INSERTING、REMOVINGおよびUPDATING)は操作が実行される前に発生し、エントリに対する変更を許可します。エントリを変更する際は、次の事項が当てはまります。

- プリコミット・エントリ・イベントに対して登録されているイベント・インターセプタが同期して呼び出されます。

- 同時更新を防止するために、イベントの処理中は各エントリに対してロックが保持されます。

- 例外がスローされると、操作がコミットされなくなります。

ポストコミット・エントリ・イベント(INSERTED、REMOVEDおよびUPDATED)は、操作が実行された後に、イベントの発生と同じ順序で発生します。ポストコミット・イベントは、エントリがそれ以降変更できないことを示します。ポストコミット・エントリ・イベントのイベント・インターセプタは、非同期に処理されます。

表27-1は、エントリ・イベント・タイプを示しています。

表27-1 エントリ・イベント

イベント・タイプ

説明

INSERTING

1つ以上のエントリが、キャッシュに挿入されようとしていることを示します。

INSERTED

1つ以上のエントリが、キャッシュに挿入されたことを示します。

REMOVING

1つ以上のエントリが、キャッシュから削除されようとしていることを示します。

REMOVED

1つ以上のエントリが、キャッシュから削除されたことを示します。

UPDATING

1つ以上のエントリが、キャッシュで更新されようとしていることを示します。

UPDATED

1つ以上のエントリが、キャッシュで更新されたことを示します。

27.2.1.2 エントリ・プロセッサ・イベント

エントリ・プロセッサ・イベントは、一連のバイナリ・エントリに対するエントリ・プロセッサの実行を表します。プリコミット・エントリ・プロセッサ・イベント(EXECUTING)は、エントリ・プロセッサが実行される前に発生し、エントリ・プロセッサ・インスタンスに対する変更を許可します。エントリ・プロセッサを変更する際は、次の事項が当てはまります。

- プリコミット・エントリ・プロセッサ・イベントに対して登録されているイベント・インターセプタが同期して呼び出されます。

- エントリ・プロセッサは複数のスレッドで共有できます。したがって、エントリ・プロセッサを変更するときはスレッド・セーフティを確保してください。

- 同時更新を防止するために、イベントの処理中は各エントリに対してロックが保持されます。

- 例外がスローされると、エントリ・プロセッサが実行されなくなります。

ポストコミット・エントリ・プロセッサ・イベント(EXECUTED)は、エントリ・プロセッサが実行された後に、イベントの発生と同じ順序で発生します。ポストコミット・イベントは、エントリがそれ以降変更できないことを示します。ポストコミット・エントリ・プロセッサ・イベントのイベント・インターセプタは、非同期に処理されます。

表27-2は、エントリ・プロセッサ・イベント・タイプを示しています。

表27-2 エントリ・プロセッサ・イベント

イベント・タイプ

説明

EXECUTING

エントリ・プロセッサが、一連のエントリに対して実行されようとしていることを示します。

EXECUTED

エントリ・プロセッサが、一連のエントリに対して実行されたことを示します。

27.2.2 パーティション・サービス・イベントの理解

パーティション・サービス・イベントは、パーティション・サービスによって実行されている操作を表します。パーティション・サービス・イベントには、転送イベント(TransferEvent)とトランザクション・イベント(TransactionEvent)が含まれます。これらのイベントは、com.tangosol.net.events.partitionパッケージ内で定義されます。

27.2.2.1 転送イベント

パーティション・サービス転送イベントは、記憶域が有効なメンバー間のパーティションの転送を表します。イベントには、転送が実行されるサービス名、パーティションID、転送に関与するクラスタ・メンバー、およびキャッシュ名とエントリのマップが含まれています。これらのエントリは変更できません。

注意:
転送イベントは、転送されるパーティションに対する操作をすべてブロックするロックが、そのパーティションに対して保持されている間に発生します。

表27-3は、遷移イベント・タイプを示しています。

表27-3 遷移イベント

イベント・タイプ

説明

DEPARTING

一連のエントリが、現在のメンバーから転送中であることを示します。

ARRIVED

一連のエントリが、現在のメンバーに転送されたこと、または現在のメンバーによってリストアされたことを示します。

27.2.2.2 トランザクション・イベント

パーティション・サービス・トランザクション・イベントは、単一のサービス・リクエストのコンテキストで行われる、(場合によっては複数のキャッシュからの)バイナリ・エントリに対する変更を表します。プリコミット・トランザクション・イベント(COMMITTING)は、操作が実行される前に発生し、エントリに対する変更を許可します。エントリを変更する際は、次の事項が当てはまります。

- 同時更新を防止するために、イベントの処理中は各エントリに対してロックが保持されます。

- 例外がスローされると、操作がコミットされなくなります。

ポストコミット・トランザクション・イベント(COMMITTED)は、操作が実行された後に発生します。ポストコミット・イベントは、エントリがそれ以降変更できないことを示します。

表27-4は、トランザクション・イベント・タイプを示しています。

表27-4 トランザクション・イベント

イベント・タイプ

説明

COMMITTING

エントリが、それぞれのキャッシュに挿入されようとしていることを示します。

COMMITTED

エントリが、それぞれのキャッシュに挿入されたことを示します。

27.2.3 ライフサイクル・イベントの理解

ライフサイクル・イベント(LifecycleEvent)は、ConfigurableCacheFactoryインスタンスに対して発生したアクションを表します。これらのイベントは、com.tangosol.net.events.applicationパッケージ内で定義されます。

ACTIVATEDイベントは、キャッシュ・ファクトリに関連付けられているすべてのサービスが起動された後に発生します。これらのサービスはキャッシュ構成ファイル内で定義され、自動的に起動されるように構成する必要があります。DISPOSINGイベントは、すべてのサービスが停止されて、すべてのリソースが解放される前に発生します。DISPOSINGイベントを処理するイベント・インターセプタは、サービスが停止される前に通知を受け取ります。ConfigurableCacheFactoryインスタンスのアクティブ化および破棄は1回のみ行うことができます。

注意:
ライフサイクル・イベントは、ConfigurableCacheFactory実装でライフサイクル・メソッドをコールするスレッドと同じスレッドによって、イベント・インターセプタにディスパッチされます。このスレッドは同期化されることがあります。イベント・インターセプタは、同じConfigurableCacheFactoryオブジェクトで、生成されたスレッドが同期化を行わないようにする必要があります。

表27-5は、ライフサイクル・イベント・タイプを示しています。

表27-5 ライフサイクル・イベント

イベント・タイプ

説明

ACTIVATED

ConfigurableCacheFactoryインスタンスがアクティブであることを示します。

DISPOSING

ConfigurableCacheFactoryインスタンスが破棄されようとしていることを示します。

27.3 ライブ・イベントの処理

アプリケーションは、イベント・インターセプタを使用してライブ・イベントを処理します。インターセプタは、どのイベントを受信するか、どのアクションを実行するのか(実行するアクションがある場合)を明示的に定義します。特定のキャッシュに対して、または特定のパーティション・サービスによって管理されるすべてのキャッシュに対して、任意の数のイベント・インターセプタを作成し、登録できます。同じイベント・タイプに対して登録されている複数のインターセプタは、自動的に連鎖され、1つのイベントのコンテキストで実行されます。

この項には次のトピックが含まれます:

- イベント・インターセプタの作成

- イベントのスレッディングの理解

- イベント・インターセプタの登録

- イベント・インターセプタの連鎖

27.3.1 イベント・インターセプタの作成

イベント・インターセプタを作成するには、EventInterceptorインタフェースを実装します。インタフェースはジェネリクスを使用して定義し、このインタフェースにより、汎用タイプのイベントをタイプ・パラメータとして指定してイベントをサブスクライブできるようになります。継承されたonEventメソッドは、イベントの受信時に必要な処理を実行する機能を提供します。EventInterceptor APIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。次の例は、すべての転送イベントをサブスクライブするもので、例27-1からの抜粋です。

public class RedistributionInterceptor
implements EventInterceptor<TransferEvent>

public void onEvent(TransferEvent event)
{
...

@Interceptor注釈を使用すると、イベントを特定のイベント・タイプにさらに制限でき、インターセプタのさらなる構成も可能です。次の例では、インターセプタ識別子を定義し、イベントを転送のDEPARTINGイベントのみに制限します。

@Interceptor(identifier = "redist", transferEvents = TransferEvent.Type.DEPARTING)
public class RedistributionInterceptor
implements EventInterceptor<TransferEvent>

public void onEvent(TransferEvent event)
{
...

@Interceptor注釈には、次の属性が含まれます。

- identifier - インターセプタの一意の識別子を指定します。識別子は、キャッシュ構成ファイルでインターセプタ・クラスを登録するときにオーバーライドできます。この属性はオプションです。この属性を省略した場合は、イベント・インフラストラクチャによって一意の名前が自動的に生成されます。

- entryEvents - インターセプタがサブスクライブするエントリ・イベント・タイプの配列を指定します。

- entryProcessorEvents - インターセプタがサブスクライブするエントリ・プロセッサ・イベント・タイプの配列を指定します。

- transferEvents - インターセプタがサブスクライブする転送イベント・タイプの配列を指定します。

- transactionEvents - インターセプタがサブスクライブするトランザクション・イベント・タイプの配列を指定します。

- order - このインターセプタを、インターセプタの連鎖の前に配置するかどうかを指定します。「イベント・インターセプタの連鎖」を参照してください。有効な値はLOWとHIGHです。HIGHの値は、そのインターセプタを、インターセプタの連鎖の前に配置することを示します。LOWの値は、順序付けのプリファレンスはないことを示します。デフォルト値はLOWです。この順序は、キャッシュ構成ファイルでインターセプタ・クラスを登録するときにオーバーライドできます。

次の例は、すべての転送イベント・タイプ(DEPARTINGとARRIVEDの両方)をサブスクライブする基本的なイベント・インターセプタの実装を示しています。onEventメソッドは、単にパーティション・アクティビティを示すイベントを記録します。この例は、Coherenceの例の一部です。

注意:
イベント・インスタンスは不変であり、それらのライフサイクルは基礎となるシステムによって制御されます。イベント・クラスの参照は、onEvent()メソッドの複数の呼出しにわたって保持しないでください。

例27-1 イベント・インターセプタの実装例

package com.tangosol.examples.events;
import com.tangosol.net.CacheFactory;
import com.tangosol.net.events.EventInterceptor;
import com.tangosol.net.events.annotation.Interceptor;
import com.tangosol.net.events.partition.TransferEvent;

@Interceptor(identifier = "redist")
public class RedistributionInterceptor
implements EventInterceptor<TransferEvent>
{

public void onEvent(TransferEvent event)
{
CacheFactory.log(String.format("Discovered event %s for partition-id %d
from remote member %s\n", event.getType(), event.getPartitionId(),
event.getRemoteMember()), CacheFactory.LOG_INFO);
}
}

27.3.2 イベントのスレッディングの理解

イベント・インターセプタは、キャッシュ操作に大きな影響を与えることがあるため、基礎となるスレッドをブロックしないように注意してください。そのようにしないとそれらに影響を与えます。イベント・インターセプタを作成する場合は、プリコミット・イベント・タイプとポストコミット・イベント・タイプの両方に対する影響を注意深く考慮する必要があります。

注意:
EventInterceptorインスタンスは再利用できますが、複数のスレッドが同時にディスパッチできるように、それらのインスタンスは不変であるかスレッド・セーフである必要があります。

プリコミット・イベント

プリコミット・イベント・タイプは、キャッシュにエントリがコミットされる前に、イベント・インターセプタにエントリを変更することを許可します。インターセプタは、同期的に処理されるため、実行時間の長い操作(データベース・アクセスなど)を実行しないでください。それによってキャッシュ操作がブロックされたり遅くなることがあります。外部リソースの呼出しは、キャッシュ操作がブロックされるのを防ぐために常にできるかぎり速く返す必要があります。

イベント・インターセプタによってプリコミット・イベントを処理する場合は、パーティション・サービスのスレッド・プールを構成します。スレッド・プールはデフォルトで無効になっており、分散キャッシュ定義内で<thread-count>要素を設定する必要があります。<thread-count>要素の詳細は、「distributed-schemeのサブ要素」を参照してください。スレッド・プールによって、キャッシュ操作を処理する追加のスレッドが作成され、プリコミット・イベントを処理するイベント・インターセプタによる全体的な影響が軽減されますが、ブロックされる可能性は依然として存在します。

ポストコミット・イベント

ポストコミット・イベントは、イベント・インターセプタによるエントリの変更を許可しません。そのイベントは、イベントの発生と同じ順序で発生し、インターセプタは非同期で処理されます。実行時間の長い操作を実行するイベント・インターセプタは、リクエストのバックログを発生させる場合があり、それによって最終的にパフォーマンスが低下することがあります。ベスト・プラクティスは、Java Executorサービスを使用してそのような操作を別のスレッドで実行することです。

27.3.3 イベント・インターセプタの登録

イベント・インターセプタは、キャッシュ構成ファイル内に登録されます。イベント・インターセプタは、特定のキャッシュまたはパーティション・サービスのいずれかに対して登録されます。特定のキャッシュに対して登録されたイベント・インターセプタは、そのキャッシュに関連するイベントのみを受信します。パーティション・サービスに対して登録されたイベント・インターセプタは、そのサービスによって管理されるキャッシュすべてのイベントを受信します。

注意:
サービスレベルのイベント(転送イベントやトランザクション・イベントなど)のイベント・インターセプタは、パーティション・サービスに対して登録する必要があり、特定のキャッシュに制限することはできません。

この項には次のトピックが含まれます:

- 特定のキャッシュに対するイベント・インターセプタの登録

- パーティション・サービスに対するイベント・インターセプタの登録

- キャッシュ構成ファクトリに対するイベント・インターセプタの登録

- カスタム登録の使用

- イベント・インターセプタの登録のガイドライン

27.3.3.1 特定のキャッシュに対するイベント・インターセプタの登録

特定のキャッシュに対してインターセプタを登録するには、任意の数の<interceptor>サブ要素を含む<interceptors>要素を<cache-mapping>要素内に含めます。各<interceptor>要素には、<instance>サブ要素を含め、EventInterceptorインタフェースを実装する完全修飾クラス名を指定する必要があります。<interceptor>要素の詳細なリファレンスについては、「interceptor」を参照してください。次の例では、MyInterceptorというイベント・インターセプタ・クラスを登録します。

<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
<interceptors>
<interceptor>
<name>MyInterceptor</name>
<instance>
<class-name>
com.tangosol.examples.events.MyInterceptor
</class-name>
</instance>
</interceptor>
</interceptors>
</cache-mapping>
</caching-scheme-mapping>

27.3.3.2 パーティション・サービスに対するイベント・インターセプタの登録

パーティション・サービスに対してインターセプタを登録するには、任意の数の<interceptor>サブ要素を含む<interceptors>要素を<distributed-scheme>要素内に含めます。各<interceptor>要素には、<instance>サブ要素を含め、EventInterceptorインタフェースを実装する完全修飾クラス名を指定する必要があります。<interceptor>要素の詳細なリファレンスについては、「interceptor」を参照してください。次の例では、例27-1で定義したRedistributionInterceptorクラスを登録します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>PartitionedService1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
<interceptors>
<interceptor>
<name>MyInterceptor</name>
<instance>
<class-name>
com.tangosol.examples.events.RedistributionInterceptor
</class-name>
</instance>
</interceptor>
</interceptors>
</distributed-scheme>

27.3.3.3 キャッシュ構成ファクトリに対するイベント・インターセプタの登録

ConfigurableCacheFactoryインスタンスに対してインターセプタを登録するには、任意の数の<interceptor>サブ要素を含む<interceptors>要素を<cache-config>要素内に含めます。各<interceptor>要素には、<instance>サブ要素を含め、EventInterceptorインタフェースを実装する完全修飾クラス名を指定する必要があります。<interceptor>要素の詳細なリファレンスについては、「interceptor」を参照してください。次の例では、MyInterceptorというイベント・インターセプタ・クラスを登録します。

<cache-config>
<interceptors>
<interceptor>
<name>MyInterceptor</name>
<instance>
<class-name>com.tangosol.examples.events.MyInterceptor</class-name>
</instance>
</interceptor>
</interceptors>
...
</cache-config>

27.3.3.4 カスタム登録の使用

@Interceptor注釈および汎用タイプは、イベント・インフラストラクチャがイベント・インターセプタを適切なイベント・ディスパッチャに登録するために使用されます。このメカニズムは、ほとんどのユースケースでは問題ありません。ただし、高度なユースケースでは、イベント・インターセプタはEventDispatcherAwareInterceptorインタフェースを実装するように選択できるため、必要なイベント・ディスパッチャにイベント・インターセプタを手動で登録します。

introduceEventDispatcherメソッドには、インターセプタが登録されるイベント・ディスパッチャが含まれます。さらに必要に応じて、ディスパッチャのメソッドを使用して、インターセプタの追加および削除、特定のイベント・タイプの制限、およびインターセプタの構成を行います。次の例は、インターセプタを明示的に登録して、エントリのINSERTINGイベントをサブスクライブし、インターセプタが最初にコールされて通知されるように順序付けを構成するカスタム実装を示しています。

public void introduceEventDispatcher(String sIdentifier, EventDispatcher
dispatcher)
{
dispatcher.addEventInterceptor(sIdentifier, this,
new HashSet(Arrays.asList(EntryEvent.Type.INSERTING)), true);
}

注意:
インターセプタが注釈を使用しないで構成されている場合、キャッシュ構成ファイルを使用してその構成をオーバーライドすることはできません。

インターセプタは、InterceptorRegistry APIを使用してプログラムによって登録することもできます。インターセプタを登録すると、現在登録されているイベント・ディスパッチャと将来のイベント・ディスパッチャのすべてにそのインターセプタが導入されます。インターセプタは、前述の例に示したようにintroduceEventDispatcherメソッドを使用して、ディスパッチャにバインドするかどうかを決定できます。

InterceptorRegistry APIはConfigurableCacheFactoryインタフェースから使用でき、getInterceptorRegistryメソッドを使用してコールします。このAPIは、宣言でインターセプタを登録するときのキャッシュ構成ファイルとあわせて使用できます。このAPIは、プログラムによってインターセプタを追加するためにカスタムDefaultCacheServer実装と一緒によく使用され、InvocationServiceインタフェースを使用する場合にインターセプタを選択によって登録するために使用されます。次の例では、インターセプタを登録します。

CacheFactory.getConfigurableCacheFactory().getInterceptorRegistry()
.registerEventInterceptor(new MyEventIntercepor());

27.3.3.5 イベント・インターセプタの登録のガイドライン

インターセプタは、同じサービスに対して複数の分散スキームで登録できます。また、分散スキームがスキーム参照を使用する場合、インターセプタ・クラスを継承できます。いずれの場合も、インターセプタ・クラスはサービスに登録されます。

ほとんどの場合、複数のインターセプタ・クラスを登録しても問題はありません。ただし、特定のサービスに対して同じインターセプタ・クラスおよび識別子名の重複が発生する可能性が高くなります。重複によって登録エラーが発生しないように、次のガイドラインに従ってください。

- 識別子名が一意であるか、識別子名を定義しない場合は、1つの分散スキームや同じサービスの複数のスキームでインターセプタ・クラスを複数回複製できます。後者の場合は、イベント・インフラストラクチャによって一意の名前が自動的に生成されます。

- 同じ識別子名のインターセプタ・クラスは(複製したものもそうでないものも)分散スキームで複数回登録することはできず、登録エラーが発生します。

- スキーム参照によって継承されたインターセプタ・クラスは、参照の連鎖内で異なるサービス名ごとに1回ずつ登録されます。

27.3.4 イベント・インターセプタの連鎖

同じイベント・タイプに対して登録されている複数のイベント・インターセプタは、イベントのディスパッチを行うスレッドによってシリアルにコールされます。この方法でインターセプタを連鎖する機能により、カスタム・ロジックが連鎖内の他のインターセプタの結果に基づいて実行される複雑な処理シナリオが可能になります。連鎖ないの各イベント・インターセプタは次のことを実行できます。

- イベントと関連付けられているデータを変更すること(許可されている場合)。たとえば、 INSERTING、UPDATING、REMOVINGなどのエントリ・イベントのプリコミット操作によってデータを変更できます。

- 例外をスローしてプリコミット操作を拒否すること。

- パーティションレベルのトランザクションに新しいエントリを参加させること。

- 連鎖内の後続のイベント・インターセプタによる副作用の結果を監視すること。インターセプタ連鎖がプリコミット記憶域イベントと関連付けられている場合、結果を監視する機能により、処理を拒否するための2番目の機会が提供されます。
後続のイベント・インターセプタの副作用の監視は、Event.nextInterceptorメソッドを使用して実行します。このメソッドが返されたとき、それは後続のイベント・インターセプタがすべて実行され、そのイベントに関連付けらている状態に対する変更をインターセプトできることを示します。Eventオブジェクトは、イベントの処理に関する状態を保持します。イベントは、連鎖内にイベント・インターセプタが存在するかぎり、各イベント・インターセプタのonEventメソッドをコールします。イベント・インターセプタ自体がEvent.nextInterceptorメソッドをコールする場合、連鎖内の次のイベント・インターセプタが起動されて実行されます。イベント・インターセプタが返されると、イベント自体が連鎖内の次のイベント・インターセプタのonEventメソッドをトリガーします。どちらの場合も、すべてのイベント・インターセプタが実行されますが、nextInterceptorメソッドをコールすることを選択すると、発生した副作用に基づいてアクションを実行するオプションがあります。

27.3.4.1 イベント・インターセプタの連鎖順序の指定

連鎖内のイベント・インターセプタは、登録された順序に基づいて実行されます。@Interceptor注釈のorder属性を使用して、インターセプタを連鎖の前に配置するかどうかを指定します。HIGHの値では、そのインターセプタが連鎖の前に配置されます。LOWの値は、デフォルト値であり、順序付けのプリファレンスはないことを示します。例:

@Interceptor(identifier = "MyInterceptor",
entryEvents = {Type.INSERTING, Type.INSERTED}
order = Order.HIGH)
public class MyInterceptor
implements EventInterceptor<EntryEvent>
...

順序は、キャッシュ構成ファイルでイベント・インターセプタを登録するときに宣言で指定することもでき、それによってイベント・インターセプタ・クラスで指定されているorder属性がオーバーライドされます。

キャッシュ構成ファイルでインターセプタの順序を指定するには、<interceptor>要素内に、HIGHまたはLOWに設定した<order>要素を含めます。例:

<interceptors>
<interceptor>
<name>MyInterceptor</name>
<order>HIGH</order>
<instance>
<class-name>package.MyInterceptor</class-name>
</instance>
</interceptor>
<interceptor>
<name>MySecondInterceptor</name>
<instance>
<class-name>package.MySecondInterceptor</class-name>
</instance>
</interceptor>
</interceptors>

28 Coherenceの問合せ言語の使用

この章では、Coherenceの問合せ言語(CohQL)を使用してCoherenceキャッシュと相互作用する方法について説明します。CohQLは、軽量な構文(SQLに似た)で、Coherenceクラスタ上でキャッシュ操作を実行するのに使用します。この言語は、プログラムからでも、コマンド行ツールからでも使用できます。

この章には次の項が含まれます:

- Coherenceの問合せ言語構文の理解

- CohQLコマンド行ツールの使用

- Javaプログラムにおけるフィルタの作成

- その他のCoherenceの問合せ言語の例

注意:

- CohQL構文はSQLによく似ているように見えますが、この構文はSQLではなく、実際には文脈的にJava Persistence問合せ言語(JPQL)の標準の方に関連している点に注意してください。

- 連続問合せ言語(CQL: Continuous Query Language)は、複合イベント処理(CEP: Complex Event Processing)に関連した問合せ言語です。CohQLと混同しないようにしてください。

28.1 Coherenceの問合せ言語構文の理解

次の各項では、CohQLの機能について説明します。各項では、特に記述文、その構文、および例について説明します。問合せの例は、「その他のCoherenceの問合せ言語の例」を参照してください。

注意:
CohQLでは、副問合せはサポートされません。

この項には次のトピックが含まれます:

- 問合せ構文の基本

- データの取得

- キャッシュのライフサイクルの管理

- キャッシュ・データの処理

- 索引の処理

- 複数の問合せ文の発行

- 問合せのコストと効果の表示

詳細は、Coherence問合せ文、句、式をアルファベット順に示している表28-1を参照してください。

表28-1 Coherenceの問合せ言語の文

この文、句、または式

参照先の項

BACKUP CACHE

キャッシュのシリアライズ表現のファイルへの書込み

バインド変数

バインド変数の使用

CREATE CACHE

キャッシュの作成

CREATE INDEX

キャッシュ上での索引の作成

DELETE

キャッシュ内のエントリの削除

DROP CACHE

クラスタからのキャッシュの削除

DROP INDEX

キャッシュからの索引の削除

ENSURE CACHE

キャッシュの作成

ENSURE INDEX

キャッシュ上での索引の作成

GROUP BY

問合せ結果の集計

INSERT

キャッシュ内へのエントリの挿入

key()擬似関数

KeyおよびValue擬似関数の使用

パス式

パス式の使用

RESTORE CACHE

キャッシュの内容のファイルからのロード

SELECT

キャッシュからのデータの取得

SOURCE

問合せ文のバッチ・モードでの処理

UPDATE

既存の値の変更

value()擬似関数

KeyおよびValue擬似関数の使用

WHERE

エントリの結果セットでのフィルタリング

28.1.1 問合せ構文の基本

この項では、構文の一部の構成要素(パス式、バインド変数、擬似関数など)について説明します。

28.1.1.1 パス式の使用

CohQLのメインの構成要素にパス式があります。パス式は、オブジェクトのインスタンスのグラフを介して移動する際に使用されます。パス式の識別子を使用して、Java Bean感覚でプロパティを表現します。これは、先頭にgetを付加し、最初の文字を大文字にして作成される、ReflectionExtractorによってバッキングされます。各要素は「ドット」(.)文字で区切られ、オブジェクトのトラバースを表現しています。たとえば、次のパス式はオブジェクト構造を移動するのに使用します。

a.b.c

これは反射的に次のメソッドを起動します。

getA().getB().getC()

28.1.1.2 バインド変数の使用

プログラム的に使用する場合には、APIは文字列を単純な一連の問合せ関数に渡します。文字列連結を行わずに変数の値を渡すには、バインド変数を使用します。バインド変数には、2つの異なる形式があります。

- 疑問符(?): 疑問符を入力する場所は、位置を示すプレースホルダーを表す数字の直後です。このプレースホルダーにより、問合せを実行する前に提供されたオブジェクトのコレクションの索引が作成されます。この形式の構文は、?nで、この場合nに任意の数字を使用できます。位置を示すバインド変数は、フィルタの構成でQueryHelperクラスによって使用されます。例:

QueryHelper.createFilter("number = ?1" , new Object[]{new Integer(42)};

- コロン(:): コロンを入力する場所は、キー値のペアとして提供されるオブジェクトの名前付きプレースホルダーとして使用される識別子の直後です。この構文は、:identifierで、この場合identifierは英数字の組合せで、アルファベット文字で開始します。名前付きのバインド変数は、フィルタの構成でQueryHelperクラスによって使用されます。例:

HashMap env = new HashMap();
env.put("iNum",new Integer(42));
QueryHelper.createFilter("number = :iNum" , env};

QueryHelperクラスとフィルタのプログラム的な構成の詳細は、「Javaプログラムにおけるフィルタの作成」を参照してください。

28.1.1.3 KeyおよびValue擬似関数の使用

多くのユーザーがオブジェクトをkeyプロパティで格納するため、CohQLでは、key()擬似関数が用意されています。key()はキャッシュのキーを表しています。問合せ構文でもvalue()擬似関数が用意されています。value()は、key()で開始されない連鎖内では暗黙的です。key()擬似関数とvalue()擬似関数は、通常、WHERE句で使用され、この句ではキーやキャッシュ・エントリの値がテストされます。key()とvalue()の使用例は、「KeyおよびValue擬似関数の例」および「コマンド行の例」を参照してください。

28.1.1.4 別名の使用

意味的には必要はありませんが、CohQLはコード・アーティファクトをできるだけJPQLへ移植できるようにするために別名をサポートしています。CohQLは、キャッシュ名と、SELECTコマンド、UPDATEコマンド、DELETEコマンドのドット付きパス式の先頭に続く別名をサポートします。CohQLでは、キャッシュの別名をvalue()擬似関数の代用およびkey()擬似関数に対する引数として使用することも可能です。

28.1.1.5 リテラル引数での引用符の使用

通常、リテラル引数(cache-nameまたはservice-nameなど)を引用符で囲む必要はありません。引数に演算子(-、+、.、<、>、=など)や空白が含まれる場合にのみ、引用符(一重または二重)が必要となります。

ファイル名も引用符で囲む必要があります。ファイル名には、通常、パス・セパレータ(/または\)およびドットが含まれ、名前が拡張子から区切られます。

コンパイラがunquotedリテラル引数、または問題のある文字が含まれるファイル名を発生する場合には、コンパイラはエラーをスローします。

28.1.2 データの取得

次の項では、SELECT文およびWHERE句について説明します。これらのエンティティは、ほとんどのキャッシュ問合せの基本的な構成要素です。

28.1.2.1 キャッシュからのデータの取得

SELECT文は、問合せの基本的な構成要素で、キャッシュからデータを取得します。句は、単純なまたは複雑なパス表現、主要な式、変形関数、複数の式、集計関数などのいくつかの形式を取ることができます。SELECT文は、別名の使用もサポートします。

SELECT文の形式は、次のとおりです。

SELECT (properties* aggregators* | * | alias)
FROM "cache-name" [[AS] alias]
[WHERE conditional-expression] [GROUP [BY] properties+]

アスタリスク(*)文字は、サブパスのかわりに完全なオブジェクトを表します。cache-nameを持つパスを接頭辞として指定する必要はありません。SELECT文のFROM部分は、問合せによりその結果が引き出されるドメインを形成するキャッシュをターゲットとします。cache-nameは、既存のキャッシュの名前です。

その他の例は、「フィルタを強調表示する単純なSELECT * FROM文」を参照してください。

次に例を示します。

- キャッシュのdeptから項目を選択します。

select * from "dept"

28.1.2.2 エントリの結果セットでのフィルタリング

WHERE句を使用して、結果セットから返されるエントリをフィルタリングします。CohQLの主要機能の1つは、パス式を使用して、式の評価の際にオブジェクト構造を移動できることです。条件式では、論理演算子、比較式、フィールドのプリミティブおよび関数演算子などを使用できます。

WHERE句のリテラル構文では、一重引用符を使用して、文字列のリテラルを囲むことができます。その引用符の前に別の一重引用符を接頭辞にして、文字列内でエスケープできます。数式は、Javaプログラミング言語の表記規則に従って定義されます。ブール値は、リテラルのTRUEとFALSEで表されます。日付リテラルはサポートされていません。

注意:
CohQLには、型情報に対するアクセス権が付与されていません。ゲッターがリテラルのタイプとは異なる数値型を返した場合、比較の演算子のtrueを想定した部分にfalseを取得することがあります。これを回避するには、リテラルの型で、longにはlを、doubleにはdを、またshortにはsを指定します。デフォルト値は、ピリオド(.)なしのリテラルに対してはIntegerで、ピリオド(.)付きのリテラルに対してはFloatです。

WHERE句内の演算子の優先度は、次のとおりです。

1. パス演算子(.)

2. 単項の+および-

3. 乗算(*)および除算(/)

4. 足し算(+)および引き算(-)

5. 比較演算子: =、>、>=、<、<=、<>、[NOT] BETWEEN、[NOT] LIKE、[NOT] IN、IS [NOT] NULL、CONTAINS [ALL|ANY]

6. 論理演算子(AND、OR、NOT)

WHERE句は、言語レベルで算術のみをサポートします。

BETWEEN演算子を条件式で使用して、式の結果が値の包括範囲内に含まれるかどうかを判断できます。数値の式、または文字列の式は、この方法で評価できます。形式は、BETWEEN lower AND upperとなります。

LIKE演算子は、_および%のワイルドカードを使用できます。ワイルドカード_は正確に1文字と一致させるために使用され、ワイルドカード%は任意の文字のゼロ回以上の出現と一致させるために使用されます。ワイルドカードをエスケープするには、escapeキーワードを使用して定義されたエスケープ文字をワイルドカードの前に置きます。次の例では、k%1という名前のキーを選択するために、\エスケープ文字を使用してワイルドカード%をエスケープします。

SELECT key(),value() FROM mycache WHERE key() LIKE "k\%1" escape "\"

さらに、任意の文字をエスケープ文字として定義できます。例:

SELECT key(),value() FROM mycache WHERE key() LIKE "k#%1" escape "#"

IN演算子では、単一の値のパス式がコレクションのメンバーかどうかを確認できます。このコレクションは、インラインリストとして定義されているか、バインド変数として表されています。インラインリストの構文は、次のとおりです。

"(" literal* ")"

CONTAINS [ALL|ANY]は、Coherenceデータ・モデルで通常非正規化データが使用されるため、非常に便利な演算子です。CONTAINS演算子では、多値のパス式に指定した値が含まれているどうかを判断できます。例:

e.citys CONTAINS "Boston"

CONTAINSのALLおよびANY形式は、IN演算子と同じ構文を持つインラインリストまたはバインド変数となります。

注意:
Coherenceで用意されているプログラムのAPIを使用すると、WHERE句の条件式構文に基づいたスタンドアロンのCoherenceフィルタを作成できます。「Javaプログラムにおけるフィルタの作成」を参照してください。

その他の例は、「フィルタを強調表示する単純なSELECT * FROM文」を参照してください。

次に例を示します。

- キャッシュdept内のすべての項目を選択します。ここでは、deptnoキーの値が10になります。

select * from "dept" where deptno = 10

28.1.3 キャッシュのライフサイクルの管理

次の項では、キャッシュの作成と削除の方法を説明します。また、キャッシュの内容のバックアップとリストアの方法も説明します。

28.1.3.1 キャッシュの作成

問合せを送信する前に、それぞれCREATE CACHEまたはENSURE CACHE文を使用して、既存のキャッシュに接続するか、新規キャッシュを作成します。この文は、まず指定されたcache-nameでキャッシュへの接続を試行します。キャッシュがクラスタ内に見つからない場合は、現在のキャッシュ構成ファイルに基づいて指定された名前でキャッシュの作成が試行されます。この文は、コマンド行で特に有用です。この文をプログラムで使用している場合、名前の変わりにサービスとクラスローダーの情報を指定するオプションがあります(クラスローダーにはコマンド行からはアクセスできません)。

注意:
文では、キャッシュ名とサービス名を引用符(二重引用符(" ")または一重引用符(' '))で囲む必要があります。

構文は次のとおりです。

[ CREATE | ENSURE ] CACHE "cache-name"
[ SERVICE "service-name" ]

次に例を示します。

- deptという名前のキャッシュを作成します。

create cache "dept"

28.1.3.2 キャッシュのシリアライズ表現のファイルへの書込み

BACKUP CACHE文を使用して、指定されたキャッシュのシリアライズ表現を、指定されたfilenameで表示されたファイルに書き込みます。filenameは、オペレーティング・システム固有のパスであり、一重または二重引用符で囲む必要があります。BACKUP CACHE文は、コマンド行ツールでのみ使用できます。構文は次のとおりです。

BACKUP CACHE "cache-name" [ TO ] [ FILE ] "filename"

注意:
バックアップ(および後続のリストア)機能は、開発およびテスト環境で使用されるように設計されており、データの整合性を確認するプロビジョニングがないため、本番のデータ・セットでは使用しないでください。この機能は、本番のバックアップ、スナップショット、またはチェックポイント・ユーティリティとしてサポートされていません。
特に:

- バックアップは、クラスタ内のシングル・ノードでのみ動作するため、低速です。

- バックアップはアトミックではありません。つまり、バックアップ中に発生した要素への変更が反映されず、データの読取りで内容が保証されない結果になります。

- エラーが発生して不完全なバックアップとなった場合、バックアップは停止します。そのような場合には、エラーを説明するIOExceptionがスローされます。

- バックアップは、3.xから12.1.xまでの前方互換性および後方互換性はありません。

次に例を示します。

- deptキャッシュのシリアライズ表現をtextfileファイルに書き込みます。

backup cache "dept" to file "textfile"

28.1.3.3 キャッシュの内容のファイルからのロード

RESTORE CACHE文を使用して、指定されたキャッシュのシリアライズ表現を、指定されたfilenameで表示されたファイルから読み取ります。filenameは、オペレーティング・システム固有のパスであり、一重または二重引用符で囲む必要があります。RESTORE CACHE文は、コマンド行ツールでのみ使用できます。構文は次のとおりです。

RESTORE CACHE "cache-name" [ FROM ] [ FILE ] "filename"

注意:
Coherenceのバージョン3.xから12.1.xまでは、バックアップをリストアできません。

次に例を示します。

- deptキャッシュをtextfileファイルからリストアします。

restore cache "dept" from file "textfile"

28.1.3.4 クラスタからのキャッシュの削除

DROP CACHE文を使用して、指定したキャッシュをクラスタから完全に削除します。キャッシュは、Java destroy()メソッドへのコールによって削除されます。いずれかのクラスタ・メンバーが、削除されたキャッシュへの参照を保持してそれになんらかの操作の実行を試行すると、そのメンバーはIllegalStateExceptionを受け取ります。Coherence問合せのDROP CACHE文の構文は、次のとおりです。

DROP CACHE  "cache-name"

次に例を示します。

- ordersキャッシュをクラスタから削除します。

drop cache "orders"

28.1.4 キャッシュ・データの処理

次の項では、キャッシュ・データの挿入および削除、結果セットのフィルタリングなど、キャッシュ内のデータの操作方法を説明します。

28.1.4.1 問合せ結果の集計

集計の問合せは、SELECT問合せの変動要素です。結果をグループ化して集計関数を適用し、結果に関するサマリー情報を取得する場合には、集計の問合せを使用します。問合せに集計関数を使用しているか、GROUP BY句が含まれる場合には、問合せは集計の問合せと見なされます。集計の問合せの最も一般的な形式では、1つ以上のグループ化の式の後にGROUP BY句内の同じリード・グループ化の式と組み合せられたSELECT句の集計関数が続く形式が使用されます。

CohQLがサポートする集計関数は、COUNT、AVG、MIN、MAX、およびSUMです。これらの関数は、Double、LongおよびBigDecimal型に対して使用できます。型を指定するには、型の後にアンダースコア(_)を付けた接頭辞を関数に含めます。例:

long_sum, bd_sum

明示的に型が指定されていない場合は、Double型であると見なされます。

その他の例は、「予測、集計、グループ化を扱う複雑な問合せ」を参照してください。

次に例を示します。

- supplierでグループ化されたordersキャッシュからの項目に対して、合計amountおよび平均priceを選択します。

select supplier,sum(amount),avg(price) from "orders" group by supplier

- supplierでグループ化されたordersキャッシュからの項目に対して、(BigDecimal型を使用して)合計amountおよび平均priceを選択します。

select supplier,bd_sum(amount),bd_avg(price) from "orders" group by supplier

28.1.4.2 既存の値の変更

UPDATE文を使用して、キャッシュ内の既存の値を変更します。構文は次のとおりです。

UPDATE "cache-name" [[AS] alias]
SET update-statement {, update-statement}*
[ WHERE conditional-expression ]

各update-statementは、パス式、割当て演算子(=)および式で構成されています。割当て文に対する式の選択は制限されています。割当ての右側は、リテラル、バインド変数、静的メソッド、またはリテラルかバインド変数のみでの新規Javaコンストラクタに決定する必要があります。UPDATE文は、別名の使用もサポートします。

追加の例は、「UPDATEの例」を参照してください。

次に例を示します。

- employeesキャッシュでグレード7以上のランクの従業員の場合、給与を1000に、休暇時間を200に更新します。

update "employees" set salary = 1000, vacation = 200 where grade > 7

28.1.4.3 キャッシュ内へのエントリの挿入

INSERT文を使用して、指定されたKEYの下に指定されたVALUEを格納します。KEY句が提供されていない場合には、新しく作成したオブジェクトに対してメッセージgetKey()が送信されます(可能な場合)。そうでない場合、valueオブジェクトがキーとして使用されます。

INSERT文はObjectsのMaps上で機能する点に注意してください。構文は次のとおりです。

INSERT INTO "cache-name"
[ KEY (literal | new java-constructor | static method) ]
VALUE (literal | new java-constructor | static method)

次に例を示します。

- キーwriterを値Davidとともにemployeeキャッシュに挿入します。

insert into "employee" key "writer" value "David"

28.1.4.4 キャッシュ内のエントリの削除

DELETE文を使用して、キャッシュ内の指定されたエントリを削除します。構文は次のとおりです。

DELETE FROM "cache-name" [[AS] alias]
[WHERE conditional-expression]

DELETE文のWHERE句は、SELECT文の場合と同様に機能します。すべてのconditional-expressionsは、削除するエンティティのセットをフィルタする際に使用できます。DELETE文は、別名の使用もサポートします。

注意事項:
WHERE句が存在しない場合には、指定したキャッシュ内のすべてのエントリが削除されます。

次に例を示します。

- bar.writerキーがDavidでないemployeeキャッシュからエントリを削除します。

delete from "employee" where bar.writer IS NOT "David"

28.1.5 索引の処理

次の項では、キャッシュ・データの索引の作成と削除の方法を説明します。索引により、Coherenceの組込みオプティマイザがさらに迅速かつ効率的に問合せを分析して、結果を返すことができるようになります。

28.1.5.1 キャッシュ上での索引の作成

CREATE INDEXまたはENSURE INDEXを使用して、特定されたキャッシュに索引を作成します。構文は次のとおりです。

[ CREATE | ENSURE ] INDEX [ON] "cache-name" (value-extractor-list)

value-extractor-listは、パス式を使用してValueExtractorsを作成する、カンマ区切りのリストです。複数の要素が存在する場合、MultiExtractorが使用されます。KeyExtractorを作成するには、key()擬似関数を使用してパス式を開始します。

索引の自然な順序が適用されます。

次に例を示します。

- ordersキャッシュ内の属性lastnameで索引を作成します。

create index "orders" lastname

28.1.5.2 キャッシュからの索引の削除

DROP INDEX文は、指定されたValueExtractorに基づいて索引を削除します。この文は、コマンド行ツールでのみ使用できます。構文は次のとおりです。

DROP INDEX [ON] "cache-name" (value-extractor-list)

次に例を示します。

- ordersキャッシュ内の属性lastnameの索引を削除します。

drop index "orders" lastname

28.1.6 複数の問合せ文の発行

次の項では、複数の問合せ文を効率的にキャッシュへ発行する方法を説明します。

28.1.6.1 問合せ文のバッチ・モードでの処理

SOURCE文では、文の「バッチ」処理が可能です。SOURCE文は、指定されたfilenameで表示されたファイルから1つ以上の問合せ文を開いて読み取ります。filenameは、オペレーティング・システム固有のパスであり、一重または二重引用符で囲む必要があります。ファイル内の各問合せ文は、セミコロン(;)で区切る必要があります。ソーシングはコマンド行ツールでのみ使用でき、コマンドの順序で構成されるファイルをロードできます。ソース・ファイルは、そのソースが他のファイルの場合もあります。構文は次のとおりです。

SOURCE FROM [ FILE ] "filename"

SOURCEは、@"filename"のように"at"記号(@)を使用して短縮できます。"ピリオド"記号の'.'は、コマンド行でのみ、'@'の省略として使用できますが、ファイル名を引用符で囲むことはできません。

次に例を示します。

- command_fileファイルの文を処理します。

source from file "command_file"

または

@ "command_file"

または

. command_file

28.1.7 問合せのコストと効果の表示

問合せのコストと効果を判断するために使用される問合せレコードを作成および出力するには、EXPLAIN PLAN FORおよびTRACEコマンドを使用します。問合せの実行レコードは、問合せ操作の一部としてフィルタの評価の見積もりコストを提供します。問合せのトレース・レコードは、問合せ操作の一部としてフィルタの評価の実コストを提供します。いずれの問合せレコードでも、フィルタで索引を使用できるかどうかが考慮されます。問合せの実行レコードおよびトレース・レコードで提供されるデータに関する詳細は、「問合せレコードの解析」を参照してください。コマンドの構文は、次のとおりです。

問合せの実行計画:

EXPLAIN PLAN FOR select statement | update statement | delete statement

トレース:

TRACE select statement | update statement | delete statement

次に例を示します。

EXPLAIN PLAN FOR select * from "mycache" where age=19 and firstName=Bob

または

TRACE SELECT * from "MyCache" WHERE age=19

28.2 CohQLコマンド行ツールの使用

CohQLコマンド行ツールには、文をコマンド行から発行するキャッシュと相互作用する、非プログラム的方法が用意されています。このツールは、com.tangosol.coherence.dslquery.QueryPlusクラスを使用して操作できます。また便宜上、COHERENCE_HOME/bin/に配置された起動スクリプトを使用してこのツールを操作できます。このスクリプトは、Windows (query.cmd)でもUNIX (query.sh)でも使用できます。

スクリプトは、コンソール・モードでクラスタ・ノードを起動します。記憶域はノード上では有効化されていません。これは、本番環境での推奨設定で、ノードが記憶域有効化キャッシュ・サーバーを持つクラスタに参加することが前提となっています。ただし、記憶域有効化ノードをテスト用に作成するには、スクリプト内のstorage_enabled設定をtrueに変更します。

注意:
構成の際には、起動スクリプトではデフォルトのオペレーション構成ファイル(tangosol-coherence.xml)とデフォルトのキャッシュ構成ファイル(coherence-cache-config.xml)が使用されます。これらのファイルは、クラスタの作成/参加およびキャッシュの構成の際にcoherence.jarに格納されます。Coherenceの構成の詳細は、第3章「構成の理解」を参照してください。

スクリプトは、COHERENCE_HOME環境変数を設定するためのオプションを提供します。COHERENCE_HOMEがコンピュータで未設定の場合、スクリプト内のその環境変数をCoherenceのインストール場所に設定します。

CohQLは、コマンド履歴内で上矢印または下矢印を動かすなど、コマンド行編集の拡張機能にJLineを使用します。ただし、JLineはCohQLの使用には必要ありません。スクリプトは、COHERENCE_HOME/lib/ディレクトリ内に格納されているjline.jarライブラリを自動的に使用します。スクリプトのJLINE_HOME変数およびクラスパスを変更することで、別の場所を指定できます。JLineライブラリが見つからない場合、メッセージが表示され、CohQLはJLine機能なしで開始されます。

28.2.1 コマンド行ツールの起動

次の手順は、起動スクリプトを使用してCohQLコマンド行ツールの起動方法を示しています。この手順は、スクリプトのstorage_enabledがfalseに設定されていること(デフォルト)を前提としています。

1. キャッシュ・サーバー・クラスタ・ノードを起動するか、既存のキャッシュ・サーバー・クラスタが起動していることを確認します。
キャッシュ・サーバー・クラスタ・ノードを起動するには、コマンド・プロンプトまたはシェルを開き、/binディレクトリにあるキャッシュ・サーバー起動スクリプトを実行します(Windowsプラットフォームではcache-server.cmd、UNIXプラットフォームではcache-server.sh)。キャッシュ・サーバーが起動し、このクラスタ・メンバーに関する情報が出力されます。

2. コマンド・プロンプトまたはシェルを開き、/binディレクトリにあるCohQLコマンド行起動スクリプトを実行します(Windowsプラットフォームではquery.cmd、UNIXプラットフォームではquery.sh)。Java環境に関する情報が表示されます。コマンド行ツール・プロンプト(CohQL>)が返されます。

注意:
既存のキャッシュ・サーバー・ノードを結合する場合、起動スクリプトを変更して、同じキャッシュ構成を含む既存のキャッシュ・サーバー・ノードと同じクラスタ設定を使用します。

3. コマンド行のヘルプを全部表示するには、プロンプトでhelpと入力します。詳細な説明のないヘルプのリストを表示するには、commandsと入力します。
コマンド行ツールを用いる一連の問合せ文については、「コマンド行の例」を参照してください。

28.2.2 コマンド行ツールの引数の使用

CohQLコマンド行ツールには、CohQL>プロンプトが返す前に読み取られ、実行される一連の引数が組み込まれています。これは、スクリプトを大型のスクリプトの一部として使用する際に(ビルド・プロセスの一部としての使用、I/Oをパイピングするための使用など)有用です。CohQL>プロンプトでhelpと入力し、コマンド行ツール内の引数のヘルプを表示します。

表28-2 Coherenceの問合せ言語コマンド行ツールの引数

引数

説明

-t

トレース・モードを有効にして、デバッグ情報を出力します。

-c

コマンド行引数の処理の後、コマンド行ツールを終了します。この引数は、標準の入力からリダイレクトする際には使用しないでください。使用すると、コマンド行の引数が処理を終了すると同時にツールが終了して、リダイレクトされた入力が読み取られません。

-s

コマンド行ツールをサイレント・モードで操作して、無関係な用語を削除します。これにより、標準の入力(<myInput)と標準の出力(>myOuput)をリダイレクトすると、コマンド行ツールをパイプまたはフィルタで使用できます。

-e

コマンド行ツールを拡張言語モードで操作します。このモードにより、更新でオブジェクト・リテラルが許可され、コマンドを挿入できるようになります。使用法の詳細は、コマンド行のヘルプを参照してください。

-l statement

指定した文を実行します。文は一重または二重の引用符で囲む必要があります。任意の数の-l引数を使用できます。

-f filename

指定したファイルの文を処理します。ファイル内の文は、セミコロン(;)で区切る必要があります。ファイルは、オペレーティング・システム固有のパスであり、一重または二重引用符で囲む必要があります。任意の数の-f引数を使用できます。

例

contactキャッシュ内のすべてのエントリを返し、そのエントリを標準出力に出力してコマンド行ツールを終了します。

query.sh -c -l "select * from contact"

dist-exampleキャッシュ内のすべてのエントリを返し、そのエントリ(余分な用語を削除)をmyOutputという名前のファイルに出力してコマンド行ツールを終了します。

query.cmd -s -c -l "select * from 'dist-example'" >myOutput

myStatementsという名前のファイルのすべてのセグメントを処理して、コマンド行ツールを終了します。

query.sh -c -f myStatements

myInputファイルからコマンドを読み取り、出力(余分な用語を削除)をmyOutputという名前のファイルに出力します。

query.sh -s <myInput >myOutput

28.2.3 コマンド行の例

次に、Windowsでのコマンド行ツールの使用方法の例を示します。この例では、単一クラスタ・メンバーを想定しているため、起動スクリプト内のstorage_enabled設定はtrueに設定されています。この例はキャッシュの作成と削除、エントリの格納と取得、バックアップ・ファイルからのキャッシュのリストアを示します。また、key()およびvalue()という擬似関数の使用を強調します。

コマンド・プロンプトでquery.cmdスクリプトを起動する際に、Java環境、Coherenceのバージョンおよびエディション、Coherenceキャッシュ・サーバーに関する情報が表示されます。プロンプト(CohQL>)に問合せ文を入力します。

次のようにしてCohQLコマンド行ツールを起動します。

C:/coherence/bin/query.cmd

employeesという名前のキャッシュを作成します。

CohQL> create cache "employees"

エントリ(キーと値のペア)をキャッシュに挿入します。

CohQL> insert into "employees" key "David" value "ID-5070"

キャッシュにオブジェクトを挿入します。

CohQL> insert into "employees" value new com.my.Employee("John", "Doe",
"address", 34)

キーの値を変更します。

CohQL> update employees set value() = "ID-5080" where key() like "David"

キャッシュ内の値を取得します。

CohQL> select * from "employees"

存在しないキーの値を取得します。空の結果セットが返されます。

CohQL> select key(), value() from "employees" where key() is "Richard"

キャッシュ内の既存のキーを削除します。空の結果セットが返されます。

CohQL> delete from employees where key() = "David"

employeesキャッシュの内容を削除します。空の結果セットが返されます。

CohQL> delete from "employees"

employeesキャッシュを破棄します。

CohQL> drop cache "employees"

employeesキャッシュを再作成します。

CohQL> create cache "employees"

さらに多くのエントリをキャッシュに挿入します。

CohQL> insert into "employees" key "David" value "ID-5080"

CohQL> insert into "employees" key "Julie" value "ID-5081"

CohQL> insert into "employees" key "Julie" value "ID-5082"

CohQL> insert into "employees" key "Mike" value "ID-5083"

employeesキャッシュ内のキーと値を取得します。

CohQL> select key(), value() from "employees"

キャッシュのシリアライズされた形式をファイルに保存します。

CohQL> backup cache "employees" to "emp.bkup"

キャッシュからキーを削除します。

CohQL> delete from "employees" where key() = "David"

キャッシュの内容を取得します。削除されたキーと値が存在していないことがわかります。

CohQL> select key(), value() from "employees"

キャッシュの内容を削除します。

CohQL> delete from "employees"

キャッシュの内容を取得します。空の結果セットが返されます。

CohQL> select * from "employees"

バックアップ・ファイルからキャッシュの内容をリストアします。

CohQL> restore cache "employees" from file "emp.bkup"

キャッシュの内容を取得します。すべてのエントリがリストアされ、返されたことを確認します。

CohQL> select key(), value() from "employees"

employeesキャッシュを破棄します。

CohQL> drop cache "employees"

コマンド行ツールを終了します。

CohQL> bye

28.3 Javaプログラムにおけるフィルタの作成

FilterBuilder APIは、Javaプログラム内から結果セットをフィルタリングする文字列指向の方法で、使用の際にはCoherence APIの詳細を覚える必要はありません。APIには、com.tangosol.util.QueryHelperクラスに過負荷のcreateFilterファクトリ・メソッドのセットが4つ用意されています。

次のリストは、createFilterメソッドの異なる形式について説明しています。渡された文字列は、Coherence問合せのWHERE句の構文(「エントリの結果セットでのフィルタリング」を参照)を使用しますが、リテラルのWHEREは使用しません。Object配列またはMapを指定する形式は、バインド変数で参照されるオブジェクトを渡すためのものです。各形式は用意されたCoherence問合せ文字列からフィルタを構築します。

- public static Filter createFilter(String s): sは、Filterを表すCoherenceの問合せ内のStringです。

- public static Filter createFilter(String s, Object[] aBindings): sは、FilterおよびaBindingsがバインド変数に使用するObjectsの配列であることを表すCoherenceの問合せ内のStringです。

- public static Filter createFilter(String s, Map bindings): sは、Filterおよびbindingsがバインド変数に使用するObjectsのMapであることを表すCoherenceの問合せ内のStringです。

- public static Filter createFilter(String s, Object[] aBindings, Map bindings): sは、Filter, aBindingsがバインド変数に使用するObjectsの配列であり、bindingsがバインド変数に使用するObjectsのMapであることを表すCoherenceの問合せ内のStringです。

これらのファクトリ・メソッドは、不具合、構文的に不正確な文、セマンティックなエラーがあると、FilterBuildingExceptionをスローします。この例外がRuntimeExceptionのサブクラスであるため、エラーの捕捉は必要ありませんが、エラーの捕捉をしないとプロセスが終了する可能性があります。

例

次の文では、メソッドのcreateFilter(String s)の形式を使用します。これはマサチューセッツ州に住み、別の州で働く従業員のフィルタを構築します。

..
QueryHelper.createFilter("homeAddress.state = 'MA'  and workAddress.state != 'MA'")
...

この文は、Coherence APIを使用する次のフィルタ/エクストラクタと同じです。

AndFilter(EqualsFilter(ChainedExtractor(#getHomeAddress[], #getState[]), MA),
NotEqualsFilter(ChainedExtractor(#getWorkAddress[], #getState[]), MA)))

QueryHelperクラスもcreateExtractorメソッドを提供し、それによりフィルタ構築時に値エクストラクタを作成できます。エクストラクタは、オブジェクトからの値の抽出(並べ替えやフィルタリングなど)とその抽出の識別の両方に使用されます。次の例は、索引作成時のcreateExtractorの使用を示しています。

cache.addIndex(QueryHelper.createExtractor("key().lastName"),/*fOrdered*/ true,
/*comparator*/ null);

28.4 その他のCoherenceの問合せ言語の例

この項では、その他の例を使用して、インスタンス化されたオブジェクト(Filters、ValueExtractors、Aggregatorsなど)によるそれらと同等のCoherence APIコールを示します。Filtersを強調する単純なselect *の例では、Filter部分のみに注目した場合、FilterBuilder APIの変換について理解できます。例の完全なセットを使用すると、QueryBuilder APIとコマンド行ツールの変換について理解できます。

この例では、識別子を修飾するキャッシュ名が削除されたパス構文の短縮された形式が使用されています。

例のJava言語形式でも、EntryProcessorsのかわりにReducerAggregatorが予測に使用されています。KeyExtractorの使用についても、Coherence 3.5ではReflectionExtractorに対する特定の変更を必要としなくなったことにも注意してください。

28.4.1 フィルタを強調表示する単純なSELECT * FROM文

- 40がpriceキーの値より大きい、キャッシュordersから項目を選択します。

select * from "orders" where 40 > price

- priceキーが100にまったく等しく、insuranceキーの値が10より小さいか、shippingキーの値が20以上である、キャッシュordersから項目を選択します。

select * from "orders" where price is 100 and insurance < 10 or shipping >= 20

- priceキーが100にまったく等しく、insuranceキーの値が10より小さいか、またはshippingキーの値が20以上のいずれかである、キャッシュordersから項目を選択します。

select * from "orders" where price is 100 and (insurance < 10 or shipping >= 20)

- priceキーの値が100に等しいか、barキーが20に等しい、キャッシュordersから項目を選択します。

select * from "orders" where price = 100 or shipping = 20

- insuranceキーの値がnullでない、キャッシュordersから項目を選択します。

select * from "orders" where insurance is not null

- emp_idキーが1から1000の値を持つか、bar.empキーが"Smith"でない、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id between 1 and 1000 or bar.emp is not "Smith"

- itemキーが値"coat"に類似しているキャッシュordersから項目を選択します。

select * from "orders" where item like "coat%"

- emp_idの値が5、10、15、または20のセット内にある、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id in (5,10,15,20)

- emp_idがリスト5、10、15、および20を含む、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id contains (5,10,15,20)

- emp_idが5、10、15、および20のすべての項目を含む、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id contains all (5,10,15,20)

- emp_idが5、10、15、および20のいずれかの項目を含む、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id contains any (5,10,15,20)

- fooキーの値が10より小さく、セット10、20で発生する、キャッシュemployeesから項目を選択します。

select * from "employees" where emp_id < 10 in (10,20)

28.4.2 予測、集計、グループ化を扱う複雑な問合せ

- キャッシュContactInfoCacheで従業員の家庭のstateとageを選択し、stateおよびageでグループ化します。

select homeAddress.state, age, count() from "ContactInfoCache" group by homeAddress.state, age

- ordersキャッシュから擬似frobitキーを選択します。空の結果セットが返されます。

select frobit,supplier,sum(amount),avg(price) from "orders" group by supplier

- $1000より大きいordersキャッシュ内の項目の場合、その項目、その価格と色を選択します。

select item_name,price,color from "orders" where price > 1000

- ordersキャッシュから、項目に対する合計amountを選択します。Double型であると見なされます。

select sum(amount) from "orders"

- ordersキャッシュから、項目に対する合計amountをLong型として選択します。

select long_sum(amount) from "orders"

- ordersキャッシュから、項目に対する合計amountをBigDecimal型として選択します。

select bd_sum(amount) from "orders"

- color属性がredまたはgreenである、ordersキャッシュから、項目に対する合計amountを選択します。

select sum(amount) from "orders" where color is "red" or color is "green"

- ordersキャッシュからの項目に対して、合計amountおよび平均priceを選択します。

select sum(amount),avg(price) from "orders"

- employeesキャッシュの可能な重複行からlastnameとcityのコピーを選択します。ここでは、stateはカリフォルニアです。

select distinct lastName,city from "employees" where state = "CA"

28.4.3 UPDATEの例

- employeesキャッシュでランクがグレード7以上の従業員の場合、給与を10%ごと増加して、休暇を50時間追加します。

update "employees" set salary = salary*1.10, vacation = vacation + 50 where grade > 7

28.4.4 KeyおよびValue擬似関数の例

この項では、key()およびvalue()という擬似関数の使用方法の例を示します。その他の例は、「コマンド行の例」を参照してください。

- ContactInfoCacheから、自宅の住所がマサチューセッツで勤務先は別の州である従業員を選択します。

select key().firstName, key().lastName from "ContactInfoCache" where homeAddress.state is 'MA' and workAddress.state != "MA"

- ContactInfoCacheキャッシュから、年齢が42より高い従業員を選択します。

select key().firstName, key().lastName, age from "ContactInfoCache" where age > 42

29 トランザクションの実行

この章では、Coherenceのトランザクションとデータの同時実行性機能の使用手順について説明します。ユーザーは、この章を読む前に、トランザクションの原則を理解しておいてください。また、Coherenceリソース・アダプタには、J2EE Connector Architecture (J2CA)、Java Transaction API (JTA)およびJava EEデプロイメントの知識が必要です。

この章には次の項が含まれます:

- トランザクションの概要

- データの同時実行性のための明示的ロックの使用

- データの同時実行性のための入力プロセッサの使用

- トランザクション・フレームワークAPIの使用

- Coherenceリソース・アダプタの使用

29.1 トランザクションの概要

トランザクションは、プログラマが複数の状態変更のスコープを1つの作業ユニットに設定できるようにして、状態変更が発生する正しい成果がシステム内で得られるようにします。状態変更は、障害が発生しないで各変更が完了できる場合にのみコミットされます。それ以外の場合には、すべての変更は前回の状態にロールバックされる必要があります。

トランザクションは、通常ACIDプロパティ(原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、永続性(Durability))と呼称される一連の条件を保持しようとします。

- 原子 - トランザクション内で実行される変更がすべてコミットされるか、前回の状態にすべてロールバックされます。

- 一貫 - トランザクションの結果が、共有されるリソースを有効な状態で残す必要があります。

- 独立 - トランザクションの結果が、トランザクションがコミットされるまでトランザクションの外部では認識できません。

- 永続 - トランザクション内で実行された変更が永続的になります。

ACIDプロパティは、トランザクションのインフラストラクチャだけでは保持できず、カスタマイズされたビジネス・ロジックが必要となることがあります。たとえば、一貫性プロパティには、システムの変更が有効かどうかを確認するプログラム・ロジックが必要です。また、ACIDプロパティを厳格に遵守すると、インフラストラクチャとアプリケーションのパフォーマンスに直接影響を与えることがあるため、慎重に検討する必要があります。

Coherenceには、様々なトランザクションの保証が得られる各種のトランザクション・オプションが用意されています。このオプションは、アプリケーションやソリューションのトランザクション要件に応じて選択する必要があります。

表29-1は、Coherenceに用意されている各種トランザクション・オプションをまとめたものです。

表29-1 Coherenceのトランザクション・オプション

オプション名

説明

明示的ロック

ConcurrentMapインタフェース(NamedCacheインタフェースによって拡張されている)は、明示的ロック操作をサポートします。ロックAPIはデータの同時実行性を保証しますが、原子性は保証しません。このオプションの詳細は、「データの同時実行性のための明示的ロックの使用」を参照してください。

エントリ・プロセッサ

Coherenceは、EntryProcessor APIによるロックなしのプログラミング・モデルもサポートしています。多くのトランザクション・タイプでは、これにより競合や待機時間が最小限に抑えられ、データ操作のフォルト・トレランスを犠牲にすることなく、システム・スループットを向上させます。このオプションでは、高レベルの同時実行性は制御されますが、原子性は保証されていません。このオプションの詳細は、「データの同時実行性のためのエントリ・プロセッサの使用」を参照してください。

暗黙的ロック

Coherenceでは、EntryProcessor API.を介して暗黙的ロックを使用したパーティションレベルのトランザクションをサポートしています。パーティションレベルのトランザクションでは、単一の操作で複数のキャッシュを更新した場合の原子性が保証されます。詳細は、「複数のキャッシュのエントリの処理」を参照してください。

トランザクション・フレームワークAPI

Coherenceトランザクション・フレームワークAPIは接続ベースのAPIで、これにより、クライアントに障害が発生した場合でも、パーティションおよびキャッシュ全体にわたって原子性トランザクションが保証されます。このフレームワークは、NamedCache操作、問合せ、集計、およびトランザクションのコンテキスト内のエントリ・プロセッサの使用をサポートします。このオプションの詳細は、「トランザクション・フレームワークAPIの使用」を参照してください。

Coherenceリソース・アダプタ

Coherenceリソース・アダプタが、Coherenceトランザクション・フレームワークAPIを利用することにより、Coherenceはリソースとして、JavaEEコンテナのトランザクション・マネージャで管理されるXAトランザクションに参加できます。このトランザクション・オプションにより、原子性の保証が実現します。このオプションの詳細は、「Coherenceリソース・アダプタの使用」を参照してください。

29.2 データの同時実行性のための明示的ロックの使用

標準的なNamedCacheインタフェースは、基本的なロック・メソッドを含むConcurrentMapインタフェースを拡張します。ロック操作は、エントリ・レベルで、NamedCache内の特定のキーに対してロックをリクエストすることで適用されます。

例29-1 キャッシュでのロック操作の適用

...
NamedCache cache = CacheFactory.getCache("dist-cache");
Object key = "example_key";
cache.lock(key, -1);
try
{
Object value = cache.get(key);
// application logic
cache.put(key, value);
}
finally
{
// Always unlock in a "finally" block
// to ensure that uncaught exceptions
// do not leave data locked
cache.unlock(key);
}
...

Coherenceのロック機能では、JavaのsynchronizedキーワードおよびC#のlockキーワードと同様、ブロック・ロックのみをロックします。複数のスレッドが共同で、ロックを適切に使用してデータへのアクセスを調整する必要があります。スレッドが、ある項目のキーをロックしていても、別のスレッドはロックせずにその項目を読み取ることができます。

ロックはサーバー障害の影響を受けず、バックアップ・サーバーにフェイルオーバーします。ロック所有者(クライアント)に障害が発生すると、ロックはただちに解除されます。

ロックの動作は、リクエストされたタイムアウトとキャッシュのタイプに応じて異なります。タイムアウトが-1の場合はロックを取得できるまで無限にブロックされ、0の場合はただちに返され、0より大きい値の場合は指定した時間(ミリ秒単位)待機してからタイムアウトします。コール元が実際にロックを取得したことを確認するには、返されたブール値を調べる必要があります。詳細は、ConcurrentMap.lock()を参照してください。タイムアウト値がlock()に渡されない場合、デフォルトはゼロになります。レプリケート・キャッシュでは、ConcurrentMap.LOCK_ALLをキーとして使用してキャッシュ全体をロックできますが、通常はお薦めしません。この操作は、パーティション・キャッシュではサポートされていません。

レプリケート・キャッシュとパーティション・キャッシュの両方で、getはロックされているキーで許可されます。putは、レプリケート・キャッシュではブロックされますが、パーティション・キャッシュではブロックされません。ロックが行われている場合、ロックの解放はコール元の責任です(lease-granularityの構成によって、同じスレッド内または同じクラスタ・ノード内で実行される)。このような理由から、ロックは常にfinally句(または同等のもの)で解放する必要があります。そうでない場合、未処理の例外があると無限にロックされることがあります。lease-granularity構成の詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

29.3 データの同時実行性のためのエントリ・プロセッサの使用

NamedCacheのスーパーインタフェースであるInvocableMapを使用すると、キャッシュ内で処理コードをロックなしで同時に実行できます。この処理は、エントリ・プロセッサによって処理されます。EntryProcessor APIは、より一般的なConcurrentMapの明示的ロックAPIに比べて柔軟性が少ないかわりに、データの信頼性を犠牲にすることなく最高レベルの効率を提供します。エントリ・プロセッサの詳細は、第24章「キャッシュ内のデータの処理」を参照してください。

エントリ・プロセッサによって処理中のエントリに暗黙的な下位レベルのロックが実行されるため、エンド・ユーザーは並列処理制御を気にすることなく、EntryProcessorの実装に処理コードを配置できます。これは、ConcurrentMap APIで提供されている明示的なlock(key)機能とは異なります。

InvocableMapでは、次の3つの方法でエントリ・プロセッサを起動できます。

- 特定のキーでエントリ・プロセッサを起動します。エントリ・プロセッサを起動するためのキーは、キャッシュに存在していなくてもかまいません。

- キーのコレクションでエントリ・プロセッサを起動します。

- Filterでエントリ・プロセッサを起動します。この場合、Filterがキャッシュ・エントリに対して実行されます。Filter基準に一致するエントリごとに、エントリ・プロセッサが実行されます。Filterの詳細は、第22章「キャッシュ内のデータの問合せ」を参照してください。

エントリ・プロセッサは、(個々のエントリを所有するノード上の)クラスタ全体でパラレル実行されます。これは、クライアントで影響を受けるキーをすべてロックし、キャッシュから必要なデータをすべて取得した後、データを処理してキャッシュにデータを戻してからキーをロック解除するのに比べて大きな利点があります。この処理は、1台のコンピュータで順次実行されるかわりに、複数のコンピュータでパラレル実行されるため、ロックの獲得や解放に伴うネットワークのオーバーヘッドがなくなります。

注意:
各クラスタ・ノードのクラスパスでEntryProcessorの実装を使用できる必要があります。

高レベルの並列処理制御のサンプルは次のとおりです。ネットワーク・アクセスが必要なコードにはコメントが付いています。

例29-2 エントリ・プロセッサを使用しない並列処理制御

final NamedCache cache = CacheFactory.getCache("dist-test");
final String key = "key";

cache.put(key, new Integer(1));

// begin processing

// *requires network access*
if (cache.lock(key, 0))
{
try
{
// *requires network access*
Integer i = (Integer) cache.get(key);
// *requires network access*
cache.put(key, new Integer(i.intValue() + 1));
}
finally
{
// *requires network access*
cache.unlock(key);
}
}

// end processing

次に、エントリ・プロセッサを使用した同等の方法を示します。ここでも、ネットワーク・アクセスにはコメントが付いています。

例29-3 エントリ・プロセッサを使用する並列処理制御

final NamedCache cache = CacheFactory.getCache("dist-test");
final String key = "key";

cache.put(key, new Integer(1));

// begin processing

// *requires network access*
cache.invoke(key, new MyCounterProcessor());

// end processing

...

public static class MyCounterProcessor
extends AbstractProcessor
{
// this is executed on the node that owns the data,
// no network access required
public Object process(InvocableMap.Entry entry)
{
Integer i = (Integer) entry.getValue();
entry.setValue(new Integer(i.intValue() + 1));
return null;
}
}

エントリ・プロセッサは個別に原子性が保証されて実行されますが、InvocableMap.invokeAll()の使用による複数のエントリ・プロセッサの起動では1つの原子性の単位として実行されません。個別のエントリ・プロセッサが完了すると、他のエントリ・プロセッサが実行中であっても、そのキャッシュに行われた更新はすぐに参照できます。さらに、エントリ・プロセッサで捕捉されなかった例外によりその他の処理の実行が妨げられることはありません。エントリ・プロセッサの実行中に、あるエントリの1次ノードに障害が発生した場合は、かわりにバックアップ・ノードが実行します。ただし、エントリ・プロセッサの完了後にノードで障害が発生した場合、そのエントリ・プロセッサはバックアップで起動されません。

一般的に、エントリ・プロセッサは短時間である必要があります。エントリ・プロセッサを長時間実行しているアプリケーションでは、分散サービスのスレッド・プール・サイズを増やして、分散サービスが実行するその他の操作が、長時間実行されているエントリ・プロセッサによってブロックされないようにする必要があります。分散サービスのスレッド・プールの詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

29.4 トランザクション・フレームワークAPIの使用

トランザクション・フレームワークAPIによって、TCMPクライアントは操作を実行して、問合せ、アグリゲータ、およびトランザクションのコンテキスト内のエントリ・プロセッサを使用できます。トランザクションでは、クライアントに障害が発生した場合でも、パーティションおよびキャッシュ全体にわたって、読取りの一貫性と原子性の保証が実現します。フレームワークは、独自の並行性戦略と記憶域実装、および失敗したトランザクションに対する独自のリカバリ・マネージャを使用します。

注意:
TransactionMap APIは非推奨となり、トランザクション・フレームワークAPIがかわりに推奨されています。この2つのAPIは相互に排他的です。

既知の制限事項

トランザクション・フレームワークAPIの制限事項は次のとおりです。

- データベースの統合 – 既存のCoherenceユーザーの場合、最も顕著な制限事項は、既存のパーティション化NamedCache実装に比べて、データベースの統合がサポートされていないことです。

- サーバー側の機能 – トランザクション・キャッシュは、古いオブジェクト・バージョンのガベージ・コレクションをサポートしていますが、エビクションまたは有効期限をサポートしていません。バッキング・マップ・リスナー、トリガーおよびCacheStoreモジュールはサポートされていません。

- 明示的ロックとペシミスティック・トランザクション – ペシミスティック/明示的ロック(ConcurrentMapインタフェース)はサポートされていません。

- フィルタ – PartitionedFilter、LimitFilter、KeyAssociationFilterなどのフィルタはサポートされていません。

- 同期リスナー – SynchronousListenerインタフェースはサポートされていません。

- ニア・キャッシュ – トランザクション・キャッシュでのニア・キャッシュのラップはサポートされていません。

- キー・パーティション戦略 – トランザクション・キャッシュにカスタムKeyPartitioningStrategyは指定できませんが、KeyAssociationまたはKeyAssociatorは機能します。

この項には次のトピックが含まれます:

- トランザクション・キャッシュの定義

- トランザクション内でのキャッシュ操作の実行

- トランザクション接続の作成

- トランザクション接続の使用

- OptimisticNamedCacheインタフェースの使用

- トランザクション実行時のPOFの構成

- トランザクション記憶域容量の構成

- Java拡張クライアントからのトランザクションの実行

- トランザクション内でのキャッシュ操作の実行

トランザクション・フレームワークAPIは、Coherence JCAリソース・アダプタの基礎となるトランザクション・フレームワークでもあります。リソース・アダプタの使用方法の詳細は、「Coherenceリソース・アダプタの使用」を参照してください。

29.4.1 トランザクション・キャッシュの定義

トランザクション・キャッシュは、トランザクション保証を提供する専用の分散キャッシュです。トランザクション・フレームワークAPIを使用してトランザクションを実行する場合は常に、トランザクション・キャッシュが必要です。トランザクション・キャッシュは、非トランザクション・キャッシュと相互操作はできません。

実行時に、トランザクション・キャッシュは、トランザクション記憶域とリカバリを提供する一連の内部トランザクション・キャッシュとともに自動的に使用されます。また、トランザクション・キャッシュにより、トランザクションのデフォルト動作(内部トランザクション・キャッシュのデフォルト動作を含む)を実行時にオーバーライドすることも可能です。

トランザクション・キャッシュは、<transactional-scheme>要素を使用して、キャッシュ構成ファイル内で定義されます。トランザクション・スキームには、分散キャッシュ・スキームで使用可能な同じ要素と属性が数多く含まれます。<transactional-scheme>要素とそのサブ要素すべての詳細は、「transactional-scheme」を参照してください。

注意:
ニア・キャッシュ・スキーム内でのトランザクション・スキームの使用は、現時点ではサポートされていません。

次の例は、キャッシュ構成ファイル内でのトランザクション・キャッシュ・スキームの定義を示しています。このキャッシュの名前はMyTxCacheで、example-transactionalという名前の<transactional-scheme>にマップされています。キャッシュ名にも、tx-*表記規則を使用できます。この規則により、複数のキャッシュ・インスタンスはトランザクション・キャッシュ・スキームへの単一マッピングを使用できます。

注意:
次の例に示されているように、<service-name>要素はオプションです。トランザクション・キャッシュ・スキームに<service-name>要素が含まれていない場合には、デフォルトのサービス名としてTransactionalCacheが使用されます。この場合、アプリケーションはデフォルトのサービス名を使用してトランザクション・サービスに接続する必要があります。「トランザクション接続の作成」を参照してください。

例29-4 トランザクション・キャッシュ定義の例

<caching-scheme-mapping>
<cache-mapping>
<cache-name>MyTxCache</cache-name>
<scheme-name>example-transactional</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<!-- Transactional caching scheme. -->
<transactional-scheme>
<scheme-name>example-transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<thread-count>10</thread-count>
<request-timeout>30000</request-timeout>
<autostart>true</autostart>
</transactional-scheme>
</caching-schemes>

<transactional-scheme>要素では、スキーム参照の使用もサポートされています。次の例では、example-transactionalという名前の<transactional-scheme>がbase-transactionalという名前の<transactional-scheme>を参照します。

<caching-scheme-mapping>
<cache-mapping>
<cache-name>tx-*</cache-name>
<scheme-name>example-transactional</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<transactional-scheme>
<scheme-name>example-transactional</scheme-name>
<scheme-ref>base-transactional</scheme-ref>
<thread-count>10</thread-count>
</transactional-scheme>

<transactional-scheme>
<scheme-name>base-transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<request-timeout>30000</request-timeout>
<autostart>true</autostart>
</transactional-scheme>
</caching-schemes>

29.4.2 トランザクション内でのキャッシュ操作の実行

アプリケーションは、次の3つの方法のいずれかで、トランザクション内でキャッシュ操作を実行します。

- NamedCache APIの使用 - アプリケーションは、NamedCache APIを使用して、トランザクション内でキャッシュ操作を暗黙的に実行します。

- Connection APIの使用 - アプリケーションは、Connection APIを使用して、トランザクション内でキャッシュ操作を明示的に実行します。

- Coherenceリソース・アダプタの使用 - Java EEアプリケーションは、Coherenceリソース・アダプタを使用して、Coherenceデータ・クラスタに接続し、分散(グローバル)トランザクションの一部としてキャッシュ操作を実行します。

29.4.2.1 NamedCache APIの使用

NamedCache APIでは、トランザクションのコンテキスト内でキャッシュ操作を暗黙的に実行できます。ただし、この方法では、アプリケーションはデフォルトのトランザクション動作を変更できません。たとえば、トランザクションはNamedCache APIアプローチの使用時には自動コミット・モードになります。各操作は正常に完了するとただちにコミットされます。複数の操作のスコープを単一のトランザクションに設定することはできません。トランザクション動作をさらに制御する必要のあるアプリケーションは、Connection APIを使用する必要があります。トランザクションのデフォルト動作の詳細は、「トランザクション接続の使用」を参照してください。

NamedCache APIアプローチは、putAllなどの単一操作を実行する際に、原子性保証の確認に適した理想的な方法です。次の例では、NamedCacheインスタンスを作成し、CacheFactory.getCache()メソッドを使用してトランザクション・キャッシュを取得する単一クライアントを示しています。この例では、例29-4で定義されたトランザクション・キャッシュを使用しています。クライアントは、すべてのput操作が正常に実行された場合にのみコミットされるputAll操作を実行します。トランザクションは、任意のput操作が失敗すると、自動的にロールバックされます。

...
String key = "k";
String key2 = "k2";
String key3 = "k3";
String key4 = "k4";

CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("MyTxCache");

Map map = new HashMap();
map.put(key, "value");
map.put(key2, "value2");
map.put(key3, "value3");
map.put(key4, "value4");

//operations performed on the cache are atomic
cache.putAll(map);

CacheFactory.shutdown();
...

29.4.2.2 Connection APIの使用

Connection APIは、トランザクション内でキャッシュ操作を実行するために使用され、トランザクション動作を明示的に制御する機能を提供します。たとえば、アプリケーションは自動コミット・モードを有効または無効にしたり、トランザクションの分離レベルを変更できます。

この項の例では、com.tangosol.coherence.transactionパッケージ内にあるConnectionインタフェース、DefaultConnectionFactoryクラスおよびOptimisticNamedCacheインタフェースの使用法を示しています。この例では、例29-4で定義されたトランザクション・キャッシュを使用しています。Connection APIの詳細は、次の例を参照してください。

例29-5では自動コミット・トランザクションを示しており、ここにある2つのinsert操作はそれぞれ、個別のトランザクションとして実行されます。

例29-5 自動コミット・トランザクションの実行

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

OptimisticNamedCache cache = con.getNamedCache("MytxCache");

cache.insert(key, value);
cache.insert(key2, value2);

con.close();
...

例29-6では非自動コミット・トランザクションを示しており、ここにある2つのinsert操作は単一のトランザクション内で実行されます。非自動コミット・トランザクションを使用するアプリケーションは、トランザクション境界を手動で定める必要があります。

例29-6 非自動コミット・トランザクションの実行

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

con.setAutoCommit(false);

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.insert(key, value);
cache.insert(key2, value2);
con.commit();

catch (Exception e)
{
con.rollback();
throw e;
}

finally
{
con.close();
}
...

例29-7は、複数のキャッシュにわたるトランザクションの実行を示しています。各トランザクション・キャッシュは、キャッシュ構成ファイルで定義する必要があります。

例29-7 複数のキャッシュにわたるトランザクション

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

con.setAutoCommit(false);
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");
OptimisticNamedCache cache1 = con.getNamedCache("MyTxCache1");

cache.insert(key, value);
cache1.insert(key2, value2);

con.commit();

con.close();
...

注意:
トランザクションは、同じサービス内にある複数のパーティションやキャッシュにまたがることがありますが、複数のサービスにまたがることはありません。

29.4.3 トランザクション接続の作成

com.tangosol.coherence.transaction.DefaultConnectionFactoryクラスは、com.tangosol.coherence.transaction.Connectionインスタンスの作成に使用します。例29-5に示した次のコードは、ファクトリの引数なしのコンストラクタを使用してConnectionインスタンスを作成する操作を示しています。

Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

この例では、クラスパスで検出される(または-Dtangosol.coherence.cacheconfigシステム・プロパティを使用して指定される)最初の構成ファイルが、Connectionインスタンスによって使用されています。オプションで、キャッシュ構成ファイルの場所と名前を指定するファクトリ・クラスに、引数としてURIを渡すことができます。たとえば、次のコードは接続ファクトリを構成する操作を示しており、その接続ファクトリは、クラスパスで検出されたcache-config.xmlという名前のキャッシュ構成ファイル(configディレクトリに格納されている)を使用しています。

Connection con = new DefaultConnectionFactory("config/cache-config.xml").
createConnection("TransactionalCache");

DefaultConnectionFactoryクラスは、接続を作成するメソッドを提供します。

- createConnection() - この引数なしのメソッドは、デフォルトのトランザクション・サービスのメンバーである接続を作成します。これはTransactionalCacheと名付けられます。この引数なしのメソッドは、使用されている<transactional-scheme>要素に特定の<service-name>要素が含まれていない場合に使用します。トランザクション・キャッシュ・スキームの定義およびサービス名の指定の詳細は、「トランザクション・キャッシュの定義」を参照してください。

- createConnection(ServiceName) - このメソッドは、トランザクション・サービスのメンバーである接続を作成します。サービス名はStringで、この接続が属するトランザクション・サービスを示します。ServiceNameは<service-name>要素にマップされます。この要素は、キャッシュ構成ファイルの<transactional-scheme>内で定義されています。サービス名が使用されていない場合には、デフォルト名(TransactionalCache)がサービス名として使用されます。トランザクション・キャッシュ・スキームの定義およびサービス名の指定の詳細は、「トランザクション・キャッシュの定義」を参照してください。

- createConnection(ServiceName, loader) - このメソッドは、トランザクション・サービスのメンバーである接続を作成します。さらに、使用するクラス・ローダーを指定します。前述の例では、接続はサービス名の指定のみで作成され、その場合にはデフォルトのクラス・ローダーが使用されます。

29.4.4 トランザクション接続の使用

com.tangosol.coherence.transaction.Connectionインタフェースは、Coherenceサービスへの論理接続を表します。アクティブな接続は、常にトランザクションに関連付けられています。新規トランザクションは、接続が作成されたとき、およびトランザクションがコミットまたはロールバックされたときに、暗黙的に起動します。

接続から派生したトランザクションには、次に示す複数のデフォルトの動作があります。デフォルトの動作は、使いやすさとパフォーマンスのバランスをとります。

- トランザクションは自動的にコミットされるか、キャッシュ操作ごとにロールバックされます。「自動コミット・モードの使用」を参照してください。

- トランザクションは、read committed分離レベルを使用します。「分離レベルの設定」を参照してください。

- トランザクションは、キャッシュに対して即座に操作を実行します。「即時モードの使用」を参照してください。

- トランザクションのデフォルトのタイムアウトは300秒です。「トランザクション・タイムアウトの設定」を参照してください。

接続のデフォルト動作は、必要に応じてConnectionインスタンスのメソッドを使用して変更できます。

29.4.4.1 自動コミット・モードの使用

自動コミット・モードでは、各キャッシュ操作を別々のトランザクションに関連付けるかどうか、また複数のキャッシュ操作を単一のトランザクションとして実行するかどうかをアプリケーションで選択できます。各キャッシュ操作は、自動コミットが有効になっている場合に個別のトランザクションで実行されます。フレームワークでは、操作が完了して接続が新規トランザクションに関連付けられ、次の操作が実行された後で、トランザクションが自動的にコミットまたはロールバックされます。デフォルトでは、Connectionインスタンスが作成されている場合、自動コミットは有効です。

例29-5に示した次のコードは、それぞれが別々のトランザクションとして実行されるinsert操作を示しています。

OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.insert(key, value);
cache.insert(key2, value2);

自動コミット・モードを無効にすることで、複数の操作が単一トランザクションの一部として実行されます。自動コミット・モードが無効になっている場合には、アプリケーションはトランザクション境界を手動で定める必要があります。例29-6に示した次のコードは、単一トランザクション内で実行されるinsert操作を示しています。

con.setAutoCommit(false);

OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.insert(key, value);
cache.insert(key2, value2);

con.commit();

自動コミット・モードが有効になっている場合には、アプリケーションはcommit()メソッドまたはrollback()メソッドを使用できません。さらに、自動コミット・モードがアクティブ・トランザクションで有効になっている場合には、すべての作業が自動的にロールバックされます。

29.4.4.2 分離レベルの設定

分離レベルはデータの並行性と一貫性の制御に役立ちます。トランザクション・フレームワークは暗黙的な書込みロックを使用し、読取りロックを実装しません。ロックされたエントリに書き込もうとすると、UnableToAcquireLockExceptionが返され、リクエストはブロックしなくなります。トランザクションが即時モードに設定されている場合は、例外が即座にスローされます。非即時モードでは、例外がスローされるようになるのは文がフラッシュされたときで、それは通常、次の読取り時かトランザクションのコミット時です。「即時モードの使用」を参照してください。

Coherenceトランザクション・フレームワークAPIがサポートしている分離レベルは次のとおりです。

- READ_COMMITTED - レベルが指定されていない場合、これがデフォルトの分離レベルです。この分離レベルは、コミットされたデータのみが参照可能になることを保証するもので、一貫性については保証しません。これは、分離レベルの中で最も弱く、通常、読取り一貫性を犠牲にして最善のパフォーマンスを実現します。

- STMT_CONSISTENT_READ - この分離レベルでは、文スコープ設定読取り整合性が実現します。これは、単一の操作では、文が開始した時点で使用可能だった読取り一貫性バージョンのデータのみを読み取ることを保証するものです。このバージョンがキャッシュ内の最新データであるかどうかはわかりません。詳細は、次の「注意」を参照してください。

- STMT_MONOTONIC_CONSISTENT_READ - この分離レベルでは、STMT_CONSISTENT_READと同じ保証が提供されますが、読取りも単調であることが保証されます。読取りで、この接続の使用中にすでに存在したすべてのバージョン以上であるバージョンが返されることが保証されます。単調な読取り保証であるため、この分離での読取りは、必要なバージョンが参照可能になるまでブロックします。

- TX_CONSISTENT_READ - この分離レベルでは、トランザクションにスコープが設定された読取り一貫性が提供されます。この一貫性とは、指定されたトランザクションで実行された操作すべてが、トランザクションが開始した時点で使用可能だった読取り一貫性と同じ一貫性で読み取ったバージョンのデータを読み取ることを保証するものです。このバージョンがキャッシュ内の最新データであるかどうかはわかりません。詳細は、次の「注意」を参照してください。

- TX_MONOTONIC_CONSISTENT_READ - この分離レベルでは、TX_CONSISTENT_READと同じ保証が提供されますが、読取りも単調であることが保証されます。読取りで、この接続の使用中にすでに存在したすべてのバージョン以上であるバージョンが返されることが保証されます。単調な読取り保証であるため、この分離でのトランザクションの初期読取りは、必要なバージョンが参照可能になるまでブロックします。

注意:
読取り一貫性分離レベル(文またはトランザクション)は、キャッシュ内の最新データより多少遅れることがあります。トランザクションが値を書き込んでコミットし、その値を次のトランザクションで読取り一貫性分離レベルを使用して即座に読み取っても、更新された値をすぐに参照できない場合があります。最新値の読取りが重要な場合には、READ_COMMITTED分離レベルが必要です。

分離レベルはConnectionインスタンスに対して設定するものであり、アクティブ・トランザクションの開始前に設定する必要があります。例:

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

con.setIsolationLevel(STMT_CONSISTENT_READ);
...

29.4.4.3 即時モードの使用

即時モードでは、クラスタ上でキャッシュ操作をいつ実行するかをアプリケーションで制御できます。即時モードが有効な場合には、キャッシュ操作はクラスタ上でただちに実行されます。即時モードが無効な場合には、キャッシュ操作は遅延され(可能な場合)、キューに入れられてバッチ処理として実行されます。通常、操作をキューに入れられるのは、値を返さない場合のみです。アプリケーションは、即時モードを無効にすることでパフォーマンスを向上できます。

デフォルトでは、即時モードは有効で、キャッシュ操作はクラスタ上でただちに実行されます。次の例は、即時モードの無効化を示します。

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

con.setEager(false);
...

29.4.4.4 トランザクション・タイムアウトの設定

トランザクション・タイムアウトによって、トランザクションがロールバックされるまでアクティブにしておける時間をアプリケーションで制御できます。トランザクション・タイムアウトは、現在のトランザクション、および接続に関連付けられている新規トランザクションに関連付けられています。

タイムアウトの値は秒で指定されます。デフォルトのタイムアウト値は300秒です。次の例では、トランザクション・タイムアウト値の設定を示しています。

...
Connection con = new DefaultConnectionFactory().
createConnection("TransactionalCache");

con.setTransactionTimeout(420);
...

29.4.5 OptimisticNamedCacheインタフェースの使用

com.tangosol.coherence.transaction.OptimisticNamedCacheインタフェースはNamedCacheインタフェースを拡張し、update()、delete()、insert()の各操作を追加します。

トランザクション・キャッシュはすべて、このタイプから派生します。このキャッシュ・タイプでは、フレームワークの並行性とデータ・ロック実装がアプリケーションで使用されていることが確認されます。

注意:
OptimisticNamedCacheは、独自のロック戦略を使用するため、ConcurrentMapインタフェースからの操作を拡張しません。

例29-5に示した次のコード・サンプルでは、MyTxCacheというトランザクション・キャッシュの取得を示し、キャッシュに対して操作を実行します。この例の場合、トランザクション・キャッシュMyTxCacheは、実行時にはキャッシュ構成ファイルに格納されている必要があります。トランザクション・キャッシュの定義の詳細は、「トランザクション・キャッシュの定義」を参照してください。

OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.insert(key, value);
cache.insert(key2, value2);

29.4.6 トランザクション実行時のPOFの構成

トランザクション・キャッシュは、トランザクション内のPortable Object Format (POF)シリアライズをサポートしています。POFは、<serializer>要素を使用してトランザクション・キャッシュ・スキーム内で有効化されます。次の例は、トランザクション・キャッシュ・スキーム内のPOFシリアライズの有効化を示しています。

<transactional-scheme>
<scheme-name>example-transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
</instance>
</serializer>
<autostart>true</autostart>
</transactional-scheme>

トランザクション・フレームワークAPIには、coherence.jarに格納されているtxn-pof-config.xml POF構成ファイルで定義されている独自のPOFタイプも含まれています。POFタイプは必須であり、実行時に検出される必要があります。

実行時にトランザクションPOFタイプをロードするには、アプリケーションのPOF構成ファイルを変更し、<include>要素を使用してtxn-pof-config.xml POF構成ファイルを追加します。例:

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
<include>txn-pof-config.xml</include>
</user-type-list>
...
</pof-config>

<include>を使用してPOF構成ファイルを組み合せる方法の詳細は、「複数のPOF構成ファイルの組合せ」を参照してください。

29.4.7 トランザクション記憶域容量の構成

トランザクション・フレームワークAPIは、バッキング・マップを使用する内部分散キャッシュにトランザクション・データを格納します。このデータには、すべてのキーのバージョンと、トランザクション・キャッシュに対するキーの値が含まれます。フレームワークは、格納されたデータをロールバック・シナリオで、またリカバリ中にも使用します。

内部記憶域の要件によって、トランザクション・キャッシュでは、キャッシュに書き込まれた各エントリに一定のオーバーヘッドが関連付けられています。さらに、トランザクション・キャッシュは複数バージョンの並行性処理制御を使用します。つまり、書込み操作ごとに、それが更新であっても、キャッシュに新規の行が生成されます。したがって、トランザクション・フレームワークAPIでは、カスタム・エビクション・ポリシーを使用して、内部記憶域キャッシュの増加を管理できます。エビクション・ポリシーは、エントリのどのバージョンを保持し、どのバージョンがエビクションに適しているかを決定することで機能します。指定されたキー(最新)の最新バージョンは追い出されません。エビクション・ポリシーは、構成済の高水位標に達すると常に施行されます。しきい値に達すると、該当するバージョンの25%が削除されます。

注意:

- エビクション・ポリシーは、高水位標を比較する際に、トランザクション記憶域全体を考慮するわけではありません。したがって、トランザクション記憶域は、記憶域のエビクション・ポリシーが認識されるまでに高水位標を少し超えることもあります。

- 現在のキー・エントリが排出されることはないため、キャッシュが十分に広くても(個別キーの数が多くても)トランザクション・キャッシュの記憶域が最大ヒープ・サイズを超える可能性があります。

記憶域のエビクション・ポリシーは、測定された記憶域サイズが高水位標を超えると書込みごとに通知されるため、デフォルトの高水位標を、現在のデータ・セットのサイズより大きくなるように増加させる必要があります。そうしないと、現在のデータ・セットのサイズが高水位標を超えてパフォーマンスが低下すると、エビクション・ポリシーは書込みごとに通知されます。読取り一貫性が使用されない場合、履歴バージョンが読み取られることはないため、現在のデータ・セットの値は予測されるサイズを少し超えるように設定できます。読取り一貫性を使用する際には、高水位標を高く設定して、十分な履歴バージョンを提供できるようにします。トランザクション記憶域のサイズを概算するには、次に示す計算式を使用します。

高水位標は、トランザクション・スキームの定義内の<high-units>要素を使用して構成されます。次の例は、高水位標を20MBに構成する処理を示しています。

<transactional-scheme>
...
<high-units>20M</high-units>
...
</trnsactional-scheme>

次の計算式により、トランザクション・キャッシュの行に対するメモリー使用量の概算値を求めることができます。

挿入操作は次のとおりです。

- プライマリ - キー(シリアライズ)+キー(ヒープ上のサイズ)+値(シリアライズ)+ 1095バイトの一定のオーバーヘッド

- バックアップ - キー(シリアライズ)+値(シリアライズ)+ 530バイトの一定のオーバーヘッド

更新操作は次のとおりです。

- プライマリ - 値(シリアライズ)+ 685バイトの一定のオーバーヘッド

- バックアップ - 値(シリアライズ)+ 420バイトの一定のオーバーヘッド

29.4.8 Java拡張クライアントからのトランザクションの実行

トランザクション・フレームワークAPIでは、Java拡張クライアントがトランザクション内でキャッシュ操作を実行できます。この場合、トランザクションAPIは、クラスタ上に配置されたエントリ・プロセッサ内で使用します。実行時には、エントリ・プロセッサをJavaクライアントのかわりに実行します。

この項の手順には、Coherence*Extendの設定方法や使用方法の詳細は記載されていません。Coherence*Extendを初めて使用する場合は、『Oracle Coherenceリモート・クライアントの開発』のCoherence*Extendの設定に関する項を参照してください。C++クライアントまたは.NETクライアントからのトランザクション実行の詳細は、『Oracle Coherenceリモート・クライアントの開発』のC++クライアントに対するトランザクションの実行に関する項および.NETクライアントに対するトランザクションの実行に関する項を参照してください。

この項は、Java拡張クライアントからトランザクションへの実行に必要な次のトピックで構成されています。

- トランザクション用の入力プロセッサの作成

- クラスタ側のトランザクション・キャッシュの構成

- クライアント側のリモート・キャッシュの構成

- Javaクライアントからのトランザクション入力プロセッサの使用

29.4.8.1 トランザクション用のエントリ・プロセッサの作成

トランザクションは、クラスタ上にあるエントリ・プロセッサ内でトランザクションAPIを使用して実行されます。エントリ・プロセッサは、Java拡張クライアントのかわりに実行します。

例29-8では、トランザクション内で単純なupdate操作を実行する入力プロセッサを示しています。実行時には、エントリ・プロセッサをクライアントとクラスタの両方に配置する必要があります。

例29-8 拡張クライアント・トランザクション用の入力プロセッサ

public class MyTxProcessor extends AbstractProcessor
{
public Object process(InvocableMap.Entry entry)
{
// obtain a connection and transaction cache
ConnectionFactory connFactory = new DefaultConnectionFactory();
Connection conn = connFactory.createConnection("TransactionalCache");
OptimisticNamedCache cache = conn.getNamedCache("MyTxCache");

conn.setAutoCommit(false);

// get a value for an existing entry
String sValue = (String) cache.get("existingEntry");

// create predicate filter
Filter predicate = new EqualsFilter(IdentityExtractor.INSTANCE, sValue);

try
{
// update the previously obtained value
cache.update("existingEntry", "newValue", predicate);
}
catch (PredicateFailedException e)
{
// value was updated after it was read
conn.rollback();
return false;
}
catch (UnableToAcquireLockException e)
{
// row is being updated by another tranaction
conn.rollback();
return false;
}
try
{
conn.commit();
}
catch (RollbackException e)
{
// transaction was rolled back
return false;
}
return true;
}
}

29.4.8.2 クラスタ側のトランザクション・キャッシュの構成

トランザクションでは、トランザクション・キャッシュをクラスタ側のキャッシュ構成ファイルで定義する必要があります。トランザクション・キャッシュの定義の詳細は、「トランザクション・キャッシュの定義」を参照してください。

次の例では、MyTxCacheというトランザクション・キャッシュを定義しています。これは、例29-8の入力プロセッサで使用されたキャッシュ名です。この例では、リモート・クライアントからエントリ・プロセッサを実行するために必要なプロキシ・スキームと分散キャッシュ・スキームも含まれています。プロキシは、ポート9099のlocalhostにおけるクライアントのTCP/IP接続を受け入れるように構成されています。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>MyTxCache</cache-name>
<scheme-name>example-transactional</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>dist-example</cache-name>
<scheme-name>example-distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<transactional-scheme>
<scheme-name>example-transactional</scheme-name>
<thread-count>7</thread-count>
<high-units>15M</high-units>
<task-timeout>0</task-timeout>
<autostart>true</autostart>
</transactional-scheme>
<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>localhost</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
</cache-config>

29.4.8.3 クライアント側のリモート・キャッシュの構成

クラスタのプロキシに接続してトランザクション・エントリ・プロセッサを実行するには、リモート・クライアントにリモート・キャッシュが必要です。リモート・キャッシュは、クライアント側のキャッシュ構成ファイルで定義します。

次の例では、リモート・キャッシュをポート9099のlocalhostに配置されているプロキシに接続するように構成します。また、リモート・キャッシュの名前(dist-example)はトランザクション・エントリ・プロセッサの開始時に使用されるクラスタ側のキャッシュの名前と一致している必要があります。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-example</cache-name>
<scheme-name>extend</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>localhost</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>30s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>30s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>

29.4.8.4 Javaクライアントからのトランザクション・エントリ・プロセッサの使用

Java拡張クライアントが、通常どおりエントリ・プロセッサを起動します。ただし、実行時にはクラスタ側のエントリ・プロセッサが起動されます。クライアントは起動が委任されたことを認識しません。次の例は、例29-8に示された入力プロセッサをJavaクライアントが呼び出す方法を示しています。

NamedCache  cache    =  CacheFactory.getCache("dist-example");
Object      oReturn  = cache.invoke("AnyKey",  new MyTxProcessor());

System.out.println("Result of extend tx execution: " + oReturn);

29.4.9 トランザクション管理情報の表示

トランザクション・フレームワークは、既存のCoherence JMX管理フレームワークを活用します。CoherenceにおけるJMXの有効化と使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

この項では、トランザクション情報を提供する2つのMBean (CacheMBeanおよびTransactionManagerMBean)について説明します。

29.4.9.1 トランザクション・キャッシュのCacheMBean

CacheMBean管理対象リソースは、トランザクション・キャッシュを含むすべてのキャッシュに対して属性と操作を提供します。MBeanの属性の多くは、単に-1という値を返すような属性を起動するトランザクション・キャッシュには使用できません。クラスタ・ノードには、トランザクション・キャッシュのキャッシュ・マネージドBeanのインスタンスをゼロ個以上指定できます。オブジェクト名に使用される形式は次のとおりです。

type=Cache, service=service name, name=cache name, nodeId=cluster node's id

表29-2は、トランザクション・キャッシュをサポートするCacheMBean属性を示しています。

表29-2 トランザクション・キャッシュのサポートされている属性

属性

型

説明

AverageGetMillis

Double

get()の呼出しにかかった平均時間(ミリ秒)。

AveragePutMillis

Double

キャッシュ統計が最後にリセットされてからのput()の呼出しにかかった平均時間(ミリ秒)。

Description

String

キャッシュの説明。

HighUnits

Integer

キャッシュ・サイズの測定単位の制限。キャッシュが最大単位レベルに達すると、そのキャッシュは自動的に削除されます。これは通常、キャッシュの高水位標と呼ばれます。

Size

Integer

現在のデータ・セット内のエントリの数。

TotalGets

Long

キャッシュ統計が最後にリセットされてからのget()操作の合計数。

TotalGetsMillis

Long

キャッシュ統計が最後にリセットされてからのget()操作にかかった時間の合計(ミリ秒)。

TotalPuts

Long

キャッシュ統計が最後にリセットされてからのput()操作の合計数。

TotalPutsMillis

Long

キャッシュ統計が最後にリセットされてからのput()操作にかかった時間の合計(ミリ秒)。

トランザクション・キャッシュの場合、resetStatistics操作がサポートされ、トランザクション・マネージャの統計がすべてリセットされます。

29.4.9.2 TransactionManagerBean

TransactionManagerMBean管理対象リソースは、トランザクション・フレームワーク専用です。これには、すべてのトランザクション・サービス・インスタンスからのサービスレベルの統計を集計したグローバル・トランザクション・マネージャの統計が用意されています。各クラスタ・ノードには、サービスごとにトランザクション・マネージャの管理対象Beanのインスタンスがあります。オブジェクト名に使用される形式は次のとおりです。

type=TransactionManager, service=service name, nodeId=cluster node's id

注意:
特定のトランザクション・マネージャの属性については、複数のノードがトランザクションに参加していた可能性がある場合でも、トランザクションのコーディネータ・ノードでこの数は保持されます。たとえば、トランザクションには複数のノードに格納されているエントリに対する変更が追加されている場合がありますが、TotalCommitted属性はそのトランザクションのコミットを調整したノード上でのみMBeanで増分されます。

表29-3は、TransactionManager属性を説明しています。

表29-3 TransactionManagerMBeanの属性

属性

型

説明

TotalActive

Long

現在アクティブなトランザクションの合計数。アクティブなトランザクションは、少なくとも1つの変更されたエントリを含むトランザクションとして数えられ、まだコミットまたはロールバックされていません。複数のノードがトランザクションに参加していた可能性がある場合でも、トランザクションのコーディネータ・ノードでこの数は保持されます。

TotalCommitted

Long

最後に統計がリセットされてから、トランザクション・マネージャがコミットしたトランザクションの合計数。複数のノードがトランザクションに参加していた可能性がある場合でも、コミットされたトランザクションのコーディネータ・ノードでこの数は保持されます。

TotalRecovered

Long

最後に統計がリセットされてから、トランザクション・マネージャがリカバリしたトランザクションの合計数。複数のノードがトランザクションに参加していた可能性がある場合でも、リカバリされたトランザクションのコーディネータ・ノードでこの数は保持されます。

TotalRolledback

Long

最後に統計がリセットされてから、トランザクション・マネージャがロールバックしたトランザクションの合計数。複数のノードがトランザクションに参加していた可能性がある場合でも、ロールバックされたトランザクションのコーディネータ・ノードでこの数は保持されます。

TotalTransactionMillis

Long

アクティブなトランザクションでかかった累積時間(ミリ秒)。

TimeoutMillis

Long

トランザクション・タイムアウト値(ミリ秒)。この値は、値の設定後に取得されたトランザクション接続にのみ適用されます。この属性は、現時点ではサポートされていません。

TransactionManagerMBeanには、すべてのトランザクション・マネージャの統計をリセットするresetStatisticsという単一操作が組み込まれています。

29.5 Coherenceリソース・アダプタの使用

Coherenceには、Coherenceキャッシュに接続するために使用するJ2EE Connector Architecture (J2CA) 1.5準拠のリソース・アダプタが組み込まれています。このリソース・アダプタは、Coherenceトランザクション・フレームワークの接続APIを活用するため、デフォルトのトランザクション保証が用意されています。さらに、リソース・アダプタには、Coherenceがグローバル・トランザクションに参加できるXAが完全にサポートされています。グローバル・トランザクションは、1つ以上のリソース・マネージャが管理する作業の単位で、WebLogic ServerまたはOC4Jとともに組み込まれたトランザクション・マネージャなど、外部トランザクション・マネージャによって制御および調整されます。

リソース・アダプタは標準リソース・アダプタ・アーカイブ(RAR)としてパッケージ化され、coherence-transaction.rarと名付けられています。リソース・アダプタはCOHERENCE_HOME/libの中にあり、J2CA 1.5と互換性のあるすべてのJava EEコンテナにデプロイできます。リソース・アダプタには、専用のリソース・アダプタ・デプロイメント・ディスクリプタ(WebLogic用はweblogic-ra.xml、OC4J用はoc4j-ra.xml)が組み込まれ、変更しないでこれらのプラットフォームにデプロイできます。RARに組み込むことができる専用のリソース・アダプタ・ディスクリプタの定義の詳細は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。

注意:
Coherenceには、後方互換性のためにcoherence-tx.rarリソース・アダプタが引き続き組み込まれます。ただし、アプリケーションではXAを完全にサポートするcoherence-transaction.rarリソース・アダプタを使用されることを強くお薦めします。CoherenceのCacheAdapterクラスを使い慣れている場合には、どちらのリソース・アダプタを引き続き使用してもかまいません。「トランザクション用のCoherenceキャッシュ・アダプタの使用」を参照してください。

この項には次のトピックが含まれます:

- トランザクション内でのキャッシュ操作の実行

- アプリケーションのパッケージ化

- トランザクション用のCoherenceキャッシュ・アダプタの使用

29.5.1 トランザクション内でのキャッシュ操作の実行

Java EEアプリケーション・コンポーネント(サーブレット、JSPおよびEJB)では、Coherenceリソース・アダプタを使用して、トランザクション内でキャッシュ操作を実行します。リソース・アダプタは、ローカル・トランザクションとグローバル・トランザクションの両方をサポートします。ローカル・トランザクションは、Coherenceキャッシュにのみスコープが設定されていてグローバル・トランザクションに参加できないトランザクションの中でキャッシュ操作を実行する場合に使用します。グローバル・トランザクションは、トランザクションに参加している複数のリソースの結果に基づいて自動的にコミットまたはロールバックするキャッシュ操作を実行する場合に使用します。

すべてのJavaEEアプリケーション・コンポーネントのように、Java Naming and Directory Interface (JNDI) APIはリソース・アダプタの接続ファクトリの検索に使用されます。接続ファクトリはCoherenceキャッシュへの論理接続の取得に使用されます。

次の例では、Coherenceリソース・アダプタを使用してグローバル・トランザクション内でキャッシュ操作を実行する方法を示します。例29-9は、コンテナ管理のトランザクション(CMT)の使用例です。この場合、コンテナではすべてのメソッドが確実にグローバル・トランザクションの範囲内で実行しています。例29-10は、ユーザー制御トランザクションの例です。この場合、アプリケーション・コンポーネントではJavaトランザクションAPI (JTA)を使用してトランザクションの境界を手動で定めます。

トランザクションでは、トランザクション・キャッシュ・スキームをキャッシュ構成ファイル内で定義する必要があります。これらの例では、例29-4で定義されたトランザクション・キャッシュを使用しています。

例29-9 CMT使用時のトランザクションの実行

Context initCtx = new InitialContext();ConnectionFactory cf = (ConnectionFactory)
initCtx.lookup("java:comp/env/eis/CoherenceTxCF");

Connection con = cf.createConnection("TransactionalCache");

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.delete("key1", null);
cache.insert("key1", "value1");
}
finally
{
con.close();
}

例29-10 ユーザー制御トランザクションの実行

Context initCtx = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)
initCtx.lookup("java:comp/env/eis/CoherenceTxCF");

UserTransaction ut = (UserTransaction) new
InitialContext().lookup("java:comp/UserTransaction");
ut.begin();

Connection con = cf.createConnection("TransactionalCache");

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.delete("key1", null);
cache.insert("key1", "value1");
ut.commit();
}

catch (Exception e)
{
ut.rollback();
throw e;
}

finally
{
con.close();
}

29.5.1.1 Coherence接続の作成

アプリケーションでは、com.tangosol.coherence.ConnectionFactoryインタフェースを使用して、Coherenceクラスタへの接続を作成します。このインタフェースのインスタンスは、JNDIルックアップを使用して取得します。例29-10に示した次のコード・サンプルでは、java:comp/env/eis/CoherenceTxCFネームスペースにバインドされた接続ファクトリのJNDIルックアップを実行します。

Context initCtx = new InitialContext();ConnectionFactory cf = (ConnectionFactory)
initCtx.lookup("java:comp/env/eis/CoherenceTxCF");

ConnectionFactoryは、com.tangosol.coherence.transaction.Connectionインスタンスの作成に使用されます。Connectionインスタンスは、Coherenceサービスへの論理接続を表します。

Connection con = cf.createConnection("TransactionalCache");

creatConnection(ServiceName)メソッドは、トランザクション・サービスのメンバーである接続を作成します。サービス名は、この接続が属するトランザクション・サービスを示すStringで、これはキャッシュ構成ファイル内の<transactional-scheme>で定義されるサービス名にマップする必要があります。トランザクション・キャッシュ・スキームの定義およびサービス名の指定の詳細は、「トランザクション・キャッシュの定義」を参照してください。

Connectionインスタンスには常に、接続内にスコープ設定された関連トランザクションがあります。新規トランザクションは、トランザクションが完了したときに起動します。次のデフォルトの動作は、接続に関連付けられています。Connectionインタフェース、およびデフォルト設定の変更の詳細は、「トランザクション接続の使用」を参照してください。

- 接続はデフォルトで自動コミット・モードです。つまり、各文は個別トランザクション内で実行され、文が完了するときトランザクションはコミットされ、接続は新規トランザクションに関連付けられます。

注意:
接続がグローバル・トランザクションで使用されると、自動コミット・モードは無効になり、有効化できません。すべてのキャッシュ操作は、単一のトランザクションで実行され、1つの単位としてコミットまたはロールバックします。また、Connectionインタフェースのcommitメソッドおよびrollbackメソッドは、接続がグローバル・トランザクションに参加している場合には使用できません。

- 接続の分離レベルは、READ_COMMITTEDに設定されています。トランザクションは、他のトランザクションからコミットされたデータのみを表示できます。

- 即時モードはデフォルトで有効にされています。これは、操作ごとにクラスタへただちにフラッシュされ、バッチ処理でフラッシュされるようにキューに配置されないということです。

- デフォルトのトランザクション・タイムアウトは300秒です。

注意:
接続がグローバル・トランザクションで使用されると、接続に関連付けられているトランザクション・タイムアウトは、コンテナのJTA構成で設定されたトランザクション・タイムアウト値でオーバーライドされます。接続がグローバル・トランザクションに参加しているときに、アプリケーションが接続上でトランザクション・タイムアウト値を設定しようとすると、その試行は無視され、警告メッセージが表示されて、トランザクション・タイムアウトが設定できないことが示されます。接続上に設定された元のタイムアウト値は、グローバル・トランザクションが完了した後に回復します。

29.5.1.2 名前付きキャッシュの取得

com.tangosol.coherence.transaction.OptimisticNamedCacheインタフェースは、NamedCacheインタフェースを拡張したものです。これは、慣例により名付けられたキャッシュ操作をすべてサポートし、更新オブジェクト、削除オブジェクトおよび挿入オブジェクトに対する独自の操作をキャッシュに追加します。トランザクションの実行時には、すべてのキャッシュ・インスタンスがこのタイプから派生する必要があります。例29-10に示した次のコード・サンプルは、MyTxCacheという名前付きキャッシュを取得し、そのキャッシュに対して操作を実行することを示しています。キャッシュは、キャッシュ構成ファイルで定義する必要があります。

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.delete("key1", null);
cache.insert("key1", "value1");

注意:
OptimisticNamedCacheは、独自のロック戦略を使用するため、ConcurrentMapインタフェースからの操作を拡張しません。

29.5.1.3 トランザクション境界の設定

ユーザー制御トランザクションを実行するアプリケーション・コンポーネントは、JNDIルックアップを使用してJTA UserTransactionインタフェースのインスタンスを取得します。このインタフェースには、トランザクションの境界を定めるメソッドが用意されています。例29-10に示した次のコード・サンプルでは、UserTransactionインスタンスを取得してトランザクションの境界を定める処理を示しています。

UserTransaction ut = (UserTransaction) new
InitialContext().lookup("java:comp/UserTransaction");

ut.begin();
Connection con = cf.createConnection("TransactionalCache");

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.delete("key1", null);
cache.insert("key1", "value1");
ut.commit();

前述のコードは、接続と名前付きキャッシュがトランザクション境界内に存在する一般的なシナリオを示しています。ただし、リソース・アダプタは、トランザクション境界にまたがって接続を使用し、グローバル・トランザクションの起動前に接続を取得するというシナリオもサポートしています。例:

Connection con = cf.createConnection("TransactionalCache");

try
{
OptimisticNamedCache cache = con.getNamedCache("MyTxCache");

cache.delete("key1", null);

UserTransaction ut = (UserTransaction) new
InitialContext().lookup("java:comp/UserTransaction");

ut.begin();
cache.insert("key1", "value1");
ut.commit();

29.5.2 アプリケーションのパッケージ化

この項では、Coherenceリソース・アダプタを使用するJavaEEアプリケーションをパッケージ化して、JavaEEアプリケーションがアプリケーション・サーバーにデプロイできるようにする手順を説明します。この項には次のトピックが含まれます:

- 接続ファクトリのリソース参照の構成

- リソース・アダプタのモジュール参照の構成

- 必要なライブラリの組込み

29.5.2.1 接続ファクトリのリソース参照の構成

アプリケーション・コンポーネントには、リソース・アダプタの接続ファクトリのリソース参照が用意されている必要があります。EJBの場合、リソース参照はejb-jar.xmlデプロイメント・ディスクリプタで定義します。サーブレットとJSPの場合、リソース参照はweb.xmlデプロイメント・ディスクリプタで定義します。次のサンプルは、リソース・アダプタの接続ファクトリのリソース参照の定義を示したもので、例29-10のコードに適用されます。

<resource-ref>
<res-ref-name>eis/CoherenceTxCF</res-ref-name>
<res-type>
com.tangosol.coherence.transaction.ConnectionFactory
</res-type>
<res-auth>Container</res-auth>
</resource-ref>

多くのアプリケーション・サーバーでは、Java EEアプリケーション・コンポーネントの標準的なデプロイメント・ディスクリプタ以外に、専用のデプロイメント・ディスクリプタも必要です。たとえば、WebLogic Serverリソース参照は、weblogic.xmlファイルとweblogic-ejb-jar.xmlファイルでそれぞれ定義されています。

<reference-descriptor>
<resource-description>
<res-ref-name>eis/CoherenceTxCF</res-ref-name>
<jndi-name>tangosol.coherenceTx</jndi-name>
</resource-description>
</reference-descriptor>

アプリケーション・コンポーネントの専用デプロイメント・ディスクリプタの使用法、および依存性インジェクションまたは注釈を使用してリソース参照を定義するための代替方法の詳細は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。

29.5.2.2 リソース・アダプタのモジュール参照の構成

JavaEEアプリケーションには、Coherenceリソース・アダプタのモジュール参照が用意されている必要があります。モジュール参照は、EARのapplication.xmlファイルで定義します。モジュール参照は、EARファイル内のCoherence RARファイル(coherence-transaction.rar)の場所をポイントします。たとえば、次の定義はEARファイルのルートに配置されたCoherenceリソース・アダプタのRARファイルをポイントします。

<application>
...
<module>
<connector>coherence-transaction.rar</connector>
</module>
...
</application>

多くのアプリケーション・サーバーでは、Java EEアプリケーションの標準的なデプロイメント・ディスクリプタ以外に、専用のデプロイメント・ディスクリプタも必要です。たとえば、Coherenceリソース・アダプタは、WebLogic Serverのweblogic-application.xmlファイルで次のように定義されています。

<weblogic-application>
<classloader-structure>
...
<module-ref>
<module-uri>coherence-transaction.rar</module-uri>
</module-ref>
...
</classloader-structure>
</weblogic-application>

アプリケーションの専用デプロイメント・ディスクリプタの使用方法の詳細は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。

29.5.2.3 必要なライブラリの組込み

Coherenceリソース・アダプタを使用するJavaEEアプリケーションには、EARファイル内にcoherence-transaction.rarファイルとcoherence.jarファイルが含まれている必要があります。次の例では、ライブラリをEARファイルのルートに配置しています。

/
/coherence-transaction.rar
/coherence.jar

WebLogicサーバーにデプロイする際には、coherence.jarファイルはEARファイルの/APP-INF/libディレクトリに配置される必要があります。例:

/
/coherence-transaction.rar
/APP-INF/lib/coherence.jar

このデプロイメントのシナリオでは、1つのCoherenceクラスタ・ノードをEAR内のすべてのアプリケーション・コンポーネントが共有します。Coherenceデプロイメントの別のオプションは、『Oracle Coherenceの管理』を参照してください。

29.5.3 トランザクション用のCoherenceキャッシュ・アダプタの使用

Coherence CacheAdapterクラスは、トランザクションの作成に代替クライアントを使用する方法を提供するもので、coherence-tx.rarリソース・アダプタの使用時に必要となります。新規のcoherence-transaction.rarリソース・アダプタもCacheAdapterクラス(変更したものもいくつか含む)をサポートし、このクラスを使い慣れている人は、新規のリソース・アダプタの利点を活用できます。ただし、アプリケーションでは、Coherenceリソース・アダプタをネイティブに使用することをお薦めします。そうすると、より強力なトランザクションのサポートが実現します。どちらのリソース・アダプタの例も、この項で説明しています。

例29-11では、CacheAdapterクラスを新規のcoherence-transaction.rarリソース・アダプタで使用するときの、トランザクション内のキャッシュ操作の実行を示しています。この例の場合、トランザクション・キャッシュMyTxCacheは、キャッシュ構成ファイルで構成する必要があります。キャッシュは、サービス名TransactionalCacheでトランザクション・キャッシュ・スキームにマップする必要があります。トランザクション・キャッシュ・スキームの定義の詳細は、「トランザクション・キャッシュの定義」を参照してください。

例29-11 coherence-transaction.rar使用時のCacheAdapterクラスの使用

Context initCtx = new InitialContext();

CacheAdapter adapter = new CacheAdapter(initCtx,
"java:comp/env/eis/CoherenceTxCCICF", 0, 0, 0);

adapter.connect("TransactionalCache", "scott", "tiger");

try
{
UserTransaction ut = (UserTransaction) new
InitialContext().lookup("java:comp/UserTransaction");

ut.begin();
OptimisticNamedCache cache =
(OptimisticNamedCache) adapter.getNamedCache("MyTxCache",
getClass().getClassLoader());
cache.delete("key", null);
cache.insert("key", "value");
ut.commit();

}
finally
{
adapter.close();
}

例29-12では、CacheAdapterクラスをcoherence-tx.rarリソース・アダプタで使用するときの、トランザクション内のキャッシュ操作の実行を示しています。

例29-12 coherence-tx.rar使用時のCacheAdapterクラスの使用

String          key = "key";
Context         ctx = new InitialContext();
UserTransaction tx  = null;
try
{
// the transaction manager from container
tx = (UserTransaction) ctx.lookup("java:comp/UserTransaction");
tx.begin();

// the try-catch-finally block below is the block of code
// that could be on an EJB and therefore automatically within
// a transactional context
CacheAdapter adapter = null;
try
{
adapter = new CacheAdapter(ctx, "tangosol.coherenceTx",
CacheAdapter.CONCUR_OPTIMISTIC,
CacheAdapter.TRANSACTION_GET_COMMITTED, 0);

NamedCache cache = adapter.getNamedCache("dist-test",
getClass().getClassLoader());

int n = ((Integer)cache.get(key)).intValue();
cache.put(key, new Integer(++n));
}
catch (Throwable t)
{
String sMsg = "Failed to connect: " + t;
System.err.println(sMsg);
t.printStackTrace(System.err);
}
finally
{
try
{
adapter.close();
}
catch (Throwable ex)
{
System.err.println("SHOULD NOT HAPPEN: " + ex);
}
}
}
finally
{
try
{
tx.commit();
}
catch (Throwable t)
{
String sMsg = "Failed to commit: " + t;
System.err.println(sMsg);
}
}

30 パーティションの処理

この章では、データ・アフィニティの使用方法と、デフォルトのパーティション設定の変更方法について説明します。この説明は、分散キャッシュに固有のものです。

この章には次の項が含まれます:

- データ・アフィニティの指定

- パーティションの数の変更

- パーティション分散戦略の変更

30.1 データ・アフィニティの指定

この項には次のトピックが含まれます:

- データ・アフィニティの概要

- KeyAssociationを使用したデータ・アフィニティの指定

- KeyAssociatorを使用したデータ・アフィニティの指定

- キー・アソシエーション・チェックの遅延

- アフィニティの使用例

30.1.1 データ・アフィニティの概要

データ・アフィニティは、関連するキャッシュ・エントリ・グループが単一のキャッシュ・パーティションに含まれることを保証する概念を表します。これにより、フォルト・トレランスを犠牲にすることなく、すべての関連データが単一のプライマリ・キャッシュ・ノードで管理されます。

アフィニティは、(同じキャッシュ・サービスで管理されている通常のケースでは)複数のキャッシュにまたがります。たとえば、Order-LineItemのようなマスター/ディテール・パターンでは、Orderオブジェクトが、関連付けられているLineItemオブジェクトのコレクション全体と共存する場合があります。

データ・アフィニティを使用する利点は2つあります。まず、一連の関連項目に対する問合せおよびトランザクションを、単一のキャッシュ・ノードのみで管理できます。また、すべての並行操作はローカルで管理可能であり、クラスタ化された同期処理は不要です。

アフィニティにより、キャッシュ問合せ、InvocableMapの操作、およびgetAll、putAll、removeAllなどのメソッドを含むCoherenceのいくつかの標準的な操作を効率的に実行できます。

注意:
データ・アフィニティは、値ではなくエントリ・キーに関して指定されます。その結果、対応付け情報がキー・クラスに存在している必要があります。同様に、対応付けロジックは、値クラスではなくキー・クラスに適用されます。

アフィニティは、パーティション・キーとの関係で指定されます。前述のOrder-LineItemの例では、Orderオブジェクトが正常にパーティション化され、LineItemオブジェクトは適切なOrderオブジェクトと関連付けられます。

この関連付けは実際の親キーに対して直接実行する必要はなく、親キーの機能マッピングになるだけで十分です。親キーの単一フィールド(一意でない場合でも可能)、または親キーの整数ハッシュとなる場合もあります。重要なのは、すべての子キーで同じ関連キーが返されることだけです。関連キーが実際のキーであるかどうかは重要ではありません(このキーは、単なるグループID)。これにより、親キーの情報を含まない子キー・クラスのサイズの影響を最小限に抑えることができます(導出データであるため、データ・サイズを明示的に決定できるほか、キー動作への影響もありません)。対応付けを汎用化しすぎると(同じグループIDに関連付けられたキーが多すぎる場合)、均一に分散されないことがあります(親キーに関係なく、すべての子キーが同じ対応付けキーを返した場合、子キーはすべて単一パーティションに割り当てられ、クラスタ全体には分散されない)。

一連のキャッシュ・エントリが共存していることを確認するには、2つの方法があります。対応付けが、値ではなくキャッシュ・キーに基づいていることを確認します(そうでない場合、キャッシュ・エントリを更新するとパーティションが変更される可能性がある)。また、Orderが子LineItemsと同じ場所にある場合、Coherenceは現在、複数のキャッシュにまたがる複合操作(単一の呼び出しリクエストcom.tangosol.util.InvocableMap.EntryProcessor内でのOrderおよびLineItemsのコレクションの更新など)をサポートしていないことに注意してください。

30.1.2 KeyAssociationを使用したデータ・アフィニティの指定

アプリケーション定義のキーでは、キャッシュ・キーのクラスは次のようにcom.tangosol.net.cache.KeyAssociationを実装できます。

例30-1 キー・アソシエーションの作成

import com.tangosol.net.cache.KeyAssociation;

public class LineItemId implements KeyAssociation
{
// {...}

public Object getAssociatedKey()
{
return getOrderId();
}

// {...}
}

30.1.3 KeyAssociatorを使用したデータ・アフィニティの指定

アプリケーションでは、カスタムのKeyAssociatorも指定できます。

例30-2 カスタムのKeyAssociator

import com.tangosol.net.partition.KeyAssociator;

public class LineItemAssociator implements KeyAssociator
{
public Object getAssociatedKey(Object oKey)
{
if (oKey instanceof LineItemId)
{
return ((LineItemId) oKey).getOrderId();
}
else if (oKey instanceof OrderId)
{
return oKey;
}
else
{
return null;
}
}

public void init(PartitionedService service)
{
}
}

キー・アソシエータは、NamedCacheに関して、そのキャッシュを定義した<distributed-scheme>要素で構成されます。

例30-3 キー・アソシエータの構成

<distributed-scheme>
...
<key-associator>
<class-name>LineItemAssociator</class-name>
</key-associator>
</distributed-scheme>

30.1.4 キー・アソシエーション・チェックの遅延

キー・アソシエーションは、クラスタ上と拡張クライアント上のいずれでも実装できます。拡張クライアントを使用する場合、最適な方法はそのクライアント上でキー・アソシエーションを実装することです。これにより、キーはクラスタに送信される前に処理されて最適なパフォーマンスが得られます。キー・アソシエーションは、デフォルトではクライアント上で処理されます。クラスタ上でのキー・アソシエーションに依存している既存のクライアント実装で、クラスタ上でキー・クラスが処理されるように強制するには、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>

注意:
パラメータがtrueに設定されている場合、キー・クラス実装は、キー・アソシエーションを使用していない場合でもクラスタ上に存在する必要があります。

.NETおよびC++クライアントでのキー・アソシエーションの遅延に関する詳細は、それぞれ、『Oracle Coherenceリモート・クライアントの開発』(.NETおよびC++)を参照してください。

30.1.5 アフィニティの使用例

例30-4は、アフィニティを使用してより効率的な問合せ(NamedCache.entrySet(Filter))およびキャッシュ・アクセス(NamedCache.getAll(Collection))を作成する方法を示しています。

例30-4 アフィニティを使用した効率的な問合せの作成

OrderId orderId = new OrderId(1234);

// this Filter is applied to all LineItem objects to fetch those
// for which getOrderId() returns the specified order identifier
// "select * from LineItem where OrderId = :orderId"Filter filterEq = new EqualsFilter("getOrderId", orderId);

// this Filter directs the query to the cluster node that currently owns
// the Order object with the given identifier
Filter filterAsc = new KeyAssociatedFilter(filterEq, orderId);

// run the optimized query to get the ChildKey objects
Set setLineItemKeys = cacheLineItems.keySet(filterAsc);

// get all the Child objects immediately
Set setLineItems = cacheLineItems.getAll(setLineItemKeys);

// Or remove all immediately
cacheLineItems.keySet().removeAll(setLineItemKeys);

30.2 パーティションの数の変更

分散キャッシュ・サービスのデフォルト・パーティション数は257パーティションです。分散キャッシュ・サービスをホストするクラスタ内のキャッシュ・サーバーはそれぞれ均等な数のパーティションを管理します。たとえば、4台のキャッシュ・サーバーからなるクラスタ内の各キャッシュ・サーバーは、64個のパーティションを管理します。デフォルト・パーティション数は、通常、最大16台のキャッシュ・サーバーを含むクラスタで許容されます。ただし、最適なパフォーマンスを確保するには、大きいクラスタほど多くのパーティションが必要です。

分散キャッシュ・サービスのパーティション数を変更するには、キャッシュ構成ファイルを編集し、サービスに使用するパーティション数を含む<partition-count>要素を<distributed-scheme>要素内に追加します。例:

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>DistributedCache</service-name>
<partition-count>1181</partition-count>
...
</distributed-scheme>

パーティション数の決定

パーティション数を選択するための正確な計算式はありません。理想的なパーティション数は、各クラスタ・メンバー上のパーティション数と、各パーティションによって保持されるデータ量とのバランスが取れているものです。パーティション数を選択する際は次のガイドラインを使用し、常にテストを実行してそのパーティション数でパフォーマンスが低下しないことを確認します。

- パーティション数は常に素数にする必要があります。素数のリストは、http://primes.utm.edu/lists/にあります。

- パーティション数は十分な大きさにして、各メンバーによって管理されるパーティション数が少なすぎることのないバランスのとれた分散がサポートされるようにする必要があります。たとえば、各メンバー上のパーティションが2つのみになるパーティション数では制約的すぎます。

- パーティション数は、転送オーバーヘッドおよび多数のパーティション転送(転送単位は1パーティション)の記録処理にネットワーク帯域幅が浪費されるほど大きくしないでください。たとえば、数千のパーティションを新しいキャッシュ・サーバー・メンバーに転送すると、大量のネットワーク・リソースが必要になり、特に起動時にクラスタ・パフォーマンスが低下することがあります。

- 1つのパーティションによって管理されるデータ量が大きすぎないようにしてください(1つのパーティションが管理するデータが多くなるほどパーティションのプロモーションおよび転送のコストが高くなります)。1つのパーティションによって管理されるデータ量は、キャッシュ・サーバーで使用可能なメモリー量によってのみ制限されます。通常は、パーティションの制限が50MBあれば、良好なパフォーマンスが保証されます。大規模なクラスタでは、パーティションの制限に50MBから100MB (速度が10GbE以上でさらに大きな容量)が使用されることもあります。さらに大きな制限を使用することもできますが、転送の待機時間がわずかに増加することと、オーバーヘッド領域が増加して大きなヒープが必要になることを理解しておいてください。

例として、4GBのヒープで構成され、索引を含まないプライマリ・データを約1.3GB格納する(ヒープの2/3をバックアップおよびスクラッチ領域のために残しておく)キャッシュ・サーバーを考えてみましょう。決定したパーティションの制限が控え目な25MBである場合、1台のキャッシュ・サーバーで問題なく53個のパーティションを使用できます(1365MB/25MBが切り捨てられてその前の素数になります)。したがって、20台のキャッシュ・サーバーを含む1つのクラスタは問題なく1051個のパーティションを使用でき(53*20が切り捨てられてその前の素数になる)、約25GBのプライマリ・データを格納します。100台のキャッシュ・サーバーからなる1つのクラスタは問題なく5297個のパーティションを使用でき、約129GBのプライマリ・データを格納できます。

30.3 パーティション分散戦略の変更

パーティション分散では、パーティションがどのように、記憶域が有効なクラスタ・メンバーに割り当てられるかを定義します。使用可能な分散スタイルには次の2つがあります。

- 自律型分散 - この分散方法では、記憶域が有効な各サービス・メンバーは、サービスのバランスを取るために、使用可能なパーティションについて各自のバランスの取れた割当てを計算し、分散をリクエストします。

- 集中管理型分散 – この分散戦略では、集中パーティション割当て戦略を使用して、記憶域が有効な各メンバーによってグローバルな分散決定が行われるようにします。集中管理型の分散は、より表現力のある分散アルゴリズムを使用することを可能にし、サービスに関するより完全でグローバルなビューを使用します。

カスタム集中管理型分散戦略は、com.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装することで作成できます。

30.3.1 パーティション割当て戦略の指定

使用可能な事前定義済パーティション割当て戦略は次のとおりです。

- legacy - (非推奨)レガシー割当て戦略では、パーティション分散は各クラスタ・メンバーで個々に管理されます。レガシー・パーティション割当て戦略は、自律型分散戦略です。

- simple - (デフォルト)単純な割当て戦略は、マシンの安全性を確保しながらパーティション分散のバランスを取ることを試みる集中管理型分散戦略であり、レガシー戦略よりも決定論的で効率的です。

- mirror:<service-name> – ミラー割当て戦略は、サービスのパーティションを、指定されたサービスのパーティションと共存させることを試みる集中管理型分散戦略です。この戦略は、キーを関連付けられたクロスサービス・キャッシュ・アクセスがメンバーに対してローカルのままになる可能性を高めるために使用されます。

- custom - com.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装するクラス。

特定のパーティション・キャッシュ・サービスに対してパーティション割当て戦略を構成するには、分散キャッシュ定義内に<partition-assignment-strategy>要素を追加します。

<distributed-scheme>
...
<partition-assignment-strategy>mirror:<MyService>
</partition-assignment-strategy>
...
</distributed-scheme>

分散キャッシュ・サービス・タイプのすべてのインスタンスに対してパーティション割当て戦略を構成するには、オペレーション・オーバーライド・ファイル内のパーティション・キャッシュ・サービスのpartition-assignment-strategy初期化パラメータをオーバーライドします。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="21">
<param-name>partition-assignment-strategy</param-name>
<param-value>mirror:<MyService></param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

30.3.2 カスタムのパーティション割当て戦略の有効化

カスタムのパーティション割当て戦略を指定するには、<partition-assignment-strategy>要素内に<instance>サブ要素を含めて、com.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装する完全修飾クラス名を指定します。カスタム・クラスは、com.tangosol.net.partition.SimpleAssignmentStrategyクラスを拡張することもできます。<instance>要素の使用の詳細は、「instance」を参照してください。次の例では、MyPAStrategyクラスで実装されるパーティション割当て戦略を有効にします。

<distributed-scheme>
...
<partition-assignment-strategy>
<instance>
<class-name>package.MyPAStrategy</class-name>
</instance>
</partition-assignment-strategy>
...
</distributed-scheme>

代替案として、<instance>要素では、PartitionAssignmentStrategyインスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次の例では、MyPAStrategyFactoryクラスでgetStrategyメソッドを使用して、戦略のインスタンスを取得します。

<distributed-scheme>
...
<partition-assignment-strategy>
<instance>
<class-factory-name>package.MyPAStrategyFactory</class-factory-name>
<method-name>getStrategy</method-name>
</instance>
</partition-assignment-strategy>
...
</distributed-scheme>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、iMaxTimeパラメータが2000に設定されます。

<distributed-scheme>
...
<partition-assignment-strategy>
<instance>
<class-name>package.MyPAStrategy</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</instance>
</partition-assignment-strategy>
...
</distributed-scheme>

31 スレッド実行の管理

この章では、タスク・タイムアウトを使用してCoherenceサービス・スレッドの実行動作を制御する方法と、カスタム実行処理のためのPriorityTask APIについて説明します。

この章には次の項が含まれます:

- 優先度タスクの概要

- 優先度タスク・タイムアウトの設定

- 優先度タスク実行オブジェクトの作成

31.1 優先度タスクの概要

Coherenceの優先度タスクを使用すると、レスポンス時間の要件が厳しいアプリケーションで、Coherence内のプロセス実行をより詳細に制御できます。たとえば、実行およびリクエストのタイムアウトを構成して、実行時間の長いスレッドの待機時間を制限できます。さらに、カスタム・タスクAPIを使用して、アプリケーションで問合せ処理を制御できます。これらの機能は、データ・グリッドのパフォーマンスおよびスループットに大きく影響する可能性があるため、細心の注意を払って使用してください。

31.2 優先度タスク・タイムアウトの設定

Coherenceのタスク実行タイムアウトの構成時には注意が必要です。この機能を実装する前であるため、タイムアウト例外を処理していないCoherenceアプリケーションの場合は特に当てはまります。たとえば、CacheStore内のライトスルーがブロックされ、構成済のタイムアウト値を超えた場合、Coherenceタスク・マネージャはスレッドの実行を中断しようとし、例外がスローされます。同様に、構成したタイムアウトを問合せや集計が超えた場合も、中断されて例外がスローされます。この機能を使用するアプリケーションでは、これらの例外を正常に処理してシステムの整合性を確保する必要があります。この構成はサービスごとに実行されるため、この機能を考慮せずに設計されている既存のキャッシュやサービスでこれらの設定を変更する場合は、細心の注意を払う必要があります。

31.2.1 実行タイムアウトの構成

<request-timeout>、<task-timeout>、<task-hung-threshold>の各要素を使用して、サービスのワーカー・スレッドの実行タイムアウトを構成します。このタイムアウト設定はキャッシュ構成ファイルでサービス用に構成され、コマンド行パラメータを使用して設定することも可能です。サービス・スレッドのタイムアウト設定の詳細は、第11章「サービス・ガーディアンの使用」を参照してください。

表31-1では、実行タイムアウトの要素について説明します。

表31-1 実行タイムアウトの要素

要素名

説明

<request-timeout>

タイムアウト可能なリクエスト(たとえば、PriorityTaskインタフェースの実装)のデフォルト・タイムアウト値を指定します。ただし、リクエストのタイムアウト値は明示的に指定しません。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

1. 実行側のノード(サーバー)にリクエストを配信するための所要時間

2. タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

3. タスクの実行時間

4. クライアントに結果を返信するための所要時間

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、クラスタ化クライアント・リクエストの場合は無限タイムアウト(0s)、非クラスタ化クライアント・リクエストの場合は30秒(30s)です。

<task-timeout>

タイムアウト可能なタスク(たとえば、PriorityTaskインタフェースを実装するエントリ・プロセッサ)のデフォルト・タイムアウト値を指定します。ただし、タスク実行のタイムアウト値は明示的に指定しません。タスク実行時間はサーバー側で測定され、開始されるまでサービス・バックログ・キューで待機するための所要時間は含まれません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。zeroが指定された場合は、デフォルトのservice-guardian <timeout-milliseconds値が使用されます。

<task-hung-threshold>

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。注意: ポストされたタスクがまだ開始されていない場合は、ハングと見なされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。

次の例では、分散キャッシュ・スレッド・カウントを7、タスク・タイムアウトを5000ミリ秒、タスク・ハングしきい値を10000ミリ秒に設定します。

例31-1 タスク時間およびタスク・ハング構成のサンプル

<caching-schemes>
<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<thread-count>7</thread-count>
<task-hung-threshold>10000</task-hung-threshold>
<task-timeout>5000</task-timeout>
</distributed-scheme>
</caching-schemes>

クライアント・リクエスト・タイムアウトを15ミリ秒に設定します。

例31-2 クライアント・リクエスト・タイムアウト構成のサンプル

<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<request-timeout>15000ms</request-timeout>
</distributed-scheme>

注意:
request-timeoutは、常にthread-hung-thresholdやtask-timeoutより長くする必要があります。

31.2.2 コマンド行オプション

ノードのサービス・タイプのデフォルト(分散キャッシュ、起動、プロキシなど)を設定するには、コマンド行オプションを使用します。表31-2では、各オプションについて説明します。

表31-2 サービス・タイプの設定用のコマンド行オプション

オプション

説明

tangosol.coherence.replicated.request.timeout

レプリケート・キャッシュ・サービス用のデフォルトのクライアント・リクエスト・タイムアウト

tangosol.coherence.optimistic.request.timeout

オプティミスティック・キャッシュ・サービス用のデフォルトのクライアント・リクエスト・タイムアウト

tangosol.coherence.distributed.request.timeout

分散キャッシュ・サービス用のデフォルトのクライアント・リクエスト・タイムアウト

tangosol.coherence.distributed.task.timeout

分散キャッシュ・サービス用のデフォルトのサーバー実行タイムアウト

tangosol.coherence.distributed.task.hung

分散キャッシュ・サービスでスレッドがハングと報告されるまでのデフォルト時間

tangosol.coherence.invocation.request.timeout

起動サービス用のデフォルトのクライアント・リクエスト・タイムアウト

tangosol.coherence.invocation.task.hung

起動サービスでスレッドがハングと報告されるまでのデフォルト時間

tangosol.coherence.invocation.task.timeout

起動サービス用のデフォルトのサーバー実行タイムアウト

tangosol.coherence.proxy.request.timeout

プロキシ・サービス用のデフォルトのクライアント・リクエスト・タイムアウト

tangosol.coherence.proxy.task.timeout

プロキシ・サービス用のデフォルトのサーバー実行タイムアウト

tangosol.coherence.proxy.task.hung

プロキシ・サービスでスレッドがハングと報告されるまでのデフォルト時間

31.3 優先度タスク実行オブジェクトの作成

PriorityTaskインタフェースを使用すると、スレッド・プールを使用してタスク実行のスケジュールを指定する順序を制御したり、タスク実行時間を指定された限度まで保持できます。また、PriorityTaskのインスタンスは、通常、InvocableインタフェースまたはRunnableインタフェースも実装します。優先度タスクの実行と関連があるのは、タスクのバック・ログが存在する場合のみです。

APIでは、タスクの実行をスケジュールする次のような方法が定義されています。

- SCHEDULE_STANDARD: タスクの実行は、自然な(リクエストの受信時間に基づいた)順序でスケジュールされます。

- SCHEDULE_FIRST: タスクは、スケジュール優先度が同等以下のタスクの前にスケジュールされ、いずれかのワーカー・スレッドが使用可能になるとすぐに実行されます。

- SCHEDULE_IMMEDIATE: タスクは、アイドル状態のワーカー・スレッドによってただちに実行されます。すべてアクティブな場合は、このタスクを実行するための新しいスレッドが作成されます。

31.3.1 優先度タスク・オブジェクト作成用のAPI

Coherenceには、優先度タスク・オブジェクトの作成に役立つ次のクラスがあります。

- PriorityProcessorは、カスタム・エントリ・プロセッサを作成する際に拡張できます。

- PriorityFilterは、カスタム優先度フィルタを作成する際に拡張できます。

- PriorityAggregatorは、カスタム集計を作成する際に拡張できます。

- PriorityTaskは、優先度起動クラスを作成する際に拡張できます。

これらのクラスの拡張後、開発者はいくつかのメソッドを実装する必要があります。getRequestTimeoutMillis、getExecutionTimeoutMillisおよびgetSchedulingPriorityの戻り値は、クラスごとにアプリケーションの構成パラメータに保存する必要があります。これらのメソッドについて、表31-3に説明します。

表31-3 タスク・タイムアウトをサポートするメソッド

メソッド

説明

public long getRequestTimeoutMillis()

コール元スレッドがリクエスト実行の結果を待機することが可能な最大時間を取得します。リクエスト時間は、リクエストが実行のために対応するサーバー・ノードに送信された時点からの経過時間として、クライアント側で測定します。これには、リクエストを実行ノードに配信するまでの時間、タスクを受信しサービス・キューに配置してから実行が開始されるまでの間隔、タスク実行時間、結果をクライアントに戻すための時間が含まれます。TIMEOUT_DEFAULT値は、対応するサービス用に構成されたデフォルトのタイムアウト値を示し、TIMEOUT_NONE値は、タスクの実行が完了するまで、またはgetExecutionTimeoutMillis()値で指定されているタスク実行タイムアウトに従って、サービスがタスクの実行をキャンセルするまで、クライアント・スレッドが無限に待機できることを示します。

public long getExecutionTimeoutMillis()

対応するサービスによって停止されるまでの、このタスクの実行が許可されている最大時間を取得します。TIMEOUT_DEFAULT値は、対応するサービス用に構成されたデフォルトのタイムアウト値を示し、TIMEOUT_NONE値は、このタスクが無限に実行可能であることを示します。指定した時間が経過するまでにタスクが完了していない場合、サービスがThread.interrupt()メソッドを使用して実行を停止しようとします。スレッドを中断してもタスクが終了しない場合は、runCanceledメソッドがコールされます。

public int getSchedulingPriority()

このタスクのスケジュールの優先度を取得します。有効な値は、SCHEDULE_STANDARD、SCHEDULE_FIRST、SCHEDULE_IMMEDIATEです。

public void runCanceled(boolean fAbandoned)

このメソッドがコールされるのは、このタスクを中断しようとする処理がすべて失敗した場合、または実行の機会がまったくないまま実行がキャンセルされた場合です。このメソッドは通常、サービス・スレッドでコールされ、実装によって遅延が発生すると対応するサービスも遅延するため、細心の注意を払って実装する必要があります。

31.3.2 タスク・タイムアウトによってスローされるエラー

タスク・タイムアウトが発生すると、ノードでRequestTimeoutExceptionが発生します。例31-3は、スローされる可能性のある例外を示しています。

例31-3 タスク・タイムアウトによってスローされる例外

com.tangosol.net.RequestTimeoutException: Request timed out after 4015 millis
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.checkRequestTimeout(Service.CDB:8)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.poll(Service.CDB:52)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.poll(Service.CDB:18)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.InvocationService.query(InvocationService.CDB:17)
at com.tangosol.coherence.component.util.safeService.SafeInvocationService.query(SafeInvocationService.CDB:1)

32 リエントラント・コールに対する制約

この章では、サービス・リエントラント・コールに関する制約事項とサービス・スレッド間でコールを実行する場合の一般的なガイドラインについて説明します。

この章には次の項が含まれます:

- リエントラント・コールに対する制約の概要

- リエントラント、サービスおよびサービス・スレッド

- リエントラントおよびリスナー

32.1 リエントラント・コールに対する制約の概要

Coherenceでは、リエントラント・コールがサポートされていません。リエントラント・サービス・コールは、サービス・スレッドがリクエストを処理しようとするときにその同じサービスに対してリクエストが行われると発生します。サービスに対するリクエストはすべてインバウンド・キューを使用して配信され、Coherenceはリクエストごとに1スレッドのモデルを使用するため、リエントラント・リクエストのそれぞれが他のスレッドを消費することになります(レスポンスを待っている間はコール側のスレッドがブロックします)。用語としては再帰型に似ていますが、概念が異なるため区別する必要があります。

Coherenceのアーキテクチャは、サービスの集合に基づいています。Coherenceの各サービスは、関連付けられた構成とともに、サービスを実装するCoherenceコードで構成されています。サービスは、リクエストを受信してレスポンスを返すキューが関連付けられているスレッドの割当てプールで実行されます。

32.2 リエントラント、サービスおよびサービス・スレッド

サービスは、サービス名とサービス・タイプ(起動、レプリケート、分散など)の一意の組合せとして定義されます。たとえば、分散サービスDist-CustomersからDist-Inventoryという名前の分散サービスをコールしたり、Dist-Customersという名前の分散サービスからRepl-Catalogという名前のレプリケート・サービスをコールできます。サービス名は、<service-name>要素を使用して、キャッシュ構成ファイルで構成されます。

32.2.1 オブジェクトの親子関係

Coherenceの現在の実装では、コールがローカルであるかリモートであるかは重要ではありません。このため、親子関係の構築の効率化をサポートするキー・アソシエーションの使用法が複雑になります。キー・アソシエーションを使用して親オブジェクトとそのすべての子オブジェクトを共存させる場合は、親オブジェクトにEntryProcessorを送信して、そのEntryProcessorで(ローカルの)子オブジェクトを把握することはできません。これは、子オブジェクトが処理中である場合も同様です。

親オブジェクトと子オブジェクトの両方にアクセスするには、次のいずれかの方法を使用できます。

- 子オブジェクトを親オブジェクトに埋め込みます(集約パターンを使用)、または

- サーバー側のバッキング・マップへの直接アクセスを使用します(安全に実行するには高度な知識が必要です)、または

- 別のサービス(たとえば、PartitionedService.getKeyOwnerを使用することでターゲット指定される起動)でロジックを実行し、そのサービスからNamedCacheインタフェースを使用してデータにアクセスします、または

- リエントラント・コールが可能な別のサービスに子オブジェクトを配置します(ただし、複数の異なるキャッシュ・サービスのパーティション間にはアフィニティがないためネットワーク・アクセスが発生します)。

ほとんどの使用状況では、集約パターンの使用が最適な方法になります。ただし、この方法が(サイズの制限などによって)現実的でなく、クライアント/サーバー・モデルを使用しないで親オブジェクトと子オブジェクトの両方にアクセスする必要がある場合には、起動サービスを使用する方法が、大半の用途で最適な解決方法になります。

32.2.2 デッドロックの回避

リエントラントが許容される場合も、スレッド・プールの飽和および壊滅的なデッドロックの発生を慎重に回避する必要があります。たとえば、サービスAがサービスBをコールし、サービスBがサービスAをコールする場合、同時コールが多数発生してスレッド・プールが満杯になり、一種のデッドロックが発生する可能性があります。従来のロックと同様、アクセスに順序付けすること(たとえば、サービスAはサービスBのコールが可能であるが、サービスBはサービスAをコールできないようにする)が回避に役立ちます。

したがって:

- サービスAからサービスAをコールすることは許されません

- サービスAからサービスBをコールし、サービスBからサービスAをコールすることは技術的には可能ですが、デッドロックが発生しやすくなるため、可能なかぎり回避する必要があります。

- サービスAがサービスBを、サービスBがサービスCを、サービスCがサービスAをコールすることは、同様に制限されます

- サービスAからサービスBをコールすることは許されます

- サービスAがサービスBを、サービスBがサービスCを、サービスAがサービスCをコールすることは、同様に許されます

サービス・スレッドは、Coherence APIリクエストの実現に関連するスレッドとして定義されます。サービス・スレッドは、次のエンティティのいずれかを起動できます。

- マップ・リスナー

- メンバーシップ・リスナー

- カスタムのシリアライズ/デシリアライズ(ExternalizableLite実装など)

- バッキング・マップ・リスナー

- CacheLoader/CacheStoreモジュール

- 問合せロジック(Aggregators、Filters、ValueExtractors、Comparatorsなど)

- エントリ・プロセッサ

- トリガー

- InvocationService起動可能ファイル

これらのエンティティは、自己のサービスに対するリエントラント・コールを行いません。

32.3 リエントラントおよびリスナー

メンバーシップ・リスナーは、クラスタまたは特定のサービスに参加するアクティブなメンバー・セットを監視できます。メンバーシップ・リスナーのスレッディングは複雑になる場合があるため、メンバー・リスナーからCoherenceのサービスへのリエントラント・コールは使用しないでください。

第V部

Coherence JCache実装の使用

第V部の内容は次のとおりです。

- 第33章「Coherence JCacheの概要」

- 第34章「最初のCoherence JCacheアプリケーションの作成」

- 第35章「基本的なCoherence JCacheタスクの実行」

- 第36章「JCacheイベントの使用」

- 第37章「JCacheエントリの処理」

33 Coherence JCacheの概要

この章では、JSR-107 JCACHE - Java Caching API仕様の概要を説明します。通常、このドキュメントでは、この仕様およびAPIをJCacheと呼んでいます。JCacheの概要の項には、基本的なAPIの説明も含まれています。APIの詳細は、Java Community Process (JCP)のWebサイトからJCacheの仕様、Javaソース、JavaDocをダウンロードしてください。

https://www.jcp.org/en/jsr/detail?id=107

この章には次の項が含まれます:

- Coherence JCache実装の概要

- JCacheとNamedCacheの機能比較

- Coherence JCacheの依存性

- Coherence JCacheプロバイダの構成の概要

- JCache入門

33.1 Coherence JCache実装の概要

Coherenceには、JCacheプロバイダ実装(COHERENCE_HOME\lib\coherence-jcache.jar)が含まれています。JCacheは、Javaでキャッシュを使用する標準APIです。アプリケーション開発者はJCache API (javax.cache.*)を使用し、Coherenceは基礎となるキャッシュ機能を提供します。プロバイダ・ベースのアプローチを使用することによって、プロバイダ間の移植性が保証され、開発者は複雑なキャッシュ・システムの作成および管理ではなく、アプリケーション・ロジックに集中できるようになります。JCacheの詳細は、「JCache入門」を参照してください。

既存のCoherenceテクノロジを使用するCoherence JCacheプロバイダは、Coherence NamedCache APIのラッパーと考えることも可能です。これによって、CoherenceはJCacheインタフェースを通して多くの優れたテクノロジの再利用および公開ができるようになります。

サポートされているキャッシュ・タイプ

Coherence JCacheプロバイダは、3つのキャッシュ・タイプを提供しています:

- ローカル・キャッシュ – アプリケーション・プロセスにローカルなキャッシュです。ローカル・キャッシュに格納されるエントリは、アプリケーション・プロセスの終了後は永続化されません。ローカル・キャッシュは、local-schemeキャッシュ定義を使用して構成されるNamedCacheキャッシュに類似しています。ローカル・キャッシュの実装は、com.tangosol.coherence.jcache.localcacheパッケージで定義されています。ローカル・キャッシュの作成の詳細は、「ローカル・キャッシュの作成」を参照してください。

- パーティション・キャッシュ – Coherenceクラスタ内の複数のプロセスにパーティション化(分散)されたキャッシュです。パーティション・キャッシュに格納されるエントリは、アプリケーション・プロセスの終了後にバックアップされ、クラスタ上に永続化されます。パーティション・キャッシュは、distributed-schemeキャッシュ定義を使用して構成されるNamedCacheキャッシュに類似しています。パーティション・キャッシュの実装は、com.tangosol.coherence.jcache.partitionedcacheパッケージで定義されています。パーティション・キャッシュの作成の詳細は、「パーティション・キャッシュの作成」を参照してください。パーティション・キャッシュの詳細は、「分散キャッシュの理解」を参照してください。

- パススルー・キャッシュ – 既存のNamedCacheキャッシュに委任するキャッシュです。パススルー・キャッシュは、アプリケーションにすべてのCoherence固有の機能をJCacheインタフェースから使用する機能を提供します。パススルー・キャッシュは、JCacheに移行したいが既存のCoherenceアプリケーション・コンポーネントも再利用したいアプリケーションに理想的です。パススルー・キャッシュの実装は、com.tangosol.coherence.jcache.passthroughcacheパッケージで定義されています。パススルー・キャッシュの作成の詳細は、「パススルー・キャッシュの作成」を参照してください。

Coherence JCacheイベント

Coherence JCacheプロバイダは、Coherence固有のイベントAPIを使用してJCacheイベントを実装しています。ローカルおよびパーティション・キャッシュの実装は、Coherence MapListener APIを活用しています。パススルー・キャッシュの実装はJCacheイベントに直接マッピングするCoherence MapEventsのみをサポートし、JCacheの失効イベントはサポートしていません。各キャッシュ・タイプは、マップ・リスナーの登録とマップ・イベントのディスパッチを担当します。イベント・クラスは、各キャッシュ・タイプのパッケージに加え、com.tangosol.coherence.jcache.commonパッケージにもあります。JCacheイベントの作成や使用の詳細は、「JCacheイベントの使用」を参照してください。

注意:

- Coherence MapListener APIには、javax.cache.event.CacheEntryExpiredListener APIと同等の機能はありません。

- NamedCache.clearメソッドを使用するとCoherenceのMapListener.entryDeletedイベントが発生しますが、JCacheのCache.clearメソッドではイベントは発生しません。

Coherence JCacheエントリ・プロセッサ

Coherence JCacheプロバイダは、Coherence固有のInvocableMap.EntryProcessor APIを使用してJCacheエントリ・プロセッサを実装しています。各キャッシュ・タイプのprocessorsパッケージには、invokeまたはinvokeAllメソッドがキャッシュから呼ばれた際にJCacheエントリ・プロセッサの実行を管理するInvokeProcessorクラスが含まれています。JCacheエントリ・プロセッサの作成や使用の詳細は、「JCacheエントリの処理」を参照してください。

各キャッシュ・タイプのprocessorsパッケージには、キャッシュ操作の実行に使用される多くのCoherence固有のエントリ・プロセッサも含まれています。たとえば、パーティション・キャッシュを使用する場合、putメソッドはPutProcessorクラスで処理されます。

JCacheのためのCoherenceのシリアライズ

Coherence JCacheプロバイダはCoherence Portable Object Format (POF)シリアライズを使用します。POFは、Coherenceで実績のあるバイナリ形式で、スペースおよび時間の両面で効率的です。パーティションおよびパススルー・キャッシュでは、多くのキャッシュ操作にPOFが活用されています。キャッシュ構成、エントリ・プロセッサ、イベント・リスナーおよびフィルタ、JCache統計もPOFを使用しています。

POFは、JCache使用の一部で要求されるシリアライズにも使用されています。com.tangosol.coherence.jcache.serializationパッケージには、JCacheファクトリ・ビルダー、失効ポリシーおよびキャッシュ・エントリ・リスナー構成をサポートするPOFシリアライザ実装が含まれています。

アプリケーションは必要に応じてシリアライズにPOFを使用できますが、これはCoherence JCacheプロバイダを使用する際の要件ではありません。キャッシュ・プロバイダ間の移植性が必要な場合は、アプリケーションはJavaのシリアライズを使用する必要があります。

Coherence JCacheの管理

Coherence JCacheプロバイダは、JCacheのCacheMXBeanおよびCacheStatisticsMXBean MXBeanインタフェースを実装しています。実装は、com.tangosol.coherence.jcache.commonパッケージにあります。ローカルおよびパーティション・キャッシュの管理情報は、デフォルトのMBeanサーバーに登録され、javax.cacheネームスペース内にあります。パススルー・キャッシュの管理情報は、Coherence固有のJMX管理の実装を使用して報告されます。JCacheの管理の有効化の詳細は、「JCache管理情報の表示」を参照してください。

33.2 JCacheとNamedCacheの機能比較

Coherence JCacheプロバイダは、Coherence固有のNamedCache APIとともに、使用可能な多くの機能をサポートしています。ただし、JCacheを通してすべての機能を使用できるわけではありません。表33-1に、2つのAPIの比較を示します。

表33-1 JCacheとNamedCacheの機能比較

機能

JCache

NamedCache

ローカル・キャッシュ

可

可

パーティション(分散)キャッシュ

可

可

レプリケート・キャッシュ

可

オプティミスティック・キャッシュ

可

ニア・キャッシュ

可

リードスルー

可

可

ライトスルー

可

可

イベント

可

可

問合せフィルタ

可

索引

可

エントリ・プロセッサ

可

可

集計

可

33.3 Coherence JCacheの依存性

JCacheおよびCoherence JCacheプロバイダを使用するアプリケーションのクラスパスには、次のライブラリを含める必要があります。

- COHERENCE_HOME\lib\cache-api.jar – 標準JCache API

- COHERENCE_HOME\lib\coherence-jcache.jar – Coherence JCacheプロバイダ実装

- COHERENCE_HOME\lib\coherence.jar – コアCoherenceライブラリ

Coherence JCacheプロバイダでは、coherence-jcache.jarライブラリのMETA-INF/servicesディレクトリにサービス定義が含まれています。この定義によって、javax.cache.Cachingブートストラップ・クラスを使用するアプリケーションがCoherenceを自動的にロードし、デフォルトのキャッシュ・プロバイダとして使用できるようになります。CoherenceのデフォルトJCacheプロバイダとして使用の詳細は、「CoherenceのJCacheプロバイダへの指定」を参照してください。

33.4 Coherence JCacheプロバイダの構成の概要

JCacheプロバイダは、Coherence固有のNamedCache APIと同じ構成ファイルを活用します。ただし、構成ファイルのカスタマイズは簡略化され、場合によってはまったく必要ないこともあります。次に、JCache実装によって使用される構成ファイルを示します。

- tangosol-coherence-override.xml – パーティション・キャッシュ用にCoherenceクラスタを構成する場合や、パススルー・キャッシュを使用する場合に、Coherenceオペレーション・オーバーライド・ファイルが使用されます。このオーバーライド・ファイルは、ローカル・キャッシュには必要ありません。オペレーション・オーバーライド・ファイルの詳細は、「オペレーション構成ファイルの指定」を参照してください。

- coherence-jcache-cache-config.xml – coherence-jcache-cache-cofig.xmlと呼ばれるCoherence JCacheプロバイダ固有のキャッシュ構成ファイルがプロバイダJARファイルに含まれ、ローカルおよびパーティション・キャッシュを作成するために使用されます。ただし、アプリケーションが構成を編集することは想定されていません。この中に含まれるキャッシュ構成ファイルでは、JCacheアプリケーションで使用するローカルおよびパーティション・キャッシュをプログラムによって定義する際に使用されるJCacheNamespaceハンドラ・クラスが定義されています。

- coherence-jcache-pof-cofig.xml – coherence-jcache-pof-cofig.xmlと呼ばれるCoherence JCacheプロバイダ固有のPOF構成ファイルがプロバイダJARファイルに含まれ、JCache POFタイプを定義するために使用されます。既存のCoherenceアプリケーションにJCache POFタイプを含めることの詳細は、「JCache POF構成ファイルの構成」を参照してください。

33.5 JCache入門

この項では、初めてJCacheを使用する方を対象にJCacheの仕様およびAPIの概要を説明します。このマニュアルの手順を実行する際に必要となる基本的な概念も含みます。JCacheに精通している場合は、この項をスキップできます。

この項は、APIドキュメントや仕様書にかわるものではありません。詳細は、Java Community Process (JCP)のWebサイトからJCacheの仕様、Javaソース、JavaDocをダウンロードしてください。

https://www.jcp.org/en/jsr/detail?id=107

33.5.1 JCacheとは

JCacheの仕様では、Javaプログラムでキャッシュを作成および使用するAPIが定義されています。多くの場合、アプリケーションは作成に大幅なコストがかかるリソースを格納および再利用するためにキャッシュを使用します。アプリケーションは、リソースの再作成に関連するコストをかけることなく高速にメモリ内のリソースにアクセスできます。一般的にアプリケーションは、パフォーマンス、可用性およびスケーラビリティを増加させるためにキャッシュを使用します。

JCache APIは、キャッシュ用にプロバイダ・ベースのモデルを定義します。プロバイダ・モデルは、キャッシュ・クライアントAPIをキャッシュ実装から分離させます。アプリケーションは明確に定義されたクライアントAPIを使用し、キャッシュ・プロバイダが実際のキャッシュの実装を担当しています。プロバイダ・ベースのモデルによって、アプリケーション開発者は複雑なキャッシュ・サブシステムの作成および管理から解放され、仕様を実装するキャッシュ・プロバイダ間の移植性が保証されます。

33.5.2 JCacheキャッシュ・プロバイダおよびキャッシュ・マネージャ

JCache APIは、CachingProviderおよびCacheManagerインタフェースを定義しています。アプリケーションは、CachingProviderインタフェースを使用してキャッシュ・マネージャを取得および使用します。アプリケーションは、CacheManagerインタフェースを使用してキャッシュを作成および使用します。アプリケーションでは、複数のキャッシュ・プロバイダを自由に使用できます。ただし、キャッシュ・マネージャは単一のキャッシュ・プロバイダとのみ関連付けることができます。

JCacheは、キャッシュ・プロバイダを取得してキャッシュ・マネージャにアクセスするいくつかの方法を提供しています。このマニュアル全体で使用されている一般的なアクセス・パターンは、Cachingブートストラップ・クラスを使用する方法です。このクラスはCachingPovider実装を取得する便利な方法を提供し、自動的に標準Javaサービス定義を含むプロバイダを検出します。

次の例は、デフォルトのCachingProvider実装を取得し、キャッシュ・マネージャを作成します。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

33.5.3 JCacheキャッシュ

JCache APIは、Cacheインタフェースを定義しています。Cacheインタフェースは、キーと値のペアを格納するデータ構造を作成します。それぞれのキーと値のペアはエントリと呼ばれ、Cache.Entryインタフェースで定義されます。キャッシュはJava Mapデータ構造に類似していますが、いくつかの主要な相違点があります。

- キーまたは値はNULLであってはいけません。

- Cache.put操作は、エントリの以前の値を返しません。Map.put操作と機能的に同等なのは、Cache.getAndPut操作です。

- キャッシュ・エントリは、失効して削除される可能性があります。

- 値は、リードスルーおよびライトスルー・キャッシングをサポートするために、自動的に外部ソースからロードされたり、自動的に外部ソースに書き込まれる可能性があります。

- キャッシュ・エントリの変更を監視できます。

- キャッシュ統計を収集できます。

Cacheインタフェースには、キャッシュ・エントリの挿入、取得、置換および削除のためのメソッドが含まれています。キャッシュのロード、キャッシュ・リスナーの登録、およびエントリ・プロセッサの起動のためのメソッドも提供されています。

次の例は、キャッシュ・マネージャを使用してMyCacheというCacheインスタンスを作成する方法を示しています。

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

JCacheは、ジェネリクスを使用してコンパイル時および実行時の両方で型チェックをサポートしています。この例では、String型であるキーおよびInteger型である値を必要とするキャッシュを作成しています。必須ではありませんが、型チェックを行うことをお薦めします。

キャッシュ・インスタンスは、次のように操作します:

String key = "k";
Integer value = 1;

cache.put(key, value);

33.5.4 JCacheキャッシュ構成

JCache APIは、キャッシュの構成に使用するCompleteConfigurationインタフェースを定義しています。MutableConfigurationクラスがこのインタフェースのデフォルトの実装です。構成オプションには、次のものがあります:

- 格納セマンティクスの設定(値による格納または参照による格納)

- キャッシュ・エントリの型の設定

- キャッシュ失効の設定

- リードスルーおよびライトスルー・キャッシングの有効化

- 管理および統計の有効化

キャッシュは作成の際に構成されます。前述のキャッシュの例では、createCacheメソッドがキャッシュの名前および構成の両方を要求していました。次の例は、createCacheメソッドで使用される構成オブジェクトの作成方法を示しています。

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setStoreByValue(true).setTypes(String.class, Integer.class)
.setReadThrough(true)
.setWriteThrough(true)
.setManagementEnabled(true)
.setStatisticsEnabled(true)
.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.FIVE_MINUTES));

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

33.5.5 JCacheカスタム・プログラミング

JCache APIは、アプリケーションにキャッシュをカスタマイズする機能を付与する複数のインタフェースを提供しています。実装を使用するためには、Factoryインタフェースを使用してインスタンスを作成する必要があります。これによって、インスタンスがシリアライズ可能なことが保証されます。アプリケーションは、次のインタフェースを実装できます。

- ExpiryPolicy – このインタフェースは、エントリの作成、アクセスおよび変更操作に基づきキャッシュ・エントリがいつ失効するか(Duration)を定義するために使用します。

- CacheLoader – このインタフェースは、外部リソースからデータをキャッシュにロードするために使用します。これは、リードスルー・キャッシングを使用する場合に必要になります。

- CacheWriter – このインタフェースは、データを外部リソースに書き込むするために使用します。これは、リードスルー・キャッシングを使用する場合に必要になります。

- CacheEntryListener – キャッシュ・イベントを受信し、それに反応するために使用されるサブインスタンスのセット(CacheEntryCreatedListener、CacheEntryUpdatedListener、CacheEntryRemovedListenerおよびCacheEntryExpiredListener)です。

- EntryProcessor – このインタフェースは、キャッシュ・エントリにアトミックでロック・フリーな複合操作を実行するために使用します。他のインタフェースとは異なり、EntryProcessorインタフェースは、インスタンスの作成にFactoryインタフェースの使用を必要としませんが、分散キャッシュで使用する場合は、シリアライズできるような実装が必要となります。

33.5.6 JCacheの管理

JCache APIは、キャッシュの管理に使用される2つの動的なMBeanを定義しています。CacheMXBean MXBeanは、キャッシュ構成情報を報告します。CacheStatisticsMXBean MXBeanは、発生する可能性のある問題のトラブルシューティングに使用されるキャッシュ・パフォーマンス統計を報告します。動的なMBeanは実装に固有のMBeanサーバーとともに登録され、JMX MBean対応ブラウザの使用を含む標準JMXを使用して取得されます。

34 最初のCoherence JCacheアプリケーションの作成

この章では、Coherence JCacheの基本的なサンプルをビルドおよび実行する手順を示し、JCacheおよびCoherence JCacheプロバイダの両方の基本概念について説明します。サンプル・アプリケーションは、ドメイン・オブジェクト(Personオブジェクト)をキャッシュに格納する単純なアプリケーションです。このサンプルでは、ローカル・キャッシュ、パーティション・キャッシュおよびパススルー・キャッシュの使用方法を示します。

初めてCoherenceを使用する場合は、「最初のCoherenceアプリケーションの作成」を参照し、Coherence固有のNamedCacheサンプルを実行することも検討してください。

この章には次の項が含まれます:

- タスク1: 単純なオブジェクトの作成

- タスク2: ローカル・キャッシュへのオブジェクトの格納

- タスク3: サンプル・クラスタの構成

- タスク4: パーティション・キャッシュへのオブジェクトの格納

- タスク5: パススルー・キャッシュへのオブジェクトの格納

34.1 タスク1: 単純なオブジェクトの作成

この章のサンプルでは、単純なPersonオブジェクトを使用します。Personオブジェクトには、コンストラクタと、姓、名および年齢という3つのフィールドが含まれています。PersonオブジェクトはSerializableインタフェースを実装しています。オブジェクトをパーティション・キャッシュに格納する場合は、シリアライズが必要になります。

例34-1 単純なPersonオブジェクト

package com.examples;

import java.io.Serializable;

public class Person implements Serializable {
private String m_sFirstName;
private String m_sLastName;
private int m_nAge;
private static final long serialVersionUID = 99L;

public Person(String sFirstName, String sLastName, int nAge)
{
m_sFirstName = sFirstName;
m_sLastName = sLastName;
m_nAge = nAge;
}

public String getFirstName()
{
return m_sFirstName;
}

public String getLastName()
{
return m_sLastName;
}

public int getAge()
{
return m_nAge;
}

public String toString()
{
return "Person( " +m_sFirstName + " " + m_sLastName + " : " + m_nAge + ")";
}
}

34.2 タスク2: ローカル・キャッシュへのオブジェクトの格納

アプリケーションは、JCache APIを使用してキャッシュにアクセスし、キャッシュとの相互作用を図ります。APIは、キャッシュを作成および使用するメソッドを提供しています。キャッシュ・タイプが定義されていない場合にCoherenceが使用するデフォルトのキャッシュ・タイプは、ローカル・キャッシュ(アプリケーション・プロセスにローカル)です。

34.2.1 サンプルJCacheアプリケーションの作成

次のアプリケーションは、1つのPersonオブジェクトをローカル・キャッシュに格納します。このアプリケーションは、キャッシュ・プロバイダの取得方法、キャッシュ・マネージャの作成方法、キャッシュの構成方法および作成方法、キャッシュの使用方法を示しています。

例34-2 サンプルJCacheアプリケーション

package com.examples;

import javax.cache.Cache;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.cache.configuration.MutableConfiguration;
import javax.cache.spi.CachingProvider;

public class JCacheExample {
public static void main(String[] args)
{
CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Object> config =
new MutableConfiguration<String, Object>();
config.setStoreByValue(true).setTypes(String.class, Object.class);

Cache<String, Object> cache = cacheManager.createCache("MyCache", config);

Person p = new Person("John","Doe",24);

String key = "k";
Person value = p;

cache.put(key, value);
System.out.println("\n Cache: " + cache.getName() + " contains: " +
cache.get(key) + "\n");

cacheManager.close();
}
}

34.2.2 サンプルJCacheアプリケーションの実行

サンプルのスタンドアロン・アプリケーションを実行するには:

1. コマンド・プロンプトから、Person.javaおよびJCacheExample.javaファイルをコンパイルします。次の例およびこれ以降のタスクでは、ファイルがAPPLICATION_HOMEという単一のディレクトリにあることを前提とします。

cd APPLICATION_HOME
javac -cp COHERENCE_HOME\lib\cache-api.jar com\examples\*

2. Javaの-cpオプションを使用してクラスパスにcoherence.jar、coherence-jcache.jarおよびcache-api.jarライブラリの場所を含め、JCacheExampleクラスを実行します。例:

java -cp .;COHERENCE_HOME\lib\cache-api.jar;
COHERENCE_HOME\lib\coherence-jcache.jar;COHERENCE_HOME\lib\coherence.jar
com.examples.JCacheExample

使用されるCoherence構成リソースおよび作成されるCoherenceキャッシュ・ファクトリを示すCoherenceのログ・メッセージが出力されます。アプリケーションはキャッシュ内のエントリを出力し、終了します。

34.3 タスク3: サンプル・クラスタの構成

パーティション・キャッシュおよびパススルー・キャッシュは、キャッシュ・データを分散させるためにCoherenceクラスタを使用します。このタスクでは、オペレーション・オーバーライド・ファイルを作成して初期状態のデフォルト・クラスタ構成を修正します。具体的には、デフォルト構成を修正してプライベート・クラスタを作成し、ネットワーク上で実行されている可能性のある既存のCoherenceクラスタにJVMプロセスが参加しないようにします。

サンプル・クラスタを構成するには:

1. tangosol-coherence-override.xmlという名前のファイルを作成します。

2. 次のオーバーライド構成を追加して、cluster_nameおよびportをクラスタ内で一意の値に置き換えます。たとえば、クラスタ名に自分の名前を使用し、ポート番号に電話番号の最後の4桁を使用します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<member-identity>
<cluster-name>cluster_name</cluster-name>
</member-identity>

<multicast-listener>
<address>224.3.6.0</address>
<port>port</port>
<time-to-live>0</time-to-live>
</multicast-listener>
</cluster-config>

</coherence>

3. APPLICATION_HOME\configディレクトリにファイルを保存します。

34.4 タスク4: パーティション・キャッシュへのオブジェクトの格納

パーティション・キャッシュは、キャッシュ・エントリをCoherenceクラスタ内の任意の数のキャッシュ・サーバーに分散させるキャッシュです。パーティション・キャッシュに格納されるエントリは、アプリケーション・プロセスの終了後にバックアップされ、クラスタ上に永続化されます。JCacheプロバイダとともにパーティション・キャッシュを使用する方法の詳細は、「パーティション・キャッシュの作成」を参照してください。

このタスクでは、キャッシュ・サーバー・プロセスとJCacheExampleアプリケーション・プロセスの2つの個別のJavaプロセスによってクラスタが形成されます。簡素化を図るため、この2つのプロセスは単一のマシン上に置かれます。この2つのプロセスは1つのコンピュータ上に共存します。キャッシュ・サーバーは、デフォルトでキャッシュ・データを格納するように構成されます。最後に、CoherenceのCacheFactoryによって、JCacheExampleアプリケーションがクラスタ上に正常にキャッシュを作成およびロードしたことが検証されます。

34.4.1 サンプル・キャッシュ・サーバーの起動

コマンド・プロンプトから、Javaの-cpオプションでAPPLICATION_HOME\configディレクトリを含めてDefaultCacheServerクラスを実行し、キャッシュ・サーバー・インスタンスを起動します。クラスパスには、cache-api.jar、coherence-jcache.jarおよびcoherence.jarライブラリも含める必要があります。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルおよびcoherence-jcache.jarがロードされることを確認します。また、tangosol.coherence.cacheconfigシステム・プロパティで、明示的にcoherence-jcache.jarの中にあるJCacheのcoherence-jcache-cache-config.xmlキャッシュ構成ファイルを指定します。例:

java -Dtangosol.coherence.cacheconfig=coherence-jcache-cache-config.xml
-cp APPLICATION_HOME\config;COHERENCE_HOME\lib\cache-api.jar;
COHERENCE_HOME\lib\coherence-jcache.jar;COHERENCE_HOME\lib\coherence.jar
com.tangosol.net.DefaultCacheServer

キャッシュ・サーバーの出力から、jcache-partitioned-serviceというクラスタの上位メンバーである分散キャッシュ・サービスが作成されたことを確認してください。

(thread=DistributedCache:jcache-partitioned-service, member=1): Service
jcache-partitioned-service joined the cluster with senior service member 1

34.4.2 アプリケーションの実行

tangosol.coherence.jcache.configuration.classnameシステム・プロパティによって、Coherence JCacheプロバイダがローカル・キャッシュのかわりにパーティション・キャッシュを使用するように構成されます。アプリケーション・コードにはいかなる変更も必要ないため、JCacheプロバイダ間の移植性が得られます。さらに、Coherenceはアプリケーション・スコープおよびキャッシュ構成も管理します。

Personオブジェクトをパーティション・キャッシュに格納するには:

1. コマンド・プロンプトで、tangosol.coherence.jcache.configuration.classnameシステム・プロパティをpartitionedに、tangosol.coherence.distributed.localstorageシステム・プロパティをfalseに設定して例34-2で作成したアプリケーションを実行します。Javaの-cpオプションで、APPLICATION_HOME\configディレクトリを含めます。クラスパスには、cache-api.jar、coherence-jcache.jarおよびcoherence.jarライブラリも含める必要があります。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルおよびcoherence-jcache.jarライブラリがロードされることを確認します。例:

java -Dtangosol.coherence.jcache.configuration.classname=partitioned
-Dtangosol.coherence.distributed.localstorage=false
-cp .;APPLICATION_HOME\config;COHERENCE_HOME\lib\cache-api.jar;
COHERENCE_HOME\lib\coherence-jcache.jar;COHERENCE_HOME\lib\coherence.jar
com.examples.JCacheExample

使用されるCoherence構成リソースを示すCoherenceのログ・メッセージが出力されます。tangosol-coherence-override.xmlファイルがロードされたことを確認してください。最後に、アプリケーション・プロセスがクラスタに参加し、jcache-partitioned-serviceインスタンスがキャッシュ・サーバー上の上位サービスに参加したことを確認してください。

(thread=DistributedCache:jcache-partitioned-service, member=2): Service
jcache-partitioned-service joined the cluster with senior service member 1

34.4.3 キャッシュの確認

この例のキャッシュ・サーバーは、デフォルトでキャッシュのデータを格納するように構成されます。データは、クラスタのすべてのメンバーが使用可能であり、それらのメンバーがクラスタから離脱した後も保持されます。たとえば、アプリケーションは、キャッシュにキーをロードし、そのキーを表示してから終了します。ただし、キャッシュとキーは、その後もすべてのクラスタ・メンバーが使用できます。

この手順では、キャッシュ・ファクトリ・コマンド行ツールを使用して、キャッシュに接続し、キャッシュ内のすべての項目を一覧表示します。

キャッシュを確認するには:

1. コマンド・プロンプトから、CacheFactoryクラスを使用してスタンドアロンのキャッシュ・ファクトリ・インスタンスを起動します。Javaの-cpオプションで、APPLICATION_HOME\configディレクトリを含めます。クラスパスには、Personオブジェクト、cache-api.jar、coherence-jcache.jarおよびcoherence.jarライブラリも含める必要があります。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルおよびcoherence-jcache.jarがロードされることを確認します。最後に、tangosol.coherence.cacheconfigシステム・プロパティをcoherence-jcache-cache-config.xmlに、tangosol.coherence.distributed.localstorageシステム・プロパティをfalseに設定します。例:

java -Dtangosol.coherence.cacheconfig=coherence-jcache-cache-config.xml
-Dtangosol.coherence.distributed.localstorage=false
-cp APPLICATION_HOME\config;APPLICATION_HOME\person.jar;
COHERENCE_HOME\lib\cache-api.jar;COHERENCE_HOME\lib\coherence-jcache.jar;
COHERENCE_HOME\lib\coherence.jar com.tangosol.net.CacheFactory

キャッシュ・ファクトリ・インスタンスが起動し、クラスタのメンバーとなり、コマンド行ツールのコマンド・プロンプトを返します。

2. コマンド行ツールのコマンド・プロンプトで、cacheコマンドを使用してMyCacheキャッシュを取得します。

cache jcache-partitioned-coherence-jcache-cache-config.xml$MyCache

注意:
この例では、キャッシュ名はアプリケーション・スコープを含んでいます。アプリケーションは、キャッシュを使用する際にアプリケーション・スコープを明示的に含む必要ありません。

3. コマンド行ツールのコマンド・プロンプトで、listコマンドを使用してキャッシュの内容を取得します。

list

コマンドは次の文字列を返し、表示します。

k = Person( John Doe : 24)

4. すべてのプロセスをシャットダウンします。

34.5 タスク5: パススルー・キャッシュへのオブジェクトの格納

パススルー・キャッシュは、既存のCoherenceキャッシュ(Coherenceキャッシュ構成ファイルで定義されるキャッシュ)に委任するキャッシュです。パススルー・キャッシュによってすべてのCoherenceネイティブの機能が使用できるようになり、キャッシュ構成の高度な制御が可能になります。

このタスクでは、キャッシュ・サーバー・プロセスとJCacheExampleアプリケーション・プロセスの2つの個別のJavaプロセスによってクラスタが形成されます。簡素化を図るため、この2つのプロセスは単一のマシン上に置かれます。この2つのプロセスは1つのコンピュータ上に共存します。キャッシュ・サーバーは、デフォルトでキャッシュ・データを格納するように構成されます。最後に、CoherenceのCacheFactoryによって、JCacheExampleアプリケーションがクラスタ上に正常にキャッシュを作成およびロードしたことが検証されます。

34.5.1 サンプル・キャッシュの定義

この例では、明示的にMyCacheという名前にマップされる分散キャッシュを定義するキャッシュ構成が作成されます。

キャッシュのサンプルを定義するには:

1. XMLファイルexample-config.xmlを作成します。

2. 次の分散キャッシュの定義をファイルにコピーします。

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>MyCache</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

3. APPLICATION_HOME\configディレクトリにファイルを保存します。

34.5.2 サンプル・キャッシュ・サーバーの起動

コマンド・プロンプトから、Javaの-cpオプションでAPPLICATION_HOME\configディレクトリおよびcoherence.jarライブラリを含めてDefaultCacheServerクラスを実行し、キャッシュ・サーバー・インスタンスを起動します。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルがロードされることを確認します。最後に、tangosol.coherence.cacheconfigシステム・プロパティで、明示的にexample-config.xmlキャッシュ構成ファイルを定義します。例:

java -Dtangosol.coherence.cacheconfig=example-config.xml
-cp APPLICATION_HOME\config;COHERENCE_HOME\lib\coherence.jar
com.tangosol.net.DefaultCacheServer

34.5.3 アプリケーションの実行

tangosol.coherence.jcache.configuration.classnameシステム・プロパティによって、Coherence JCacheプロバイダがパススルー・キャッシュを使用するように構成されます。アプリケーション・コードにはいかなる変更も必要ありません。

コマンド・プロンプトで、JCacheExampleクラスを実行し、tangosol.coherence.jcache.configuration.classnameシステム・プロパティをpassthroughに、tangosol.coherence.cacheconfigシステム・プロパティをexample-configに、tangosol.coherence.distributed.localstorageシステム・プロパティをfalseに設定します。Javaの-cpオプションで、APPLICATION_HOME\configディレクトリを含めます。クラスパスには、cache-api.jar、coherence-jcache.jarおよびcoherence.jarライブラリも含める必要があります。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルがロードされることを確認します。例:

java -Dtangosol.coherence.jcache.configuration.classname=passthrough
-Dtangosol.coherence.cacheconfig=example-config.xml
-Dtangosol.coherence.distributed.localstorage=false
-cp .;APPLICATION_HOME\config;COHERENCE_HOME\lib\cache-api.jar;
COHERENCE_HOME\lib\coherence-jcache.jar;COHERENCE_HOME\lib\coherence.jar
com.examples.JCacheExample

使用されるCoherence構成リソースを示すCoherenceのログ・メッセージが出力されます。tangosol-coherence-override.xmlファイルおよびexample-config.xmlファイルがロードされたことを確認してください。アプリケーション・プロセスはキャッシュ・サーバー・プロセスを含むクラスタに接続し、両方のプロセスがDistributedCacheサービスを実行します。これまでと同様に、アプリケーションはキャッシュ内のエントリを出力し、終了します。

34.5.4 キャッシュの確認

この例のキャッシュ・サーバーは、デフォルトでキャッシュのデータを格納するように構成されます。データは、クラスタのすべてのメンバーが使用可能であり、それらのメンバーがクラスタから離脱した後も保持されます。たとえば、アプリケーションは、キャッシュにキーをロードし、そのキーを表示してから終了します。ただし、キャッシュとキーは、その後もすべてのクラスタ・メンバーが使用できます。

この手順では、キャッシュ・ファクトリ・コマンド行ツールを使用して、MyCacheキャッシュに接続し、キャッシュ内のすべての項目を一覧表示します。

キャッシュを確認するには:

1. コマンド・プロンプトから、CacheFactoryクラスを使用してスタンドアロンのキャッシュ・ファクトリ・インスタンスを起動します。Javaの-cpオプションで、APPLICATION_HOME\configディレクトリを含めます。クラスパスには、Personオブジェクトおよびcoherence.jarライブラリも含める必要があります。クラスパス上で、coherence.jarライブラリよりも先にオペレーション・オーバーライド・ファイルがロードされることを確認します。また、tangosol.coherence.cacheconfigシステム・プロパティをexample-config.xmlに、tangosol.coherence.distributed.localstorageシステム・プロパティをfalseに設定します。例:

java -Dtangosol.coherence.cacheconfig=example-config.xml
-Dtangosol.coherence.distributed.localstorage=false
-cp APPLICATION_HOME\config;APPLICATION_HOME\person.jar;
COHERENCE_HOME\lib\coherence.jar com.tangosol.net.CacheFactory

キャッシュ・ファクトリ・インスタンスが起動し、クラスタのメンバーとなり、コマンド行ツールのコマンド・プロンプトを返します。

2. コマンド行ツールのコマンド・プロンプトで、cacheコマンドを使用してMyCacheキャッシュを取得します。

cache MyCache

3. コマンド行ツールのコマンド・プロンプトで、listコマンドを使用してキャッシュの内容を取得します。

list

コマンドは次の文字列を返し、表示します。

k = Person( John Doe : 24)

35 基本的なCoherence JCacheタスクの実行

この章には、Coherence JCacheプロバイダを使用するアプリケーション開発に一般的な基本タスクが含まれています。多くの手順でJCache APIが示され、Coherence JCacheプロバイダ実装に固有な内容が含まれています。

この章には次の項が含まれます:

- JCacheプロバイダとしてのCoherenceの指定

- Coherence JCacheキャッシュの作成

- Coherence JCacheキャッシュの構成

- キャッシュ操作の実行

- リードスルーおよびライトスルー・キャッシングの使用

- JCache POF構成ファイルの構成

- JCache管理情報の表示

35.1 JCacheプロバイダとしてのCoherenceの指定

coherence-jcache.jarライブラリにあるMETA-INF/services/javax.cache.spi.CachingProviderサービス定義は、javax.cache.Cachingブートストラップ・クラスを使用するアプリケーションはデフォルトでCoherence JCacheプロバイダを使用することを前提としています。この章の手順および例は、Coherence JCacheプロバイダがデフォルトのJCacheプロバイダであることを前提としています。ただし、アプリケーションは複数のキャッシュ・プロバイダを登録および使用できます。そのような場合、アプリケーションにはCoherence JCacheプロバイダを選択するオプションが複数あります。

注意:
複数のJCacheプロバイダが登録されている場合、getCachingProvider()またはgetCachingProvider(ClassLoader)メソッドを使用するとキャッシュ例外が発生します。

最初のオプションは、デフォルトのキャッシュ・プロバイダをjavax.cache.spi.cachingproviderシステム・プロパティを使用してオーバーライドし、Coherence JCacheプロバイダ実装クラスの完全修飾名を指定する方法です。例:

System.setProperty("javax.cache.spi.cachingprovider",
"com.tangosol.coherence.jcache.CoherenceBasedCachingProvider");

システム・プロパティは、実行時にコマンド行で指定することもできます。例:

-Djavax.cache.spi.cachingprovider=com.tangosol.coherence.jcache.
CoherenceBasedCachingProvider

2番目のオプションは、Caching.getCachingProvider(String)またはCaching.getCachingProvider(String, ClassLoader)メソッドを使用して、明示的にCoherence JCacheプロバイダ実装を要求する方法です。例:

CachingProvider cachingProvider = Caching.getCachingProvider(
"com.tangosol.coherence.jcache.CoherenceBasedCachingProvider");
CacheManager cacheManager = cachingProvider.getCacheManager();
...

複数のキャッシュ・プロバイダが登録されている場合は、getCachingProvidersメソッドを使用して登録済のプロバイダのリストを反復処理します。

最後のオプションとして、アプリケーションは直接Coherence JCacheプロバイダをインスタンス化することもできます。ただし、このオプションにはプロバイダ間の移植性はありません。次の例はCoherence JCacheプロバイダをインスタンス化します。

CachingProvider cachingProvider = new CoherenceBasedCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

35.2 Coherence JCacheキャッシュの作成

Coherence JCacheプロバイダは、ローカル、パーティションおよびパススルーの3つのキャッシュ・タイプをサポートしています。ローカル・キャッシュは、アプリケーション・プロセスにローカルなキャッシュです。パーティション・キャッシュは、Coherenceの記憶域が有効なクラスタ・メンバーにキャッシュ・データを分散させます。パススルー・キャッシュは、Coherenceキャッシュ構成ファイル内で構成されるCoherence固有のキャッシュに委任します。この項では、これらのキャッシュ・タイプそれぞれのJCache APIを使用した作成方法を示します。

この項には次のトピックが含まれます:

- ローカル・キャッシュの作成

- パーティション・キャッシュの作成

- パススルー・キャッシュの作成

- JCacheからのCoherence固有の機能の使用

35.2.1 ローカル・キャッシュの作成

アプリケーションは、ローカル・キャッシュを使用してデータをキャッシュできます。ローカル・キャッシュはCoherence JCacheプロバイダを使用する際のデフォルトのキャッシュ・タイプで、Coherenceローカル・キャッシュ・スキームに類似しています。ローカル・キャッシュはデータのバックアップを提供せず、アプリケーションが終了した後はデータは永続化されません。次の例では、JCache APIを使用してローカル・キャッシュを作成しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setStoreByValue(true).setTypes(String.class, String.class);

Cache<String, String> cache = cacheManager.createCache("MyCache", config);

ローカル・キャッシュは、jcache-local-serviceサービスによって管理されるjcache-local-schemeという名前のローカル・キャッシュ・スキームにマップされるjcache-local-*キャッシュ名を使用するCoherence NamedCacheインスタンスを作成します。

35.2.2 パーティション・キャッシュの作成

アプリケーションは、Coherenceパーティション・キャッシュにデータをキャッシュできます。アプリケーション・プロセスは自動的にCoherenceクラスタに参加し、Coherenceはクラスタ全体のデータの分散およびバックアップを管理します。パーティション・キャッシュはいかなるアプリケーションのコードの変更も必要としないため、既存のJCacheアプリケーションは簡単にCoherenceパーティション・キャッシュを使用するように移行できます。

注意:
パーティション・キャッシュは参照による格納セマンティクスをサポートしていません。

パーティション・キャッシュを作成するには、tangosol.coherence.jcache.configuration.classnameプロパティにpartitionedを設定します。例:

-Dtangosol.coherence.jcache.configuration.classname=partitioned

システム・プロパティは、何の値も指定されなかった場合のデフォルト値であり、ローカル・キャッシュが作成されるlocalという値もサポートします。

パーティション・キャッシュは、jcache-partitioned-serviceサービスによって管理されるjcache-partitioned-schemeという名前のパーティション・キャッシュ・スキームにマップされるjcache-partitioned-*キャッシュ名を使用するCoherence NamedCacheインスタンスを作成します。

オペレーション構成

JCacheアプリケーションは、tangosol-coherence-override.xmlオペレーション・オーバーライド・ファイルおよびCoherenceシステム・プロパティのいずれかまたは両方を使用してCoherenceオペレーション設定を構成する必要があります。とりわけこのオペレーション設定によって、アプリケーションは既存のクラスタへ参加できるようになります。オペレーション・オーバーライド・ファイルの詳細は、「オペレーション構成ファイルの指定」を参照してください。たとえば、アプリケーションは実行時に次のシステム・プロパティを指定してCluster1という名前でマルチキャスト・アドレス231.1.1.1およびポート3060を持つクラスタに参加できます。

-Dtangosol.coherence.cluster=Cluster1
-Dtangosol.coherence.clusteraddress=231.1.1.1
-Dtangosol.coherence.clusterport=3060

キャッシュ構成

JCache用のパーティション・キャッシュは、自動的にcoherence-jcache.jarライブラリに含まれるデフォルトのCoherenceキャッシュ構成ファイルを使用します。この構成ファイルの名前はcoherence-jcache-cache-config.xmlです。クラスタ内のキャッシュ・サーバーは、coherence-jcache-cache-config.xmlファイルも使用する必要があります。たとえば、キャッシュ・サーバーはtangosol.coherence.cacheconfigシステム・プロパティを使用して明示的にキャッシュ構成ファイルを設定できます。

-Dtangosol.coherence.cacheconfig=coherence-jcache-cache-config.xml

注意:
既存のCoherenceキャッシュ構成ファイルの使用については、「JCacheからのCoherence固有の機能の使用」を参照してください。

35.2.3 パススルー・キャッシュの作成

アプリケーションは、パススルー・キャッシュを使用してすべてのキャッシュ操作を既存のCoherenceキャッシュに委任できます。パススルー・キャッシュを使用すると、Coherence固有のNamedCacheインスタンスをJCacheインタフェースから使用することになります。パススルー・キャッシュによって、アプリケーションはすべてのCoherence固有の機能および構成をフル活用できます。

パススルー・キャッシュを作成するためには、アプリケーションはCoherenceのPassThroughCacheConfiguration JCache構成オブジェクトを使用し、Coherenceキャッシュ構成ファイルで定義されている既存のキャッシュ・マッピングの名前を指定することができます。例:

...
CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

PassThroughCacheConfiguration<String, Object> config =
new PassThroughCacheConfiguration<String, Object>();
config.setTypes(String.class, Object.class);

Cache<String, Object> cache = cacheManager.createCache("MyCache", config);

代替として、既存のJCacheアプリケーションではMutableConfigurationオブジェクトを使用し続けて、tangosol.coherence.jcache.configuration.classnameプロパティを指定してその値をpassthroughに設定することで、パススルー・キャッシュを作成することができます。例:

-Dtangosol.coherence.jcache.configuration.classname=passthrough

システム・プロパティにより、JCacheアプリケーションはアプリケーション・コードを変更することなくCoherenceネイティブ機能を使用することができます。ただし、ほとんどのMutableConfigurationオブジェクト・プロパティは無視されます。システム・プロパティを使用してパススルー・キャッシュを作成すると、警告メッセージが出力されます。

WARNING: Lossy conversion of configuration javax.cache.configuration.MutableConfiguration to a PassThroughConfiguration.
Most properties from class javax.cache.configuration.MutableConfiguration are
ignored. Configure PassThroughCache using native Coherence configuration
methodologies.

オペレーション構成

JCache用のパススルー・キャッシュは、tangosol-coherence-override.xmlオペレーション・オーバーライド・ファイルおよびCoherenceシステム・プロパティのいずれかまたは両方を使用してCoherenceオペレーション設定を構成します。とりわけこのオペレーション設定によって、アプリケーションは既存のクラスタへ参加できるようになります。オペレーション・オーバーライド・ファイルの詳細は、「オペレーション構成ファイルの指定」を参照してください。

キャッシュ構成

JCache用のパススルー・キャッシュは、既存のCoherenceキャッシュ構成ファイルを使用します。アプリケーションは、実行時にtangosol.coherence.cacheconfigプロパティを使用してファイルの場所を指定できます。例:

-Dtangosol.coherence.cacheconfig=my-cache-config.xml

前述の方法によってキャッシュ・マネージャが使用するデフォルトURIが変更され、指定されたキャッシュ構成ファイルが取得されます。JCache APIを使用し、システム・プロパティの設定に依存せずにキャッシュ構成を指定する別の方法は、キャッシュ・マネージャを作成する際にURIを指定する方法です。例:

Caching.getCacheManager(new URI(my-cache-config.xml), null, null);

前述の方法で返されたキャッシュ・マネージャから作成されたすべてのキャッシュは、getCacheManagerの呼出しで指定されたキャッシュ構成ファイルを使用します。

キャッシュ構成ファイルの詳細は、「キャッシュ構成ファイルの指定」を参照してください。

35.2.4 JCacheからのCoherence固有の機能の使用

Coherence JCacheプロバイダによって、アプリケーションはCoherence固有の機能を使用できます。Coherence固有の機能を使用するアプリケーションには、JCacheプロバイダ間の移植性はありません。一般的に、アプリケーションは既存のCoherenceの実装および構成を再利用するために固有の機能を使用します。

この項には次のトピックが含まれます:

- JCacheからのNamedCacheインスタンスへのアクセス

- JCacheでのCoherence構成の使用

35.2.4.1 JCacheからのNamedCacheインスタンスへのアクセス

JCacheアプリケーションは、キャッシュの基礎となるCoherence NamedCacheインスタンスに直接アクセスできます。NamedCacheとJCache APIを入れ替えて使用することによってキャッシュに直接アクセスすることはできません。さらに、NamedCacheインスタンスを使用してキャッシュのキーおよび値にアクセスすると、Coherence JCacheプロバイダ実装によって提供される追加の動作はバイパスされます。

次の例は、JCacheキャッシュの基礎となるNamedCacheインスタンスに直接アクセスし、エントリの挿入および取得を行うためにインスタンスを使用しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setStoreByValue(true).setTypes(String.class, String.class);

Cache<String, String> cache = cacheManager.createCache("MyCache", config);

String key = "k";
String value = "Hello World";

NamedCache nc = cache.unwrap(NamedCache.class);

nc.put(key, value);

System.out.println("The value is " + nc.get(key) + "\n");

nc.destroy();
cacheManager.close();

35.2.4.2 JCacheでのCoherence構成の使用

JCacheに同等なものがないCoherence固有の概念(失効など)は、Coherenceキャッシュ構成ファイル、オペレーション・オーバーライド・ファイルまたはCoherenceシステム・プロパティを使用して構成できます。

注意:
JCacheプロバイダ実装間で移植性を持つように設計されているアプリケーションは、JCache CompleteConfiguration APIが提供する構成のみに依存する必要があります。

既存のCoherenceキャッシュ構成ファイルをJCacheパーティションおよびローカル・キャッシュに使用する場合は、ファイルにjcacheネームスペース・ハンドラ定義を含める必要があります。例:

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xmlns:jcache="class://com.tangosol.coherence.jcache.JCacheNamespace"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
...

JCacheネームスペース・ハンドラは、JCache固有のキャッシュ構成ファイルに必要なすべての欠落している要素を生成し、アプリケーションが標準キャッシュ構成ファイルを拡張できるようにします。すでにキャッシュ構成ファイルで定義されている場合、JCacheネームスペース・ハンドラは要素を生成しません。

35.3 Coherence JCacheキャッシュの構成

CoherenceのJCacheベースのキャッシュは、キャッシュが作成される際にMutableConfigurationクラスによってプログラムから構成されます。JCacheプロバイダ間の移植性を維持するために、この標準のJCacheクラスを使用する必要があります。例:

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setStoreByValue(true).setTypes(String.class, String.class);

Cache<String, String> cache = cacheManager.createCache("MyCache", config);

ローカルおよびパーティション・キャッシュを使用するアプリケーションは、オプションでJCache CompleteConfiguration APIのCoherence JCacheプロバイダ固有の実装を使用できます。この実装は、それぞれLocalCacheConfigurationおよびPartitionedCacheConfigurationです。ただし、これらのクラスはJCacheプロバイダ間の移植性はありません。例:

PartitionedCacheConfiguration<String, String> config =
new PartitionedCacheConfiguration<String, String>();
config.setStoreByValue(true).setTypes(String.class, String.class);

パススルー・キャッシュを使用するアプリケーションには、Coherence JCacheプロバイダPassThroughCacheConfiguration構成クラスが必要です。パススルー・キャッシュはCoherence固有の構成を使用して構成されるため、JCache固有の構成オプションの使用はサポートしません。

PassThroughCacheConfiguration<String, String> config =
new PassThroughCacheConfiguration<String, String>();

この項には次のトピックが含まれます:

- 格納セマンティクスの設定

- キャッシュ・エントリの型の設定

- キャッシュ失効の設定

- リードスルーおよびライトスルー・キャッシングの有効化

- 管理の有効化

35.3.1 格納セマンティクスの設定

JCacheは、キャッシュが参照による格納と値による格納のどちらのセマンティクスを使用するかを指定するオプションを提供しています。setStoreByValueメソッドは、キーと値両方の格納セマンティクスを構成します。trueは値による格納セマンティクスを、falseは参照による格納セマンティクスを示します。Coherence JCacheプロバイダは、すべてのキャッシュ・タイプにおいてデフォルトで値による格納セマンティクスを使用し、ローカル・キャッシュにおいてのみ参照による格納をサポートしています。パーティション・キャッシュは参照による格納をサポートしていません。さらに、すべてのCoherence JCacheキャッシュ・タイプで、プロバイダは値による格納セマンティクスの実装にJavaシリアライズまたはPOFのどちらかを使用しています。ローカル・キャッシュで参照による格納を構成しているアプリケーションは、キーと値がシリアライズ可能またはPOFが有効化されている必要はありません。

次の例では、ローカル・キャッシュで参照による格納セマンティクスを使用するように構成しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setStoreByValue(false);

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

注意:
参照による格納が有効な場合は、キャッシュへの参照を保持しているスレッドによってキャッシュが変更される可能性があります。変更されたキーは取得できない可能性があります。さらに、Javaのパーミッションが正しく設定されていない場合は、JVM内のすべてのスレッドが変更された値を監視できる可能性があります。ローカル・ヒープを超えるとエントリはある形式に変換され、この変換以後に発生した変更はキャッシュに反映されない可能性があります。

35.3.2 キャッシュ・エントリの型の設定

JCacheでは、エントリのキーと値の型を設定できます。その後、キャッシュに配置されるすべてのエントリは、宣言された型に従う必要があります。そうでない場合は、ランタイム例外が発生します。setTypesメソッド(nullの設定は不可)が、エントリの型を構成するために使用されます。次の例では、キーの型をStringに、値の型をIntegerに設定しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setTypes(String.class, Integer.class);

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

注意:
Coherence JCache実装では、キャッシュを変更する操作に渡されるオブジェクトが、javax.cache.configuration.Configuration APIで構成された内容と一致することを確認する実行時チェックは行われません。アプリケーションはキャッシュを操作するためにジェネリクスを使用し、コンパイル時の静的なチェックを活用する必要があります。

型が構成されていない場合、デフォルトのキーと値の型はObject.classです。デフォルトの型を使用するか、または明示的にObject.class型を構成した場合、実行時の型チェックは無効になり、アプリケーションは任意のキーまたは値の型を使用できるようになります。ただし、その場合は、型の安全性の保証はアプリケーションの責任です。次の例では、明示的にキーと値のタイプをObject.classに設定し、キャッシュを取得する際の型パラメータを省略することによって、型チェックを無効化しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<Object, Object> config =
new MutableConfiguration<Object, Object>();
config.setStoreByValue(true).setTypes(Object.class, Object.class);

Cache<Object, Object> cache = cacheManager.getCache("MyCache");

必須ではありませんが、前述の例はコンパイル時の型チェックも使用しています。省略された場合、コンパイラは型の安全性をチェックしません。次の例では、コンパイル時と実行時の両方の型チェックを無効化しています。

MutableConfiguration config = new MutableConfiguration();
cacheManager.createCache("MyCache", config);

35.3.3 キャッシュ失効の設定

JCacheでは、エントリがキャッシュの中で使用可能な時間を構成できます。失効したエントリは有効ではなく、アプリケーションが使用することはできません。

注意:
Coherence JCacheプロバイダは、最大キャッシュ容量に到達している場合、失効する予定がないエントリを削除する可能性があります。キャッシュ・エントリは、エントリのアクセス頻度および最終アクセス日時の組合せに基づくデフォルトのエビクション・ポリシーによって削除されます。アクセス頻度が最も低いエントリおよびアクセスされていない期間が最も長いエントリが最初に削除されます。

失効は、失効ポリシーおよび時間値を選択するsetExpiryPolicyFactoryメソッドを使用して構成されます。次の例では、キャッシュ内のエントリを作成されてから5分で失効するように構成しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(
Duration.FIVE_MINUTES));

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

ポリシーがnullに設定されるか、失効が構成されていない場合、デフォルトで永続ポリシーが使用され、エントリは失効しません。各ポリシーでは、キャッシュ・エントリが失効とみなされる前に経過する必要がある期間を指定できます。便宜上、ZERO、ONE_MINUTE、FIVE_MINUTES、TEN_MINUTES、TWENETY_MINUTES、THIRTY_MINUTES、ONE_HOURおよびONE_DAYという定義済の期間が提供されています。任意の負でない期間の値を構成できます。

次の失効ポリシーがサポートされています:

- 作成 – キャッシュ・エントリは、作成日時に基づいて失効します。更新によって失効日時がリセットされることはありません。このポリシーは、JCacheのCreatedExpiryPolicyクラスで実装されています。

- アクセス – キャッシュ・エントリは、最終アクセス日時に基づいて失効します。アクセスには、キャッシュの更新は含まれません。このポリシーは、JCacheのAccessedExpiryPolicyクラスで実装されています。

- 変更 – キャッシュ・エントリは、最終更新日時に基づいて失効します。更新には、エントリの作成および変更(更新)が含まれます。このポリシーは、JCacheのModifiedExpiryPolicyクラスで実装されています。

- タッチ – 最後にタッチされた日時に基づくキャッシュ・エントリです。タッチには、作成、更新またはアクセスが含まれます。このポリシーは、JCacheのTouchedExpiryPolicyクラスで実装されています。

- 永続(デフォルト) – キャッシュ・エントリは失効しません。このポリシーは、JCacheのEternalExpiryPolicyクラスで実装されています。

失効ポリシーおよび期間は、分散キャッシュ・シナリオをサポートするためにシリアライズされる必要があります。Coherence JCacheプロバイダはシリアライズにPortable Object Format (POF)を使用し、プロバイダには失効タイプ用のPOFシリアライザが含まれています。パーティション・キャッシュがパススルー・キャッシュとともに使用されている場合は、Coherence JCacheプロバイダがこれらのタイプを使用できるように構成する必要があります。詳細は、「JCache POF構成ファイルの構成」を参照してください。

35.3.4 リードスルーおよびライトスルー・キャッシングの有効化

リードスルーおよびライトスルー・キャッシングを使用すると、アプリケーションはデータ・ソースからキャッシュへのデータのロードや、キャッシュからデータ・ソースへのデータの書込みができるようになります。データ・ソースはデータベースと統合するのが最も一般的ですが、すべてのデータ・ソースはJCacheのキャッシュと統合できます。リードスルーおよびライトスルー・キャッシングはデフォルトでは有効でなく、JCacheのCacheLoaderおよびCacheWriterインタフェースそれぞれにアプリケーション固有の実装が必要となります。

リードスルーおよびライトスルー・キャッシングを有効にするには、setReadThroughおよびsetWriteThroughメソッドをそれぞれtrueに設定します。例:

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setReadThrough(true).setWriteThrough(true);

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

CacheLoaderおよびCacheWriterの実装を登録するには、それぞれsetCacheLoaderFactoryおよびsetCacheWriterFactoryメソッドを使用し、実装クラスの完全修飾名を入力します。例:

cacheWriter = new MyCacheWriter();
cacheLoader = new MyCacheLoader();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setReadThrough(true).setWriteThrough(true)
.setCacheWriterFactory(FactoryBuilder.factoryOf(cacheWriter));
.setCacheLoaderFactory(FactoryBuilder.factoryOf(cacheLoader));

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

この実装は、あるキャッシュ操作を行った際に自動的に使用されます。リードスルーおよびライトスルー・キャッシングの詳細は、「リードスルーおよびライトスルー・キャッシングの使用」を参照してください。

35.3.5 管理の有効化

JCacheは、CacheMXBeanおよびCacheStatisticsMXBeanという2つの動的MBeanを提供しています。CacheMXBean MBeanは、キャッシュの構成設定を表示します。CacheStatisticsMXBean MBeanは、キャッシュのパフォーマンス統計を表示します。JCacheの管理の詳細は、「JCache管理情報の表示」を参照してください。

管理はデフォルトで無効になっています。管理情報を有効化するには、キャッシュを構成する際にsetManagementEnabledおよびsetStatisticsEnabledメソッドをtrueに設定します。例:

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration config = new MutableConfiguration();
config.setManagementEnabled(true).setStatisticsEnabled(true);

Cache cache = cacheManager.createCache("MyCache", config);

管理は、実行時にキャッシュ・マネージャを使用して有効化することもできます。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration config = new MutableConfiguration();

Cache cache = cacheManager.createCache("MyCache", config);

cacheManager.enableManagement("MyCache", true);
cacheManager.enableStatistics("MyCache", true);

35.4 キャッシュ操作の実行

JCacheには、キャッシュとやり取りを行う多くの操作が含まれています。これらの操作は、javax.cache.Cacheインタフェースで定義されています。すべての使用可能なJCacheの操作のセマンティクスおよび詳細は、Cache APIドキュメントを参照してください。

キャッシュ操作を行う前に、まずキャッシュの作成および構成を行う必要があります。次の例では、単純なputおよびget操作を実行します:

注意:
キーと値はnullにはできません。

CachingProvider provider = Caching.getCachingProvider();
CacheManager cacheManager = provider.getCacheManager();

MutableConfiguration config = new MutableConfiguration();

Cache cache = cacheManager.createCache("MyCache", config);

cache.put("k1", "Hello World");
System.out.println("The value is " + cache.get("k1")+ "\n");

前述の例では、コンパイル時または実行時のエントリの型チェックは行われません。型チェックの実行の詳細は、「キャッシュ・エントリの型の設定」を参照してください。

CoherenceのJCache操作の理解

キャッシュ操作の実装は、LocalCache、PartitionedCacheおよびPassThroughCacheの各キャッシュ・タイプによって異なります。たとえば、パーティション・キャッシュの操作は、Coherenceのデータ・シリアライズの利点を活用できるCoherenceエントリ・プロセッサによって実装されています。各キャッシュ・タイプは、使用するキャッシュ・トポロジの利点を活用できるキャッシュ操作の実装を提供しています。

35.5 リードスルーおよびライトスルー・キャッシングの使用

JCacheは、キャッシュと外部リソースを統合するために、リードスルーおよびライトスルー・キャッシングの使用をサポートしています。リードスルー・キャッシングを使用するとエントリが自動的に外部リソースからロードされ、ライトスルー・キャッシングを使用するとエントリが自動的に外部リソースに書き込まれます。リードスルーおよびライトスルー・キャッシングでは、アプリケーションがそれぞれJCacheのCacheLoaderおよびCacheWriterインタフェースを実装している必要があります。リードスルーおよびライトスルー・キャッシングは、デフォルトでは有効になっていません。詳細は、「リードスルーおよびライトスルー・キャッシングの有効化」を参照してください。

注意:
Coherenceパススルー・キャッシュを使用するアプリケーションは、Coherenceでリードスルーおよびライトスルー・キャッシングをネイティブに使用でき、JCache固有のローダーおよびライターの実装を含める必要はありません。

35.5.1 リードスルー実装の提供

リードスルー・キャッシングを使用するには、アプリケーションはCacheLoaderインタフェースを実装する必要があります。実装の詳細は、使用する外部リソースに固有です。CacheLoaderメソッドの実装の詳細は、JCache APIドキュメントを参照してください。

CacheLoaderインタフェースは、loadおよびloadAllメソッドを提供しています。これらのメソッドは、実装が外部リソースに接続してそこから値または一連の値を取得するために必要なロジックを含める目的で使用されます。get、getAll、getAndRemoveまたはgetAndReplace操作の結果、指定されたキーのエントリが見つからない場合にキャッシュ・ローダーの実装が毎回自動的に起動されます。エントリ・プロセッサを使用し、そのエントリ・プロセッサがgetValueメソッドを使用する場合、invokeおよびinvokeAll操作によって自動的にキャッシュ・ローダーが使用されます。エントリ・プロセッサの詳細は、「JCacheエントリの処理」を参照してください。

35.5.1.1 キャッシュの事前ロード

Cache APIには、キャッシュの事前ロードに使用されるCache.loadAllメソッドが含まれています。このメソッドを使用すると、CacheLoader実装のloadAllメソッドが呼び出されます。この場合でもCacheLoaderの実装はキャッシュ上で構成される必要がありますが、リードスルー・キャッシングが有効化されている必要はありません。例:

cacheLoader = new MyCacheLoader();

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setTypes(String.class, String.class)
.setReadThrough(false)
.setCacheLoaderFactory(FactoryBuilder.factoryOf(cacheLoader));

前述の例では、factoryOfメソッドはMyCacheLoaderの実装のインスタンスを受け取っています。このメソッドは、状態を持ち実装クラスがシリアライズ可能である必要がある実装に使用されます。実装に状態がない場合は、かわりにfactoryOf(Class)またはfactoryOf(String classname)メソッドを使用することをお薦めします。

外部リソースからのキャッシュのロードが完了するまでには、長い時間がかかる可能性があります。CompletionListenerインタフェースを使用すると、アプリケーションはキャッシュがロードされた場合またはキャッシュのロード時に例外が発生した場合に通知を受けることができます。CompletionListenerFutureクラスは、必要に応じて使用できるデフォルトの実装です。例:

cacheLoader = new MyCacheLoader();

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setTypes(String.class, String.class)
.setReadThrough(false)
.setCacheLoaderFactory(FactoryBuilder.factoryOf(cacheLoader));
Cache<String, String> cache = cacheManager.createCache("MyCache", config);

CompletionListenerFuture future = new CompletionListenerFuture();

cache.loadAll(keys, true, future);

35.5.2 ライトスルー実装の提供

ライトスルー・キャッシングを使用するには、アプリケーションはCacheWriterインタフェースを実装する必要があります。実装の詳細は、使用する外部リソースに固有です。CacheWriterメソッドの実装の詳細は、JCache APIドキュメントを参照してください。

CacheWriterインタフェースは、エントリを外部リソースに書き込むメソッド(writeおよびwriteAll)および外部リソースからエントリを削除するメソッド(deleteおよびdeleteAll)を提供しています。これらのメソッドは、実装が外部リソースに接続してそのデータを更新するために必要なロジックを含める目的で使用されます。キャッシュ・ライターの実装は、put、putAll、putIfAbsent、remove、removeAll、replace、getAndPut、getAndRemove、getAndReplace、invokeおよびinvokeAllのキャッシュ操作が行われると、毎回自動的に起動されます。

35.6 JCache POF構成ファイルの構成

Coherence JCacheプロバイダはシリアライズにPOFを使用し、coherence-pof-config.xmlファイルを必要とします。JCache固有のPOFタイプは、coherence-jacache.jar\coherence-jcache-pof-config.xml POF構成ファイルで定義されています。パーティション・キャッシュをパススルー・キャッシュとともに使用している場合、POF構成ファイルの一部にJCache POFタイプが含まれている必要があります。例:

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-pof-config coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
<include>coherence-jcache-pof-config.xml</include>
...

POF構成ファイルの詳細は、「POF構成ファイルの指定」を参照してください。

35.7 JCache管理情報の表示

Coherence JCacheプロバイダは、CacheMXBeanおよびCacheStatisticsMXBeanの両方の動的MBeanインタフェースを実装しています。このインタフェースは、次の管理情報を提供します:

- CacheMXBean – キャッシュの構成情報を報告します。各構成オプションおよび現在の設定が、属性としてリストされます。

- CacheStatisticsMXBean – キャッシュのパフォーマンス情報を報告します。パフォーマンス統計は属性としてリストされ、キャッシュで発生する可能性がある問題のトラブルシューティングに使用できます。

管理情報は、デフォルトでは有効化されていません。管理の有効化の詳細は、「管理の有効化」を参照してください。

注意:
パススルー・キャッシュの管理情報は、Coherence固有のJMX管理の実装を使用して報告されます。Coherence固有の管理の有効化の詳細は、『Oracle Coherenceのマネージメント』を参照してください。

Coherence JCache MBean

管理情報は、JDK (JDK_HOME/bin/jvisualvm)に含まれているJava VisualVMコンソールなどのすべてのJMX MBean対応のブラウザで表示できます。ローカルおよびパーティション・キャッシュの管理MBeanは、デフォルトのMBeanサーバーに登録され、javax.cacheのJMXブラウザ内にあります。

Coherence-Java VisualVMプラグイン

JCache管理情報はCoherence-Java VisiualVMプラグインを使用して表示することができます。プラグインには、経時的な管理情報を集計し、構成およびパフォーマンスの問題のトラブルシューティングに使用するJCacheタブが含まれています。JCacheのCoherenceレポートの詳細は、『Oracle Coherenceのマネージメント』を参照してください。

Coherenceレポート

JCache管理情報はCoherenceレポートを使用して表示することもできます。Coherence JCacheレポートは、経時的な管理情報を集計し、構成およびパフォーマンスの問題のトラブルシューティングに使用されます。JCacheのCoherenceレポートの詳細は、『Oracle Coherenceのマネージメント』を参照してください。

35.7.1 CacheConfiguration MBeanの理解

CoherenceCacheMXBeanクラスはCacheMXBeanインタフェースを実装し、キャッシュの構成情報を提供します。MBeanオブジェクトは各キャッシュに登録されます。MBeanのオブジェクト名は次のようになります。

javax.cache:type=CacheConfiguration,CacheManager=coherence-jcache-cache-config.xml,Cache=cache_name

35.7.1.1 属性

表35-1に、CacheConfiguration MBeanの属性を示します。

表35-1 CacheConfiguration MBeanの属性

属性

型

アクセス

説明

KeyType

String

読取り専用

キャッシュが必要とするキーの型です。必要とされるキーの型が構成されていない場合のデフォルトの値は、java.lang.objectで、これは型チェックが無効になっていることを示します。

ManagementEnabled

Boolean

読取り専用

キャッシュの管理が有効化されているかどうかを示します。デフォルト値はfalseです。

ReadThrough

Boolean

読取り専用

キャッシュ操作がリードスルー・モードかどうかを示します。デフォルト値はfalseです。

StatisticsEnabled

Boolean

読取り専用

キャッシュのパフォーマンス統計が収集されているかどうかを示します。デフォルト値はfalseです。

StoreByValue

Boolean

読取り専用

キャッシュが値による格納または参照による格納のどちらのセマンティクスを使用しているかを示します。デフォルト値はtrueで、キーと値は値によって格納されることを示します。falseは、キーと値は参照によって格納されることを示します。

ValueType

String

読取り専用

キャッシュが必要とする値の型です。必要とされる値の型が構成されていない場合のデフォルトの値は、java.lang.objectで、これは型チェックが無効になっていることを示します。

WriteThrough

Boolean

読取り専用

キャッシュ操作がライトスルー・モードかどうかを示します。デフォルト値はfalseです。

35.7.1.2 操作

CacheConfiguration MBeanには、すべての構成管理情報をリセットするclear操作が含まれています。

35.7.2 CacheStatistics MBeanの理解

Coherence JCacheプロバイダには、JCacheのCacheStatisticsMXBeanインタフェースの2つの実装が含まれています。ContextJCacheStatistics実装は、ローカル・キャッシュのパフォーマンス統計の収集に使用されます。PartitionedJCacheStatisticsは、Coherence内のすべての記憶域メンバーのパフォーマンス統計の収集および集計に使用されます。MBeanオブジェクトは各キャッシュに登録されます。MBeanのオブジェクト名は次のようになります。

javax.cache:type=CacheStatistics,CacheManager=coherence-jcache-cache-config.xml,Cache=cache_name

35.7.2.1 属性

表35-2に、CacheStatistics MBeanの属性を示します。

表35-2 キャッシュ統計属性

属性

型

アクセス

説明

AverageGetTime

Float

読取り専用

get操作を行う平均時間です。リードスルー・キャッシュの場合、キャッシュ・ミスによるエントリのロードに必要な時間は含まれません。

AveragePutTime

Float

読取り専用

put操作を行う平均時間です。

AverageRemoveTime

Float

読取り専用

remove操作を行う平均時間です。

CacheEvictions

Long

読取り専用

キャッシュからのエビクションの総数です。エビクションは、スペースを開放するため、キャッシュによって開始されます。エビクションは、remove操作とはみなされません。

注意: この属性は、Coherence JCacheプロバイダでは実装されていません。

CacheGets

Long

読取り専用

get操作の総数です。この値はヒットとミスの合計に等しく、キーの存在チェック操作は含みません。

CacheHitPercentage

Float

読取り専用

エントリを返したキャッシュ・リクエストの割合です。この割合は、キャッシュ・ヒットをキャッシュのget操作で割って計算され、10進値として報告されます。

CacheHits

Long

読取り専用

成功したget操作の回数です。

CacheMissPercentage

Float

読取り専用

エントリを返さなかったキャッシュ・リクエストの割合です。この割合は、キャッシュ・ミスをキャッシュのget操作で割って計算され、10進値として報告されます。

CacheMisses

Long

読取り専用

成功しなかったget操作の回数です。

CachePuts

Long

読取り専用

既存のエントリの置換操作を含むput操作の総数です。

CacheRemovals

Long

読取り専用

remove操作の総数です。スペースを開放するためにキャッシュによって開始されるエビクションは含みません。

35.7.2.2 操作

CacheStatistics MBeanには、すべてのキャッシュ統計をリセットするclear操作が含まれています。

35.7.3 パーティション・キャッシュ統計のリフレッシュ間隔の変更

Coherence JCacheプロバイダは、パーティション・キャッシュのパフォーマンス統計のリフレッシュ・タイミングを決定するためにリフレッシュ間隔を使用します。リフレッシュは遅延して実行されます。統計は、リフレッシュ間隔に達して統計を取得する呼出しが行われた場合にのみリフレッシュされます。統計を取得する呼出しが行われない場合は、リフレッシュ間隔に達した場合でも統計はリフレッシュされません。

デフォルトのリフレッシュ間隔は3秒で、様々なクラスタ・サイズおよびネットワーク・パフォーマンスに対応するために変更できます。たとえば、多くの記憶域メンバーを持つクラスタでは、すべてのメンバーの統計の集計および恒常的な更新の回避のために、長いリフレッシュ間隔が必要かもしれません。

リフレッシュ間隔を変更するには、tangosol.coherence.jcache.statistics.refreshtimeシステム・プロパティに時間をミリ秒で設定します。次の例では、リフレッシュ間隔を5秒に構成しています。

-Dtangosol.coherence.jcache.statistics.refreshtime=5000

36 JCacheイベントの使用

この章では、JCacheイベントを処理するイベント・リスナーの作成および登録の手順について説明します。JCacheイベント・モデルはjavax.cache.eventパッケージで定義され、Java Caching API仕様の第8章「Cache EntryListeners」で説明されています。

この章には次の項が含まれます:

- JCacheイベントの使用の概要

- イベント・リスナーの作成

- イベント・フィルタの作成

- イベント・リスナーおよびフィルタの登録

36.1 JCacheイベントの使用の概要

JCacheイベント・モデルによって、アプリケーションはキャッシュ内のエントリの監視可能な変更を表すイベントの受信および処理が可能になります。イベント・モデルは、標準JavaイベントおよびJavaアプリケーションには一般的なイベント・リスナー規則を使用します。

JCacheイベントは、CacheEntryEventクラスで定義されるキャッシュ・エントリに固有の標準Javaイベントです。JCacheはキャッシュ・エントリ用に4つのイベント・タイプを定義しています。

- CREATED – キャッシュ・エントリの作成を示します。

- UPDATED – キャッシュ・エントリの更新を示します。

- REMOVED – キャッシュ・エントリの削除を示します。

- EXPIRED – キャッシュ・エントリの失効を示します。

JCacheイベント・モデルはイベント・リスナー使用してイベントを処理し、すべての必要なイベントの処理を実行します。各イベント・タイプには、対応するイベント・リスナー・インタフェースがあり、必要に応じて実装できます。さらに、イベント・フィルタを使用することによって、イベントがリスナーにディスパッチされる前にイベントを処理できます。イベント・リスナーおよびフィルタは、キャッシュの構成時に静的に登録することも、キャッシュが作成された後に動的に登録することもできます。

Coherence JCacheプロバイダでは、ローカル、パーティションおよびパススルー・キャッシュのJCacheイベントの使用がサポートされています。プロバイダは、Coherence固有のMapListenerおよびMapEvent APIを活用してJCacheイベントを実装しています。アプリケーションは、基礎となるNamedCacheインスタンスに動的にアクセスしてMapListener APIを使用できますが、直接そのように使用する場合は、JCache Coherence実装によって提供される追加の動作はバイパスされます。

36.2 イベント・リスナーの作成

各イベント・タイプには、CacheEntryListenerインタフェースを拡張した対応するイベント・リスナー・インタフェースがあります。イベント・タイプ・インタフェースには、CacheEntryCreatedListener、CacheEntryUpdatedListener、CacheEntryRemovedListenerおよびCacheEntryExpiredListenerインタフェースが含まれています。単一のイベント・リスナーが複数のイベント・タイプ・リスナー・インタフェースを実装することも、複数のイベント・リスナーが同じイベント・タイプ・リスナー・インタフェースを実装することも可能です。次の例では、キャッシュにエントリが作成されるごとにイベントの詳細を含むログ・メッセージを出力するCREATEDイベントのイベント・リスナーを作成しています。

例36-1 イベント・リスナーの実装例

import java.io.Serializable;
import javax.cache.event.CacheEntryCreatedListener;
import javax.cache.event.CacheEntryEvent;
import javax.cache.event.CacheEntryListenerException;

public class MyCacheEntryListener<K, V>
implements CacheEntryCreatedListener<K, V>, Serializable
{
private static final long serialVersionUID = 1L;

public void onCreated(Iterable<CacheEntryEvent<? extends K, ? extends V>>
events)
throws CacheEntryListenerException
{
for (CacheEntryEvent<? extends K, ? extends V> event : events)
{
System.out.println("Received a " + event);
}
}
}

シリアライズが必要なイベント・リスナーは、POFシリアライズを使用できます。ただし、POFにはキャッシュ・プロバイダ実装間の移植性はありません。

36.3 イベント・フィルタの作成

キャッシュ・エントリ・イベント・フィルタは、イベントがエントリ・イベント・リスナーにディスパッチされる前にキャッシュ・イベントを評価する機会を提供します。イベント・フィルタによって、必要に応じて追加の処理を実行することが可能になります。イベント・フィルタは、CacheEntryEventFilterインタフェースを実装する必要があります。次の例では、イベントのディスパッチを停止し、システム・メッセージを出力するCREATEDイベントのイベント・フィルタを作成しています。

例36-2 イベント・フィルタの実装例

import java.io.Serializable;
import javax.cache.event.CacheEntryEvent;
import javax.cache.event.CacheEntryEventFilter;
import javax.cache.event.CacheEntryListenerException;
import javax.cache.event.EventType;

public class MyCacheEntryEventFilter<K, V>
implements CacheEntryEventFilter<K, V>, Serializable
{
private static final long serialVersionUID = 1L;

public boolean evaluate(CacheEntryEvent<? extends K, ? extends V> event)
throws CacheEntryListenerException
{
boolean result = false;

if (event.getEventType() == EventType.CREATED)
{
System.out.println("filter event=" + event + " filter result=" +
result);
}

return result;
}
}

シリアライズが必要なイベント・フィルタは、POFシリアライズを使用できます。ただし、POFにはキャッシュ・プロバイダ実装間の移植性はありません。

36.4 イベント・リスナーおよびフィルタの登録

キャッシュ・エントリ・リスナーおよびイベント・フィルタは、キャッシュの構成時に静的に登録することも、キャッシュ・インスタンスが作成された後に動的に登録することもできます。どちらの方法でも、リスナー構成を使用する必要があります。この構成は、CacheEntryListenerConfigurationインタフェースで定義されています。MutableCacheEntryListenerConfigurationクラスは、この項で説明される必要に応じて使用できるデフォルトの実装を提供しています。この構成は、使用するリスナー実装クラス、使用するフィルタ実装クラス、古い値をイベントの一部として送信するかどうか、イベント通知が同期的な非同期的かを指定するために使用されます。リスナーに通知が行われる順番は保証されていません。

36.4.1 キャッシュ構成時のイベント・リスナーおよびフィルタの登録

CacheEntryListenerおよびCacheEntryEventFilterの実装を構成時に静的に登録するには、addCacheEntryListenerConfigurationメソッドを使用し、実装クラスを含め、必要に応じてリスナーを構成します。次の例では、例36-1および例36-2で作成したイベント・リスナーおよびフィルタをそれぞれ登録しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

m_listener = new MyCacheEntryListener();

MutableConfiguration<String, String> config =
new MutableConfiguration<String, String>();
config.setTypes(String.class, String.class).addCacheEntryListenerConfiguration(
new MutableCacheEntryListenerConfiguration<String, String>
(FactoryBuilder.factoryOf(m_listener),FactoryBuilder.factoryOf(
new MyCacheEntryEventFilter<String, String>()),true,true));

Cache<String, String> cache = cacheManager.createCache("MyCache", config);

構成例では、2つのtrueプロパティで示されるように、エントリの古い値を含め、同期ディスパッチを使用するようにイベント通知を設定しています。

removeCacheEntryListenerConfigurationメソッドは、以前に登録されたキャッシュ・エントリ・リスナーを削除します。

36.4.2 実行時のイベント・リスナーおよびフィルタの登録

CacheEntryListenerおよびCacheEntryEventFilterの実装をキャッシュ・インスタンスに実行時に動的に登録するには、RegisterCacheEntryListenerメソッドを使用し、実装クラスを含め、必要に応じてリスナーを構成します。次の例では、例36-1および例36-2で作成したイベント・リスナーおよびフィルタをそれぞれ登録しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

m_listener = new MyCacheEntryListener();

MutableConfiguration<String, Sring> config =
new MutableConfiguration<String, String>();
config.setTypes(String.class, String.class);

Cache<String, String> cache = cacheManager.createCache("MyCache", config);

cache.registerCacheEntryListener(
new MutableCacheEntryListenerConfiguration<String, String>
(FactoryBuilder.factoryOf(m_listener),FactoryBuilder.factoryOf(
new MyCacheEntryEventFilter<String, String>()),false,false));

構成例では、2つのfalseプロパティで示されるように、エントリの古い値を含めず、非同期ディスパッチを使用するようにイベント通知を設定しています。

deregisterCacheEntryListenerメソッドは、以前に登録されたキャッシュ・エントリ・リスナーを削除します。

37 JCacheエントリの処理

この章では、キャッシュ・エントリを変更するためにJCacheエントリ・プロセッサを作成および使用する手順について説明します。エントリ・プロセッサはjavax.cache.processorパッケージで定義され、Java Caching API仕様の第9章「Entry Processors」で説明されています。

この章には次の項が含まれます:

- JCacheエントリの処理の概要

- エントリ・プロセッサの作成

- エントリ・プロセッサの使用

37.1 JCacheエントリの処理の概要

JCacheは、アトミックでロック・フリーな方法でキャッシュ・エントリの更新を実行するエントリ・プロセッサの使用をサポートしています。分散キャッシュ環境では、エントリはキャッシュ・データを保持している異なるサーバーのそれぞれで並列に処理されます。

多くの場合、エントリ・プロセッサは1回の操作でキャッシュに複数の変更を行うために使用されます。たとえば、エントリ・プロセッサは一連のキーの値を評価し、あるロジックに基づいて異なる値を返すかもしれません。アプリケーションは処理の最終的な結果のみを表示でき、エントリ・プロセッサが起動中である中間の結果にはアクセスしません。処理中にエラーは発生した場合、例外がスローされ、キャッシュは変更されません。

エントリ・プロセッサはEntryProcessorインタフェースを実装する必要があります。エントリ・プロセッサの実装は、Cache.invokeおよびCache.invokeAllメソッドによって実行時にキャッシュ・エントリ上で起動されます。

また、Coherence JCacheプロバイダは、ローカル、パーティションおよびパススルー・キャッシュでのJCacheエントリ・プロセッサの使用をサポートしています。プロバイダは、Coherence固有のInvocableMap.EntryProcessor APIを使用してJCacheエントリ・プロセッサを実装しています。

37.2 エントリ・プロセッサの作成

エントリ・プロセッサはEntryProcessorインタフェースを実装する必要があります。このインタフェースには、キャッシュ・エントリのすべての処理ロジックを提供する1つのprocessメソッドが含まれています。エントリ・プロセッサは、MutableEntryエントリを操作します。MutableEntryインタフェースは、エントリ・プロセッサが処理の間、エントリに排他アクセスすることを保証します。processメソッドでも、すべての引数を定義できます。引数は、プロセッサが起動された際にそのプロセッサに渡されます。

エントリ・プロセッサの一部として実行される操作はアプリケーションには見えず、processメソッドが完了した後でのみ有効になります。processメソッドでエラーが発生した場合、キャッシュ・エントリは変更されません。

エントリ・プロセッサはインプロセスで実行されることは保証されないため、常にシリアライズ可能です。たとえば、Coherenceパーティション・キャッシュを使用する場合は、エントリ・プロセッサが処理されるデータを含むキャッシュ・サーバー上で実行される可能性があります。Coherenceキャッシュでは、エントリ・プロセッサはPOFシリアライズも使用できます。ただし、POFにはキャッシュ・プロバイダ実装間の移植性はありません。

例37-1では、キャッシュ・エントリの値を1つ増やすエントリ・プロセッサを作成しています。このエントリの値は整数です。キー、値および戻り値の型は、APIによって要求される型の安全性を保証するために明示的に定義されています。

例37-1 EntryProcessorの実装例

import java.io.Serializable;
import javax.cache.processor.EntryProcessor;
import javax.cache.processor.EntryProcessorException;
import javax.cache.processor.MutableEntry;

public class MyEntryProcessor implements EntryProcessor <String, Integer,
Integer>, Serializable
{
public static final long serialVersionUID = 1L;

public Integer process(MutableEntry<String, Integer> entry,
Object... arguments) throws EntryProcessorException
{

if (entry.exists())
{
Integer current = entry.getValue();
entry.setValue(current + 1);
return current;
}
else
{
entry.setValue(0);
return -1;
}
}
}

37.3 エントリ・プロセッサの使用

Cache APIは、エントリ・プロセッサを起動する2つのメソッドを提供しています。invokeメソッドは単一のキャッシュ・エントリを操作し、invokeAllメソッドは一連のキャッシュ・エントリを操作します。エントリは、キー名を使用して指定します。

37.3.1 単一のキーに対するエントリ・プロセッサの起動

エントリ・プロセッサは、Cacheインスタンスからinvokeメソッドを使用して単一のキーに対して起動されます。次の例は、単一キーの処理を示しています。この例では、例37-1で作成したMyEntryProcessorの実装を使用しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setTypes(String.class, Integer.class);

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

String key = "k";
Integer value = 1;

cache.put(key, value);

System.out.println("The value is " + cache.get(key) + "\n");

cache.invoke(key, new MyEntryProcessor());

System.out.println("The value is now " + cache.get(key) + "\n");

37.3.2 複数のキーに対するエントリ・プロセッサの起動

エントリ・プロセッサは、invokeAllメソッドを使用して複数のキーに対して起動されます。キーは、Set実装によってグループ化されている必要があります。プロセッサはセット内の各キーに対して起動されますが、キーが処理される順番は保証されていません。次の例は、HashSetクラスによってグループ化されている複数のキーを処理し、EntryProcessorResult.getメソッドを使用してある特定のキーに対するエントリ・プロセッサから戻された値を取得する方法を示しています。この例では、例37-1で作成したMyEntryProcessorの実装を使用しています。

CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<String, Integer> config =
new MutableConfiguration<String, Integer>();
config.setTypes(String.class, Integer.class);

Cache<String, Integer> cache = cacheManager.createCache("MyCache", config);

String key = "k";
Integer value = 1;
String key1 = "k1";
Integer value1 = 1;

cache.put(key, value);
cache.put(key1, value1);

HashSet hs = new HashSet();
hs.add(key);
hs.add(key1);

Map<String, EntryProcessorResult<Integer>> map = cache.invokeAll(hs,
new MyEntryProcessor());

System.out.println("The value of k is now " + cache.get(key) +
" the result of invokeAll for k is previous value of " + map.get(key).get() +
"\n");

System.out.println("The value of k1 is now " + cache.get(key1) +
" the result of invokeAll for k1 is previous value of " + map.get(key1).get() +
"\n");

第VI部

付録

第VI部は、次の付録で構成されています。

- 付録A「オペレーション構成の要素」

- 付録B「キャッシュ構成の要素」

- 付録C「POFユーザー定義型の構成要素」

- 付録D「システム・プロパティのオーバーライド」

- 付録E「PIF-POFバイナリ形式」

A オペレーション構成の要素

この付録では、オペレーション・デプロイメント・ディスクリプタ要素の詳細なリファレンスを提供し、これらの要素が表示されるデプロイメント・ディスクリプタ・ファイルについて簡単に説明します。

この付録では次の項について説明します。

- オペレーション・デプロイメント・ディスクリプタ

- オペレーション・オーバーライド・ファイル

- 要素リファレンス

- 属性リファレンス

A.1 オペレーション・デプロイメント・ディスクリプタ

tangosol-coherence.xmlオペレーション・デプロイメント・ディスクリプタでは、クラスタリング、通信およびデータ管理サービスを制御する操作設定および実行時設定を指定します。このオペレーション・デプロイメント・ディスクリプタはcoherence.jarライブラリのルートにあります。カスタムのtangosol-coherence.xmlファイルを作成できますが、操作設定の変更に推奨される方法は、後述の「オペレーション・オーバーライド・ファイル」で説明するように、tangosol-coherence-override.xmlオペレーション・オーバーライド・ファイルを使用することです。

オペレーション・デプロイメント・ディスクリプタ・スキーマはcoherence-operational-config.xsdファイルで定義します。これがcoherence-operational-config-base.xsdファイルをインポートし、これがさらにcoherence-config-base.xsdファイルを暗黙的にインポートします。このオペレーション・デプロイメント・ディスクリプタ・スキーマ・ファイルは、coherence.jarライブラリのルートおよび次のWeb URLにあります。

http://xmlns.oracle.com/coherence/coherence-operational-config/1.2/coherence-operational-config.xsd

<cohrence>要素はオペレーション・ディスクリプタのルート要素であり、XSDおよびCoherenceネームスペース・リファレンスと、coherence-operational-config.xsdファイルの場所が含まれます。例:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">

注意:

- coherence.jarライブラリにあるスキーマは、xsi:schemaLocation属性がWeb URLを参照する場合であっても、常に実行時に使用されます。

- xsi:schemaLocation属性を省略すると、スキーマ検証を無効にできます。

- デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、デプロイメント・ディスクリプタ・ファイルがASCII形式であり、ランタイム環境にバイナリ形式でデプロイされることを確認してください。

A.2 オペレーション・オーバーライド・ファイル

操作設定の構成に推奨される方法は、オペレーション・オーバーライド・ファイルを使用することです。オーバーライド・ファイルのスキーマは、すべての要素がオプションであることを除き、オペレーション・デプロイメント・ディスクリプタと同一です。欠落している要素はすべてtangosol-coherence.xmlオペレーション・デプロイメント・ディスクリプタからロードされます。オーバーライド・ファイルのデフォルト名はtangosol-coherence-override.xmlです。実行時に、このファイルがクラスパス内のcoherence.jarライブラリの前に置かれている必要があります。

追加のオーバーライド・ファイルは、<coherence>要素内のxml-override属性を使用して構成できます。これにより、ステージングと本番など、類似のデプロイメント環境間で追加のチューニングが可能になります。この機能の例は、coherence.jar内のtangosol-coherence-override-eval.xml、tangosol-coherence-override-dev.xmlおよびtangosol-coherence-override-prod.xmlの各ファイルを参照してください。xml-override属性の使用方法の詳細は、「属性リファレンス」を参照してください。

要素リファレンス

表A-1は、オペレーション構成のすべての非終端要素を示しています。

表A-1 オペレーション構成の非終端要素

要素

使用場所

access-controller

security-config

address-provider

well-known-addresses、address-providers

address-providers

cluster-config

authorized-hosts

cluster-config

cache-factory-builder-config

coherence

callback-handler

security-config

cluster-config

coherence

cluster-quorum-policy

cluster-config

coherence

ルート要素

configurable-cache-factory-config

coherence

filter

filters

filter

cluster-config

flashjournal-manager

journaling-config

flow-control

packet-delivery

host-range

authorized-hosts

identity-asserter

security-config

identity-manager

ssl

identity-transformer

security-config

incoming-message-handler

cluster-config

init-param

init-params

init-params

access-controller、address-provider、callback-handler、configurable-cache-factory-config、filter、service

instance

socket-provider、service-failure-policy

journaling-config

cluster-config

key-store

identity-manager、trust-manager

license-config

coherence

logging-config

coherence

management-config

coherence

mbean

mbeans

mbeans

management-config

mbean-filter

management-config

member-identity

cluster-config

multicast-listener

cluster-config

notification-queueing

packet-publisher

outgoing-message-handler

cluster-config

outstanding-packets

flow-control

packet-buffer

multicast-listener、packet-publisher、unicast-listener

packet-bundling

packet-delivery

packet-delivery

packet-publisher

packet-publisher

cluster-config

packet-size

packet-publisher

packet-speaker

cluster-config

pause-detection

flow-control

provider

ssl、identity-manager、trust-manager

ramjournal-manager

journaling-config

reporter

management-config

security-config

coherence

serializer

serializers

serializers

cluster-config

service-guardian

cluster-config

service

services

services

cluster-config

shutdown-listener

cluster-config

socket-address

well-known-addresses

socket-provider

socket-providers、unicast-listener

socket-providers

cluster-config

ssl

socket-provider

tcp-ring-listener

cluster-config

traffic-jam

packet-publisher

trust-manager

ssl

unicast-listener

cluster-config

volume-threshold

packet-speaker

well-known-addresses

unicast-listener

access-controller

使用場所: security-config

説明

access-controller要素には、com.tangosol.net.security.AccessControllerインタフェースを実装するクラスの構成情報が含まれます。Coherenceセキュリティ・フレームワークはこれを使用してアクセス権をチェックしたり、ノード間の通信を暗号化または復号化します。

要素

表A-2で、access-controller要素のサブ要素を説明します。

表A-2 access-controllerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

com.tangosol.net.security.AccessControllerインタフェースを実装するJavaクラスの名前を指定します。セキュリティ・フレームワークはこれを使用してクラスタ化リソースのアクセス権をチェックしたり、これらの権限に関するノード間の通信を暗号化または復号化します。アクセス・コントローラの使用方法の詳細は、『Oracle Coherenceの保護』を参照してください。デフォルト値はcom.tangosol.net.security.DefaultControllerです。

<init-params>

オプション

AccessControllerインタフェースを実装するクラスの初期化パラメータを1つ以上記述します。デフォルトのAccessController実装の場合、パラメータには次のように、キーストア・ファイルと権限記述ファイルへのパスを指定します。

<init-params>
<init-param id="1">
<param-type>java.io.File</param-type>
<param-value system-property="tangosol.coherence.security.keystore"></param-value>
</init-param>
<init-param id="2">
<param-type>java.io.File</param-type>
<param-value system-property="tangosol.coherence.security.permissions"></param-value>
</init-param>
</init-params>

デフォルトのAccessController実装およびデフォルトのパラメータに基づいて事前構成されるシステム・プロパティ・オーバーライドは、前述のように、tangosol.coherence.security.keystoreおよびtangosol.coherence.security.permissionsになります。init-param要素のサブ要素の詳細は、「init-param」を参照してください。

address-provider

使用場所: well-known-addresses、address-providers

説明

address-provider要素は、ソケット・アドレス情報(IPまたはDNS名およびポート)またはcom.tangosol.net.AddressProviderインタフェースの実装のいずれかを指定します。このインタフェースは、ソケット・アドレスをプログラムで定義する方法を提供します。

well-known-addresses要素内で、address-provider要素を使用して、com.tangosol.net.AddressProviderインタフェースを実装するアドレス・ファクトリを指定します。このインタフェースは、プログラムでWell Knownアドレス(WKA)メンバーを定義する方法を提供します。WKAの詳細は、「Well Knownアドレスの使用」を参照してください。次の例は、well-known-addresses要素内でのaddress-provider要素の使用方法を示しています。

<unicast-listener>
<well-known-addresses>
<address-provider>
<class-name>package.MyAddressProvider</class-name>
</address-provider>
</well-known-addresses>
</unicast-listener>

address-providers要素内で、address-provider要素を使用して、ソケット・アドレスまたはcom.tangosol.net.AddressProviderインタフェースを実装するアドレス・ファクトリを指定します。アドレス・プロバイダ定義は、Coherence*Extendの設定に使用されるTCP/IPアクセプタおよびTCP/IPイニシエータによって参照されます。また、TCP/IPアクセプタもmemcachedクライアントで使用できます。

キャッシュ構成ファイルのtcp-acceptor、memcached-acceptor、remote-addressesおよびname-service-addresses要素は、指定されているid属性値を使用してアドレス・プロバイダ定義を参照します。tcp-acceptor要素の詳細は、「tcp-acceptor」を参照してください。memcached-acceptor要素の詳細は、「memcached-acceptor」を参照してください。remote-addresses要素の詳細は、「remote-addresses」を参照してください。name-service-addresses要素の詳細は、「name-service-addresses」を参照してください。次の例は、<address-providers>要素内でのアドレス・プロバイダ定義の定義方法を示しています。

<address-providers>
<address-provider id="ap1">
<class-name>package.MyAddressProvider</class-name>
</address-provider>
<address-provider id="ap2">
<socket-address>
<address>192.168.1.3</address>
<port>9999</port>
</socket-address>
</address-provider>
<address-provider id="ap3">
<socket-address>
<address>192.168.1.4</address>
<port>9999</port>
</socket-address>
</address-provider>
</address-providers>

要素

表A-3で、address-provider要素のサブ要素を説明します。

表A-3 address-providerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.AddressProviderインタフェースを実装するクラスの完全修飾名を指定します。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

一致するシグネチャを持つpublicなコンストラクタが含まれる実装によってアクセス可能な初期化パラメータを指定します。初期化パラメータは、<class-name>要素と<class-factory-name>要素の両方を使用する場合に指定できます。

<socket-address>

オプション

ソケットがバインドされるアドレス(IPまたはDNS名およびポート)を指定します。

この要素は、TCP/IPアクセプタのソケット・アドレスを定義する場合にのみ使用してください。アドレス・プロバイダ実装が<class-name>または<class-factory-name>要素を使用して定義されている場合、この要素は使用できません。

address-providers

使用場所: cluster-config

説明

address-providers要素には、アドレス・プロバイダごとの宣言データを記述します。

要素

表A-4で、address-provider要素のサブ要素を説明します。

表A-4 address-providersのサブ要素

要素

必須/
オプション

説明

<address-provider>

オプション

ソケット・アドレス情報またはcom.tangosol.net.AddressProviderインタフェースの実装のいずれかを指定します。address-provider要素は複数指定できます。

authorized-hosts

使用場所: cluster-config

説明

これを指定すると、クラスタ・メンバーシップが、ユニキャスト・アドレスのコレクションまたはアドレス範囲で指定されたクラスタ・ノードに制限されます。ユニキャスト・アドレスは、認可されたクラスタ・ノードのunicast-listener要素のアドレス値です。任意の数のhost-address要素およびhost-range要素を指定できます。

要素

表A-5で、authorized-hosts要素のサブ要素を説明します。

表A-5 authorized-hostsのサブ要素

要素

必須/
オプション

説明

<host-address>

オプション

IPアドレスまたはホスト名を指定します。これを指定すると、host-addressが指定されたホスト、または指定されたhost-range内のホストのみがクラスタに参加できます。内容のオーバーライド属性idを使用して、この要素の内容の全部または一部を、ベース・ドキュメントの外部にあるXMLドキュメントでオーバーライドすることもできます。

<host-range>

オプション

IPアドレスの範囲を指定します。これを指定すると、host-addressが指定されたホスト、または指定されたhost-range内のホストのみがクラスタに参加できます。内容のオーバーライド属性idを使用して、この要素の内容の全部または一部を、ベース・ドキュメントの外部にあるXMLドキュメントでオーバーライドすることもできます。

<host-filter>

オプション

新しいクラスタ・メンバーを受け入れるかどうかを判断するためクラスタによって使用されるcom.tangosol.util.Filter実装のクラス構成情報を指定します。evaluate()メソッドにクライアントのjava.net.InetAddressが渡されます。新しいメンバーのクラスタへの参加を許可するには、実装がtrueを返す必要があります。

cache-factory-builder-config

使用場所: coherence

説明

cache-factory-builder-config要素には、com.tangosol.net.CacheFactoryBuilderインタフェースのインスタンスを作成するための構成情報を記述します。デフォルトの実装はcom.tangosol.net.DefaultCacheFactoryBuilderクラスで、高度な用途では、これを拡張してConfigurableCacheFactoryインスタンスを作成および管理するためのよりドメイン固有なロジックを提供できます。

複数のクラス・ローダーにわたる複数のキャッシュ・ファクトリ構成を構築および管理するには、カスタムのCacheFactoryBuilder実装を使用します。これは、異なるクラス・ローダーによってスコープ設定されるアプリケーションが、異なるキャッシュ構成ファイルを使用できるようにする高度な使用例(JavaEEおよびOSGIと同様)です。たとえば、次のコードでは、2つのクラスローダーのカスタムConfigurableCacheFactory実装を使用します。

CacheFactoryBuilder cfb = CacheFactory.getCacheFactoryBuilder();

//load the first configuration
cfb.getConfigurableCacheFactory("example-config.xml", loader0);
CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("dist-example");

//load the second configuration
cfb.getConfigurableCacheFactory("example-config1.xml", loader1);
CacheFactory.ensureCluster();
NamedCache cache1 = CacheFactory.getCache("dist-example1");

要素

表A-6で、cache-factory-builder-config要素のサブ要素を説明します。

表A-6 cache-factory-builder-configのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tagosol.net.CacheFactoryBuilderインタフェースを実装するJavaクラスの名前を指定します。デフォルト値はcom.tangosol.net.DefaultCacheFactoryBuilderです。

<init-params>

オプション

キャッシュ・ファクトリ・ビルダー実装の初期化パラメータを記述します。

<scope-resolver>

オプション

com.tangosol.net.ScopeResolverインタフェースを実装するクラスの構成情報を指定します。スコープ・リゾルバを実装すると、実行時に与えられたConfigurableCacheFactoryのスコープ名を変更し、同じクラスタで実行されているアプリケーション間の分離を有効(または無効)にできます。カスタム・スコープ・リゾルバの実装は、<class-nameサブ要素内で指定します。ScopeResolverインタフェースの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

キャッシュ構成ファイル内でスコープ名を指定する方法の詳細は、<cache-config>要素の<scope-name>サブ要素を参照してください。

callback-handler

使用場所: security-config

表A-7で、callback-handler要素のサブ要素を説明します。

表A-7 callback-handlerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

javax.security.auth.callback.CallbackHandlerインタフェースの実装を提供するJavaクラスの名前を指定します。

<init-params>

オプション

CallbackHandler実装の初期化パラメータを1つ以上記述します。

cluster-config

使用場所: <coherence>

説明

通信パラメータやサービス・パラメータなどのクラスタ構成情報を記述します。

要素

表A-8で、cluster-config要素のサブ要素を説明します。

表A-8 cluster-configのサブ要素

要素

必須/
オプション

説明

<member-identity>

オプション

クラスタ・メンバーの位置とロールの定義に有用な、詳細な識別情報を指定します。

<unicast-listener>

必須

Point-to-Pointネットワーク通信の受信に使用するユニキャスト・リスナーの構成情報を指定します。

<multicast-listener>

必須

Point-to-Multipointネットワーク通信の受信に使用するマルチキャスト・リスナーの構成情報を指定します。

<tcp-ring-listener>

必須

停止検出に使用するTCPリング・リスナーの構成情報を指定します。

<shutdown-listener>

必須

外部シャットダウン・リクエストを受信したときに実行するアクションを指定します。

<service-guardian>

必須

サービスのデッドロックの検出と解決に使用されるサービス・ガーディアンの構成情報を指定します。

<packet-speaker>

必須

ネットワーク・データ転送に使用するパケット・スピーカーの構成情報を指定します。

<packet-publisher>

必須

ネットワーク・データ転送の管理に使用するパケット・パブリッシャの構成情報を指定します。

<incoming-message-handler>

必須

受信するクラスタ通信のディスパッチに使用する受信メッセージ・ハンドラの構成情報を指定します。

<outgoing-message-handler>

必須

送信するクラスタ通信のディスパッチに使用する送信メッセージ・ハンドラの構成情報を指定します。

<authorized-hosts>

オプション

クラスタに参加できるホストを指定します。

<services>

必須

使用可能なCoherenceサービスすべての宣言データを指定します。

<filters>

オプション

クラスタ・ノード間で転送されるデータに対するカスタム変換を実行できるデータ変換フィルタを指定します。

<serializers>

オプション

com.tangosol.io.Serializerを実装する任意の数のシリアライザ・クラス構成を指定します。

<address-providers>

オプション

プロキシ・サービスのTCP/IPアクセプタによって参照可能な任意の数のアドレス・プロバイダ定義を指定します。

<socket-providers>

必須

ソケット・プロバイダの定義を記述します。

<cluster-quorum-policy>

オプション

クラスタ・サービスのクォーラムベース・アクション・ポリシーの構成情報を記述します。

<journaling-config>

オプション

ジャーナル・サブシステムの構成を指定します。

cluster-quorum-policy

使用場所: <cluster-config>

説明

cluster-quorum-policy要素には、クラスタ・サービス用のクォーラム・ポリシー設定を記述します。

要素

表A-9で、cluster-quorum-policy要素のサブ要素を説明します。

表A-9 cluster-quorum-policy-schemeのサブ要素

要素

必須/
オプション

説明

<timeout-survivor-quorum>

オプション

根本原因に関係なく、ネットワークのタイムアウトの検出により1つ以上のクラスタ・メンバーを終了するために保持する必要のある、クラスタ・メンバーの最小数を指定します。値は負ではない整数である必要があります。

(<role-name>要素で定義した)指定されたロールのクラスタ・メンバーのこの値を指定するには、role属性を使用します。例:

<timeout-survivor-quorum role="Server">50
</timeout-survivor-quorum>

<class-name>

オプション

カスタム・クォーラム・ポリシーを提供するクラスを指定します。この要素は、<timeout-survivor-quorum>要素または<class-factory-name>要素と一緒には使用できません。

クラスは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。初期化パラメータは、<init-params>要素を使用して指定できます。

<class-factory-name>

オプション

カスタム・アクション・ポリシー・インスタンスを作成するためのファクトリ・クラスを指定します。この要素は、<timeout-survivor-quorum>要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用されます。アクション・ポリシーは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。さらに、初期化パラメータは、<init-params>要素を使用して指定できます。

coherence

ルート要素

説明

coherence要素は、オペレーション・デプロイメント・ディスクリプタtangosol-coherence.xmlのルート要素です。

要素

表A-10で、coherence要素のサブ要素を説明します。

表A-10 coherenceのサブ要素

要素

必須/
オプション

説明

<cluster-config>

必須

クラスタ構成情報を記述します。この要素では、ほとんどの通信およびサービスのパラメータを定義します。

<logging-config>

必須

ロギング機能の構成情報を記述します。

<configurable-cache-factory-config>

必須

構成可能なキャッシュ・ファクトリの構成情報を記述します。これにより、キャッシュ構成設定のロード元およびロード方法を制御します。

<cache-factory-builder-config>

必須

キャッシュ・ファクトリ・ビルダーの構成情報を記述します。これにより、複数のクラス・ローダーにわたり、複数のキャッシュ・ファクトリ構成の構築および管理が可能になります。

<management-config>

必須

Coherenceの管理フレームワークの構成情報を記述します。詳細は、『Oracle Coherenceのマネージメント』を参照してください。

<security-config>

オプション

Coherenceのセキュリティ・フレームワークの構成情報を記述します。

<license-config>

オプション

エディションおよび操作モードの構成を記述します。

configurable-cache-factory-config

使用場所: coherence

説明

configurable-cache-factory-config要素には、com.tangosol.net.ConfigurableCacheFactoryインタフェースのインスタンスを作成するための構成情報を記述します。デフォルトの実装は、com.tangosol.net.ExtensibleConfigurableCacheFactoryクラスです。

カスタムのConfigurableCacheFactory実装の使用は高度な使用例で、通常、異なるクラス・ローダーによってスコープ設定されるアプリケーションが、異なるキャッシュ構成ファイルを使用できるようにするために使用されます(JavaEEおよびOSGIと同様)。

次の例では、異なるキャッシュ定義を含み、異なるClassLoadersを使用する2つの構成ファイルをロードします。

//load the first configuration and use a cache

ConfigurableCacheFactory  eccf= new
ExtensibleConfigurableCacheFactory("example-config.xml", loader0);
NamedCache cache = eccf.ensureCache("dist-example", loader0);
cache.put(key, value);

//load the second cache configuration and use a cache

ConfigurableCacheFactory  eccf1= new
ExtensibleConfigurableCacheFactory("example-config1.xml", loader1);
NamedCache cache1 = eccf1.ensureCache("dist-example1", loader1);
cache1.put(key, value);

注意:
この例では、各キャッシュ定義が異なるサービス名を使用する必要があります。そうしない場合、異なる構成ディスクリプタのファクトリによりサービスが開始されたことを示す例外がスローされます。

要素

表A-11で、configurable-cache-factory-config要素のサブ要素を説明します。

表A-11 configurable-cache-factory-configのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

com.tangosol.net.ConfigurableCacheFactoryインタフェースを実装するJavaクラスの名前を指定します。デフォルト値はcom.tangosol.net.ExtensibleConfigurableCacheFactoryです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.cachefactoryです。

<init-params>

オプション

キャッシュ構成ファクトリ実装の初期化パラメータを記述します。デフォルトのキャッシュ構成ファクトリ・クラスの場合、次のように1つのパラメータが使用されます。

<init-param>
<param-type>java.lang.String</param-type>
<param-value>coherence-cache-config.xml</param-value>
</init-param>

./path/to/config.xmlのような絶対パスまたは相対パスが指定されない場合、アプリケーションのクラスパスを使用して、指定されたディスクリプタを見つけます。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.cacheconfigです。

filter

使用場所: filters

説明

データ変換フィルタはサービスによって使用され、クラスタ・ノード間で転送されるデータに対するカスタム変換に適用できます。これは、ネットワーク・トラフィックを圧縮するインスタンスに使用できます。詳細は、<filter-class>要素を参照してください。

実装

データ変換フィルタは、com.tangosol.util.WrapperStreamFactoryインタフェースの実装です。

注意:
データ変換フィルタは、com.tangosol.util.Filterには関係がなく、キャッシュの問合せに使用するCoherence APIの一部です。

要素

表A-12で、各filter要素のサブ要素を説明します。

表A-12 filterのサブ要素

要素

必須/
オプション

説明

<filter-name>

必須

フィルタの正規名を指定します。この名前はクラスタ内で一意です。例: gzip

<filter-class>

必須

フィルタ実装のクラス名を指定します。このクラスには、パラメータがゼロのpublicなコンストラクタが必要であり、com.tangosol.util.WrapperStreamFactoryインタフェースを実装する必要があります。

<init-params>

オプション

フィルタを構成するための初期化パラメータを指定します。たとえばcom.tangosol.net.CompressionFilterを使用する場合、パラメータは次のように指定します。

<init-param>
<param-name>strategy</param-name>
<param-value>gzip</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>default</param-value>
</init-param>

標準的なフィルタのパラメータ値の詳細は、「ネットワーク・フィルタの使用」を参照してください。

filters

使用場所: cluster-config

説明

filters要素には、各フィルタの宣言データを記述します。

要素

表A-13で、filters要素のサブ要素を説明します。

表A-13 filtersのサブ要素

要素

必須/
オプション

説明

<filter>

オプション

filter要素には、特定のフィルタの宣言データを記述します。

flashjournal-manager

使用場所: journaling-config

説明

<flashjournal-manager>要素には、フラッシュ・ジャーナル・リソース・マネージャの構成が含まれており、これによって一時的なジャーナルベースのファイルからソリッド状態のデバイスへのI/Oが管理されます。

要素

表A-14で、flashjournal-manager要素のサブ要素を説明します。

表A-14 flashjournal-managerのサブ要素

要素

必須/
オプション

説明

<minimum-load-factor>

オプション

この値未満であれば、ジャーナル・ファイルが圧縮(ガベージ・コレクション)に適したものになる、ライブ・データ率を指定します。

<maximum-value-size>

オプション

フラッシュ・ジャーナルに格納されるバイナリ値の最大サイズをバイト単位で指定します。64MB以下の値を指定する必要があります。デフォルト値は64MBです。

<maximum-file-size>

オプション

基礎となるジャーナル・ファイルの最大ファイル・サイズを指定します。この値は2の累乗であり、ブロック・サイズの倍数である必要があります。値は、1MBと4GBの間である必要があり、最低2つの値をファイルに格納できるだけの大きさである必要があります。デフォルト値は2GBです。

<collector-timeout>

オプション

ジャーナル・コレクタが、タイムアウトと判断する前に待機する時間を指定します。タイムアウトの最小値は30sです。有効な値は、時間間隔を表す文字列です。デフォルト値は10mです。

<block-size>

オプション

書込みバッファがここで指定したサイズに達すると、基礎となるディスク・ファイルへの書き込みが発生します。このサイズは、物理デバイスの最適ブロック・サイズと一致するか、その倍数であり、2の累乗である必要があります。値は4KBから1MBの範囲にする必要があります。デフォルト値は256KBです。

<maximum-pool-size>

オプション

バッファ・プールのサイズをバイト単位で指定します。このサイズによって、割当て可能または特定の時点で存在可能なバッファの数が制限されることはありません。このサイズによって決まるのは、再利用されるバッファの数のみです。プールの最大サイズは1GBです。デフォルト値は16MBです。

<directory>

オプション

ジャーナル・ファイルを配置するディレクトリを指定します。既存のディレクトリを指定する必要があります。実行時には作成されません。ディレクトリが存在しないか、指定されていない場合は、JVMまたはオペレーティング・システムのデフォルトの一時ディレクトリが使用されます。推奨される場所は、ローカルのフラッシュ(SSD)ドライブです。

他のアプリケーションまたはシステム操作によって共有されているドライブ上にあるディレクトリを指定すると、予定外の領域使用量になる可能性が高くなります。より予測可能な環境を確保するために、共有されていないディスク・パーティション上のディレクトリを使用してください。

<async-limit>

オプション

バックログの最大サイズをバイト単位で指定します。バックログは、まだ永続化されていないデータの量です。クライアント・スレッドは、指定されている制限を超えるとブロックされ、バックログが制限を下回るまでブロックされたままになります。これは、メモリー不足の状態を回避するのに役立ちます。注意: バックログで使用するメモリーの最大容量は、指定されている容量の2倍以上にする必要があります。これは、データがバイナリ形式であり、ライトビハインド・バッファにレンダリングされるからです。値は4KBから1GBの範囲にする必要があります。デフォルト値は16MBです。

<tmp-purge-delay>

オプション

ジャーナル・サブシステムによって使用されている一時ファイルが削除に適したものになるまでの待機時間を指定します。この遅延は、ファイルが最後に使用された後に開始されます。デフォルト値は2時間です。

<high-journal-size>

オプション

ジャーナル・サイズまたはフラッシュ・ジャーナル容量のパーセンテージに、バイト単位で弱い制限を指定します。弱い制限では、圧縮(ガベージ・コレクション)スレッドが自己調整して、失効している値を削除し、ジャーナルをその制限以内に保ちます。これは、強い制限ではなく、ジャーナルは依然として最大ファイル数(512)まで大きくなることができます。デフォルト値は11GBです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.flashjournal.highjournalsizeです。

<writer-timeout>

オプション

ジャーナル・ライターが、タイムアウトと判断する前に待機する時間を指定します。タイムアウトの最小値は30sです。有効な値は、時間間隔を表す文字列です。デフォルト値は8hです。

(writer-timeout値に達した後で)ライターに障害が発生した場合、そのメンバーが再起動されるまでジャーナルは読取り専用になります。(async-limit値で設定されている)書込みバックログの最大値に達した場合、ジャーナルは、書込みが解決されるまでまたはwriter-timeoutを超えた場合は無制限に、その後の格納リクエストに対して例外で応答します。

flow-control

使用場所: packet-delivery

説明

flow-control要素には、パケット速度の調整およびリモートGCの検出に関連する構成情報を記述します。

要素

表A-15で、flow-control要素のサブ要素を説明します。

表A-15 flow-controlのサブ要素

要素

必須/
オプション

説明

<enabled>

オプション

フロー制御を有効にするかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

<pause-detection>

オプション

応答のないクラスタ・ノードに再送信するパケットの数を定義します。このパケット数を超過すると、そのノードは一時停止していると見なされます。

<outstanding-packets>

オプション

クラスタ・ノードに送信する未確認パケットの数を定義します。このパケット数を超過すると、そのノードを送信先とするパケットは遅延されます。

host-range

使用場所: authorized-hosts

説明

クラスタに参加できるノードのユニキャスト・アドレスの範囲を指定します。

要素

表A-16で、各host-range要素のサブ要素を説明します。

表A-16 host-rangeのサブ要素

要素

必須/
オプション

説明

<from-address>

必須

ホスト・アドレスの範囲の開始IPアドレスを指定します(例: 198.168.1.1)。

<to-address>

必須

ホストの範囲の終了IPアドレスを指定します(例: 198.168.2.255)。

identity-asserter

使用場所: security-config

説明

<identity-asserter>要素には、com.tangosol.net.security.IdentityAsserterインタフェースを実装するクラスの構成情報を記述します。このクラスは、ユーザーのIDを確立するためIDトークンを検証する際にコールされ、Coherence*Extendプロキシ・サーバーで使用されます。IDアサーション・プロバイダが(Coherence*Extendクライアント上で使用される)IDトランスフォーマとともに使用され、有効なクライアントのみが拡張プロキシに接続できるようにします。

要素

表A-17で、<identity-asserter>要素のサブ要素を説明します。

表A-17 identity-asserterのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.security.IdentityAsserterを実装するクラスを指定します。この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

asserterインスタンスを作成するためのファクトリ・クラスを指定します。このインスタンスは、com.tangosol.net.security.IdentityAsserterを実装する必要があります。この要素は、<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

アサーション・プロバイダ実装のクラス初期化パラメータを記述します。

identity-manager

使用場所: ssl

説明

<identity-manager>要素には、javax.net.ssl.KeyManagerインスタンスを初期化するための構成情報を記述します。

アイデンティティ・マネージャは、そのピアへのローカル接続を認証するために使用されるキー・マテリアルの管理を行います。キー・マテリアルが使用できない場合、その接続では認証資格証明を提示できません。

要素

表A-18で、identity-manager要素のサブ要素を説明します。

表A-18 identity-managerのサブ要素

要素

必須/
オプション

説明

<algorithm>

オプション

アイデンティティ・マネージャによって使用されるアルゴリズムを指定します。デフォルト値はSunX509です。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<key-store>

オプション

キー・ストア実装の構成を指定します。

<password>

必須

秘密鍵のパスワードを指定します。

identity-transformer

使用場所: security-config

説明

<identity-transformer>要素には、com.tangosol.net.security.IdentityTransformerインタフェースを実装するクラスの構成情報を記述します。このクラスは、Subject(.NETではPrincipal)を、IDをアサートしCoherence*Extendクライアントで使用されるトークンに変換する際にコールされます。IDトランスフォーマが(Coherence*Extendプロキシ・サーバー上で使用される)IDアサーション・プロバイダとともに使用され、有効なクライアントのみが拡張プロキシに接続できるようにします。

要素

表A-19で、<identity-transformer>要素のサブ要素を説明します。

表A-19 identity-transformerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.security.IdentityTransformerを実装するクラスを指定します。この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

asserterインスタンスを作成するためのファクトリ・クラスを指定します。このインスタンスは、com.tangosol.net.security.IdentityTransformerを実装する必要があります。この要素は、<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

トランスフォーマ実装のクラス初期化パラメータを記述します。

incoming-message-handler

使用場所: cluster-config

説明

incoming-message-handlerは、UDPパケットを論理メッセージにアセンブルして、それを適切なCoherenceサービスにディスパッチして処理させます。

要素

表A-20で、incoming-message-handler要素のサブ要素を説明します。

表A-20 incoming-message-handlerのサブ要素

要素

必須/
オプション

説明

<maximum-time-variance>

必須

新しいクラスタ・メンバーのシステム時刻とクラスタ時刻との間の差異を測定する際に、ブロードキャスト・メッセージの送受信間の最大時刻差異を指定します。差異が小さいほど、クラスタ内で実行中の複数のシステム間でクラスタ時刻が接近する確率が高まりますが、クラスタに参加するプロセスは、指定された差異内でメッセージの交換が起こることが可能になるまで延長されます。通常は、20ミリ秒程度の値で十分ですが、負荷の高いクラスタや複数のネットワーク・ホップでは、より大きな値が必要になる場合があります。デフォルト値は16です。

<use-nack-packets>

必須

パケットの受信側で否定応答(パケット・リクエスト)を使用して、欠落パケットを認識したときに積極的に応答するかどうかを指定します。詳細と構成は、「notification-queueing」を参照してください。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

<priority>

必須

受信メッセージ・ハンドラの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は7です。

init-param

使用場所: init-params

説明

初期化パラメータを定義します。任意の数のinit-param要素を指定できます。

要素

表A-21で、init-param要素のサブ要素を説明します。

表A-21 init-paramのサブ要素

要素

必須/
オプション

説明

<param-name>

オプション

初期化パラメータの名前を指定します。例:

<init-param>
<param-name>sTableName</param-name>
<param-value>EmployeeTable</param-value>
</init-param>

<param-type>要素が指定されている場合は、<param-name>要素は指定できません。特定のサービスで使用できる事前定義のパラメータの詳細は、「初期化パラメータの設定」を参照してください。

<param-type>

オプション

初期化パラメータのJavaタイプを指定します。次の標準タイプがサポートされています。

- java.lang.String (string)

- java.lang.Boolean (boolean)

- java.lang.Integer (int)

- java.lang.Long (long)

- java.lang.Double (double)

- java.math.BigDecimal

- java.io.File

- java.sql.Date

- java.sql.Time

- java.sql.Timestamp

例:

<init-param>
<param-type>java.lang.String</param-type>
<param-value>EmployeeTable</param-value>
</init-param>

<param-name>要素が指定されている場合は、<param-type>要素は指定できません。

<param-value>

必須

初期化パラメータの値を指定します。この値は、パラメータのJavaタイプに固有の形式にします。

<description>

オプション

初期化パラメータの説明を指定します。

init-params

使用場所: address-provider、filter、service、configurable-cache-factory-config、access-controllerおよびcallback-handler

説明

一連の初期化パラメータを定義します。

要素

表A-22で、init-params要素のサブ要素を説明します。

表A-22 init-paramsのサブ要素

要素

必須/
オプション

説明

<init-param>

オプション

個別の初期化パラメータを定義します。

instance

使用場所: service-failure-policy、scope-resolverおよびpartition-assignment-strategy

説明

<instance>要素には、カスタム機能をプラグインするために使用される実装クラスまたはクラス・ファクトリの構成を記述します。

要素

表A-23で、instance要素のサブ要素を説明します。

表A-23 instanceのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

実装クラスの完全修飾名を指定します。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

一致するシグネチャを持つpublicなコンストラクタが含まれる実装によってアクセス可能な初期化パラメータを指定します。初期化パラメータは、<class-name>要素と<class-factory-name>要素の両方を使用する場合に指定できます。

journaling-config

使用場所: cluster-config

説明

<journaling-config>要素には、フラッシュおよびRAMメモリーにバイナリ形式でデータを格納する役割を持つリソース・マネージャの構成が含まれます。

要素

表A-23で、journaling-config要素のサブ要素を説明します。

表A-24 journaling-configのサブ要素

要素

必須/
オプション

説明

<ramjournal-manager>

必須

RAMジャーナル・リソース・マネージャの構成を指定します。

<flashjournal-manager>

必須

フラッシュ・ジャーナル・リソース・マネージャの構成を指定します。

key-store

使用場所: identity-manager、trust-manager

説明

key-store要素は、SSLの実装時に使用するキー・ストア実装の構成を指定します。キー・ストア実装は、java.security.KeyStoreクラスのインスタンスです。

要素

表A-25で、key-store要素のサブ要素を説明します。

表A-25 key-storeのサブ要素

要素

必須/
オプション

説明

<url>

必須

キー・ストアへのUniform Resource Locator (URL)を指定します。

<password>

オプション

キャッシュ・ストアのパスワードを指定します。

<type>

オプション

java.security.KeyStoreインスタンスのタイプを指定します。デフォルト値はJKSです。

license-config

使用場所: coherence

表A-26で、license-config要素のサブ要素を説明します。

表A-26 license-configのサブ要素

要素

必須/
オプション

説明

<edition-name>

オプション

メンバーが使用する製品のエディションを指定します。有効な値は、GE (Grid Edition)、EE (Enterprise Edition)、SE (Standard Edition)、RTC (Real-Time Client)、DC (Data Client)です。デフォルト値はGEです。

注意: エディションの切替えによってライセンスの制限が適用されることはなくなりました。デフォルトの設定(GE)を変更しないでください。

<license-mode>

オプション

製品を開発モードと本番モードのいずれで使用するかを指定します。有効な値は、prod(本番)とdev(開発)です。注意: この値は、tangosol-coherence-override.xmlでオーバーライドできません。これは、tangosol-coherence.xmlで指定するか、またはJavaコマンド行でシステム・プロパティtangosol.coherence.modeとして指定する必要があります(後者を推奨)。デフォルト値はdevです。

logging-config

使用場所: coherence

要素

次の表で、logging-config要素のサブ要素を説明します。

表A-27 logging-configのサブ要素

要素

必須/
オプション

説明

<destination>

必須

ロギング・システムで使用する出力デバイスを指定します。有効な値は次のとおりです。

- stdout

- stderr(デフォルト)

- jdk

- log4j

- slf4j

- file name

log4jが指定されている場合、Log4jライブラリがクラスパスに存在する必要があります。どちらの場合でも、適切なロギング構成メカニズム(システム・プロパティやプロパティ・ファイルなど)がJDK/Log4jロギング・ライブラリの構成に必要です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.logです。

<logger-name>

オプション

Coherence関連のメッセージを記録するよう選択されたロギング・システム内でのロガー名を指定します。この値は、JDKおよびlog4jロギング・システムでのみ使用されます。デフォルト値はCoherenceです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.log.loggerです。

<severity-level>

必須

どのログ・メッセージをログ出力先に出力するかを指定します。有効な値は-1から9です。-1を指定した場合、メッセージは出力されません。ログ・レベルを上げると、より多くのログ・メッセージが出力されます。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.log.levelです。

<message-format>

必須

ログ出力先に渡す前に、ロギング・レベルが指定されたメッセージをフォーマットする方法を指定します。このフォーマットには、静的テキストおよび{date}、{uptime}、{product}、{version}、{level}、{thread}、{member}、{location}、{role}、{text}および{ecid}のいずれかの置換可能なパラメータを含めることができます。デフォルト値は次のとおりです。

{date}/{uptime} {product} {version} &lt;{level}&gt; (thread={thread}, member={member}): {text}

<character-limit>

必須

ロガー・デーモンがメッセージ・キューから処理する文字の最大数を指定します。この数を超過すると、キューに残っているメッセージがすべて破棄されます。破棄されたメッセージはすべて、ロギング・システムによって、破棄されたメッセージの数と合計サイズの詳細を説明する1つのログ・エントリでまとめられます。有効な値は、正の整数または0です。ゼロは制限がないことを示します。製品モードのデフォルト値は1048576、開発モードのデフォルト値は2147483647です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.log.limitです。

management-config

使用場所: coherence

要素

表A-28で、management-config要素のサブ要素を説明します。

表A-28 management-configのサブ要素

要素

オプション/
必須

説明

<managed-nodes>

必須

クラスタ・ノードのJVMに[in-process] MBeanサーバーを設定するかどうか、また設定する場合は、そのノードに他ノードの管理オブジェクトの管理を許可するかどうかを指定します。有効な値は次のとおりです。

- none - (デフォルト)このクラスタ・ノードにはMBeanサーバーがインストールされていません。

- local-only - このクラスタ・ノードにローカルな(つまり、同じJVM内の)MBeanのみを管理します。

- remote-only - リモートで管理できる他のクラスタ・ノードのMBeanを管理します。<allowed-remote-management>サブ要素を参照してください。

- all - ローカルとリモートの両方で管理できるクラスタ・ノードを管理します。<allowed-remote-management>サブ要素を参照してください。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.managementです。

<allow-remote-management>

必須

このクラスタ・ノードで、管理オブジェクトをリモートのMBeanサーバーに公開するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.management.remoteです。

<refresh-policy>

オプション

リモート管理情報のリフレッシュに使用されるメソッドを指定します。有効な値は、refresh-ahead、refresh-behindまたはrefresh-expiredです。デフォルト値はrefresh-aheadです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.management.refresh.policyです。

<refresh-expiry>

オプション

管理ノードでリモートのMBean情報が無効化されるまでの時間間隔(ミリ秒単位)を指定します。有効な値は、時間間隔を表す文字列です。デフォルト値は1sです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.management.refresh.expiryです。

<refresh-timeout>

オプション

MBean情報のリフレッシュ時に管理ノードがリモート・ノードからのレスポンスを待つ期間を指定します。この値はrefresh-expiryの間隔より小さくする必要があります。有効な値は、時間間隔を表す文字列です。デフォルト値は250msです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.management.refresh.timeoutです。

<read-only>

オプション

このクラスタ・ノードで公開された管理オブジェクトに、実行時属性の変更操作を許可するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.management.readonlyです。

<default-domain-name>

オプション

Coherence管理フレームワークにより公開されるMBeanを登録するために使用される既存のMBeanサーバーのドメイン名を指定します。この要素は、クラスタ・メンバーで管理が有効化されていて、MBeanサーバーがクラスタ・メンバーと同じプロセス内にある場合にのみ使用できます。値が指定されていない場合、最初の既存のMBeanサーバーが使用されます。この要素は、既存のMBeanサーバーを識別するためにのみ使用してください。

この要素は、MBeanServerFinderインタフェースの実装時にも使用されます。後述の<server-factory>要素を参照してください。

<service-name>

オプション

リモート管理に使用する起動サービスの名前を指定します。この要素は、allow-remote-managementがtrueに設定されている場合にのみ使用されます。

<server-factory>

オプション

com.tangosol.net.management.MBeanServerFinderインタフェースを実装するMBeanServerファクトリの構成情報を記述します。これは、新しいMBeanの登録および既存のMBeanの検索のためCoherence JMXフレームワークによって使用されるMbeanサーバーを見つけるために使用されます。ドメイン名が<default-domain-name>要素に指定されている場合、クラスをインスタンス化するときにそれが使用されます。クラス名は、<class-name>サブ要素を使用して入力され、<init-params>要素を使用して初期化パラメータをサポートします。

<mbeans>

オプション

ノードがクラスタに参加するときに登録されるMBeanのリストを記述します。

<mbean-filter>

オプション

登録前にMBeanをフィルタ処理するために使用されるフィルタ・クラスの構成情報を記述します。

<reporter>

オプション

Reporterの構成を記述します。

<extended-mbean-name>

オプション

nodeId属性で識別されるグローバルMBean名を拡張して、対応するメンバー名(指定された場合)を識別するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseで、グローバルMBean名にメンバー名が含まれないことを示します。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.management.extendedmbeannameです。

mbean

使用場所: mbeans

説明

mbean要素には、Coherence管理フレームワークでインスタンス化および登録される要素のリストを記述します。

要素

表A-29で、mbean要素のサブ要素を説明します。

表A-29 mbeanのサブ要素

要素

必須/
オプション

説明

<mbean-class>

オプション

Coherence管理フレームワークでインスタンス化および登録する標準MBeanのフル・クラス名を指定します。正しくインスタンス化するには、クラスパスにMBeanクラスを指定する必要があります。

この要素は、<mbean-factory>要素または<mbean-query>要素と一緒には使用できません。

<mbean-factory>

オプション

Coherence管理フレームワークに登録するMBeanを取得するために使用するクラス・ファクトリの名前を指定します。正しくインスタンス化するには、クラスパスにファクトリ・クラスを指定する必要があります。この要素は、<mbean-accessor>要素と一緒に使用されます。

この要素は、<mbean-class>要素または<mbean-query>要素と一緒には使用できません。

<mbean-query>

オプション

JMX ObjectName問合せパターンを指定します。問合せパターンはローカルのMBeanサーバーに対して実行され、生成されたオブジェクトはCoherence管理フレームワークに登録されます。これにより、グリッドに対してMBeanのシングル・ポイント統合が可能になります。たとえば次の問合せには、Coherence Managementインフラストラクチャのjava.langドメインにすべてのMBeanが含まれます。

<mbean-query>java.lang:*</mbean-query>

この要素は、<mbean-class>要素または<mbean-factory>要素と一緒には使用できません。

<mbean-server-domain>

オプション

ソースMBeanサーバーのデフォルト・ドメインの名前を指定します。これは、mbean-queryを実行する必要のあるMBeanサーバーを見つけるために使用されます。

<mbean-accessor>

オプション

MBeanのインスタンス化に使用されるファクトリ・クラス(<mbean-factory>要素により指定)のメソッド名を指定します。

<mbean-name>

必須

Coherence管理フレームワークに登録するMBeanのJMX ObjectName接頭辞を指定します。接頭辞は、カンマで区切られたKey=Valueのペアとします。CoherenceのMBeanの命名規則には、名前は型/値のペア(たとえば、type=Platform)で始まる必要があると規定されています。

<local-only>

オプション

MBeanをクラスタ全体で参照可能にするかどうかを指定します。有効な値は、trueまたはfalseです。trueに設定されていると、MBeanはローカルのMBeanサーバーにのみ登録され、他のクラスタ・ノードからはアクセスできません。falseに設定されていると、nodeId=...キー属性がその名前に追加され、MBeanが任意の管理ノード(<managed-nodes>要素がallまたはremote-onlyの値に設定されているノード)から参照できます。デフォルト値はfalseです。

<enabled>

オプション

このインスタンスでMBeanをインスタンス化および登録するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<extend-lifecycle>

オプション

MBeanがノード接続のライフ・サイクルを超えるかどうかを指定します。有効な値は、trueまたはfalseです。trueの場合、MBeanは複数回の接続にわたって統計および値を保持します(JVMのライフ・サイクルと一致します)。falseの場合、MBeanは破棄され、グリッドからノードの接続が切断されたときに再作成されます。デフォルト値はfalseです。

mbeans

使用場所: management-config

説明

mbeans要素は、カスタムMBeanを定義するためのルート要素で、カスタムMBean構成ファイルのルート要素です。これには、Coherence管理フレームワークでインスタンス化および登録されるmbean要素のリストを記述します。

要素

表A-30で、mbeans要素のサブ要素を説明します。

表A-30 mbeansのサブ要素

要素

必須/
オプション

説明

<mbean>

必須

Coherence管理フレームワークでインスタンス化および登録されるMBeanのタイプ、実装およびObjectNameを指定します。

mbean-filter

使用場所: management-config

説明

mbean-filter要素は、MBeanサーバーに登録する前にMBean名を評価するフィルタの指定に使用します。com.tangosol.net.management.ObjectNameExcludeFilterクラスはデフォルトのフィルタで、標準のRegexパターンを使用するJMXオブジェクト名に基づいて、MBeanが登録されないように除外する場合に使用します。リストは、空白文字により区切られた名前のリストとして入力されます。次のMBeanは、初期状態の構成では除外されています。

<management-config>
<mbean-filter>
<class-name>com.tangosol.net.management.ObjectNameExcludeFilter</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value system-property="tangosol.coherence.management.exclude">
.*type=Service,name=Management,.*
.*type=Platform,Domain=java.lang,subType=ClassLoading,.*
.*type=Platform,Domain=java.lang,subType=Compilation,.*
.*type=Platform,Domain=java.lang,subType=MemoryManager,.*
.*type=Platform,Domain=java.lang,subType=Threading,.*
</param-value>
</init-param>
</init-params>
</mbean-filter>
</management-config>

要素

表A-44で、mbean-filter要素のサブ要素を説明します。

表A-31 mbean-filterのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

MBeanをフィルタ処理するためのフィルタ・クラスの名前を指定します。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

フィルタ・インスタンスを作成するためのファクトリ・クラスを指定します。

この要素は、<name>要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

フィルタ実装のクラス初期化パラメータを記述します。

member-identity

使用場所: cluster-config

member-identity要素には、クラスタ・メンバーの位置とロールの定義に有用な、詳細な識別情報を記述します。

要素

表A-32で、member-identity要素のサブ要素を説明します。

表A-32 member-identityのサブ要素

要素

必須/
オプション

説明

<cluster-name>

オプション

cluster-name要素には、クラスタの名前を記述します。クラスタに参加するには、すべてのメンバーで同じクラスタ名を指定する必要があります。本番システムでは必ずクラスタ名を指定して、アプリケーション間の不慮のクラスタ検出を回避してください。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.clusterです。

<site-name>

オプション

site-name要素には、メンバーがホストされる地理上のサイトの名前を記述します。WANによるクラスタリングでは、メンバーが配置されるデータセンターをこの値で特定します。サイト名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(地理的に別のサイトにあるデータの明示的なバックアップ)の基盤として使用できます。サイト名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.siteです。

<rack-name>

オプション

rack-name要素には、メンバーがホストされている地理的サイト内の場所の名前を記述し、多くの場合、ケージ、ラックまたはブレードフレームの識別子です。ラック名は、高度なルーティング、ロード・バランシングおよび障害時リカバリ計画(別のブレードフレームにあるデータの明示的なバックアップ)の基盤として使用できます。ラック名は、分散キャッシングおよびデフォルト・パーティション割当て戦略を使用している場合にデータのバックアップ先を決定するために役立ちます。最後に、この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.rackです。

<machine-name>

オプション

machine-name要素には、メンバーがホストされる物理サーバーの名前を記述します。多くの場合、サーバーの識別子自体と同じ名前を指定します(たとえば、HOSTNAMEやDNSエントリに表示される名前)。名前を指定した場合、これはIDを作成する際の基盤として使用されます。さらにIDを使用することにより、データが様々なコンピュータにバックアップされることが保証され、シングル・ポイント障害(SPOF)が回避されます。この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。この要素に値を指定するかどうかはオプションです。ただし、名前は常に指定することを強くお薦めします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.machineです。

<process-name>

オプション

process-name要素には、メンバーがホストされるプロセス(JVM)の名前を記述します。この名前を使用すると、同じコンピュータで稼働する複数のJVMを容易に区別できます。この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。この要素に値を指定するかどうかはオプションです。多くの場合、JVM当たりに存在するメンバーは1つのみであるため、この名前は冗長になります。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.processです。

<member-name>

オプション

member-name要素には、メンバー自身の名前を記述します。この名前を使用すると、同じコンピュータ(さらには同じJVM)で複数のメンバーが稼働している場合などに、メンバー同士を容易に区別できます。この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。この要素に値を指定するかどうかはオプションです。ただし、名前は常に指定することを強くお薦めします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.memberです。

<role-name>

オプション

role-name要素には、メンバー・ロールを記述します。この名前を使用すると、アプリケーションでメンバーを、キャッシュ・サーバーやキャッシュ・クライアントなどの専門のロールに整理できます。この名前は、管理情報(例、JMX)の表示およびログ・エントリの解釈にも有用です。この要素に値を指定するかどうかはオプションです。ただし、名前は常に指定することを強くお薦めします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.roleです。

<priority>

オプション

priority要素は、対応するメンバーの優先度を指定します。優先度は、メンバー間の優劣を決定する基準に使用されます。2つのメンバーのいずれかをクラスタから排除する状況が発生した場合、まれなケースですが 2つのいずれに障害があって排除すべきかを客観的に判断できないときは、優先度の低いメンバーが排除されます。有効な値は1から10で、10が最も高い優先度です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.priorityです。

multicast-listener

使用場所: cluster-config

説明

マルチキャスト・リスナーの構成情報を指定します。この要素は、クラスタ全体およびPoint-to-Pointの通信のためにクラスタで使用するアドレスおよびポートを指定するために使用します。クラスタ内のノードはすべて、同じマルチキャスト・アドレスおよびポートを使用する必要があります。同じネットワークの別のクラスタは、別のマルチキャスト・アドレスを使用する必要があります。マルチキャストを使用する際のクラスタの構築に問題がある場合は、『Oracle Coherenceの管理』でマルチキャスト接続テストの実行方法を参照してください。

マルチキャストフリーのクラスタリング

デフォルトでは、クラスタの形成時に他のノードを検出するためにマルチキャスト・プロトコルが使用されます。マルチキャスト・ネットワーキングが適さない場合、または環境内で使用できない場合には、well-known-addresses機能を使用するとマルチキャスト・トラフィックを使用する必要がなくなります。

要素

表A-33で、multicast-listener要素のサブ要素を説明します。

表A-33 multicast-listenerのサブ要素

要素

必須
/オプション

説明

<interface>

オプション

マルチキャスト・ソケットがバインドされるIPアドレスを指定します。デフォルトでは、マルチキャスト・ソケットにはunicast-listenerのIPアドレスのインタフェース(NIC)が使用されます。このオプションにより、マルチキャスト用に別のインタフェースを指定できます。このアドレスを0.0.0.0に設定すると、オペレーティング・システムはユニキャスト・ルーティング表を使用して、自動的にインタフェースを選択できます。

<address>

必須

ソケットがリスニングまたは公開を行うマルチキャストIPアドレスを指定します。有効な値は224.0.0.0から239.255.255.255です。デフォルト値は、リリースおよびビルド・レベルによって異なり、一般的に{build}.{major version}.{minor version}.{patch}という表記規則に従います。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.clusteraddressです。

<port>

必須

ソケットがリスニングまたは公開を行うポートを指定します。有効な値は1から65535です。デフォルト値は、リリースおよびビルド・レベルによって異なり、一般的に{version}+{{{build}という表記規則に従います。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.clusterportです。

<time-to-live>

必須

マルチキャストの有効時間設定を指定します。これにより、パケットが横断するホップの最大数を決定します。ホップは、あるネットワーク・セグメントから別のネットワーク・セグメントへの、ルーターを使用した横断として測定されます。有効な値は0から255です。デフォルト値は4です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.ttlです。

<packet-buffer>

必須

オペレーティング・システムがバッファリングを要求される受信パケットの量を指定します。この値はパケット数またはバイト数で表します。

<priority>

必須

マルチキャスト・リスナーの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は8です。

<join-timeout-milliseconds>

必須

新しいメンバーがクラスタの形跡を見つけないで待機する時間を指定します(ミリ秒単位)。この時間を超過すると、自身のクラスタが開始され、上位クラスタ・メンバーに自身が昇格されます。有効な値は1000から1000000です。デフォルト値は3000です。

注意: 本番で使用する場合、推奨値は30000です。

<multicast-threshold-percent>

必須

パケットをユニキャストとマルチキャストのいずれで送信するかを決定する際に使用するしきい値(%)を指定します。この割合は1 - 100%で指定します。n個のノードで構成されるクラスタにおいて、特定のノードが他の送信先ノードのセット(送信者自身を除く)のサイズをdとすると(dは0からn-1)、次の両方とも当てはまる場合にのみ、パケットはマルチキャストで送信されます。

1. パケットがネットワーク経由で複数のノードに送信されている(d > 1)。

2. ノード数がしきい値より大きい(d > (n-1) * (しきい値/100))。
この値を1に設定すると、実装は基本的にすべてのマルチポイント・トラフィックでマルチキャストを使用できます。

この値を100に設定すると、100%を超えるしきい値はないため、明示的なブロードキャスト・トラフィック(クラスタ・ハートビートやクラスタ検出など)を除いて、実装はすべてのマルチポイント・トラフィックでユニキャストを使用することになります。この値を25に設定すると、送信先が全ノードの4分の1未満の場合は、パケットはユニキャストを使用して送信され、4分の1以上の場合はマルチキャストを使用して送信されます。

有効な値は1から100です。デフォルト値は25です。

注意: この要素はwell-known-addresses要素が空の場合にのみ使用されます。

notification-queueing

使用場所: packet-publisher

説明

notification-queueing要素は、他のクラスタ・ノードに送信される通知パケットのタイミングを指定するために使用します。通知パケットは、確認が要求されているパケットを受信したことの肯定応答に使用されます。

要素

次の表で、notification-queuing要素のサブ要素を説明します。

表A-34 notification-queuingのサブ要素

要素

必須/
オプション

説明

<ack-delay-
milliseconds>

必須

パケット・パブリッシャの最大遅延時間を指定します(ミリ秒単位)。この時間を超過すると、ACKパケットが送信されます。ACKパケットは、バッチ化された肯定応答数がACKパケットを満たした場合に、早期に送信されることがあります。この値はリモート・ノードのpacket-deliveryの再送信タイムアウトより十分小さくして、リモート・ノードでACKを受信および処理するのに十分な時間を与える必要があります。この値を超過すると、再送信タイムアウトに達します。デフォルト値は16です。

<nack-delay-
milliseconds>

必須

パケット・パブリッシャの遅延時間を指定します(ミリ秒単位)。この時間を超過すると、NACKパケットが送信されます。デフォルト値は1です。

outgoing-message-handler

使用場所: cluster-config

説明

outgoing-message-handler要素には、送信メッセージ・ハンドラ(ディスパッチャとも呼ばれる)関連の構成情報を記述します。

要素

表A-35で、outgoing-message-handler要素のサブ要素を説明します。

表A-35 outgoing-message-handlerのサブ要素

要素

必須/
オプション

説明

<use-filters>

オプション

このハンドラにより使用される<filter-name>要素のリストを指定します。フィルタ定義の詳細は、<filter>要素を参照してください。

outstanding-packets

使用場所: flow-control

説明

クラスタ・ノードに送信する未確認パケットの数を定義します。このパケット数を超過すると、そのノードを送信先とするパケットは遅延されます。これにより、送信側が原因で受信側のネットワーク・バッファがオーバーフローすることがなくなります。

要素

表A-36で、outstanding-packets要素のサブ要素を説明します。

表A-36 outstanding-packetsのサブ要素

要素

必須/
オプション

説明

<maximum-packets>

オプション

クラスタ・ノードに送信する未確認パケットの最大数です。このパケット数を超過すると、そのノードを送信先とするパケットは遅延されます。この値を256未満に設定しないことをお薦めします。デフォルト値は4096です。

<minimum-packets>

オプション

クラスタ・ノードに送信する未確認パケット数の範囲の下限です。このパケット数を超過すると、そのノードを送信先とするパケットは遅延されます。この値を16未満に設定しないことをお薦めします。デフォルト値は64です。

packet-buffer

使用場所: unicast-listener、multicast-listener、packet-publisher

説明

データグラム・ソケットに使用するオペレーティング・システムのバッファのサイズを指定します(パケットまたはバイト単位)。

要素

表A-37で、packet-buffer要素のサブ要素を説明します。

表A-37 packet-bufferのサブ要素

要素

必須/
オプション

説明

<maximum-packets>

オプション

unicast-listener、multicast-listenerおよびpacket-publisherの場合: データグラム・ソケット自身がバッファに求められるサイズのpacket-sizeのパケット数を指定します。SO_SNDBUFおよびSO_RCVBUFを参照してください。基礎となるソケットの実装で一定のサイズ以上をサポートできない場合、実際のバッファ・サイズは小さくなることがあります。デフォルト値は、公開用が32、マルチキャスト・リスニング用が64、およびユニキャスト・リスニング用が1428です。

<size>要素が指定されている場合、<maximum-packets>要素は指定できません。

<size>

オプション

基礎になるソケット・バッファの要求されるサイズを、パケット数ではなくバイト数で指定します。

<maximum-packets>要素が指定されている場合、<size>要素は指定できません。

packet-bundling

使用場所: packet-delivery

説明

packet-bundling要素には、ネットワーク切替えインフラストラクチャにかかる負荷を軽減するために、複数の小さなパケットを1つの大きなパケットにバンドルする操作に関連する構成情報を記述します。

要素

表A-38で、packet-bundling要素のサブ要素を説明します。

表A-38 packet-bundlingのサブ要素

要素

必須/オプション

説明

<maximum-deferral-
time>

オプション

追加のパケットがバンドルされるまで待機する間のパケットの最大遅延時間。この値を0に設定すると、待機のないアルゴリズムとなり、即座にアクセスできるパケットのみがバンドルされます。0より大きい値を設定すると、追加のパケットが得られるまで待機する間に、多少の送信遅延が発生します。スループットに有害な影響が出ないように、通常この値は250マイクロ秒未満に設定します。単位を指定しない場合は、ナノ秒と見なされます。デフォルト値は1us (マイクロ秒)です。

<aggression-factor>

オプション

パケット遅延アルゴリズムの積極性を指定します。maximum-deferral-time要素では遅延時間の上限を定義しますが、aggression-factorは平均の遅延時間に影響します。積極性の値が高いほど、パブリッシャが追加のパケットを待つ時間が長くなります。この係数は実数で表します。多くの場合は待機時間を最小に抑えながらパケットの使用率を上げることができるように、0.0から1.0の値を使用します。デフォルト値は0です。

packet-delivery

使用場所: packet-publisher

説明

パケット配信に関連するタイミングおよび転送レートのパラメータを指定します。

要素

表A-39で、packet-delivery要素のサブ要素を説明します。

表A-39 packet-deliveryのサブ要素

要素

必須/
オプション

説明

<resend-milliseconds>

必須

確認が要求されるパケットの場合、対応するACKパケットを待つ最小時間をミリ秒単位で指定します。この時間を超過すると、パケットが再送信されます。デフォルト値は200です。

<timeout-milliseconds>

必須

確認が要求されるパケットの場合、最大時間をミリ秒単位で指定します。この時間を超過すると、パケットが再送信されます。このタイムアウトが経過した後、Coherenceでは受信側が終了していると見なすかどうかが決定されます。これを決定するには、他のノードがその受信者と通信できているかどうかなど、他のデータも考慮されます。デフォルト値は300000です。本番で使用する場合、300000および予想される最大のGCの全所要時間の2倍より大きな値を指定することをお薦めします。

<heartbeat-milliseconds>

必須

ハートビートの間隔を指定します。各メンバーはユニキャストのハートビートを発行し、最も上位のメンバーは、ブロードキャスト・メッセージとなるクラスタ・ハートビートを発行します。ハートビートは、高速な停止検出の一環としてtcp-ring-listenerで使用されます。デフォルト値は1000です。

<flow-control>

オプション

ノード当たりのパケット速度の調整およびリモートのGCの検出を構成します。

<packet-bundling>

オプション

Coherenceでパケット使用率の最大化を試行する積極性を構成します。

packet-publisher

使用場所: cluster-config

説明

ネットワーク・データ転送を管理するパケット・パブリッシャの構成情報を指定します。

信頼性のあるパケット配信

パケット・パブリッシャは、送信したパケットが送信先のクラスタ・ノードに確実に届くように管理します。パブリッシャは肯定応答を待つ一連のパケットを保持し、ACKがpacket-delivery再送信タイムアウトまでに届かない場合、そのパケットは再送信されます(<packet-delivery>サブ要素を参照)。受信側ノードはACKを遅延して、一連のACKを1つのレスポンスにバッチ化します(<notification-queuing>サブ要素を参照)。

要素

表A-40で、packet-publisher要素のサブ要素を説明します。

表A-40 packet-publisherのサブ要素

要素

必須/
オプション

説明

<packet-size>

オプション

使用するUDPパケットのサイズを指定します。

<packet-delivery>

必須

信頼性のあるパケット配信に関連するタイミングのパラメータを指定します。

<notification-queueing>

必須

通知キューに関連する構成情報を記述します。

<traffic-jam>

必須

パブリッシャのキューに配置できるパケットの最大数を指定します。この数を超過すると、クライアント・スレッドによってブロックされます。

<packet-buffer>

必須

オペレーティング・システムがバッファリングを要求される送信パケットの数を指定します。この値はパケット数またはバイト数で表します。

<priority>

必須

パケット・パブリッシャの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は6です。

<enabled>

オプション

TCMPクラスタリングを有効にするかどうかを指定します。Coherence*ExtendベースとCoherence TCMPベース両方のクラスタリングを使用している場合、この機能を使用してTCMPを無効化し、ノードがExtendプロトコルのみを使用して接続するようにできます。有効な値は、trueとfalseです。デフォルト値はtrueです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.tcmp.enabledです。

packet-size

使用場所: packet-publisher

説明

packet-size要素は、UDPパケットの最大サイズと最適サイズを指定します。クラスタ・ノードは、いずれも同一の最大パケット・サイズを使用する必要があります。

要素

表A-41で、packet-size要素のサブ要素を説明します。

表A-41 packet-sizeのサブ要素

要素

必須/
オプション

説明

<maximum-length>

必須

すべてのクラスタ・メンバーが問題なく処理できるパケット・サイズをバイト単位で指定します。この値は、クラスタ内のすべてのメンバーで同一にする必要があります。小さい値を設定することでクラスタの最大サイズを意図的に制限できます。これには512以上の値を指定する必要があります。デフォルト値は64KBです。

<preferred-length>

必須

ユニキャスト・ソケットおよびマルチキャスト・ソケットで送受信されるDatagramPacketオブジェクトの最適サイズをバイト単位で指定します。

これには<maximum-length>値よりも大きい値または小さい値を指定できます。この値は、クラスタ内のすべてのメンバーで同一にする必要はありません。理想的な値は、UDPパケット・ヘッダー(32バイト)またはTCPパケット・ヘッダー(52バイト)用の十分な容量を確保しながら、ネットワークMTU内に収まる値です。最適の長さは512以上である必要があります。デフォルト値は、ローカル・ノードのMTUに基づきます。

packet-speaker

使用場所: cluster-config

説明

パケット・パブリッシャの負荷が高い場合、ネットワーク・データ転送に使用するパケット・スピーカーの構成情報を指定します。

要素

表A-42で、packet-speaker要素のサブ要素を説明します。

表A-42 packet-speakerのサブ要素

要素

必須/
オプション

説明

<enabled>

オプション

packet-speakerスレッドを有効化するかどうかを指定します。有効な値は、trueとfalseです。デフォルト値はtrueです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.speaker.enabledです。

<volume-threshold>

オプション

スピーカーの起動に必要なパケットの負荷を指定します。

<priority>

必須

パケット・スピーカーの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は8です。

pause-detection

使用場所: flow-control

説明

Coherenceでリモート一時停止検出を使用すると、(GCが長いなどが原因で)応答のないクラスタ・ノードを検出し、それに対して反応できます。ノードが一時停止としてマークされた場合、そのノードを送信先とするパケットは、ノードが応答を再開するまでは、通常より遅い速度で送信されます。リモートGCの検出を使用すると、ノードが応答できない間にノードがあふれないようにできます。

要素

表A-43で、pause-detection要素のサブ要素を説明します。

表A-43 pause-detectionのサブ要素

要素

必須/
オプション

説明

<maximum-packets>

オプション

応答のないクラスタ・ノードに再送信するパケットの最大数です。このパケット数を超過すると、そのノードは一時停止していると見なされます。この値を0に指定すると、一時停止検出が無効になります。デフォルト値は16です。

provider

使用場所: ssl、identity-manager、trust-manager

説明

provider要素には、java.security.Providerクラスを拡張するセキュリティ・プロバイダの構成情報を記述します。

要素

表A-44で、provider要素のサブ要素を説明します。

表A-44 providerのサブ要素

要素

必須/
オプション

説明

<name>

オプション

java.security.Providerクラスを拡張するセキュリティ・プロバイダの名前を指定します。

クラス名は、この要素を使用するか、<class-name>要素または<class-factory-name>要素を使用して入力できます。

<class-name>

オプション

java.security.Providerクラスを拡張するセキュリティ・プロバイダの名前を指定します。

この要素は、<name>要素または<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

Providerインスタンスを作成するためのファクトリ・クラスを指定します。インスタンスは、java.security.Providerクラスを実装する必要があります。

この要素は、<name>要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

プロバイダ実装のクラス初期化パラメータを記述します。

この要素は、<name>要素と一緒には使用できません。

ramjournal-manager

使用場所: journaling-config

説明

<ramjournal-manager>要素には、RAMジャーナル・リソース・マネージャの構成を記述します。これは、ジャーナルベースのストレージのメモリー・バッファをメモリー内で管理します。RAMジャーナル・リソース・マネージャは、常にフラッシュ・ジャーナル・リソース・マネージャを使用してラージ・オブジェクトを格納し、RAMジャーナルに割り当てられている合計メモリー量に達したときにはオーバーフローとしても使用されます。RAMジャーナルでは、ジャーナルのガベージ・コレクションが一時的に要求に従うことができない場合にも、フラッシュ・ジャーナルを使用します。フラッシュ・ジャーナル・リソース・マネージャの構成の詳細は、「flashjournal-manager」を参照してください。

要素

表A-45で、ramjournal-manager要素のサブ要素を説明します。

表A-45 ramjournal-managerのサブ要素

要素

必須/
オプション

説明

<minimum-load-factor>

オプション

この値未満であれば、ジャーナル・ファイルが圧縮(ガベージ・コレクション)に適したものになる、ライブ・データ率を指定します。

<maximum-value-size>

オプション

RAMジャーナルに格納するバイナリ値の最大サイズをバイト単位で指定します。4MB以下の値を指定する必要があります。デフォルト値は64KBです。

最大値サイズを超えるバイナリ値は、自動的にフラッシュ・ジャーナルに委任されます。

<maximum-file-size>

オプション

基礎となるジャーナル・ファイルの最大ファイル・サイズを指定します。この値は2の累乗であり、ブロック・サイズの倍数である必要があります。値は2MBから2GBの範囲にする必要があります。デフォルト値は2MBです。最大ファイル・サイズは変更しないでください。

<collector-timeout>

オプション

ジャーナル・コレクタが、タイムアウトと判断する前に待機する時間を指定します。タイムアウトの最小値は30sです。有効な値は、時間間隔を表す文字列です。デフォルト値は10mです。

<maximum-size>

オプション

ジャーナルで使用するRAMの最大量を指定します。この値は、使用可能なヒープの最大量の割合として、または特定のメモリー量として指定できます。値にパーセント記号(%)が含まれている場合は、JVM最大ヒープの割合として解釈されます(JVM最大ヒープは通常、Javaコマンド行で-Xmx引数によって指定します)。特定のメモリー量として指定する場合、この値は16MBから64GBの間で指定する必要があります。デフォルト値は25です。つまり、RAMジャーナル・リソース・マネージャでは、最大で、使用可能なJVMヒープの25%を使用するということです。RAMジャーナルは常にフラッシュ・ジャーナルによってバッキングされ、最大RAMサイズを超えているデータはすべて、自動的にフラッシュ・ジャーナルに委任されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.ramjournal.sizeです。

<off-heap>

オプション

仮想マシンのバイト・バッファとヒープ外NIOバッファのどちらで使用するのかを指定します。

reporter

使用場所: management-config

説明

Reporterには、JMXのレポート作成機能が用意されています。Reporterは、即時利用可能なレポートを提供し、さらにカスタムのレポートの作成をサポートします。レポートは、管理者および開発者が容量管理や問題のトラブルシューティングを行う際に役立ちます。

要素

表A-46で、reporter要素のサブ要素を説明します。

表A-46 reporterのサブ要素

要素

必須/
オプション

説明

<configuration>

必須

レポート・グループ・デプロイメント・ディスクリプタの場所を指定します。デフォルト・ファイルはreports/report-group.xmlで、coherence.jarライブラリにあります。

<autostart>

必須

ノードの起動時にReporterを自動的に起動させるかどうかを指定します。有効な値は、trueとfalseです。デフォルト値はfalseです。

<distributed>

必須

Reporterを複数の管理ノード上で実行するかどうかを指定します。有効な値は、trueとfalseです。デフォルト値はfalseです。

<timezone>

オプション

レポート内に表示するタイムスタンプのタイムゾーンを指定します。サポートされるタイムゾーン書式の詳細は、java.util.TimeZoneを参照してください。タイムゾーンが指定されていない場合のデフォルトは、ローカルのタイムゾーンです。

<timeformat>

オプション

レポート内に表示するタイムスタンプの日時の書式を指定します。java.text.SimpleDateFormatクラスでサポートされているパターンの値を指定する必要があります。デフォルト値はEEE MMM dd HH:mm:ss zzz yyyyです。

security-config

使用場所: coherence

要素

表A-47で、security-config要素のサブ要素を説明します。

表A-47 security-configのサブ要素

要素

必須/
オプション

説明

<enabled>

必須

アクセス・コントローラ・セキュリティ機能が有効かどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.securityです。

<login-module-name>

必須

コール元の認証に使用するJAAS LoginModuleの名前を指定します。この名前は、JAASで使用される構成ファイルのモジュールと一致している必要があります(-Djava.security.auth.login.config Javaコマンド行属性などを使用して指定されます)。詳細は、Oracleログイン・モジュール開発者ガイドを参照してください。

<access-controller>

必須

com.tangosol.net.security.AccessControllerインタフェースを実装するクラスの構成情報を記述します。セキュリティ・フレームワークはこれを使用してクラスタ化リソースのアクセス権をチェックしたり、これらの権限に関するノード間の通信を暗号化または復号化します。

<callback-handler>

オプション

javax.security.auth.callback.CallbackHandlerインタフェースを実装するクラスの構成情報を記述します。このインタフェースは、コール元に関連付けられた識別情報がない場合に、保護されたクラスタ化リソースにアクセスしようとするとコールされます。

<identity-asserter>

オプション

ユーザーIDを確立するためIDトークンの検証の際にコールされるcom.tangosol.net.security.IdentityAsserterインタフェースを実装するクラスの構成情報を記述します。IDアサーション・プロバイダがIDトランスフォーマとともに使用され、Coherence*Extendのクライアントおよびプロキシ間の接続を保護します。

<identity-transformer>

オプション

Subject(.NETではPrincipal)を、IDをアサートするトークンに変換する際にコールされるcom.tangosol.net.security.IdentityTransformerインタフェースを実装するクラスの構成情報を記述します。IDトランスフォーマがIDアサーション・プロバイダとともに使用され、Coherence*Extendのクライアントおよびプロキシ間の接続を保護します。

<subject-scope>

オプション

リモート・キャッシュまたはサービス参照がサブジェクトによって共有されるかどうかを指定します。有効な値は、trueまたはfalseです。値をtrueに設定すると、リモート参照はグローバルに共有されません。各サブジェクトは異なる参照を取得します。デフォルト値はfalseです。

<authorizer>

オプション

コール元が対応する権限オブジェクトによって記述されるアクションを実行することを認可するための環境固有の機能を表すcom.tangosol.net.security.Authorizerインタフェースを実装するクラスの構成情報を記述します。クラスを入力するには<instance>要素を使用します。

serializer

使用場所: serializers

説明

serializer要素には、シリアライザ・クラス構成を記述します。シリアライザ・クラスはcom.tangosol.io.Serializerを実装する必要があります。JavaシリアライザとPOFシリアライザが事前に定義されています。

<cluster-config>
<serializers>
<serializer id="java">
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</serializer>

<serializer id="pof">
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
</serializers>
</cluster-config>

シリアライザの定義は、個々のキャッシュ・スキーム定義で参照され(「serializer」を参照)、また明示的にシリアライザを定義しないサービスのデフォルト・シリアライザでも参照されます(「defaults」を参照)。

必要に応じて、オペレーション・オーバーライド・ファイルで追加のシリアライザを定義できます。

要素

表A-48で、serializer要素のサブ要素を説明します。

表A-48 serializerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.io.Serializerを実装するクラスを指定します。この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

カスタムのシリアライザ・インスタンスを作成するためのファクトリ・クラスを指定します。このインスタンスは、com.tangosol.io.Serializerを実装する必要があります。

この要素は、<class-name>要素と一緒には使用できません。この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

シリアライザ実装のクラス初期化パラメータを記述します。

serializers

使用場所: cluster-config

説明

serializers要素には、各シリアライザの宣言データを記述します。

要素

表A-49で、serializers要素のサブ要素を説明します。

表A-49 serializersのサブ要素

要素

必須/
オプション

説明

<serializer>

オプション

特定のシリアライザの宣言データを指定します。

service

使用場所: services.

説明

Coherenceサービスの構成を指定します。

サービス・コンポーネント

構成可能なサービスの種類は、次のとおりです。

- PartitionedService.PartitionedCache: サービスを実行する複数のクラスタ・ノードにわたって、キャッシュ・エントリを均一にパーティション化するキャッシュ・サービス。このサービスは、多くの場合、分散キャッシュ・サービスと呼ばれます。

- ReplicatedCache: サービスを実行する全クラスタ・ノードの全キャッシュ・エントリのコピーを保持するキャッシュ・サービス。

- ReplicatedCache.Optimistic: 最適なロックを使用するReplicatedCacheのバージョン。

- SimpleCache: 並行処理制御なしのReplicatedCacheのバージョン。

- LocalCache: すべてのキャッシュ・エントリが1つのクラスタ・ノードに存在するキャッシュのキャッシュ・サービス。

- InvocationService: リモート・クラスタ・ノードでのカスタム操作の実行に使用されるサービス。

- ProxyService: Coherence*Extendクライアントからの接続を受け入れるサービス。

- RemoteCache—キャッシュ操作をCoherence*Extendクライアントからクラスタ上のキャッシュにルーティングするサービスです。

- RemoteInvocation—キャッシュ呼出しタスクをCoherence*Extendクライアントからクラスタ上のキャッシュにルーティングするサービスです。

- NameService—このサービスは特殊化されたTCPアクセプタで、Coherence*Extendクライアントでは、プロキシ・サービス・アドレスではなく、プロキシ・サービス名を指定することでプロキシに接続できます。

- RemoteNameService— JVMがクラスタに参加せずにリモートNameServiceを使用できるようにするNameServiceの実装です。

要素

表A-50で、services要素のサブ要素を説明します。

表A-50 serviceのサブ要素

要素

必須/
オプション

説明

<service-type>

必須

サービスの正規名を指定します。これにより、キャッシュ構成のキャッシング・スキームのservice-name要素からこのサービスを参照できます。詳細は、「caching-schemes」を参照してください。

<service-component>

必須

サービスの完全修飾クラス名、またはベースのサービス・コンポーネントに対する再配置可能なコンポーネントの相対名を指定します。有効な値は次のとおりです。

- PartitionedService.PartitionedCache (DistributedCache)

- ReplicatedCache

- ReplicatedCache.Optimistic

- SimpleCache

- LocalCache

- InvocationService

- ProxyService

- RemoteCache

- RemoteInvocation

- NameService

<use-filters>

オプション

このサービスで使用するfilter名のリストを記述します。たとえば、use-filterを次のように指定します。

<use-filters>
<filter-name>gzip</filter-name>
</use-filters>

この例では、このサービスによって使用されるネットワーク・メッセージに対してgzip圧縮がアクティブ化されるため、WANおよび低帯域幅ネットワークのパフォーマンスが大幅に向上します。

<init-params>

オプション

各サービスに固有の初期化パラメータを指定します。各パラメータの説明を次に示します。

初期化パラメータの設定

サービスの初期化パラメータは、Coherenceのオペレーション構成デプロイメント・ディスクリプタの<init-param>要素によって定義されます。init-paramの下に表示されるパラメータは、サービスによって異なります。

次の各項では、各サービスに構成可能なパラメータについて説明します。

- DistributedCacheサービスのパラメータ

- ReplicatedCacheサービスのパラメータ

- OptimisticCacheサービスのパラメータ

- 起動サービスのパラメータ

- LocalCacheサービスのパラメータ

- プロキシ・サービスのパラメータ

- RemoteCacheサービスのパラメータ

- RemoteInvocationサービスのパラメータ

- NameServiceのパラメータ

- RemoteNameServiceのパラメータ

各項の表では、各サービスに構成可能な具体的な<param-name>と<param-value>のペアについて説明します。「パラメータ名」列には<param-name>要素の値が、「パラメータ値の説明」列には対応する<param-value>要素に対する可能な値が示されています。

DistributedCacheサービスのパラメータ

DistributedCacheサービスでは、表A-51に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内の<distributed-scheme>要素の一部としても指定できます。

表A-51 DistributedCacheサービスのパラメータ

パラメータ名

パラメータ値の説明

lease-granularity

リース所有権の精度を指定します。有効な値は次のとおりです。

- thread (default)

- member

値がthreadの場合、ロックはそのロックを取得したスレッドによって保持され、そのスレッドによってのみ解放されます。値がmember の場合、ロックはクラスタ・ノードによって保持され、ロックを取得したクラスタ・ノード上で実行されるスレッドによって解放できます。

partition-count

分散キャッシュ・パーティションの数を指定します。分散キャッシュ・サービスを実行している記憶域が有効なクラスタ・メンバーはそれぞれ均等な数のパーティションを管理します。

有効な値は、1と32767の間の正の整数で、素数にする必要があります。デフォルト値は257パーティションです。詳細は、「パーティションの数の変更」を参照してください。

local-storage

このDistributedCacheサービスのメンバーによって、ローカル記憶域を有効化するかどうかを指定します。

通常、構成ファイル内ではこの値を未指定にしておき、システム・プロパティtangosol.coherence.distributed.localstorageを使用し、プロセスごとに設定します。これによって、キャッシュ・クライアントとキャッシュ・サーバーは、同じ構成ディスクリプタを使用できます。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.distributed.localstorageです。

transfer-threshold

プライマリ・バケット分散のしきい値をキロバイト単位で指定します。分散キャッシュ・サービスに新しいノードが結合する場合、またはサービスのメンバーのいずれかの結合が解除される場合、残りのノードによって、バケット所有権の再分散タスクが実行されます。このプロセスでは、所有権情報とともに既存のデータの均衡化が再実行されます。このパラメータでは、データ転送通信で優先されるメッセージ・サイズを示します。この値を低く設定すると、分散プロセスの所要時間は長くなりますが、このアクティビティ実行中のネットワーク帯域幅の使用量は軽減されます。有効な値は、ゼロより大きな整数です。デフォルト値は0.5MBです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.distributed.transferです。

backup-count

パーティション・キャッシュ・サービスのうち、各保存単位のバックアップ・データをキャッシュに保持するメンバーの数を指定します。デフォルト値は1です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.backupcountです。

thread-count

パーティション・キャッシュ・サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数、0または-1です。値0は、すべての関連するタスクがそのサービス・スレッドで実行されることを示します。値-1は、可能な場合はタスクがコール元のスレッドで実行されることを示します。デフォルト値は0です。

単にインメモリー・データを使用する(リードスルー、ライトスルーおよびライトビハインドを使用しない)シナリオまたは単純なアクセスを使用する(エントリ・プロセッサや集計などを使用しない)シナリオでは、値を0に設定します。負荷の大きい計算を行うシナリオ(集計など)では、スレッドの数は、その計算で使用可能なコアの数にする必要があります。たとえば、16コア・ボックス上で4つのノードを実行する場合、プール内に約4つのスレッドが存在することになります。I/Oの負荷の高いシナリオ(リードスルー、ライトスルー、ライトビハインドなど)では、スレッドの数はそれより多くなります。この場合、そのボックスが飽和状態になるところまでスレッドを増やします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.distributed.threadsです。

key-associator

com.tangosol.net.partition.KeyAssociatorインタフェースを実装するクラスの名前を指定します。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。

key-partitioning

com.tangosol.net.partition.KeyPartitioningStrategyインタフェースを実装するクラスの名前を指定します。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。

partition-listener

com.tangosol.net.partition.PartitionListenerインタフェースを実装するクラスの名前を指定します。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。

task-hung-threshold

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。

注意: ポストされたタスクがまだ開始されていない場合は、ハングとみなされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.task.hungです。

task-timeout

サービス・ワーカー・スレッド上で実行するリクエストのタイムアウト値をミリ秒単位で指定します。この属性は、スレッド・プールが使用されている(thread-count値が正の)場合にのみ適用され、PriorityTaskインタフェースを実装するエントリ・プロセッサ実装にのみ適用されます。タスク実行時間はサーバー側で測定され、開始されるまでサービス・バックログ・キューで待機するための所要時間は含まれません。有効な値は、正の整数またはゼロです。ゼロを指定すると、service-guardianのデフォルトの<timeout-milliseconds>値が使用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.task.timeoutです。

request-timeout

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

この要素の値は、(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?の形式で指定する必要があります。前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は0です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.timeoutです。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

backup-count-after-
writebehind

ライトビハインドを必要としないキャッシュ内の各保存単位のバックアップ・データ(つまり、クラスタ全体がシャットダウンしても失われにくいデータ)を保持する、パーティション・キャッシュ・サービスのメンバー数を指定します。ライトビハインドが必要とマークされている保存単位は、backup-countパラメータで指定されているメンバー数でバックアップされます。ライトビハインドが必要とマークされていない保存単位は、backup-count-after-writebehindパラメータで指定されているメンバー数でバックアップされます。

この要素の値は0に設定するか、要素の指定を完全に省略する必要があります。論理的な根拠として、このデータは別のデータ・ストアにバックアップされるため、書込み対象のライトビハインド・キューにデータが一時的に配置される場合を除いて、メモリー内でのバックアップは必要ありません。値0は、ライトビハインドが発生した場合に、そのデータのバックアップ・コピーが破棄されることを意味します。ただし、ライトビハインドが発生するまでは、backup-countパラメータに従ってデータがバックアップされます。

推奨値は0です。

guardian-timeout

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。パラメータが指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.guard.timeoutです。

service-failure-policy

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

有効な値は次のとおりです。

- exit-cluster - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報です。

member-listener

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。member-listenerは、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

partitioned-quorum-
policy-scheme

パーティション・キャッシュ・サービス用のクォーラム・ポリシー設定を指定します。「partitioned-quorum-policy-scheme」を参照してください。

partition-assignment-
strategy

パーティション・サービスでパーティション分散を管理する際に使用する戦略を指定します。

- legacy - (非推奨)レガシー割当て戦略では、パーティション分散は各クラスタ・メンバーで個々に管理されます。

- simple - (デフォルト)単純な割当て戦略は、マシンの安全性を確保しながらパーティション分散のバランスを取ることを試み、レガシー戦略よりも決定論的で効率的です。

- mirror:<service-name> – ミラー割当て戦略は、サービスのパーティションを、指定されたサービスのパーティションと共存させることを試みます。この戦略は、キーを関連付けられたクロスサービス・キャッシュ・アクセスがメンバーに対してローカルのままになる可能性を高めるために使用されます。

- custom - com.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装するクラス。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.assignmentstrategyです。

compressor

バックアップ更新をデルタ形式で圧縮するか、全体を送信するかを指定します。デルタ更新は、バックアップ・エントリの一部を表しており、プライマリ・エントリと同期させるには変更が必要です。有効な値は次のとおりです。

- none (デフォルト) - デルタ・バックアップを無効にします。コンプレッサは使用されません。プライマリ・エントリが変更されると、バックアップ・バイナリ・エントリ全体が置換されます。

- standard - パーティション・サービスで使用されているシリアライザに基づいて、デルタ・コンプレッサを自動的に選択します。

- com.tangosol.io.DeltaCompressorインタフェースを実装するクラスの完全修飾名。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.distributed.compressorです。

service-priority

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

event-dispatcher-priority

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

worker-priority

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は5です。

reliable-transport

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram (デフォルト) – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、<unicast-listener>要素の<reliable-transport>サブ要素で構成される共有トランスポート・インスタンスです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.transport.reliableです。

async-backup

パーティション(分散)キャッシュ・サービスが、クライアントに同時に応答する際に、変更を非同期にバックアップするかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.distributed.asyncbackupです。

ReplicatedCacheサービスのパラメータ

ReplicatedCacheサービスでは、表A-52に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のreplicated-scheme要素の一部としても指定できます。

表A-52 ReplicatedCacheサービスのパラメータ

パラメータ名

パラメータ値の説明

standard-lease-
milliseconds

標準的なリースの継続時間をミリ秒単位で指定します。リースがこのミリ秒数を超過すると、ロックは自動的に解放されます。期限切れが発生しないリースを指定するには、この値をゼロに設定します。この設定の目的は、スタック・スレッドを原因とするデッドロックまたはブロックが発生しないようにすることです。最長の予想ロック継続時間より高い(たとえば、トランザクション・タイムアウトより高い)値を設定する必要があります。また、packet-delivery/timeout-millisecondsの値より高い値を設定することをお薦めします。有効な値は、桁数の多い正の数値またはゼロです。デフォルト値は0です。

lease-granularity

リース所有権の精度を指定します。リリース2.3以降で使用できます。有効な値は次のとおりです。

- thread (default)

- member

値がthreadの場合、ロックはそのロックを取得したスレッドによって保持され、そのスレッドによってのみ解放されます。値がmember の場合、ロックはクラスタ・ノードによって保持され、ロックを取得したクラスタ・ノード上で実行されるスレッドによって解放できます。

mobile-issues

リースの問題を最新のロック・ホルダーに転送するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

request-timeout

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

この要素の値は、(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?の形式で指定する必要があります。前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は0です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.replicated.request.timeoutです。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

guardian-timeout

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。パラメータが指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.replicated.guard.timeoutです。

service-failure-policy

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

有効な値は次のとおりです。

- exit-cluster - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報です。

member-listener

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。member-listenerは、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

service-priority

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

event-dispatcher-priority

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

reliable-transport

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、<unicast-listener>要素の<reliable-transport>サブ要素で構成される共有トランスポート・インスタンスです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.replicated.transport.reliableです。

OptimisticCacheサービスのパラメータ

OptimisiticCacheサービスでは、表A-53に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のoptimistic-scheme要素の一部としても指定できます。

表A-53 OptimisiticCacheサービスのパラメータ

パラメータ名

パラメータ値の説明

request-timeout

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

この要素の値は、(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?の形式で指定する必要があります。前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は0です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.optimistic.request.timeoutです。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

guardian-timeout

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。パラメータが指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.optimistic.guard.timeoutです。

service-failure-policy

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

有効な値は次のとおりです。

- exit-cluster - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報です。

member-listener

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。member-listenerは、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

service-priority

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

event-dispatcher-priority

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

reliable-transport

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、<unicast-listener>要素の<reliable-transport>サブ要素で構成される共有トランスポート・インスタンスです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.optimistic.transport.reliableです。

起動サービスのパラメータ

起動サービスでは、表A-54に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のinvocation-scheme要素の一部としても指定できます。

表A-54 起動サービスのパラメータ

パラメータ名

パラメータ値の説明

thread-count

サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数、0または-1です。値0は、すべての関連するタスクがそのサービス・スレッドで実行されることを示します。値-1は、可能な場合はタスクがコール元のスレッドで実行されることを示します。

単にインメモリー・データを使用する(リードスルー、ライトスルーおよびライトビハインドを使用しない)シナリオまたは単純なアクセスを使用する(エントリ・プロセッサや集計などを使用しない)シナリオでは、値を0に設定します。負荷の大きい計算を行うシナリオ(集計など)では、スレッドの数は、その計算で使用可能なコアの数にする必要があります。たとえば、16コア・ボックス上で4つのノードを実行する場合、プール内に約4つのスレッドが存在することになります。I/Oの負荷の高いシナリオ(リードスルー、ライトスルー、ライトビハインドなど)では、スレッドの数はそれより多くなります。この場合、そのボックスが飽和状態になるところまでスレッドを増やします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.invocation.threadsです。

task-hung-threshold

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。注意: ポストされたタスクがまだ開始されていない場合は、ハングと見なされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.invocation.task.hungです。

task-timeout

タイムアウト可能なリクエスト(ポーリングおよびPriorityTaskの実装)のデフォルト・タスク実行タイムアウト値を指定します。ただし、タスク実行のタイムアウト値は明示的に指定しません。タスク実行時間はサーバー側で測定され、開始されるまでサービス・バックログ・キューで待機するための所要時間は含まれません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.invocation.task.timeoutです。

request-timeout

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

この要素の値は、(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?の形式で指定する必要があります。前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は0です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.invocation.request.timeoutです。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

guardian-timeout

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。パラメータが指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.invocation.guard.timeoutです。

service-failure-policy

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

有効な値は次のとおりです。

- exit-cluster - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報です。

member-listener

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。member-listenerは、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

service-priority

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

event-dispatcher-priority

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

worker-priority

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は5です。

reliable-transport

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、<unicast-listener>要素の<reliable-transport>サブ要素で構成される共有トランスポート・インスタンスです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.invocation.transport.reliableです。

LocalCacheサービスのパラメータ

LocalCacheサービスでは、表A-55に記載されたパラメータがサポートされます。

表A-55 LocalCacheサービスのパラメータ

パラメータ名

パラメータ値の説明

lock-enforce

入力、削除および消去操作にロックを施行するかどうかを指定します。この値がfalseの場合は、クライアントがロックおよびロック解除を明示的にコールする必要があります。

デフォルト値はfalseです。

lock-wait

ロックの取得を試行し続ける時間をミリ秒単位で指定します。このパラメータは、ロックの施行が有効になっている場合のみ使用されます。値を-1にすると、ロックが取得できるまでコール元のスレッドをブロックします。

デフォルト値は0です。

プロキシ・サービスのパラメータ

プロキシ・サービスでは、表A-56に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のproxy-scheme要素の一部としても指定できます。

表A-56 プロキシ・サービスのパラメータ

パラメータ名

パラメータ値の説明

acceptor-config

接続アクセプタの構成を記述します。サービスでは、この接続アクセプタを使用してCoherence*Extendクライアントからの接続を受け入れ、クライアントがクラスタに参加していなくても、クラスタの提供するサービスを使用できるようにします。

proxy-config

このサービスによって管理されるクラスタ化サービス・プロキシの構成を記述します。

thread-count

プロキシ・サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数または0です。デフォルト値は、0で、これは動的スレッド・プーリングが有効化され、スレッド数がプロキシ・サービスの負荷に基づいて自動的に調整されることを示します。明示的に正の値を指定すると、プール内のスレッド数を設定できます。

注意: プロキシ・サービス・スレッドは、コール元のアプリケーションのかわりに操作を実行します。したがって、スレッド数を明示的に設定する場合は、値は同時操作と同じ数に設定します。

スレッド・プールを無効化するには、thread-count-maxおよびthread-count-minパラメータを0に設定します。スレッド・プールを無効化すると、関連するタスクはすべて、プロキシ・サービス・スレッドで実行されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.threadsです。

task-hung-threshold

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。

注意: ポストされたタスクがまだ開始されていない場合は、ハングとみなされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.task.hungです。

task-timeout

タイムアウト可能なタスク(たとえば、com.tangosol.net.PriorityTaskインタフェースの実装)のデフォルトのタイムアウト値をミリ秒単位で指定します。ただし、タスク実行のタイムアウト値は明示的に指定しません。タスク実行時間はサーバー側で測定され、開始されるまでサービス・バックログ・キューで待機するための所要時間は含まれません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.task.timeoutです。

request-timeout

他の同名のプロキシに送信されるリクエストがくるまでプロキシが待機する最大時間を指定します。プロキシ間でリクエストが送信されることはないため、このパラメータを使用しないでください。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

guardian-timeout

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。パラメータが指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.guard.timeoutです。

service-failure-policy

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。すべてのサービスに関してサービス・ガーディアンをグローバルに構成する方法の詳細は、service-guardian要素を参照してください。

有効な値は次のとおりです。

- exit-cluster - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報です。

member-listener

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。member-listenerは、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

proxy-quorum-policy-scheme

プロキシ・サービス用のクォーラム・ポリシー設定を指定します。

load-balancer

プロキシ・スキームの一環として戦略が明示的に構成されていない場合にプロキシ・サービスで使用するデフォルトのロード・バランシング戦略を指定します。有効な値は次のとおりです。

- proxy - (デフォルト)この戦略では、既存の接続数、接続制限、送受信メッセージのバックログおよびデーモン・プールの使用率に基づいて、プロキシ・サービス・メンバーにクライアント接続を均等に分散します。

- client - この戦略では、クライアント・アドレス・プロバイダの実装に依存して、プロキシ・サービス・メンバーへのクライアントの分散を指定します。クライアント・アドレス・プロバイダが実装されていない場合は、接続が成功するまで、拡張クライアントが各プロキシ・サービスをランダムに試行します。

service-priority

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

event-dispatcher-priority

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

worker-priority

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は5です。

reliable-transport

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、<unicast-listener>要素の<reliable-transport>サブ要素で構成される共有トランスポート・インスタンスです。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.transport.reliableです。

thread-count-max

動的スレッド・プールで許容されるデーモン・スレッドの最大数を指定します。このパラメータは、thread-countが0に設定されている場合にのみ有効です。有効な値は、正の整数または0です。このパラメータおよびthread-count-minパラメータの両方に値を設定すると、デーモン・スレッドは作成されず、すべてのクライアント・リクエストはプロキシ・サービス・スレッドで処理されます。デフォルト値は、コア数の4倍です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.threads.maxです。

thread-count-min

動的スレッド・プールで許容される(および最初に作成される)デーモン・スレッドの最小数を指定します。このパラメータは、thread-countが0に設定されている場合にのみ有効です。有効な値は、正の整数または0です。このパラメータおよびthread-count-maxパラメータの両方に値を設定すると、デーモン・スレッドは作成されず、すべてのクライアント・リクエストはプロキシ・サービス・スレッドで処理されます。デフォルト値は、コア数の2倍です。

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.proxy.threads.minです。

RemoteCacheサービスのパラメータ

RemoteCacheサービスでは、表A-57に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のremote-cache-scheme要素の一部としても指定できます。

表A-57 RemoteCacheサービスのパラメータ

パラメータ名

パラメータ値の説明

initiator-config

クラスタへの接続を確立するためにサービスで使用される接続イニシエータの構成を記述します。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

defer-key-association-check

キー・アソシエーションの処理を、拡張クライアントによって行うか、クラスタ側まで遅延するかを指定します。有効な値は、trueとfalseです。デフォルト値はfalseであり、キー・アソシエーションの処理を拡張クライアントによって行うことを示します。この値をtrueに設定する場合、.NETクライアントおよびC++クライアントには、クラスタ・キャッシュ・サーバー上のキークラスのパラレルJava実装を含める必要があります。

RemoteInvocationサービスのパラメータ

RemoteInvocationサービスでは、表A-58に記載されたパラメータがサポートされます。これらの設定は、各サービス・インスタンスに対してcoherence-cache-config.xmlディスクリプタ内のremote-invocation-scheme要素の一部としても指定できます。

表A-58 RemoteInvocationサービスのパラメータ

パラメータ名

パラメータ値の説明

initiator-config

クラスタへの接続を確立するためにサービスで使用される接続イニシエータの構成を記述します。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

NameServiceのパラメータ

NameServiceサービスでは、表A-59に記載されたパラメータがサポートされます。

表A-59 NameServiceのパラメータ

パラメータ名

パラメータ値の説明

acceptor-config

クラスタでCoherence*Extendクライアントの使用に利用可能なプロキシ・サービスを検出するために使用される接続アクセプタの構成が含まれています。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

RemoteNameServiceのパラメータ

RemoteNameServiceサービスでは、表A-60に記載されたパラメータがサポートされます。

表A-60 RemoteNameServiceのパラメータ

パラメータ名

パラメータ値の説明

initiator-config/tcp-initiator

クラスタへの接続を確立するためにサービスで使用されるTCP接続イニシエータの構成を記述します。

serializer

オブジェクト・シリアライゼーション用のシリアライザ・クラスを指定します。シリアライザ・クラスはcom.tangosol.io.Serializerインタフェースを実装する必要があります。シリアライザの指定に最適な方法は、グローバルなserializer要素内で定義してから、キャッシュ構成ファイル内でキャッシュ用に構成することです。

service-guardian

使用場所: cluster-config

説明

サービスのデッドロックを検出して解決を試みるサービス・ガーディアンの構成を指定します。

要素

表A-61で、service-guardian要素のサブ要素を説明します。

表A-61 service-guardianのサブ要素

要素

必須/
オプション

説明

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<timeout-milliseconds>

オプション

サービスがデッドロックされたり応答しなくなったりするのを回避するために使用されるタイムアウト値。service-guardian/timeout-milliseconds値は、packet-delivery/timeout-milliseconds値と同じか、またはそれより大きい値に設定することをお薦めします。デフォルト値は305000です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.guard.timeoutです。

内容のオーバーライド属性xml-overrideを使用して、この要素の内容の全部または一部を、ベース・ドキュメントの外部にあるXMLドキュメントでオーバーライドすることもできます。詳細は、「属性リファレンス」を参照してください。

services

使用場所: cluster-config

説明

services要素には、各サービスの宣言データを記述します。

要素

表A-50で、services要素のサブ要素を説明します。

表A-62 servicesのサブ要素

要素

必須/
オプション

説明

<service>

オプション

特定のサービスの宣言データを指定します。

shutdown-listener

使用場所: cluster-config

説明

外部シャットダウン・リクエストを受信したときにクラスタ・ノードで実行するアクションを指定します。外部シャットダウンには、UNIXのkillコマンドやWindowsおよびUNIXのCtrl-Cなどがあります。

要素

表A-63で、shutdown-listener要素のサブ要素を説明します。

表A-63 shutdown-listenerのサブ要素

要素

必須/
オプション

説明

<enabled>

必須

外部JVMシャットダウンの際に実行するアクションの種類を指定します。有効な値は次のとおりです。

- none - 明示的なシャットダウン・アクションを実行しません。

- force - (デフォルト)Cluster.stop()をコールして、ノードのハードストップ(強制停止)を実行します。

- graceful - Cluster.shutdown()をコールして、通常のシャットダウンを実行します。

- true - forceと同じ。

- false - noneと同じ。

注意: 本番で使用する場合、外部シャットダウンに対する動作が目的どおりであることがテストで検証されている場合を除き、この値をnoneに設定することをお薦めします。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.shutdownhookです。

socket-address

使用場所: well-known-addresses、address-provider

説明

socket-address要素は、ソケットがバインドされるアドレス(IPまたはDNS名およびポート)を指定します。

要素

表A-64で、socket-address要素のサブ要素を説明します。

表A-64 socket-addressのサブ要素

要素

必須/
オプション

説明

<address>

必須

ソケットがリスニングまたは公開するIPアドレスを指定します。IPアドレスまたはDNS名を入力します。

注意: localhostをループバック・アドレスとして定義しているシステムではlocalhostの設定が機能しない場合があります。その場合は、コンピュータ名または特定のIPアドレスを指定します。

<port>

必須

ソケットがリスニングまたは公開を行うポートを指定します。有効な値は1から65535です。

注意: WKAメンバーを設定する場合、このポート値は、ユニキャスト・リスナー・ポート用に指定されているポート値と一致する必要があります。<unicast-listener>要素を参照してください。

socket-provider

使用場所: socket-providers、unicast-listener、ssl

説明

<socket-provider>要素には、ソケットおよびチャンネル・ファクトリの構成情報を記述します。次のソケット・プロバイダがサポートされており、定義済のid属性名を使用して参照されます。

<socket-providers>
<socket-provider id="system">
<system/>
</socket-provider>

<socket-provider id="tcp">
<tcp/>
</socket-provider>

<socket-provider id="ssl">
<ssl>
<identity-manager>
<key-store>
<url system-property="tangosol.coherence.security.keystore">
file:keystore.jks</url>
<password system-property="tangosol.coherence.security.password"/>
</key-store>
<password system-property="tangosol.coherence.security.password"/>
</identity-manager>
<trust-manager>
<algorithm>PeerX509</algorithm>
<key-store>
<url system-property="tangosol.coherence.security.keystore">
file:keystore.jks</url>
<password system-property="tangosol.coherence.security.password"/>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>

<socket-provider id="sdp">
<sdp/>
</socket-provider>
</socket-providers>

より詳細なSSL構成をサポートするために、別のSSL定義を作成できます。

要素

表A-65で、socket-provider要素のサブ要素を説明します。

表A-65 socket-providerのサブ要素

要素

必須/
オプション

説明

<system>

オプション

JVMのデフォルトのソケットおよびチャンネル実装のインスタンスを作成するソケット・プロバイダを指定します。これがデフォルトのソケット・プロバイダです。

<ssl>

オプション

SSLを使用するソケットおよびチャンネル実装を作成するソケット・プロバイダを指定します。

<tcp>

オプション

TCPベースのソケットおよびチャンネル実装を生成するソケット・プロバイダを指定します。

<sdp>

オプション

JVMおよび基礎となるネットワーク・スタックでSDPがサポートされている場合、SDPベースのソケットおよびチャネルの実装を生成するソケット・プロバイダを指定します。

socket-providers

使用場所: cluster-config

説明

socket-providers要素には、ソケット・プロバイダ実装ごとの宣言データを記述します。Coherenceでは、system、tcp、sslおよびsdpのソケット・プロバイダがサポートされています。

要素

表A-66で、socket-providers要素のサブ要素を説明します。

表A-66 socket-providersのサブ要素

要素

必須/
オプション

説明

<socket-provider>

オプション

ソケットおよびチャンネル・ファクトリの構成情報を指定します。

ssl

使用場所: socket-provider

説明

<ssl>要素には、SSLを使用するソケットおよびチャンネル実装を作成するソケット・プロバイダの構成情報を記述します。SSLがユニキャスト・リスナー用に構成されている場合、リスナーはwell-known-addressesを使用して構成する必要があります。

要素

表A-67で、ssl要素のサブ要素を説明します。

表A-67 sslのサブ要素

要素

必須/
オプション

説明

<protocol>

オプション

SSLソケット・プロバイダによって作成されたソケットおよびチャンネル実装が使用するプロトコルの名前を指定します。デフォルト値はTLSです。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<executor>

オプション

java.util.concurrent.Executorインタフェースの実装の構成情報を指定します。

<class-name>サブ要素は、Executorインタフェースを実装するクラスの名前を提供するために使用されます。代替策としては、<class-factory-name>サブ要素を使用して、Executorインスタンスおよび(オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定する)<method-name>サブ要素を作成するためのファクトリ・クラスを指定します。いずれの方法でも、<init-params>要素を使用して初期化パラメータを指定できます。

<identity-manager>

オプション

アイデンティティ・マネージャ・インスタンスを初期化するための構成情報を指定します。

<trust-manager>

オプション

トラスト・マネージャ・インスタンスを初期化するための構成情報を指定します。

<hostname-verifier>

オプション

javax.net.ssl.HostnameVerifierインタフェースの実装の構成情報を指定します。SSLハンドシェイク時に、URLのホスト名とサーバーの識別ホスト名が一致しない場合、検証メカニズムによってこのインスタンスがコールバックされ、接続を許可するかどうかが決定されます。

<class-name>サブ要素は、HostnameVerifierインタフェースを実装するクラスの名前を提供するために使用されます。代替策としては、<class-factory-name>サブ要素を使用して、HostnameVerifierインスタンスおよび(オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定する)<method-name>サブ要素を作成するためのファクトリ・クラスを指定します。いずれの方法でも、<init-params>要素を使用して初期化パラメータを指定できます。

cipher-suites

オプション

暗号のリストを指定します。cipher-suites要素内のname要素を使用して暗号を入力します。複数のname要素を指定できます。

usage属性を使用して、暗号のリストを許可するかどうかを指定します。usage属性値がblack-listの場合、指定した暗号がデフォルトの有効な暗号リストから削除されます。usage属性値がwhite-listの場合、指定した暗号が有効な暗号です。usage属性値が指定されていない場合のデフォルト値はwhite-listです。

protocol-versions

オプション

プロトコル・バージョンのリストを指定します。protocol-versions要素内のname要素を使用してプロトコル・バージョンを入力します。複数のname要素を指定できます。

usage属性を使用して、プロトコル・バージョンのリストを許可するかどうかを指定します。usage属性値がblack-listの場合、指定したプロトコル・バージョンがデフォルトの有効なプロトコル・リストから削除されます。usage属性値がwhite-listの場合、指定したプロトコル・バージョンが有効なプロトコルです。usage属性値が指定されていない場合のデフォルト値はwhite-listです。

<socket-provider>

オプション

SSLの委譲プロバイダの構成情報を指定します。有効な値は、tcpおよびsdpです。デフォルト値はtcpです。

tcp-ring-listener

使用場所: cluster-config

説明

TCPリングを使用すると、クラスタ内の別のノードの停止を迅速に検出できます。これを有効にすると、そのクラスタ・ノードでは、クラスタ全体に及ぶTCP接続のリングを1つ使用します。クラスタ・ノードは、TCP接続を使用して1つのハートビート間隔内で別のノードの停止を検出できます(デフォルト値は1秒です。packet-deliveryの<heartbeat-milliseconds>サブ要素を参照)。これを無効にすると、別のノードがUDPパケットへの応答を停止したことを非常に長い間隔で検出する方法に頼る必要があります(packet-deliveryの<timeout-milliseconds>サブ要素を参照)。停止が検出されると、他のすべてのクラスタ・ノードに送信されます。

要素

表A-68で、tcp-ring-listener要素のサブ要素を説明します。

表A-68 tcp-ring-listenerのサブ要素

要素

必須/
オプション

説明

<enabled>

オプション

ノードの障害を迅速に検出するためにTCPリング・リスナーを有効にするかどうかを指定します。有効な値は、trueとfalseです。デフォルト値はtrueです。

<ip-timeout>

オプション

クラスタ・メンバーをホストするコンピュータに接続できないことを決定するために使用するタイムアウトを指定します。マシンに接続できないメンバーを削除する必要があることを決定する前に、指定した回数の接続を試行できます。有効な値は、時間間隔を表す文字列です。タイムアウトを0にすることは、システムレベルのモニタリングが無効となるためお薦めしません。デフォルト値は5sです。

<ip-timeout>および<ip-attempts>の要素の値は、許容できる一時的なネットワークの停止に影響を与えないだけの大きな値にする必要があります。

この機能は、java.net.InetAddress.isReachableメカニズムに依存しています。使用可能かどうかの特定方法の詳細は、APIのドキュメントを参照してください。

<ip-attempts>

オプション

クラスタ・メンバーをホストするコンピュータが使用できなくなり、これらのクラスタ・メンバーを削除する必要があることを決定する前に試行する接続の回数を指定します。

<ip-timeout>および<ip-attempts>の要素の値は、許容できる一時的なネットワークの停止に影響を与えないだけの大きな値にする必要があります。有効な値は正の整数です。デフォルト値は3です。

<listen-backlog>

オプション

TCP/IPサーバー・ソケットのバックログ・キューのサイズを指定します。有効値は正の整数です。デフォルト値は、オペレーティング・システムに依存します。

<priority>

必須

TCPリング・リスナーの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は6です。

traffic-jam

使用場所: packet-publisher

説明

traffic-jam要素は、クライアント・スレッドでパケット・パブリッシャがパケットをエンキューしてネットワークに転送する速度を制御するために使用します。この制限を超えると、未処理のパケット数が指定された制限を下回るまで、任意のクライアント・スレッドは強制的に一時停止されます。パブリッシャのパケット転送速度を制限するには、flow-control要素を参照してください。

要素

表A-69で、traffic-jam要素のサブ要素を説明します。

表A-69 traffic-jamのサブ要素

要素

必須/
オプション

説明

<maximum-packets>

必須

パブリッシャが許容する保留パケットの最大数を指定します。この数を超過すると、パブリッシャが渋滞しており、クライアント・リクエスト(ローカルの非システム・スレッドからのリクエスト)のペースを落とす必要があると判断されます。ゼロは制限がないことを示します。このプロパティで再送信キューのサイズを制限することにより、予期しないメモリー不足状態のほとんどは発生しなくなります。デフォルト値は8192です。

<pause-milliseconds>

必須

パブリッシャが渋滞しているときにメッセージを送信しようとするクライアント・スレッドを一時停止する時間(ミリ秒)。パブリッシャは、渋滞が解消されるまでメッセージの送信を許可せず、このプロパティで指定された期間中、スレッドのスリープ処理を繰り返します。デフォルト値は10です。

trust-manager

使用場所: ssl

説明

<trust-manager>要素には、javax.net.ssl.TrustManagerインスタンスを初期化するための構成情報を記述します。

トラスト・マネージャは、信頼の決定を行う際に使用されるトラスト・マテリアルを管理し、ピアが提示した資格証明を受け入れるかどうかを決定します。

有効なtrust-manager構成には、少なくとも1つの子要素が記述されます。

要素

表A-70で、trust-manager要素のサブ要素を説明します。

表A-70 trust-managerのサブ要素

要素

必須/
オプション

説明

<algorithm>

オプション

トラスト・マネージャによって使用されるアルゴリズムを指定します。デフォルト値はSunX509です。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<key-store>

オプション

キー・ストア実装の構成を指定します。

unicast-listener

使用場所: cluster-config

説明

ユニキャスト・リスナーの構成情報を指定します。この要素は、Point-to-Pointのクラスタ通信をリスニングするためにクラスタ・ノードでバインドするアドレスおよびポートを指定するために使用します。

マルチキャストフリーのクラスタリング

デフォルトでは、クラスタの形成時に他のノードを検出するためにマルチキャスト・プロトコルが使用されます。マルチキャスト・ネットワーキングが適さない場合、または環境内で使用できない場合には、well-known-addresses機能を使用するとマルチキャスト・トラフィックを使用する必要がなくなります。

要素

表A-71で、unicast-listener要素のサブ要素を説明します。

表A-71 unicast-listenerのサブ要素

要素

必須/
オプション

説明

<socket-provider>

オプション

ソケット・プロバイダの構成を指定するか、<socket-providers>要素内で定義されているソケット・プロバイダ構成を参照します。使用可能なソケット・プロバイダは、system (デフォルト)、ssl、tcpおよびsdpです。定義済のid属性名を使用してソケット・プロバイダ構成を参照します。例:

<socket-provider>ssl</socket-provider>

事前構成済システム・プロパティのオーバーライド値はtangosol.coherence.socketproviderです。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するために使用されるトランスポート・プロトコルを指定します。デフォルトでは、すべてのサービスが構成されたプロトコルおよび共有トランスポート・インスタンスを使用します。また、サービスはreliable-transportサービス・パラメータを使用して明示的にトランスポート・プロトコルを指定することもできます。その場合は、サービス固有のトランスポート・インスタンスを使用することになります。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram (デフォルト) – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.transport.reliableです。

<well-known-addresses>

オプション

マルチキャスト・ブロードキャストを使用してクラスタ・メンバーを検出するかわりに、クラスタ検出プロトコルで使用される「Well Known」アドレス(WKA)のリストを記述します。

<address>

必須

ソケットがリスニングまたは公開するIPアドレスを指定します。アドレスはサブネットおよびマスクとしてCIDR注釈を使用して(たとえば192.168.1.0/24と)入力することもでき、それにより、使用可能なローカルIPアドレスに対するランタイム解決が可能になります。

注意: localhostをループバック・アドレスとして定義しているシステムではlocalhostの設定が機能しない場合があります。その場合は、コンピュータ名または特定のIPアドレスを指定します。また、デフォルトで、マルチキャスト・リスナーは、このアドレスによって定義されたインタフェースと同じインタフェースにバインドします。デフォルト値はlocalhostです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.localhostです。

<port>

必須

ソケットがリスニングまたは公開を行うポートを指定します。第2ポートは自動的に開かれ、次に使用可能なポートにデフォルト設定されます。有効な値は1から65535です。第1ポートのデフォルト値は8088、第2ポートのデフォルト値は8089(使用可能な場合)です。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.localportです。

<port-auto-adjust>

必須

指定したポートがすでに使用されているためにバインドできない場合に、ユニキャスト・ポートを自動的に増分するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.localport.adjustです。

<packet-buffer>

必須

オペレーティング・システムがバッファリングを要求される受信パケットの量を指定します。この値はパケット数またはバイト数で表します。

<priority>

必須

ユニキャスト・リスナーの実行スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は8です。

volume-threshold

使用場所: packet-speaker

説明

スピーカー・デーモンの起動に必要な送信パケットの最小量を指定します。

パフォーマンスへの影響

要素

表A-72で、packet-speaker要素のサブ要素を説明します。

表A-72 packet-speakerのサブ要素

要素

必須/
オプション

説明

<minimum-packets>

必須

スピーカー・デーモンを起動するために送信の準備を整える必要のあるパケットの最小数を指定します。値を0に指定するとスピーカーが常に強制的に使用され、高い値を指定すると使用されなくなります。指定しない場合(デフォルト)は、packet-bufferと一致します。

well-known-addresses

使用場所: unicast-listener

注意:
これは、セキュリティ関連の機能ではなく、クラスタに参加できるアドレスを制限するものではありません。クラスタ・メンバーシップの制限の詳細は、authorized-hosts要素を参照してください。
マルチキャストを使用する際のクラスタの構築に問題がある場合は、『Oracle Coherenceの管理』でマルチキャスト接続テストの実行方法を参照してください。

説明

デフォルトでは、クラスタの形成時に他のノードを検出するためにマルチキャスト・プロトコルが使用されます。マルチキャスト・ネットワーキングが適さない場合、または環境内で使用できない場合には、well-known-addresses機能を使用するとマルチキャスト・トラフィックを使用する必要がなくなります。使用中は、クラスタの開始が許可され、クラスタの存続期間を通して使用できる見込みのあるノードの比較的小さなリストでクラスタが構成されます。すべてのWKAノードが任意の時点で同時にアクティブである必要はありません。このリストは、マルチキャストを使用しないでクラスタの経路を見つけるために他のすべてのノードで使用され、他のノードが参加できるように既知のノードとして構成されているノードが少なくとも1つは稼働している必要があります。

例

次の例では、2つのwell-known-addressesをデフォルト・ポートで構成します。

<cluster-config>
<unicast-listener>
<well-known-addresses>
<socket-address id="1">
<address>192.168.0.100</address>
<port>8088</port>
</socket-address>
<socket-address id="2">
<address>192.168.0.101</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>

要素

表A-73で、well-known-addresses要素のサブ要素を説明します。

表A-73 well-known-addressesのサブ要素

要素

必須/
オプション

説明

<socket-address>

オプション

マルチキャスト・ブロードキャストを使用するかわりにクラスタ検出プロトコルで使用されるWKAのリストを指定します。1つ以上のWKAを指定した場合、メンバーがクラスタに参加するようにするには、そのメンバーがWKAになるか、または少なくとも1つのWKAメンバーが稼働している必要があります。また、すべてのクラスタ通信はユニキャストを使用して実行されます。空の場合または指定していない場合は、マルチキャスト通信が使用されます。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.wkaおよびtangosol.coherence.wka.portです。

<address-provider>

オプション

WKAを提供するcom.tangosol.net.AddressProvider実装の構成を記述します。コールするコンポーネントは、ノードの起動時に一覧の取得を試みます。プロバイダは、終了するnullアドレスを返し、使用できるすべてのアドレスが返されたことを示す必要があります。

属性リファレンス

表A-74で、オペレーション・デプロイメント・ディスクリプタで使用可能な属性を説明します。

表A-74 オペレーション・デプロイメント・ディスクリプタの属性

属性

必須/
オプション

説明

xml-override

オプション

xml-override属性を使用すると、要素の内容の全部または一部を、ベース・ドキュメントの外部にあるXMLドキュメントでオーバーライドできます。この属性の有効な値は、XMLドキュメントの名前であり、coherence.jarライブラリに含まれるクラスでClassLoader.getResourceAsStream(String name)を使用してアクセスできる必要があります。一般的には、名前の先頭に「/」が付き、クラスパスに存在している必要があります。

この属性で参照されるオーバーライドXMLドキュメントは、存在しなくてもかまいません。ただし、存在する場合は、そのルート要素の名前が、オーバーライドする要素の名前と同じである必要があります。名前の同じ要素が複数ある場合(例、<service>)、id属性を使用して、オーバーライドされるベース要素、およびオーバーライド要素自体を特定する必要があります。オーバーライド・ドキュメントの要素のうち、一致する要素がベース・ドキュメントにない要素のみがベースに付加されます。

次の要素は、自身のXMLオーバーライド・ファイルでオーバーライドできます。

address-provider、authorized-hosts、cache-factory-builder-config、cluster-config、coherence、configurable-cache-factory-config、incoming-message-handler、logging-config、multicast-listener、outgoing-message-handler、security-config、serializer、service、service-failure-policy、shutdown-listener、tcp-ring-listener、unicast-listener、packet-speaker、packet-publisher、mbeans

id

オプション

id属性は、複数出現する可能性のある要素を区別します(<service>など)。「XMLオーバーライド機能の理解」を参照してください。

system-property

オプション

この属性は、任意の要素のシステム・プロパティ名を指定するために使用します。システム・プロパティは、Javaコマンド行から要素の値をオーバーライドする際に使用します。この機能により、すべてのクラスタ・ノードで同じオペレーション・ディスクリプタ(およびオーバーライド・ファイル)を使用し、システム・プロパティで各ノードをカスタマイズできます。この機能の詳細は、付録D「システム・プロパティのオーバーライド」を参照してください。

B キャッシュ構成の要素

この付録では、キャッシュ構成デプロイメント・ディスクリプタの要素のリファレンスと、ディスクリプタの簡単な概要を示します。

この付録では次の項について説明します。

- キャッシュ構成デプロイメント・ディスクリプタ

- 要素リファレンス

- 属性リファレンス

B.1 キャッシュ構成デプロイメント・ディスクリプタ

キャッシュ構成デプロイメント・ディスクリプタでは、クラスタ内で使用できる様々な種類のキャッシュを指定します。ディスクリプタの名前と場所はオペレーション・デプロイメント・ディスクリプタで指定され、coherence-cache-config.xmlにデフォルト設定されます。サンプルの構成ディスクリプタがcoherence.jarライブラリのルートにパッケージ化されており、アプリケーションのクラスパス内でcoherence.jarファイルより前にカスタムのcoherence-cache-config.xmlファイルが検出されないかぎり、これが使用されます。可能であれば、すべてのクラスタ・メンバーで使用するキャッシュ構成ディスクリプタを統一してください。

キャッシュ構成デプロイメント・ディスクリプタ・スキーマはcoherence-cache-config.xsdファイルで定義します。これがcoherence-cache-config-base.xsdファイルをインポートし、これがさらにcoherence-config-base.xsdファイルをインポートします。これらのXSDファイルは、coherence.jarライブラリのルートおよび次のWeb URLにあります。

http://xmlns.oracle.com/coherence/coherence-cache-config/1.2/coherence-cache-config.xsd

<cache-config>要素はキャッシュ構成ディスクリプタのルート要素であり、通常はXSDおよびCoherenceネームスペース・リファレンスと、coherence-cache-config.xsdファイルの場所が含まれます。例:

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">

注意:

- coherence.jarライブラリにあるスキーマは、xsi:schemaLocation属性がWeb URLを参照する場合であっても、常に実行時に使用されます。

- xsi:schemaLocation属性を省略すると、スキーマ検証を無効にできます。

- デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、デプロイメント・ディスクリプタ・ファイルがASCII形式であり、ランタイム環境にバイナリ形式でデプロイされることを確認してください。

要素リファレンス

表B-1は、キャッシュ構成デプロイメント・ディスクリプタのすべての非終端要素を示しています。

表B-1 キャッシュ構成の非終端要素

要素

使用場所

acceptor-config

proxy-scheme

address-provider

name-service-addresses、remote-addresses、tcp-acceptor

async-store-manager

external-scheme、paged-external-scheme

authorized-hosts

tcp-acceptor

back-scheme

near-scheme、overflow-scheme

backing-map-scheme

distributed-scheme、optimistic-scheme、replicated-scheme

backup-storage

distributed-scheme

bdb-store-manager

external-scheme、paged-external-scheme,、async-store-manager

cache-config

ルート要素

cache-mapping

caching-scheme-mapping

cache-service-proxy

proxy-config

caching-scheme-mapping

cache-config

caching-schemes

cache-config

class-scheme

caching-schemes、local-scheme、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme、cachestore-scheme、listener

cachestore-scheme

local-scheme、read-write-backing-map-scheme

custom-store-manager

external-scheme、paged-external-scheme,、async-store-manager

defaults

cache-config

distributed-scheme

caching-schemes、near-scheme、overflow-scheme

external-scheme

caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

http-acceptor

acceptor-config

identity-manager

ssl

flashjournal-scheme

back-scheme、backing-map-scheme、caching-schemes、internal-cache-scheme

front-scheme

near-scheme、overflow-scheme

incoming-message-handler

acceptor-config、initiator-config

init-param

init-params

init-params

class-scheme

initiator-config

remote-cache-scheme、remote-invocation-scheme

interceptor

interceptors

interceptors

cache-mapping、distributed-scheme

instance

serializer、socket-provider、service-failure-policy

invocation-scheme

caching-schemes

key-associator

distributed-scheme

key-partitioning

distributed-scheme

key-store

identity-manager、trust-manager

listener

local-scheme、external-scheme、paged-external-scheme、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

local-address

http-acceptor、tcp-acceptor、tcp-initiator

local-scheme

caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

memcached-acceptor

acceptor-config

name-service-addresses

tcp-initiator

near-scheme

caching-schemes

nio-file-manager

external-scheme、paged-external-scheme,、async-store-manager

nio-memory-manager

external-scheme、paged-external-scheme,、async-store-manager

operation-bundling

cachestore-scheme、distributed-scheme、remote-cache-scheme

optimistic-scheme

caching-schemes、near-scheme、overflow-scheme

outgoing-message-handler

acceptor-config、initiator-config

overflow-scheme

caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、read-write-backing-map-scheme

paged-external-scheme

caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

partitioned-quorum-policy-scheme

distributed-scheme

provider

identity-manager、ssl、trust-manager

proxy-config

proxy-scheme

proxy-scheme

caching-schemes

proxy-quorum-policy-scheme

proxy-scheme

ramjournal-scheme

back-scheme、backing-map-scheme、caching-schemes、internal-cache-scheme

read-write-backing-map-scheme

caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme

remote-addresses

tcp-initiator

remote-cache-scheme

cachestore-scheme、caching-schemes、near-scheme

remote-invocation-scheme

caching-schemes

replicated-scheme

caching-schemes、near-scheme、overflow-scheme

serializer

acceptor-config、defaults、distributed-scheme、initiator-config、invocation-scheme、optimistic-scheme、replicated-scheme、transactional-scheme

socket-address

name-service-addresses、remote-addresses

socket-provider

tcp-acceptor、tcp-initiator

ssl

socket-provider

tcp-acceptor

acceptor-config

tcp-initiator

initiator-config

transactional-scheme

caching-schemes

trust-manager

ssl

acceptor-config

使用場所: proxy-scheme

説明

acceptor-config要素は、TCP/IPまたはHTTP (REST用)接続アクセプタの構成情報を指定します。接続アクセプタはプロキシ・サービスで使用され、Coherence*Extendクライアントからクラスタへの接続を有効にして、クライアントがクラスタに参加していなくても、クラスタ・サービスを使用できるようにします。

要素

表B-2で、acceptor-config要素のサブ要素を説明します。

表B-2 acceptor-configのサブ要素

要素

必須/
オプション

説明

<http-acceptor>

オプション

リモートのRESTクライアントからのHTTPを介した接続を受け入れる接続アクセプタの構成情報を指定します。この要素は、<tcp-acceptor>または<memcached-acceptor>要素とあわせて使用することはできません。

<tcp-acceptor>

オプション

Coherence*ExtendクライアントからクラスタへのTCP/IPを介した接続を有効にする、接続アクセプタの構成情報を指定します。この要素は、<http-acceptor>または<memcached-acceptor>要素とあわせて使用することはできません。

<memcached-acceptor>

オプション

リモートのmemcachedクライアントからのTCP/IPを介した接続を受け入れる接続アクセプタの構成情報を指定します。この要素は、<tcp-acceptor>または<http-acceptor>要素とあわせて使用することはできません。

<incoming-message-handler>

オプション

クライアントからクラスタへの接続リソース使用量の規制に使用される構成情報を指定します。

<outgoing-message-handler>

オプション

クライアントからクラスタへの接続の切断を検出するために接続アクセプタで使用される構成情報を指定します。

<use-filters>

オプション

この接続アクセプタで使用するフィルタ名のリストを記述します。たとえば、<use-filter>を次のように指定すると、すべてのネットワーク・メッセージに対してgzip圧縮がアクティブ化されるため、WANおよび低帯域幅ネットワークのパフォーマンスが大幅に向上します。

<use-filters>
<filter-name>gzip</filter-name>
</use-filters>

<serializer>

オプション

接続アクセプタがユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定します。次の例は、POFユーザー定義型の構成ファイルmy-pof-types.xmlを使用してユーザー定義型をPOFストリームに対してシリアライズおよびデシリアライズするConfigurablePofContextを構成しています。

<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>my-pof-types.xml</param-value>
</init-param>
</init-params>
</serializer>

<connection-limit>

オプション

この接続アクセプタで許可される同時接続の最大数。有効な値は、正の整数および0です。値0は制限がないことを意味します。デフォルト値は0です。

address-provider

使用場所: name-service-addresses、remote-addresses、tcp-acceptor、memcached-acceptor

説明

address-provider要素は、ソケット・アドレス情報(IPまたはDNS名およびポート)またはcom.tangosol.net.AddressProviderインタフェースの実装のいずれかを指定します。このインタフェースは、ソケット・アドレスをプログラムで定義する方法を提供します。

推奨する方法は、オペレーション・オーバーライド・ファイルに含まれているアドレス・プロバイダ定義を参照することです。この方法により、アプリケーション構成からデプロイメント構成が切り離されます。ただし、ソケット・アドレスも、インラインに構成でき、開発時にはソケット・アドレスが一般的です。参照可能なアドレス・プロバイダの定義の詳細は、「address-provider」を参照してください。

次の例では、TCP/IPアクセプタがバインドされるソケット・アドレスを含むアドレス・プロバイダ定義を参照します。

<tcp-acceptor>
<address-provider>ap2</address-provider>
</tcp-acceptor>

次の例では、クラスタ上のTCP/IPアクセプタのソケット・アドレスを含むアドレス・プロバイダ定義を参照します。

<tcp-initiator>
<remote-addresses>
<address-provider>ap3</address-provider>
</remote-addresses>
</tcp-initiator>

次の例では、クラスタ上のネーム・サービスTCP/IPアクセプタのソケット・アドレスを含むアドレス・プロバイダ定義を参照します。

<tcp-initiator>
<name-service-addresses>
<address-provider>ap4</address-provider>
</name-service-addresses>
</tcp-initiator>

次の例では、TCP/IP memcachedアクセプタがバインドされるソケット・アドレスを含むアドレス・プロバイダ定義を参照します。

<memcached-acceptor>
<address-provider>ap5</address-provider>
</memcached-acceptor>

要素

表B-3で、address-provider要素のサブ要素を説明します。

表B-3 address-providerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.AddressProviderインタフェースを実装するクラスの完全修飾名を指定します。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

アドレス・プロバイダ・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。インスタンスは、com.tangosol.net.AddressProviderインタフェースを実装する必要があります。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

一致するシグネチャを持つpublicなコンストラクタが含まれる実装によってアクセス可能な初期化パラメータを指定します。初期化パラメータは、<class-name>要素および<class-factory-name>要素の両方に指定できます。

<socket-address>

オプション

ソケットがバインドされるアドレス(IPまたはDNS名およびポート)を指定します。

アドレス・プロバイダ実装が<class-name>または<class-factory-name>要素を使用して定義されている場合、この要素は使用できません。

async-store-manager

使用場所: external-scheme、paged-external-scheme

説明

async-store-manager要素は、他のストア・マネージャの実装に、非同期の書込み機能を追加します。サポートされるストア・マネージャは次のとおりです。

- custom-store-manager: ストア・マネージャのカスタム実装を定義します。

- bdb-store-manager: Berkeley Database JEを使用してオンディクス・キャッシュを実装します。

- nio-file-manager: NIOを使用してメモリーマップ・ファイル・ベースのキャッシュを実装します。

- nio-memory-manager: NIOを使用してJVMヒープ外キャッシュ(インメモリー・キャッシュ)を実装します。

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

実装

このストア・マネージャは、com.tangosol.io.AsyncBinaryStoreManagerクラスによって実装されます。

要素

表B-4で、async-store-manager要素のサブ要素を説明します。

表B-4 async-store-managerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

非同期ストア・マネージャのカスタム実装を指定します。カスタム実装では、com.tangosol.io.AsyncBinaryStoreManagerクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタムasync-store-managerの実装で使用する初期化パラメータを指定します。

<bdb-store-manager>

オプション

キャッシュ記憶域にBerkeley Database JEのオンディスク・データベースを使用するよう外部キャッシュを構成します。

<custom-store-manager>

オプション

ストレージ・マネージャのカスタム実装を使用するよう外部キャッシュを構成します。

<nio-file-manager>

オプション

キャッシュ記憶域にメモリーマップ・ファイルを使用するよう外部キャッシュを構成します。

<nio-memory-manager>

オプション

キャッシュ記憶域にJVMヒープ外のメモリー領域を使用するよう外部キャッシュを構成します。

<async-limit>

オプション

非同期に書き込まれるキューに配置される最大バイト数を指定します。この値をゼロに設定すると、最大バイト数の実装デフォルトが使用されることを示します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- K(キロ、2^10)

- M(メガ、2^20)

値に係数が含まれていない場合は、1が係数として適用されます。有効な値は、正のメモリー・サイズまたは0です。デフォルト値は4MBです。

authorized-hosts

使用場所: tcp-acceptor

説明

この要素には、TCP/IPアクセプタを使用してクラスタへの接続が許可される、TCP/IPイニシエータ・ホストのIPアドレス・コレクションを記述します。このコレクションが空の場合、制約は課せられません。任意の数のhost-address要素およびhost-range要素を指定できます。

要素

表B-5で、authorized-hosts要素のサブ要素を説明します。

表B-5 authorized-hostsのサブ要素

要素

必須/
オプション

説明

<host-address>

オプション

IPアドレスまたはホスト名を指定します。これを指定すると、host-addressが指定されたホスト、または指定されたhost-range内のホストのみがクラスタに参加できます。内容のオーバーライド属性idを使用して、この要素の内容の全部または一部を、ベース・ドキュメントの外部にあるXMLドキュメントでオーバーライドすることもできます。

<host-range>

オプション

IPアドレスの範囲を指定します。これを指定すると、host-addressが指定されたホスト、または指定されたhost-range内のホストのみがクラスタに参加できます。

<host-filter>

オプション

特定のTCP/IPイニシエータを受け入れるかどうかを確認するためTCP/IPアクセプタで使用するcom.tangosol.util.Filter実装のクラス構成情報を指定します。evaluate()メソッドがクライアントのjava.net.InetAddressに渡されます。クライアントに接続を許可するには、実装がtrueを返す必要があります。クラスは<class-name>サブ要素を使用して指定されます。<init-params>サブ要素内に任意の初期化パラメータを定義できます。

back-scheme

使用場所: near-scheme、overflow-scheme

説明

back-scheme要素は、複合キャッシュのバック層キャッシュを指定します。

要素

表B-6で、back-scheme要素のサブ要素を説明します。

表B-6 back-schemeのサブ要素

要素

必須/
オプション

説明

<distributed-scheme>

オプション

キャッシュ・エントリの記憶域がクラスタ・ノード全体でパーティション化されるキャッシュ・スキームを定義します。

<optimistic-scheme>

オプション

ペシミスティック・ロックではなくオプティミスティック・ロックを使用するレプリケート・キャッシュ・スキームを定義します。

<replicated-scheme>

オプション

各キャッシュ・エントリがすべてのクラスタ・ノードに格納されるキャッシュ・スキームを定義します。

<transactional-scheme>

オプション

トランザクションが保証され、キャッシュ・エントリの記憶域がクラスタ・ノード全体でパーティション化されるキャッシュ・スキームを定義します。

<local-scheme>

オプション

ローカル・キャッシュ・スキームは、インメモリー・ローカル・キャッシュを定義します。ローカル・キャッシュは一般に、他のキャッシュ・スキーム内にネストされます(ニア・スキームのフロント層としてなど)。

<external-scheme>

オプション

外部スキームを使用すると、JVMヒープ・ベースでないキャッシュを定義することで大容量の記憶域の使用が可能になります。

<paged-external-scheme>

オプション

external-scheme同様、paged-external-schemesは、より大きな記憶域容量の使用を可能にする非JVMヒープ・ベースのキャッシュを定義します。

<class-scheme>

オプション

クラス・スキームは、任意のJavaオブジェクトをインスタンス化して、他のスキームでの使用を可能にするメカニズムを提供します。この要素を含むスキームによって、拡張の必要なクラスまたはインタフェースが指定されます。

<flashjournal-scheme>

オプション

ジャーナルを使用してデータをフラッシュ・メモリーに格納するスキームを指定します。

<ramjournal-scheme>

オプション

ジャーナルを使用してデータをRAMメモリーに格納するスキームを指定します。

<remote-cache-scheme>

オプション

Coherence*Extendを使用してCoherenceクラスタ外部からのキャッシュへのアクセスを有効にするキャッシュ・スキームを定義します。

backing-map-scheme

使用場所: distributed-scheme、optimistic-scheme、replicated-scheme

説明

キャッシュ・サーバー内でのエントリの格納に使用するキャッシュのタイプを指定します。

オーバーフロー・ベースのバッキング・マップを使用する際は、対応するbackup-storageでオーバーフローを構成することが重要です(可能であれば、backing-mapと同じスキームを使用します)。構成例については、「オーバーフローが設定されたパーティション・キャッシュ」を参照してください。

注意:
partitionedサブ要素は、親要素がdistributed-scheme要素の場合にのみ使用されます。

要素

表B-7で、backing-map-scheme要素のサブ要素を説明します。

表B-7 backing-map-schemeのサブ要素

要素

必須/
オプション

説明

<partitioned>

オプション

含まれるバッキング・マップがPartitionAwareBackingMapかどうかを指定します。(この要素は、distributed-scheme内でのみ考慮されます。)この値がtrueである場合、バッキング・マップとして指定されているスキームが使用されて、PartitionAwareBackingMapの各個別パーティションのバッキング・マップが構成されます。この値がfalseである場合、そのスキームがバッキング・マップ自身全体に使用されます。PartitionAwareBackingMapインタフェースの具体的な実装は次のとおりです。

- com.tangosol.net.partition.ObservableSplittingBackingCache

- com.tangosol.net.partition.PartitionSplittingBackingCache

- com.tangosol.net.partition.ReadWriteSplittingBackingMap

有効な値は、trueまたはfalseです。デフォルト値はfalseです。注意: RAMジャーナルおよびフラッシュ・ジャーナルを使用するバッキング・マップは常にパーティション化されています。

<local-scheme>

オプション

ローカル・キャッシュ・スキームは、インメモリー・ローカル・キャッシュを定義します。ローカル・キャッシュは一般に、他のキャッシュ・スキーム内にネストされます(ニア・スキームのフロント層としてなど)。

<external-scheme>

オプション

外部スキームを使用すると、JVMヒープ・ベースでないキャッシュを定義することで大容量の記憶域の使用が可能になります。

<paged-external-scheme>

オプション

external-scheme同様、paged-external-schemesは、より大きな記憶域容量の使用を可能にする非JVMヒープ・ベースのキャッシュを定義します。

<overflow-scheme>

オプション

overflow-schemeは、高速でサイズ制限のあるフロント層キャッシュと、低速でより大容量のバック層キャッシュで構成される2層キャッシュを定義します。

<class-scheme>

オプション

クラス・スキームは、任意のJavaオブジェクトをインスタンス化して、他のスキームでの使用を可能にするメカニズムを提供します。この要素を含むスキームによって、拡張の必要なクラスまたはインタフェースが指定されます。

<flashjournal-scheme>

オプション

ジャーナルを使用してデータをフラッシュ・メモリーに格納するスキームを指定します。

<ramjournal-scheme>

オプション

ジャーナルを使用してデータをRAMメモリーに格納するスキームを指定します。

<read-write-backing-map-scheme>

オプション

read-write-backing-map-schemeは、永続ストアのサイズ制限されたキャッシュを提供するバッキング・マップを定義します。

backup-storage

使用場所: distributed-scheme

説明

backup-storage要素は、パーティション・キャッシュのバックアップ記憶域のタイプと構成を指定します。

要素

表B-8で、backup-storage要素のサブ要素を説明します。

表B-8 backup-storageのサブ要素

要素

必須/
オプション

説明

<type>

オプション

バックアップ・データの保持に使用する記憶域のタイプを指定します。有効な値は次のとおりです。

- on-heap: (デフォルト)対応する実装クラスはjava.util.HashMapです。

- off-heap: 対応する実装クラスは、com.tangosol.io.nio.DirectBufferManagerを使用するcom.tangosol.io.nio.BinaryMapです。

- file-mapped: 対応する実装クラスは、com.tangosol.io.nio.MappedBufferManagerを使用するcom.tangosol.io.nio.BinaryMapです。

- custom: 対応する実装クラスは、class-name要素によって指定されるクラスです。

- scheme: 対応する実装クラスは、scheme-name要素によってcaching-schemeとして指定されます。

事前構成のシステム・プロパティのオーバーライド値はtangosol.coherence.distributed.backupです。

<initial-size>

オプション

バッファの初期サイズをバイト単位で指定します。クラス名は、<type>要素がoff-heapまたはfile-mappedに設定されている場合にのみ適用されます。バッファの初期サイズをバイト単位で指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1MBです。

<maximum-size>

オプション

バッファの初期サイズをバイト単位で指定します。クラス名は、<type>要素がoff-heapまたはfile-mappedに設定されている場合にのみ適用されます。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1024MBです。

<directory>

オプション

ディスク永続マネージャ(com.tangosol.util.nio.MappedBufferManager)がファイルを格納するときのルートとして使用するディレクトリのパス名を指定します。ディレクトリは、<type要素がfile-mappedに設定されている場合にのみ適用されます。値を指定しない場合または存在しないディレクトリを指定した場合は、デフォルトの場所にある一時ファイルが使用されます。デフォルト値は、Javaランタイムによって指定されるデフォルトの一時ディレクトリです。

<class-name>

オプション

カスタム記憶域実装のクラス名を指定します。クラス名は、<type>要素がcustomに設定されている場合にのみ適用されます。

<scheme-name>

オプション

ConfigurableCacheFactoryのスキーム名を指定します。スキーム名は、<type>要素がschemeに設定されている場合にのみ適用されます。

bdb-store-manager

使用場所: external-scheme、paged-external-scheme、async-store-manager

注意:
bdb-store-managerを使用するには、Berkeley Database JEのJavaクラス・ライブラリが必要です。詳細は、Berkeley Database JEの製品ページを参照してください。

http://www.oracle.com/technology/documentation/berkeley-db/je/index.html

説明

BDBストア・マネージャは、Berkeley Database JEのオンディスク埋込みデータベースを記憶域として使用する外部キャッシュの定義に使用されます。Berkeleyベースのストア構成の例は、「オンディスク永続キャッシュ」および「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を参照してください。

実装

このストア・マネージャは、com.tangosol.io.bdb.BerkeleyDBBinaryStoreManagerクラスによって実装され、com.tangosol.io.bdb.BerkeleyDBBinaryStoreクラスによって実装されるBinaryStoreオブジェクトを生成します。

要素

表B-9で、bdb-store-manager要素のサブ要素を説明します。

表B-9 bdb-store-managerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

Berkeley Database BinaryStoreManagerのカスタム実装を指定します。カスタム実装では、com.tangosol.io.bdb.BerkeleyDBBinaryStoreManagerクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

追加のBerkeley DBの構成設定を指定します。Berkeley DBの構成の手順を参照してください。

http://www.oracle.com/technology/documentation/berkeley-db/je/GettingStartedGuide/administration.html#propertyfile

また、カスタム実装で使用する初期化パラメータを指定する際にも使用されます。

<directory>

オプション

Berkeley Database JEのストア・マネージャがファイルを格納するルート・ディレクトリのパス名を指定します。指定しない場合、または存在しないディレクトリを指定した場合は、デフォルトの場所にある一時ディレクトリが使用されます。

<store-name>

オプション

Berkeley Database JEのストア・マネージャがデータを格納するデータベース表名を指定します。このパラメータを指定すると、bdb-store-managerでは非一時(永続)データベース・インスタンスが使用されます。これは、非一時ストアのキャッシュ・ローダーでバッキングされるローカル・キャッシュを対象としてのみ提供されるもので、この機能により、ローカル・キャッシュには起動時にディスクからデータが事前移入されるようになります。この設定は、レプリケート・キャッシュおよび分散キャッシュでは有効にしないでください。通常<store-name>要素は未指定のままにして、一時記憶域が使用されることを示す必要があります。

このプロパティを指定する場合は、{cache-name}マクロを使用することをお薦めします。{cache-name}マクロの詳細は、「パラメータ・マクロの使用」を参照してください。

bundle-config

使用場所: operation-bundling

説明

bundle-config要素は、1つ以上のバンドリング可能な操作に対するバンドリング戦略の構成を指定します。

要素

表B-10で、bundle-config要素のサブ要素を説明します。

表B-10 bundle-configのサブ要素

要素

必須/
オプション

説明

<operation-name>

オプション

複数のスレッドに対して同時実行される呼出しを、機能的に類似した1つのバルク操作にバンドルする操作名を指定します。バルク操作は、単一の引数でなく、引数のコレクションを取ります。

有効な値は、バンドル構成のコンテキストによって異なります。<cachestore-scheme>での有効な操作は次のとおりです。

- load"

- store

- erase

<distributed-scheme>および<remote-cache-scheme>での有効な操作は次のとおりです。

- get

- put

- remove

いずれの場合も、すべての有効な操作に対応するallという擬似操作があります。デフォルト値はallです。

<preferred-size>

オプション

バンドル・サイズのしきい値を指定します。バンドル・サイズがこの値に達すると、対応するバルク操作が即座に起動されます。この値は、コンテキスト固有の単位で測定されます。

有効な値は、0(バンドリングが無効)または正の値です。デフォルト値は0です。

<delay-millis>

オプション

個別の実行リクエストをバンドルして対応するバルク操作にまとめて渡すため、各実行リクエストに許容される最大遅延時間をミリ秒単位で指定します。指定された遅延時間内にpreferred-sizeしきい値に達した場合は、バンドルが即座に処理されます。

有効な値は正の数値です。デフォルト値は1です。

<thread-threshold>

オプション

個別の(バンドルされない)リクエストを同時実行することが要求されるスレッドの最小数を指定します。この値を超えると、バンドラがパススルー・モードからバンドリング・モードに切り替わります。

有効な値は正の数値です。デフォルト値は4です。

<auto-adjust>

オプション

(実行時統計に基づく)preferred-size値の自動調整を許可するかどうかを指定します。

有効な値は、trueまたはfalseです。デフォルト値はfalseです。

cache-config

ルート要素

説明

cache-config要素は、キャッシュ構成ディスクリプタcoherence-cache-config.xmlのルート要素です。このドキュメントの詳細は、「キャッシュ構成デプロイメント・ディスクリプタ」を参照してください。

高レベルのキャッシュ構成は、キャッシュ・スキームとキャッシュ・スキーム・マッピングで構成されます。キャッシュ・スキームには、(データベースでバッキングされる分散キャッシュなど)キャッシュのタイプを記述します。キャッシュのマッピングには、特定のキャッシュ名に対して使用されるスキームを定義します。

要素

表B-11で、cache-config要素のサブ要素を説明します。

表B-11 cache-configのサブ要素

要素

必須/
オプション

説明

<scope-name>

オプション

<cache-config>要素内での<scope-name>要素の使用は非推奨になりました。かわりに、defaults要素内で<scope-name>要素を使用してください。

<defaults>

オプション

ファクトリ全体のデフォルト設定を定義します。

<interceptors>

オプション

イベントを処理する任意の数のイベント・インターセプタを指定します。<cache-config>要素の子として<interceptors>要素を指定すると、インターセプタのスコープがキャッシュ構成に設定され、インターセプタがConfigurableCacheFactoryライフサイクル・イベントなどのイベントを受信できるようになります。

<caching-scheme-mapping>

必須

キャッシュ名に基づいて、キャッシュに使用されるキャッシュ・スキームを指定します。

<caching-schemes>

必須

クラスタ内で使用可能なキャッシュ・スキームを定義します。

cache-mapping

使用場所: caching-scheme-mapping

説明

cache-mapping要素によって、特定のキャッシュ名またはアプリケーションが使用するキャッシュ名パターンで使用されるcaching-schemesが指定されます。

要素

表B-12で、cache-mapping要素のサブ要素を説明します。

表B-12 cache-mappingのサブ要素

要素

必須/
オプション

説明

<cache-name>

必須

キャッシュ名または名前のパターンを指定します。名前は、キャッシュ・ファクトリ内で一意です。次のキャッシュ名パターンがサポートされています:

- 完全一致。たとえば、MyCacheです。

- ワイルドカードを使用した接頭辞の一致(prefix*)。たとえば、My*。Myで始まるすべてのキャッシュ名が一致します。

- ワイルドカードを使用した全一致(*)。すべてのキャッシュ名に一致します。

キャッシュ名は複数のキャッシュ・マッピングに一致する可能性があります。その場合、ワイルドカード一致よりも完全一致が優先されます。完全一致が指定されていない場合は、最後に一致したワイルドカード・パターン(ファイルで定義された順番に基づく)が選択されます。

<scheme-name>

必須

キャッシュ・スキーム名を記述します。この名前は構成ファイル内で一意です。キャッシュ・スキームはcaching-schemes要素で構成されます。

<init-params>

オプション

置換可能なキャッシュ・スキーム・パラメータの指定を可能にします。キャッシュ・スキームの解析時に、形式param-nameの置換可能パラメータが検出されると、そのパラメータが対応するパラメータ値に置換されます。次のキャッシュのマッピング例を参照してください。

<cache-mapping>
<cache-name>My*</cache-name>
<scheme-name>my-scheme</scheme-name>
<init-params>
<init-param>
<param-name>cache-loader</param-name>
<param-value>com.acme.MyCacheLoader</param-value>
</init-param>
<init-param>
<param-name>size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>

My*に一致するすべてのキャッシュ名において、対応するcache-scheme要素の任意の部分にcache-loaderリテラルが存在すると、すべての対象リテラルが文字列com.acme.MyCacheLoaderに置換され、リテラルのsize-limitが値1000に置換されます。

<interceptors>

オプション

特定のキャッシュのイベントを処理する任意の数のイベント・インターセプタを指定します。

cache-service-proxy

使用場所: proxy-config

説明

cache-service-proxy要素には、プロキシ・サービスによって管理されるキャッシュ・サービス・プロキシの構成情報を記述します。

要素

表B-13で、cache-service-proxy要素のサブ要素を説明します。

表B-13 cache-service-proxyのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.CacheServiceインタフェースを実装するクラスの完全修飾名を指定します。このクラスは、必要に応じてカスタム処理を実装するため、クライアントとプロキシされるキャッシュ・サービス間のインターセプタとして機能します。たとえば、このクラスを使用して、プロキシされるキャッシュ・サービスの使用を許可する前に認可チェックを行うことができます。

<init-params>

オプション

CacheService実装の初期化パラメータを記述します。

<enabled>

オプション

キャッシュ・サービス・プロキシが有効化されているかどうかを指定します。無効化されている場合、クライアントはプロキシ・キャッシュにアクセスできません。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

<lock-enabled>

オプション

リモート・クライアントからのロック・リクエストをプロキシ・キャッシュで許可するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<read-only>

オプション

リモート・クライアントからのキャッシュ更新リクエストをプロキシ・キャッシュで禁止するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

cachestore-scheme

使用場所: local-scheme、read-write-backing-map-scheme

説明

キャッシュ・ストア・スキームは、キャッシュをバックエンドのデータ・ストアに接続するメカニズムを定義します。キャッシュ・ストア・スキームでは、読取り/書込み機能を提供するcom.tangosol.net.cache.CacheStoreインタフェース、または読取り専用のcom.tangosol.net.cache.CacheLoaderインタフェースを実装するクラスを使用します。これらのインタフェースのカスタム実装を生成して、Coherenceを様々なデータ・ストアに接続することもできます。cachestore-schemeの使用例については、「データベースのキャッシュ」を参照してください。

要素

表B-14で、cachestore-scheme要素のサブ要素を説明します。

表B-14 cachestore-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。「スキームの継承の使用」を参照してください。

<class-scheme>

オプション

キャッシュ・ストアの実装を指定します。指定されたクラスでは、次のいずれかのインタフェースを実装する必要があります。

- com.tangosol.net.cache.CacheStore: 読取り/書込み機能をサポートする場合

- com.tangosol.net.cache.CacheLoader: 読取り専用機能をサポートする場合

- com.tangosol.net.cache.BinaryEntryStore: CacheStoreに似ていますが、BinaryEntryオブジェクト上で稼働します。

<remote-cache-scheme>

オプション

キャッシュ・ストアの実装としてCoherence*Extendを使用するようcachestore-schemeを構成します。

<operation-bundling>

オプション

バンドリング戦略の構成情報を指定します。

caching-scheme-mapping

使用場所: cache-config

説明

キャッシュ名(または名前のパターン)とcaching-schemesとのマッピングを定義します。たとえば、名前がaccounts-で始まるキャッシュでは分散(distributed-scheme)キャッシュ・スキームを使用し、名前がrates-で始まるキャッシュではreplicated-schemeキャッシュ・スキームを使用するように定義できます。

要素

表B-15は、caching-scheme-mapping要素で定義可能なサブ要素について説明しています。

表B-15 caching-scheme-mappingのサブ要素

要素

必須/
オプション

説明

<cache-mapping>

必須

キャッシュ名と、このキャッシュで使用するキャッシュ・スキームとの単一バインディングを記述します。

caching-schemes

使用場所: cache-config

説明

caching-schemes要素は、一連のキャッシュ・スキーム要素を定義します。各キャッシュ・スキームは、キャッシュのタイプを定義します(データベースでバッキングされるパーティション・キャッシュ、LRUエビクション・ポリシーが指定されたローカル・キャッシュなど)。スキームのタイプはマッピング(「caching-scheme-mapping」を参照)を使用して実際のキャッシュにバインドされます。

要素

表B-16は、caching-schemes要素で定義可能な各スキーム・タイプについて説明しています。

表B-16 caching-schemesのサブ要素

要素

必須/
オプション

説明

<distributed-scheme>

オプション

キャッシュ・エントリの記憶域がクラスタ・ノード全体でパーティション化されるキャッシュ・スキームを定義します。

<optimistic-scheme>

オプション

ペシミスティック・ロックではなくオプティミスティック・ロックを使用するレプリケート・キャッシュ・スキームを定義します。

<replicated-scheme>

オプション

各キャッシュ・エントリがすべてのクラスタ・ノードに格納されるキャッシュ・スキームを定義します。

<transactional-scheme>

オプション

トランザクションが保証され、キャッシュ・エントリの記憶域がクラスタ・ノード全体でパーティション化されるキャッシュ・スキームを定義します。

<local-scheme>

オプション

on-heapキャッシュ記憶域を提供するキャッシュ・スキームを定義します。

<external-scheme>

オプション

off-heapキャッシュ記憶域(オンディスク・キャッシュなど)を提供するキャッシュ・スキームを定義します。

<paged-external-scheme>

オプション

時間ベースのページングを使用してサイズ制限される、off-heapキャッシュ記憶域を提供するキャッシュ・スキームを定義します。

<overflow-scheme>

オプション

サイズ制限のあるフロント層のオーバーフローで削除されたエントリが大規模なバック層キャッシュに格納される2層キャッシュ・スキームを定義します。

<class-scheme>

オプション

キャッシュのカスタム実装を使用してキャッシュ・スキームを定義します。カスタム実装では、java.util.Mapインタフェースを実装し、パラメータがゼロのpublicなコンストラクタを組み込む必要があります。さらに、CacheService以外によってMapのコンテンツが変更される可能性がある場合(たとえば、Mapが自身のエントリを定期的に自動失効させる場合やコンテンツ・サイズを制限する場合)、返されるオブジェクトはcom.tangosol.util.ObservableMapインタフェースを実装する必要があります。

<flashjournal-scheme>

オプション

データをフラッシュ・メモリーに格納するスキームを指定します。

<ramjournal-scheme>

オプション

データをRAMメモリーに格納するスキームを指定します。

<near-scheme>

オプション

高速のローカル・フロント層と大規模なバック層のキャッシュで構成される2層キャッシュ・スキームを定義します。

<invocation-scheme>

オプション

クラスタ・ノード全体でカスタム操作をパラレルに実行するための起動サービスを定義します。

<read-write-backing-map-scheme>

オプション

永続ストアのキャッシュを提供するバッキング・マップ・スキームを定義します。

<remote-cache-scheme>

オプション

Coherence*Extendを使用してCoherenceクラスタ外部からのキャッシュへのアクセスを有効にするキャッシュ・スキームを定義します。

<remote-invocation-scheme>

オプション

Coherenceクラスタ外からCoherence*Extendを使用して起動できる起動スキームを定義します。

<proxy-scheme>

オプション

Coherence*Extendを使用してクライアントにリモート接続できるプロキシ・サービス・スキームを定義します。

class-scheme

使用場所: caching-schemes、local-scheme、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、front-scheme、overflow-scheme、read-write-backing-map-scheme、cachestore-scheme、listener、eviction-policy、unit-calculator

説明

クラス・スキームは、任意のJavaオブジェクトをインスタンス化して、他のスキームでの使用を可能にするメカニズムを提供します。この要素を含むスキームによって、拡張の必要なクラスまたはインタフェースが指定されます。class-schemeの使用例については、「データベースのキャッシュ」を参照してください。

class-schemeでは、class-nameを使用して直接的に、またはclass-factory-nameおよびmethod-nameを使用して間接的にオブジェクトのインスタンス化を構成できます。class-schemeは、class-nameで構成するか、class-factory-nameとmethod-nameで構成する必要があります。

要素

表B-17で、class-scheme要素のサブ要素を説明します。

表B-17 class-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

インスタンス化するJavaクラスの完全修飾名を記述します。このクラスは、含まれるスキームの記述に従って適切な実装クラスを拡張し、スーパークラスと完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

オブジェクトのインスタンス化でファクトリとして使用されるJavaクラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

一致するシグネチャを持つpublicなコンストラクタが含まれる実装によってアクセス可能な初期化パラメータを指定します。

custom-store-manager

使用場所: external-scheme、paged-external-scheme、async-store-manager

説明

外部キャッシュで使用するストア・マネージャのカスタム実装の作成および構成に使用されます。

要素

表B-18で、custom-store-manager要素のサブ要素を説明します。

表B-18 custom-store-managerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

ストア・マネージャの実装を指定します。指定したクラスは、com.tangosol.io.BinaryStoreManagerインタフェースを実装する必要があります。

<init-params>

オプション

カスタム・ストア・マネージャの実装で使用する初期化パラメータを指定します。

defaults

使用場所: cache-config

説明

defaults要素は、ファクトリ全体のデフォルト設定を定義します。この機能は、これらの設定を明示的に定義していないすべてのサービスで使用される、シリアライザおよびソケット・プロバイダのグローバル構成を有効化します。

要素

表B-19で、defaults要素のサブ要素を説明します。

表B-19 defaultsのサブ要素

要素

必須/
オプション

説明

<scope-name>

オプション

この構成のスコープ名を指定します。スコープ名は、キャッシュ・ファクトリによって生成されたすべてのサービスに(接頭辞として)追加されます。この名前は、複数のキャッシュ・ファクトリを使用する場合にサービスを分離するために使用されるため、異なる構成から意図しない同じような名前のサービスが参加しないようになります。

<serializer>

オプション

com.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルの<serializers要素内で定義されているシリアライザ・クラス構成を参照します。事前定義のシリアライザには、java(デフォルト)とpofの2つがあり、定義済のid属性名を使用して参照されています。例:

<serializer>pof</serializer>

<socket-provider>

オプション

ソケット・プロバイダの構成を指定するか、オペレーション・デプロイメント・ディスクリプタの<socket-providers>要素内で定義されているソケット・プロバイダ構成を参照します。使用可能なソケット・プロバイダは、system (デフォルト)、tcp、sslおよびsdpです。定義済id属性名を使用してソケット・プロバイダを参照します。例:

<socket-provider>ssl</socket-provider>

この設定で指定されるのは、Coherence*Extendサービスのソケット・プロバイダのみです。TCMPソケット・プロバイダは、オペレーション構成の<unicast-listener>要素内で指定されます。

distributed-scheme

使用場所: caching-schemes、near-scheme、overflow-scheme

説明

distributed-schemeは、エントリの記憶域をクラスタ・ノード全体でパーティション化するキャッシュを定義します。パーティション・キャッシュの詳細は、「分散キャッシュの理解」を参照してください。様々なdistributed-schemeの構成例は、「パーティション・キャッシュ」を参照してください。

クラスタ化された並列処理制御

パーティション・キャッシュでは、クラスタ全体を対象とするキーベースのロック機能がサポートされるため、更新の欠落といった従来の問題を発生させることなく、クラスタ内のデータを変更できます。明示的ロックを行わずに実行された操作もすべてアトミックですが、キャッシュに格納された値がアトミック操作間で変更されない保証はありません。

キャッシュ・クライアント

パーティション・キャッシュ・サービスでは、クラスタの総記憶域には含まれないクラスタ・ノードの概念がサポートされます。記憶域が有効化されないノードはキャッシュ・クライアントと見なされます(<local-storage>サブ要素を参照)。

キャッシュ・パーティション

キャッシュ・エントリは複数の論理パーティションに均等にセグメント化されます(<partition-count>サブ要素を参照)。これらのパーティションの管理の役割は、特定のパーティション・サービス(<service-name>サブ要素を参照)を実行する、記憶域が有効化された(<local-storage>サブ要素を参照)クラスタ・ノード間で均等に分担されます。

キー・アソシエーション

デフォルトでは、各パーティションに割り当てられた特定のエントリ・セットはアプリケーションに対して透過的になります。場合によっては、特定の関連するエントリを同じクラスタ・ノード内に保持することが有用になります。key-associator(<key-associatorサブ要素を参照)を使用すると、関連するエントリを指定して、対応付けられたエントリをパーティション・キャッシュ・サービスで同じパーティション内(つまり、同じクラスタ・ノード上)に格納できます。キー・アソシエーションは、アプリケーション・コード内からcom.tangosol.net.cache.KeyAssociationインタフェースを実装するキーを使用して指定することもできます。

キャッシュ記憶域(バッキング・マップ)

キャッシュの記憶域は<backing-map-scheme>サブ要素を使用して指定します。たとえば、バッキング・マップにlocal-schemeを使用するパーティション・キャッシュでは、記憶域が有効化されたクラスタ・ノードのメモリー内にキャッシュ・エントリが格納されます。

フェイルオーバー

フェイルオーバーを目的として、構成した数のキャッシュのバックアップ(<backup-count>サブ要素を参照)をクラスタ・ノード全体のbackup-storage(<backup-storage>サブ要素を参照)で管理できます。各バックアップもパーティションに分割されます。可能なかぎりバックアップ・パーティションはプライマリ・パーティションと同じコンピュータには配置しません。クラスタ・ノードが突然クラスタから切断された場合は、そのパーティションの役割が自動的に既存のバックアップに再割当てされ、それらのパーティションの新しいバックアップが(リモート・ノード上に)作成されて、構成されたバックアップ数が維持されます。

パーティションの再分散

クラスタにおけるノードの参加および切断時には、バックグラウンドでパーティションの再分散が行われ、パーティション総数の管理の役割がクラスタ・ノード間で均等に分担されます。バックグラウンドでのパーティションの転送で消費される帯域幅の量は、transfer-threshold(<transfer-threshold>サブ要素を参照)によって制御されます。

要素

表B-20で、distributed-scheme要素のサブ要素を説明します。

表B-20 distributed-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

この分散スキームから作成されたキャッシュを管理する分散キャッシュ・サービス・インスタンスの名前を指定します。分散キャッシュ・サービス定義は、tangosol-coherence.xmlファイルの<services>要素内で定義されすま。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。分散スキームごとに、異なるパーティション・キャッシュ・サービス・インスタンスを使用して、別々のキャッシュを管理できます。名前が指定されていない場合のデフォルト名は、DistributedCacheです。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたservice-priority値です。詳細は、「DistributedCacheサービスのパラメータ」のservice-priorityパラメータを参照してください。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたevent-dispatcher-priority値です。詳細は、「DistributedCacheサービスのパラメータ」のevent-dispatcher-priorityパラメータを参照してください。

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「DistributedCacheサービスのパラメータ」のreliable-transportパラメータを参照してください。

<compressor>

オプション

バックアップ更新をデルタ形式で圧縮するか、全体を送信するかを指定します。デルタ更新は、バックアップ・エントリの一部を表しており、プライマリ・エントリと同期させるには変更が必要です。デルタは、コンプレッサを使用して作成および適用します。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたcompressor値です。詳細は、「"DistributedCacheサービスのパラメータ」のcompressorパラメータを参照してください。有効な値は次のとおりです。

- none - デルタ・バックアップを無効にします。コンプレッサは使用されません。プライマリ・エントリが変更されると、バックアップ・バイナリ・エントリ全体が置換されます。

- standard - パーティション・サービスで使用されているシリアライザに基づいて、デルタ・コンプレッサを自動的に選択します。

- <instance> - com.tangosol.io.DeltaCompressorインタフェースを実装するクラスの構成です。

<thread-count>

オプション

パーティション・キャッシュ・サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数、0または-1です。値0は、すべての関連するタスクがそのサービス・スレッドで実行されることを示します。値-1は、可能な場合はタスクがコール元のスレッドで実行されることを示します。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたthread-count値です。詳細は、「DistributedCacheサービスのパラメータ」のthread-countパラメータを参照してください。

<worker-priority>

オプション

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたworker-priority値です。詳細は、「DistributedCacheサービスのパラメータ」のworker-priorityパラメータを参照してください。

<lease-granularity>

オプション

リース所有権の精度を指定します。有効な値は次のとおりです。

- thread

- member

値がthreadの場合、ロックはそのロックを取得したスレッドによって保持され、そのスレッドによってのみ解放されます。値がmemberの場合、ロックはクラスタ・ノードによって保持され、ロックを取得したクラスタ・ノード上で実行されるスレッドによって解放できます。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたlease-granularity値です。詳細は、「DistributedCacheサービスのパラメータ」のlease-granularityパラメータを参照してください。

<local-storage>

オプション

クラスタ・ノードをクラスタの記憶域として機能させる(つまり、パーティションを保持する)かどうかを指定します。無効化した場合、そのノードはキャッシュ・クライアントと見なされます。

有効な値は、trueまたはfalseです。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたlocal-storage値です。詳細は、「DistributedCacheサービスのパラメータ」のlocal-storageパラメータを参照してください。

<partition-count>

オプション

分散キャッシュ・パーティションの数を指定します。分散キャッシュ・サービスを実行している記憶域が有効なクラスタ・メンバーはそれぞれ均等な数のパーティションを管理します。

有効な値は、1と32767の間の正の整数で、素数にする必要があります。素数のリストは、http://primes.utm.edu/lists/にあります。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。「DistributedCacheサービスのパラメータ」のpartition-countパラメータを参照してください。

<transfer-threshold>

オプション

プライマリ・バケット分散のしきい値をキロバイト単位で指定します。パーティション・キャッシュ・サービスに新しいノードが結合する場合、またはサービスのメンバーのいずれかの結合が解除される場合、残りのノードによって、バケット所有権の再分散タスクが実行されます。このプロセスでは、所有権情報とともに既存のデータの均衡化が再実行されます。このパラメータでは、データ転送通信で優先されるメッセージ・サイズを示します。この値を低く設定すると、分散プロセスの所要時間は長くなりますが、このアクティビティ実行中のネットワーク帯域幅の使用量は軽減されます。有効な値は、ゼロより大きな整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtransfer-threshold値です。詳細は、「DistributedCacheサービスのパラメータ」のtransfer-thresholdパラメータを参照してください。

<backup-count>

オプション

パーティション・キャッシュ・サービスのうち、各保存単位のバックアップ・データをキャッシュに保持するメンバーの数を指定します。この値が0になっていると、異常終了した場合にキャッシュ内のデータの一部が失われます。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたbackup-count値です。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

<backup-count-after-writebehind>

オプション

ライトビハインドを必要としないキャッシュ内の各保存単位のバックアップ・データ(つまり、クラスタ全体がシャットダウンしても失われにくいデータ)を保持する、パーティション・キャッシュ・サービスのメンバー数を指定します。ライトビハインドが必要とマークされている保存単位は、<backup-count>サブ要素で指定されているメンバー数でバックアップされます。ライトビハインドが必要とマークされていない保存単位は、<backup-count-after-writebehind>要素で指定されているメンバー数でバックアップされます。

この要素の値は0に設定するか、要素の指定を完全に省略する必要があります。論理的な根拠として、このデータは別のデータ・ストアにバックアップされるため、書込み対象のライトビハインド・キューにデータが一時的に配置される場合を除いて、メモリー内でのバックアップは必要ありません。値0は、ライトビハインドが発生した場合に、そのデータのバックアップ・コピーが破棄されることを意味します。ただし、ライトビハインドが発生するまでは、<backup-count>設定に従ってデータがバックアップされます。

推奨値は0です。それ以外の場合は、この要素の指定を省略してください。

<backup-storage>

オプション

パーティション・キャッシュのバックアップ記憶域のタイプと構成を指定します。

<key-associator>

オプション

キー間の対応付けを行い、対応付けられたキーの同一パーティションへの格納を可能にするクラスを指定します。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。

<key-partitioning>

オプション

com.tangosol.net.partition.KeyPartitioningStrategyインタフェースを実装するクラスを指定します。これはパーティションにキーを割り当てる役割を果たします。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。指定しない場合は、デフォルトのキー・パーティション化アルゴリズムが使用され、キーがパーティション間で均等にセグメント化されます。

<partition-assignment-strategy>

オプション

パーティション・サービスでパーティション分散を管理する際に使用する戦略を指定します。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたpartition-assignment-strategy値です。詳細は、「DistributedCacheサービスのパラメータ」のpartition-assignment-strategyパラメータを参照してください。

- legacy - (非推奨)レガシー割当て戦略では、パーティション分散は各クラスタ・メンバーで個々に管理されます。

- simple - 単純な割当て戦略は、マシンの安全性を確保しながらパーティション分散のバランスを取ることを試み、レガシー戦略よりも決定論的で効率的です。

- mirror:<service-name> – ミラー割当て戦略は、サービスのパーティションを、指定されたサービスのパーティションと共存させることを試みます。この戦略は、キーを関連付けられたクロスサービス・キャッシュ・アクセスがメンバーに対してローカルのままになる可能性を高めるために使用されます。

- custom - com.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装するクラス。カスタム戦略は、<instance>要素を使用して指定します。

<partition-listener>

オプション

com.tangosol.net.partition.PartitionListenerインタフェースを実装するクラスを指定します。

<task-hung-threshold>

オプション

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。注意: ポストされたタスクがまだ開始されていない場合は、ハングと見なされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtask-hung-threshold値です。詳細は、「DistributedCacheサービスのパラメータ」のtask-hung-thresholdパラメータを参照してください。

<task-timeout>

オプション

サービス・ワーカー・スレッド上で実行するリクエストのタイムアウト値をミリ秒単位で指定します。この属性は、スレッド・プールが使用されている(thread-count値が正の)場合にのみ適用され、PriorityTaskインタフェースを実装するエントリ・プロセッサ実装にのみ適用されます。ゼロを指定すると、service-guardianのデフォルトの<timeout-milliseconds>値が使用されます。有効な値は正の整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。「DistributedCacheサービスのパラメータ」のtask-timeoutパラメータを参照してください。

<request-timeout>

オプション

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「DistributedCacheサービスのパラメータ」のrequest-timeoutパラメータを参照してください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<member-listener>

オプション

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。クラスの定義に使用する要素の詳細は、「instance」のサブ要素を参照してください。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。<member-listener>要素は、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

<operation-bundling>

オプション

バンドリング戦略の構成情報を指定します。

<backing-map-scheme>

オプション

キャッシュ・サーバー内でのエントリの格納に使用するキャッシュのタイプを指定します。

有効なスキームは次のとおりです。

- local-scheme

- external-scheme

- paged-external-scheme

- class-scheme

- flashjournal-scheme

- ramjournal-scheme

- overflow-scheme

- read-write-backing-map-scheme

ヒープ外バッキング・マップを使用する際は、対応する<backup-storage>をヒープ外用に構成することが重要です(可能であれば、backing-mapと同じスキームを使用します)。ここでヒープ外とは、JVMガベージ・コレクションが行われるヒープ領域外に一部またはすべてのエントリが格納される記憶域のことを指します。<overflow-scheme>や<external-scheme>などがあります。構成例については、「オーバーフローが設定されたパーティション・キャッシュ」を参照してください。

<partitioned-quorum-policy-scheme>

オプション

パーティション・キャッシュ・サービス用のクォーラム・ポリシー設定を指定します。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るMapListenerの実装を指定します。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<interceptors>

オプション

特定の分散サービスのすべてのキャッシュのイベントを処理する任意の数のイベント・インターセプタを指定します。

<async-backup>

オプション

パーティション(分散)キャッシュ・サービスが、クライアントに同時に応答する際に、データを非同期にバックアップするかどうかを指定します。非同期バックアップは、多くの場合、クライアントのパフォーマンスを向上させるために使用されます。ただし、厳密なデータ整合性を必要とするアプリケーションは、そのデータが危険にさらされないように設計し、テストする必要があります。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

external-scheme

使用場所: caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

説明

外部スキームを使用すると、JVMヒープ・ベースでないキャッシュを定義することで大容量の記憶域の使用が可能になります。様々な外部キャッシュの構成例は、「ローカル・キャッシュ(単一のJVMからアクセス可能)」を参照してください。

実装

このスキームは、次を使用して実装されます。

- com.tangosol.net.cache.SerializationMap: サイズ制限のないキャッシュ

- com.tangosol.net.cache.SerializationCache: サイズ制限のあるキャッシュ

実装タイプは次の規則に従って選択されます。

- <high-units>サブ要素に0以外の値が指定されている場合はSerializationCacheが使用されます。

- これ以外の場合はSerializationMapが使用されます。

プラガブルなストレージ・マネージャ

外部スキームでは、プラガブルなストア・マネージャを使用して、バイナリ・キー値のペアの格納と取得を行います。サポートされるストア・マネージャは次のとおりです。

- 他のストア・マネージャの実装に対して非同期の書込み機能を提供するラッパー

- ストア・マネージャのカスタム実装定義が可能

- オンディスク・キャッシュの実装にBerkeley Database JEを使用

- メモリーマップ・ファイル・ベースのキャッシュの実装にNIOを使用

- JVMヒープ外キャッシュ(インメモリー・キャッシュ)の実装にNIOを使用

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

サイズ制限のあるキャッシュ

このキャッシュはサイズ制限のあるキャッシュとして構成できます。これにより、キャッシュが最大許容サイズ(<high-units>サブ要素)に達すると、自動的に小さなサイズへのプルーニングが行われます。

注意:
ディスクベースのキャッシュに対するエビクションにはコストがかかる場合があります。その場合はpaged-external-schemeの使用を検討します。

エントリの有効期限

外部スキームでは、<expiry-delay>サブ要素の構成に従って、値の有効期間に基づいたエントリの自動失効がサポートされます。

永続性(長期記憶域)

外部キャッシュは一般に、大きなデータ・セットの一時記憶域(たとえば、overflow-schemeのバック層)として使用されます。ただし、Berkeley Database JEを実装すると、すべての非クラスタ化キャッシュの永続性をサポートします(bdb-store-managerの<store-name>サブ要素を参照してください)。クラスタ化の永続性は、distributed-schemeのread-write-backing-map-schemeを使用して構成します。

要素

表B-21で、external-scheme要素のサブ要素を説明します。

表B-21 external-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

外部キャッシュのカスタム実装を指定します。カスタム実装では、次のいずれかのクラスを拡張する必要があります。

- com.tangosol.net.cache.SerializationCache: サイズ制限のあるキャッシュ

- com.tangosol.net.cache.SerializationMap: サイズ制限のないキャッシュ

- com.tangosol.net.cache.SimpleSerializationMap: サイズ制限のないキャッシュ

- com.tangosol.net.cache.CompactSerializationCache—圧縮されたon-heapフットプリント

また、スーパークラスと完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタム外部キャッシュの実装で使用する初期化パラメータを指定します。

<async-store-manager>

オプション

他のストレージ・マネージャに対して非同期のストレージ・マネージャ・ラッパーを使用するよう外部キャッシュを構成します。「プラガブルなストレージ・マネージャ」を参照してください。

<bdb-store-manager>

オプション

キャッシュ記憶域にBerkeley Database JEのオンディスク・データベースを使用するよう外部キャッシュを構成します。

<custom-store-manager>

オプション

ストレージ・マネージャのカスタム実装を使用するよう外部キャッシュを構成します。

<nio-file-manager>

オプション

キャッシュ記憶域にメモリーマップ・ファイルを使用するよう外部キャッシュを構成します。

<nio-memory-manager>

オプション

キャッシュ記憶域にJVMヒープ外のメモリー領域を使用するよう外部キャッシュを構成します。

<high-units>

オプション

キャッシュのサイズ制限を指定します。この値は、プルーニングが開始されるまでキャッシュに配置できる単位の最大数を表します。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。この制限を超えると、キャッシュでプルーニング・プロセスが開始され、単位数がこの制限を下回るまで最低使用頻度のエントリが順番に削除されます。スキームのclass-name要素を使用すると、SerializationCacheにカスタム拡張を行って代替のエビクション・ポリシーを実装できます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、値に制限はありません。

注意: 値はデフォルトで約2GBに制限されます。より大きな値を指定するには、<unit-factor>要素を使用して、<high-units>値を乗算する係数を変更します。

<unit-calculator>

オプション

使用する単位換算カリキュレータのタイプを指定します。単位換算カリキュレータは、特定のオブジェクトのコスト(単位)の決定に使用されます。この要素は、<high-units>要素が正の数値に設定されている場合にのみ使用されます。有効な値は次のとおりです。

- FIXED - すべてのキャッシュ・オブジェクトに対して均等加重1を割り当てる単位換算カリキュレータ。

- BINARY (デフォルト) - オブジェクトに対して、そのオブジェクトをキャッシュに配置するために必要なメモリーのバイト数に相当する加重を割り当てる単位換算カリキュレータ。このカリキュレータは、シリアライズされたバイナリ形式でデータをキャッシュするパーティション・キャッシュに使用します。詳細は、com.tangosol.net.cache.BinaryMemoryCalculatorを参照してください。

- <class-scheme - class schemeとして指定されたカスタムの単位換算カリキュレータ。このスキームで指定されたクラスは、com/tangosol/net/cache/ConfigurableCacheMap.UnitCalculatorインタフェースを実装する必要があります。

<unit-factor>

オプション

<low-units>および<high-units>設定の調整に使用する係数を指定します。たとえば、BINARY単位換算カリキュレータでは、係数1048576を使用してバイトをメガバイトに換算できます。

注意: この要素は、<low-units>および<high-units>の設定のタイプを32ビット値から64ビット値に変更することを回避するためにのみ導入されたものであり、<high-units>要素が正の数値に設定されている場合にのみ使用されます。

有効値は正の整数です。デフォルト値は1です。

<expiry-delay>

オプション

前回の更新からエントリが期限切れとなるまでの、キャッシュでエントリが保持される期間を指定します。期限切れになったキャッシュ内のエントリはクライアントからアクセス不能となり削除されます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。値0は期限がないことを意味します。デフォルト値は0です。

注意: expiry-delayのパラメータ (cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

flashjournal-scheme

使用場所: back-scheme、backing-map-scheme、caching-schemes、internal-cache-scheme

説明

flashjournal-scheme要素には、外部のブロックベースのファイル・ストア(フラッシュ)にデータを格納するスキームの構成情報を記述します。フラッシュ・ジャーナルの動作は、フラッシュ・ジャーナル・リソース・マネージャで制御します。フラッシュ・ジャーナルの動作の構成の詳細は、「flashjournal-manager」を参照してください。

このスキームでは、com.tangosol.net.cache.CompactSerializationCacheクラスをバッキング・マップ実装として使用し、com.tangosol.io.journal.JournalBinaryStoreを使用してバイナリ・キー値のペアのジャーナルへの格納と取得を行います。

要素

表B-22で、flashjournal-scheme要素のサブ要素を説明します。

表B-22 flashjournal-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

簡単なシリアライズ・マップ・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.CompactSerializationCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットをスーパークラスとして宣言する必要があります。

<init-params>

オプション

カスタム・シリアライズ・マップ・キャッシュの初期化パラメータを指定します。

<eviction-policy>

オプション

使用するエビクション・ポリシーのタイプを指定します。有効な値は次のとおりです。

- LRU - 最低使用頻度(Least Recently Used)によるエビクション・ポリシーでは、最後にアクセスされた時間を基準として削除対象エントリが選択されます。アクセスされていない期間が最も長いエントリから順番に削除されます。

- LFU - 最低アクセス頻度(Least Frequently Used)によるエビクション・ポリシーでは、アクセス頻度を基準として削除対象エントリが選択されます。アクセス頻度が最も低いエントリから順番に削除されます。

- HYBRID(デフォルト) - ハイブリッド・エビクション・ポリシーでは、アクセス頻度およびアクセス時間の組合せ(加重スコア)を基準として削除対象エントリが選択されます。アクセス頻度が低く、アクセスされていない期間が最も長いエントリから順番に削除されます。

- <class-scheme> - class schemeとして指定されたカスタム・エビクション・ポリシー。このスキームで指定されたクラスは、ConfigurableCacheMap.EvictionPolicyインタフェースを実装するか、AbstractEvictionPolicyクラスを拡張する必要があります

<high-units>

オプション

キャッシュのサイズ制限を指定します。この値は、プルーニングが開始されるまでキャッシュに配置できる単位の最大数を表します。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。この制限を超えると、キャッシュでプルーニング・プロセスが開始され、エビクション・ポリシーに従ってエントリが順番に削除されます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、値に制限はありません。

注意: 値はデフォルトで約2GBに制限されます。より大きな値を指定するには、<unit-factor>要素を使用して、<high-units>値を乗算する係数を変更します。

<low-units>

オプション

プルーニングを実行する際にどこまでキャッシュを小さくするかを示す単位の最小数を指定します。プルーニングによりキャッシュにこの数の単位が含まれるとはかぎりませんが、これより少ない数になることはありません。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。プルーニングの実行時は、このサイズに達するまでエビクション・ポリシーに従ってエントリが順番に削除されていきます。有効な値は、正の整数またはゼロです。ゼロはデフォルト値を意味します。デフォルト値は<high-units>設定の80%です(つまり、<high-units>の設定が1000である場合、<low-units>のデフォルト値は800になります)。

<unit-calculator>

オプション

使用する単位換算カリキュレータのタイプを指定します。単位換算カリキュレータは、特定のオブジェクトのコスト(単位)の決定に使用されます。この要素は、<high-units>要素が正の数値に設定されている場合にのみ使用されます。有効な値は次のとおりです。

- FIXED - すべてのキャッシュ・オブジェクトに対して均等加重1を割り当てる単位換算カリキュレータ。

- BINARY (デフォルト) - オブジェクトに対して、そのオブジェクトをキャッシュに配置するために必要なメモリーのバイト数に相当する加重を割り当てる単位換算カリキュレータ。このカリキュレータは、シリアライズされたバイナリ形式でデータをキャッシュするパーティション・キャッシュに使用します。詳細は、com.tangosol.net.cache.BinaryMemoryCalculatorを参照してください。

- <class-scheme - class schemeとして指定されたカスタムの単位換算カリキュレータ。このスキームで指定されたクラスは、com/tangosol/net/cache/ConfigurableCacheMap.UnitCalculatorインタフェースを実装する必要があります。

<unit-factor>

オプション

<low-units>および<high-units>設定の調整に使用する係数を指定します。たとえば、BINARY単位換算カリキュレータでは、係数1048576を使用してバイトをメガバイトに換算できます。

注意: この要素は、<low-units>および<high-units>の設定のタイプを32ビット値から64ビット値に変更することを回避するためにのみ導入されたものであり、<high-units>要素が正の数値に設定されている場合にのみ使用されます。

有効値は正の整数です。デフォルト値は1です。

<expiry-delay>

オプション

前回の更新からエントリが期限切れとなるまでの、キャッシュでエントリが保持される期間を指定します。期限切れになったキャッシュ内のエントリはクライアントからアクセス不能となり削除されます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。値0は期限がないことを意味します。デフォルト値は0です。

注意: expiry-delayのパラメータ (cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

front-scheme

使用場所: near-scheme、overflow-scheme

説明

front-scheme要素は、複合キャッシュのフロント層キャッシュを指定します。

要素

表B-23で、front-scheme要素のサブ要素を説明します。

表B-23 front-schemeのサブ要素

要素

必須/
オプション

説明

<local-scheme>

オプション

ローカル・キャッシュ・スキームは、インメモリー・ローカル・キャッシュを定義します。ローカル・キャッシュは一般に、他のキャッシュ・スキーム内にネストされます(ニア・スキームのフロント層としてなど)。

<class-scheme>

オプション

クラス・スキームは、任意のJavaオブジェクトをインスタンス化して、他のスキームでの使用を可能にするメカニズムを提供します。この要素を含むスキームによって、拡張の必要なクラスまたはインタフェースが指定されます。

http-acceptor

使用場所: acceptor-config

説明

http-acceptor要素は、HTTPを介したリモートのRESTクライアントからの接続のアクセプタを指定します。

要素

表B-24で、http-acceptor要素のサブ要素を説明します。

表B-24 http-acceptorのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.coherence.rest.server.HttpServerインタフェースを実装するHTTPサーバー・クラスを指定します。HTTPサーバー・クラスはインバウンドHTTPリクエストを処理します。Coherence RESTは、com.tangosol.coherence.rest.server.DefaultHttpServer (Oracleの軽量HTTPサーバーでバッキング)とcom.tangosol.coherence.rest.server.GrizzlyHttpServer (Grizzlyでバッキング)の2つの即時利用可能な実装を備えています。値が指定されていない場合のデフォルト値はcom.tangosol.coherence.rest.server.DefaultHttpServerです。

<init-params>

オプション

HTTPサーバー・クラスのクラス初期化パラメータを記述します。

<socket-provider>

オプション

ソケットおよびチャンネル・ファクトリの構成を指定します。

<local-address>

必須

HTTPサーバー・ソケットがバインドされるローカル・アドレス(IPまたはDNS名およびポート)を指定します。

<resource-config>

オプション

HTTPアクセプタがリソース・クラスおよびプロバイダ・クラスをロードする際に使用されるJerseyリソース構成クラスを指定します。

<auth-method>

オプション

HTTPサーバーの認証メカニズムを指定します。クライアントは、サーバーによって公開されるリソースへのアクセスを得るための前提条件として、構成済メカニズムを使用して認証を受ける必要があります。有効な値は次のとおりです。

- basic - このメソッドは、クライアントにHTTP Basic認証を使用して認証を受けることを要求します。

- cert - このメソッドは、クライアントにクライアント側SSL証明書ベースの認証を使用して認証を受けることを要求します。認証を受けるには、証明書をサーバーに渡す必要があります。SSLベース・ソケット・プロバイダを、<socket-provider>要素を使用して構成する必要があります。

- cert+basic - このメソッドは、クライアントに、クライアント側SSL証明書とHTTP Basic認証の両方を使用して認証を受けることを要求します。

- none (デフォルト) - このメソッドは、クライアントに認証を受けることを要求しません。

identity-manager

使用場所: ssl

説明

<identity-manager>要素には、javax.net.ssl.KeyManagerインスタンスを初期化するための構成情報を記述します。

アイデンティティ・マネージャは、そのピアへのローカル接続を認証するために使用されるキー・マテリアルの管理を行います。キー・マテリアルが使用できない場合、その接続では認証資格証明を提示できません。

要素

表B-25は、identity-manager要素で定義可能なサブ要素について説明しています。

表B-25 identity-managerのサブ要素

要素

必須/
オプション

説明

<algorithm>

オプション

アイデンティティ・マネージャによって使用されるアルゴリズムを指定します。デフォルト値はSunX509です。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<key-store>

オプション

キー・ストア実装の構成を指定します。

<password>

必須

秘密鍵のパスワードを指定します。

incoming-message-handler

使用場所: acceptor-config、initiator-config

説明

<incoming-message-handler>要素は、クライアントからクラスタへの接続リソース使用量の規制に使用される構成情報を含んでいます。接続イニシエータおよび接続アクセプタは、この情報を使用して過剰なリソースを使用する接続を事前に検知および解放します。

要素

表B-25は、incoming-message-handler要素で定義可能な要素について説明しています。

表B-26 incoming-message-handlerのサブ要素

要素

必須/
オプション

説明

max-message-size

オプション

Coherence*Extend接続で送信されるメッセージのサイズ制限を指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Kが係数として適用されます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、これはメッセージ・サイズに制限がないことを示します。

initiator-config

使用場所: remote-cache-scheme、remote-invocation-scheme

説明

initiator-config要素は、TCP/IP接続イニシエータの構成情報を指定します。接続イニシエータを使用すると、Coherence*Extendクライアントからクラスタへの接続が有効になり、クライアントがクラスタに参加していなくても、クラスタの提供するサービスを使用できるようになります。

要素

表B-27で、initiator-config要素のサブ要素を説明します。

表B-27 initiator-configのサブ要素

要素

必須/
オプション

説明

<tcp-initiator>

オプション

TCP/IPを介してクラスタに接続する、接続イニシエータの構成情報を指定します。

<incoming-message-handler>

オプション

クライアントからクラスタへの接続リソース使用量の規制に使用される構成情報を指定します。

<outgoing-message-handler>

オプション

クライアントからクラスタへの接続の切断を検出するために接続イニシエータで使用される構成情報を指定します。

<use-filters>

オプション

この接続アクセプタで使用するフィルタ名のリストを記述します。たとえば、<use-filter>を次のように指定すると、すべてのネットワーク・メッセージに対してgzip圧縮がアクティブ化されるため、WANおよび低帯域幅ネットワークのパフォーマンスが大幅に向上します。

<use-filters>
<filter-name>gzip</filter-name>
</use-filters>

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<connect-timeout>

オプション

接続アクセプタへの接続を確立する際の最大待機時間を指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。デフォルト値は無限のタイムアウトです。

init-param

使用場所: init-params

説明

個別の初期化パラメータを定義します。

要素

表B-28で、init-param要素のサブ要素を説明します。

表B-28 init-paramのサブ要素

要素

必須/
オプション

説明

<param-name>

オプション

初期化パラメータの名前を指定します。例:

<init-param>
<param-name>sTableName</param-name>
<param-value>EmployeeTable</param-value>
</init-param>

<param-type>要素が指定されている場合は、<param-name>要素は指定できません。

<param-type>

オプション

初期化パラメータのJavaタイプを指定します。次の標準タイプがサポートされています。

- java.lang.String (string)

- java.lang.Boolean (boolean)

- java.lang.Integer (int)

- java.lang.Long (long)

- java.lang.Double (double)

- java.math.BigDecimal

- java.io.File

- java.sql.Date

- java.sql.Time

- java.sql.Timestamp

例:

<init-param>
<param-type>java.lang.String</param-type>
<param-value>EmployeeTable</param-value>
</init-param>

<param-name>要素が指定されている場合は、<param-type>要素は指定できません。

<param-value>

必須

初期化パラメータの値を指定します。この値は、パラメータのJavaタイプに固有の形式にします。

<description>

オプション

初期化パラメータの説明を指定します。

init-params

使用場所: class-scheme、cache-mapping

説明

一連の初期化パラメータを、名前と値のペアで定義します。init-paramsの使用例については、「データベースのパーティション・キャッシュ」を参照してください。

要素

表B-29で、init-params要素のサブ要素を説明します。

表B-29 init-paramsのサブ要素

要素

必須/
オプション

説明

<init-param>

オプション

個別の初期化パラメータを定義します。

instance

使用場所: interceptor、serializer、service-failure-policy、load-balancerおよびpartition-assignment-strategy

説明

<instance>要素には、カスタム機能をプラグインするために使用される実装クラスまたはクラス・ファクトリの構成を記述します。

要素

表B-30で、instance要素のサブ要素を説明します。

表B-30 instanceのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

実装クラスの完全修飾名を指定します。

この要素は、<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

interceptor

使用場所: interceptors

説明

interceptor要素は、ライブ・イベントの処理を行うイベント・インターセプタと関連付けられる構成を定義します。イベント・インターセプタはcom.tangosol.net.events.AbstractConfigurableEventInterceptorクラスを拡張します。このベース・クラスは、イベント・インターセプタを特定のキャッシュまたはサービスに制限する機能を提供します。このベース・クラスは、@Interceptor注釈のサポートも提供します。これにより、実装においてイベント・タイプに基づいてイベントのサブセットに対して登録することおよびイベント・インターセプタ識別子およびイベントインターセプタの順序を構成することが可能になります。interceptor要素内でインターセプタの識別子および順序付けを指定すると、このベース・クラスの設定がオーバーライドされます。

要素

表B-31で、interceptor要素のサブ要素を説明します。

表B-31 interceptorのサブ要素

要素

必須/
オプション

説明

<name>

オプション

インターセプタの一意の識別子を指定します。

<order>

オプション

このインターセプタを、インターセプタの連鎖の最初のインターセプタにするかどうかを指定します。有効な値はLOWとHIGHです。HIGHの値は、そのインターセプタを、インターセプタの連鎖の最初のものにすることを示します。LOWの値は、順序付けのプリファレンスはないことを示します。デフォルト値はLOWです。

<instance>

必須

インスタンス化するインターセプタ・クラスを指定します。そのインターセプタ・クラスは、AbstractConfigurableEventInterceptorクラスを拡張する必要があります。

interceptors

使用場所: cache-mappingおよびdistributed-scheme

説明

interceptors要素には、任意の数のイベント・インターセプタ定義が含まれます。

要素

表B-32で、interceptors要素のサブ要素を説明します。

表B-32 interceptorsのサブ要素

要素

必須/
オプション

説明

<interceptor>

オプション

イベント・インターセプタの実装を指定します。

invocation-scheme

使用場所: caching-schemes

説明

起動サービスを定義します。起動サービスは、任意の数のクラスタ・ノード上でカスタム操作をパラレルに実行するために使用します。詳細は、com.tangosol.net.InvocationService APIを参照してください。

要素

表B-33で、invocation-scheme要素のサブ要素を説明します。

表B-33 invocation-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

このスキームからの起動を管理するサービス名を指定します。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたservice-priority値です。「起動サービスのパラメータ」のservice-priorityパラメータを参照してください。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたevent-dispatcher-priority値です。「起動サービスのパラメータ」のevent-dispatcher-priorityパラメータを参照してください。

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「起動サービスのパラメータ」のreliable-transportパラメータを参照してください。

<thread-count>

オプション

起動サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数、0または-1です。値0は、すべての関連するタスクがそのサービス・スレッドで実行されることを示します。値-1は、可能な場合はタスクがコール元のスレッドで実行されることを示します。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたthread-count値です。詳細は、「起動サービスのパラメータ」を参照してください。

<worker-priority>

オプション

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたworker-priority値です。「起動サービスのパラメータ」のworker-priorityパラメータを参照してください。

<task-hung-threshold>

オプション

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。注意: ポストされたタスクがまだ開始されていない場合は、ハングと見なされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtask-hung-threshold値です。「起動サービスのパラメータ」のtask-hung-thresholdパラメータを参照してください。

<task-timeout>

オプション

タイムアウト可能なタスク(たとえば、com.tangosol.net.PriorityTaskインタフェースの実装)のデフォルト・タイムアウト値を指定します。ただし、タスク実行のタイムアウト値は明示的に指定しません。タスク実行時間はサーバー側で測定され、開始されるまでサービス・バックログ・キューで待機するための所要時間は含まれません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。zeroが指定された場合は、デフォルトのservice-guardian <timeout-milliseconds値が使用されます。有効な値は正の整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtask-timeout値です。「起動サービスのパラメータ」のtask-timeoutパラメータを参照してください。

<request-timeout>

オプション

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたrequest-timeout値です。「起動サービスのパラメータ」のrequest-timeoutパラメータを参照してください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<member-listener>

オプション

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、サービス・ライフサイクル・イベントを受信します。<member-listener>要素は、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このサービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

invocation-service-proxy

使用場所: proxy-config

説明

invocation-service-proxy要素には、プロキシ・サービスによって管理される起動サービス・プロキシの構成情報を記述します。

要素

表B-34で、invocation-service-proxy要素のサブ要素を説明します。

表B-34 invocation-service-proxyのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

com.tangosol.net.InvocationServiceインタフェースを実装するクラスの完全修飾名を指定します。このクラスは、必要に応じてカスタム処理を実装するため、クライアントとプロキシされる起動サービス間のインターセプタとして機能します。たとえば、このクラスを使用して、プロキシされる起動サービスの使用を許可する前に認可チェックを行うことができます。

<init-params>

オプション

InvocationService実装の初期化パラメータを記述します。

<enabled>

オプション

起動サービス・プロキシが有効化されているかどうかを指定します。無効化されている場合、クライアントはプロキシ・サービスJVMでInvocableオブジェクトを実行できません。有効な値は、trueまたはfalseです。デフォルト値はtrueです。

key-associator

使用場所: distributed-scheme

説明

キーの対応付けを決定するcom.tangosol.net.partition.KeyAssociatorの実装を指定します。これにより、関連するキーを同じパーティションに格納できます。

また、com.tangosol.net.cache.KeyAssociationインタフェースを実装することにより、キャッシュのキーで関連付けを管理することもできます。

要素

表B-35で、key-associator要素のサブ要素を説明します。

表B-35 key-associatorのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

com.tangosol.net.partition.KeyAssociatorインタフェースを実装するクラスの名前。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。デフォルト値は、tangosol.coherence.xmlディスクリプタに指定されたkey-associatorパラメータの値です。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

key-partitioning

使用場所: distributed-scheme

説明

キーを格納するパーティションを決定するcom.tangosol.net.partition.KeyPartitioningStrategyの実装を指定します。

要素

表B-36で、key-partitioning要素のサブ要素を説明します。

表B-36 key-partitioningのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

com.tangosol.net.partition.KeyPartitioningStrategyインタフェースを実装するクラスの名前。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたkey-partitioningパラメータの値です。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

key-store

使用場所: identity-manager、trust-manager

説明

key-store要素は、SSLの実装時に使用するキー・ストア実装の構成を指定します。キー・ストア実装は、java.security.KeyStoreクラスのインスタンスです。

要素

表B-37は、key-store要素で定義可能なサブ要素について説明しています。

表B-37 key-storeのサブ要素

要素

必須/
オプション

説明

<url>

必須

キー・ストアへのUniform Resource Locator (URL)を指定します。

<password>

オプション

キャッシュ・ストアのパスワードを指定します。

<type>

オプション

java.security.KeyStoreインスタンスのタイプを指定します。デフォルト値はJKSです。

listener

使用場所: local-scheme、external-scheme、paged-external-scheme、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

説明

Listener要素は、キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

要素

表B-38で、listener要素のサブ要素を説明します。

表B-38 listenerのサブ要素

要素

必須/
オプション

説明

<class-scheme>

必須

使用するlistener実装の完全なクラス名を指定します。指定したクラスは、com.tangosol.util.MapListenerインタフェースを実装する必要があります。

local-address

使用場所: http-acceptor、tcp-acceptor、tcp-initiator

説明

local-address要素は、ソケットがバインドされるローカル・アドレス(IPまたはDNS名およびポート)を指定します。

<tcp-acceptor>要素のローカル・アドレスは、Coherence*Extendクライアントからの接続を受け入れるプロキシ・サービスによって使用されるTCP/IPサーバー・ソケットを指定します。<http-acceptor>要素のローカル・アドレスは、RESTクライアントからの接続を受け入れるために使用されるHTTPサーバー・ソケットを指定します。次の例で、サーバー・ソケットは192.168.0.2:9099にバインドされます。

<local-address>
<address>192.168.0.2</address>
<port>9099</port>
</local-address>

<tcp-initiator>要素のローカル・アドレスは、クラスタ上のプロキシ・サービスに接続するためにリモート・サービスによって使用されるTCP/IPクライアント・ソケットを指定します。次の例で、クライアント・ソケットは、192.168.0.1のポート9099にバインドされます。

<local-address>
<address>192.168.0.1</address>
<port>9099</port>
</local-address>

注意:
TCP/IPアクセプタのソケット・アドレスもaddress-provider要素を使用して定義できます。詳細は、「address-provider」を参照してください。

要素

表B-65で、local-address要素のサブ要素を説明します。

表B-39 local-addressのサブ要素

要素

必須/
オプション

説明

<address>

オプション

ソケットがリスニングおよび公開を行うアドレス(IPまたはDNS名)を指定します。アドレスがバインド・アドレスである場合、そのアドレスはサブネットおよびマスクとしてCIDR注釈を使用して(たとえば192.168.1.0/24と)入力することもでき、それにより、使用可能なローカルIPアドレスに対するランタイム解決が可能になります。

<port>

オプション

TCP/IPソケットがリスニングおよび公開を行うポートを指定します。有効な値は1から65535です。

local-scheme

使用場所: caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、front-scheme、overflow-scheme、read-write-backing-map-scheme、backing-map-scheme

説明

ローカル・キャッシュ・スキームは、インメモリー・ローカル・キャッシュを定義します。ローカル・キャッシュは一般に、他のキャッシュ・スキーム内にネストされます(near-schemeのフロント層としてなど)。様々なローカル・キャッシュの構成例は、「ニア・キャッシュ」を参照してください。

実装

ローカル・キャッシュは、com.tangosol.net.cache.LocalCacheクラスによって実装されます。

外部ストアのキャッシュ

ローカル・キャッシュは外部のキャッシュ・ストアでバッキングできます(「cachestore-scheme」を参照)。キャッシュ・ミスでは、バックエンドのストアまでリードスルーしてデータが取得されます。書込み可能なストアが提供されている場合は、キャッシュへの書込みがキャッシュ・ストアに伝播します。キャッシュ・ストアに対する読取り/書込みアクセスの最適化については、「read-write-backing-map-scheme」を参照してください。

サイズ制限のあるキャッシュ

このキャッシュはサイズ制限のあるキャッシュとして構成できます。これにより、キャッシュが最大許容サイズ(<high-units>サブ要素を参照)に達すると、エビクション・ポリシー(<eviction-policy>サブ要素を参照)に従って削除対象エントリが選択され、指定されたより小さなサイズ(<low-units>サブ要素を参照)へのプルーニングが行われます。エントリとサイズの制限は、スキームの単位換算カリキュレータ(<unit-calculator>サブ要素を参照)によって計算された単位で測定されます。

エントリの有効期限

ローカル・キャッシュでは、値の有効期間に基づいたエントリの自動失効がサポートされます(<expiry-delay>サブ要素を参照)。

要素

表B-40で、local-scheme要素のサブ要素を説明します。

表B-40 local-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

ローカル・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.LocalCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<service-name>

オプション

このスキームで作成されたキャッシュを管理するサービス名を指定します。サービスは、tangosol-coherence.xmlディスクリプタの<services>要素で構成します。詳細は、付録A「オペレーション構成の要素」を参照してください。

<init-params>

オプション

カスタム・ローカル・キャッシュの実装で使用する初期化パラメータを指定します。

<eviction-policy>

オプション

使用するエビクション・ポリシーのタイプを指定します。有効な値は次のとおりです。

- LRU - 最低使用頻度(Least Recently Used)によるエビクション・ポリシーでは、最後にアクセスされた時間を基準として削除対象エントリが選択されます。アクセスされていない期間が最も長いエントリから順番に削除されます。

- LFU - 最低アクセス頻度(Least Frequently Used)によるエビクション・ポリシーでは、アクセス頻度を基準として削除対象エントリが選択されます。アクセス頻度が最も低いエントリから順番に削除されます。

- HYBRID(デフォルト) - ハイブリッド・エビクション・ポリシーでは、アクセス頻度およびアクセス時間の組合せ(加重スコア)を基準として削除対象エントリが選択されます。アクセス頻度が低く、アクセスされていない期間が最も長いエントリから順番に削除されます。

- <class-scheme> - class schemeとして指定されたカスタム・エビクション・ポリシー。このスキームで指定されたクラスは、ConfigurableCacheMap.EvictionPolicyインタフェースを実装するか、AbstractEvictionPolicyクラスを拡張する必要があります

<high-units>

オプション

キャッシュのサイズ制限を指定します。この値は、プルーニングが開始されるまでキャッシュに配置できる単位の最大数を表します。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。この制限を超えると、キャッシュでプルーニング・プロセスが開始され、エビクション・ポリシーに従ってエントリが順番に削除されます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、値に制限はありません。

注意: 値はデフォルトで約2GBに制限されます。より大きな値を指定するには、<unit-factor>要素を使用して、<high-units>値を乗算する係数を変更します。

<low-units>

オプション

プルーニングを実行する際にどこまでキャッシュを小さくするかを示す単位の最小数を指定します。プルーニングによりキャッシュにこの数の単位が含まれるとはかぎりませんが、これより少ない数になることはありません。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。プルーニングの実行時は、このサイズに達するまでエビクション・ポリシーに従ってエントリが順番に削除されていきます。有効な値は、正の整数またはゼロです。ゼロはデフォルト値を意味します。デフォルト値は<high-units>設定の80%です(つまり、<high-units>の設定が1000である場合、<low-units>のデフォルト値は800になります)。

<unit-calculator>

オプション

使用する単位換算カリキュレータのタイプを指定します。単位換算カリキュレータは、特定のオブジェクトのコスト(単位)の決定に使用されます。この要素は、<high-units>要素が正の数値に設定されている場合にのみ使用されます。有効な値は次のとおりです。

- FIXED - すべてのキャッシュ・オブジェクトに対して均等加重1を割り当てる単位換算カリキュレータ。

- BINARY (デフォルト) - オブジェクトに対して、そのオブジェクトをキャッシュに配置するために必要なメモリーのバイト数に相当する加重を割り当てる単位換算カリキュレータ。このカリキュレータは、シリアライズされたバイナリ形式でデータをキャッシュするパーティション・キャッシュに使用します。詳細は、com.tangosol.net.cache.BinaryMemoryCalculatorを参照してください。

- <class-scheme - class schemeとして指定されたカスタムの単位換算カリキュレータ。このスキームで指定されたクラスは、com/tangosol/net/cache/ConfigurableCacheMap.UnitCalculatorインタフェースを実装する必要があります。

<unit-factor>

オプション

<low-units>および<high-units>設定の調整に使用する係数を指定します。たとえば、BINARY単位換算カリキュレータでは、係数1048576を使用してバイトをメガバイトに換算できます。

注意: この要素は、<low-units>および<high-units>の設定のタイプを32ビット値から64ビット値に変更することを回避するためにのみ導入されたものであり、<high-units>要素が正の数値に設定されている場合にのみ使用されます。

有効値は正の整数です。デフォルト値は1です。

<expiry-delay>

オプション

前回の更新からエントリが期限切れとなるまでの、キャッシュでエントリが保持される期間を指定します。期限切れになったキャッシュ内のエントリはクライアントからアクセス不能となり削除されます。キャッシュ・ストアを使用する場合は、期限切れエントリの読取りを試行すると、対象エントリが構成済のキャッシュ・ストア(<cachestore-scheme>を参照)からリロードされます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。値0は期限がないことを意味します。デフォルト値は0です。

注意: expiry-delayのパラメータ (cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

<cachestore-scheme>

オプション

キャッシュの対象となるストアを指定します。指定しない場合、キャッシュ・データはメモリー内にのみ配置され、そのキャッシュに対して実行された操作のみを反映します。

<pre-load>

オプション

キャッシュがCacheLoader(またはCacheStore)オブジェクトからデータを事前ロードするかどうかを指定します。有効な値は、trueとfalseです。デフォルト値はfalseです。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

memcached-acceptor

使用場所: acceptor-config

説明

memcached-acceptor要素には、リモートmemcachedクライアントからのTCP/IPを介した接続を受け入れるアクセプタの構成情報が含まれています。アクセプタによって、memcachedクライアントはmemcachedバイナリ・プロトコルでCoherenceキャッシュを使用できるようになります。

要素

表B-41で、memcached-acceptor要素のサブ要素を説明します。

表B-41 memcached-acceptorのサブ要素

要素

必須/
オプション

説明

<cache-name>

必須

memcachedアクセプタに接続するmemcachedクライアントが使用するキャッシュを指定します。キャッシュ名は、キャッシュ・マッピングを使用して実際のキャッシュ・スキームに解決されます。詳細は、「cache-mapping」を参照してください。キャッシュ名は、パーティション・キャッシュ・スキームに解決される必要があります。

<interop-enabled>

オプション

値をキャッシュに格納する際にmemcachedアクセプタが、構成済キャッシュ・サービス・シリアライザをバイパスできるかどうかを指定します。これは、Coherence*Extendとmemcachedクライアントでデータを共有する場合にのみ必要です。memcachedクライアントがオブジェクトをbyte[]に変換するためにPOFシリアライザのようにCoherenceシリアライザを使用し、キャッシュ・サービスも同じシリアライザを使用していることが前提です。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<memcached-auth-method>

オプション

memcachedアクセプタの認証メカニズムを指定します。クライアントは、サーバーによって公開されるリソースへのアクセスを得るため、構成済メカニズムを使用して認証を受けている必要があります。有効な値は、plain (SASL PLAIN)およびnoneです。デフォルト値はnoneです。

<socket-provider>

オプション

ソケットおよびチャンネル・ファクトリの構成を指定します。

<address-provider>

必須

TCP/IPサーバー・ソケットがバインドされるローカル・アドレス(IPまたはDNS名およびポート)またはプログラムでソケット・アドレスを提供するcom.tangosol.net.AddressProviderインタフェースの実装のいずれかを指定します。address-provider要素では、ソケット・アドレス参照もサポートされています。

name-service-addresses

使用場所: tcp-initiator

説明

name-service-addresses要素には、1つ以上のネーム・サービスTCP/IPアクセプタのアドレス(IPまたはDNS名およびポート)を記述します。TCP/IPイニシエータは、この情報を使用してリモート・クラスタとの接続を確立します。TCP/IPイニシエータは、記載されたアドレスをすべて試すか、接続が確立されるまで、アドレスへの接続をランダムに試行します。詳細および構成例については、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

要素

表B-42で、name-service-addresses要素のサブ要素を説明します。

表B-42 name-service-addressesのサブ要素

要素

必須/
オプション

説明

<socket-address>

オプション

ネーム・サービスTCP/IPアクセプタがリスニングを行うアドレス(IPまたはDNS名およびポート)を指定します。<socket-address>要素は複数定義できます。

<address-provider>

オプション

ネーム・サービスTCP/IPアクセプタがリスニングを行うアドレス(IPまたはDNS名およびポート)またはそのアドレスを提供するcom.tangosol.net.AddressProviderの実装の構成を指定します。address-provider要素では、ソケット・アドレス参照もサポートされています。

<name-services-addresses>要素には、<socket-address>要素または<address-provider>要素のいずれかを含めることができますが、両方を含めることはできません。

near-scheme

使用場所: caching-schemes

説明

near-schemeは、バック層キャッシュのサブセットをキャッシュするフロント層で構成される2層キャッシュを定義します。一般にフロント層は高速でサイズ制限があり、バック層は低速ですが大容量のキャッシュです。一般的なデプロイメントでは、フロント層にはローカル・キャッシュが、バック層には分散キャッシュが使用されます。その結果、大規模なパーティション・キャッシュの一部がローカル・インメモリーにキャッシュされ、非常に高速な読取りアクセスが実現されます。ニア・キャッシュの詳細は、「ニア・キャッシュの理解」を、ニア・キャッシュの構成例については、「ニア・キャッシュ」を参照してください。

実装

ニア・スキームは、com.tangosol.net.cache.NearCacheクラスによって実装されます。

フロント層の無効化

<invalidation-strategy>サブ要素は、ニア・キャッシュのフロント層とバック層の同期を保持するために使用される戦略を定義します。この戦略に従って、バック層で発生した特定のイベントをリスニングしてニア・キャッシュのフロント部分を自動的に更新(または無効化)するようニア・キャッシュが構成されます。

要素

表B-43で、near-scheme要素のサブ要素を説明します。

表B-43 near-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

ニア・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.NearCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタム・ニア・キャッシュの実装用の初期化パラメータを指定します。

<front-scheme>

必須

フロント層キャッシュとして使用するキャッシュを指定します。

<back-scheme>

必須

フロント層キャッシュとして使用するキャッシュを指定します。

<invalidation-strategy>

オプション

フロント層およびバック層の同期を保持するために使用される戦略を指定します。詳細は、com.tangosol.net.cache.NearCacheを参照してください。有効な値は次のとおりです。

- auto (デフォルト) - この戦略は、present戦略とまったく同じです。

- none - キャッシュに対して無効化イベントをリスニングしないよう指示します。これは、パフォーマンスとスケーラビリティが低く、現在値ではない可能性があるデータの使用がビジネス要件で許可されている場合に最適です。データの鮮度は、十分に簡潔なエビクション・ポリシーを使用することで保証できます。最悪の場合は、パフォーマンスが標準の分散キャッシュと同程度になります。

- present - ニア・キャッシュに対して、フロント・マップに現存するアイテムに関連したバック・マップ・イベントのみをリスニングするよう指示します。この戦略は、クラスタ・ノードにスティッキーなデータ・アクセス・パターン(スティッキーなロード・バランサによるHTTPセッション管理など)がある場合に最適です。

- all - ニア・キャッシュに対してすべてのバック・マップ・イベントをリスニングするよう指示します。この戦略は、読取り頻度の高いアクセス・パターンにおいて、各クラスタ・メンバーのフロント・キャッシュ間に大量のオーバーラップがある場合に最適です。

- logical - ニア・キャッシュに対して、統合削除でないすべてのバッキング・マップ・イベントをリスニングするよう指示します。統合削除イベントは、エビクションまたは期限切れの結果として出力されることがあります。この無効化戦略では、バッキング・マップから統合的に削除されたキャッシュ・エントリをフロント・マップに含めることができます。その後にバッキング・マップにこれらのエントリを再挿入すると、フロント・マップの対応するエントリは無効化されます。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

nio-file-manager

使用場所: external-scheme、paged-external-scheme、async-store-manager

説明

記憶域にメモリーマップ・ファイルを使用する外部ストアを構成します。

実装

このストア・マネージャは、com.tangosol.io.nio.MappedStoreManagerクラスによって実装されます。このクラスで作成されるBinaryStoreオブジェクトは、com.tangosol.io.nio.BinaryMapStoreのインスタンスです。

要素

表B-44で、nio-file-manager要素のサブ要素を説明します。

表B-44 nio-file-managerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

ローカル・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.io.nio.MappedStoreManagerクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタムnio-file-managerの実装で使用する初期化パラメータを指定します。

<initial-size>

オプション

バッファの初期サイズをメガバイト単位で指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1MBです。

<maximum-size>

オプション

バッファの最大サイズをバイト単位で指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1024MBです。

<directory>

オプション

マネージャがファイルを格納するルート・ディレクトリのパス名を指定します。指定しない場合、または存在しないディレクトリを指定した場合は、デフォルトの場所にある一時ファイルが使用されます。

nio-memory-manager

使用場所: external-scheme、paged-external-scheme、async-store-manager

説明

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

記憶域にJVMヒープ外のメモリー領域を使用するストア・マネージャを構成します。つまり、Javaヒープ・サイズには影響せず、アプリケーションの一時停止の原因となり得る関連したJVMガベージ・コレクションのパフォーマンスにも影響しない構成です。NIOキャッシュの構成例については、「NIOインメモリー・キャッシュ」を参照してください。

注意:
NIOバッファの合計が64MBを超える場合、JVMはコマンド行パラメータを使用する必要があります。例: -XX:MaxDirectMemorySize=512M

実装

com.tangosol.io.nio.DirectStoreManagerクラスによって実装されます。このクラスで作成されるBinaryStoreオブジェクトは、com.tangosol.io.nio.BinaryMapStoreのインスタンスです。

要素

表B-45で、nio-memory-manager要素のサブ要素を説明します。

表B-45 nio-memory-managerのサブ要素

要素

必須/
オプション

説明

<class-name>

オプション

ローカル・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.io.nio.DirectStoreManagerクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタムnio-memory-managerの実装で使用する初期化パラメータを指定します。

<initial-size>

オプション

バッファの初期サイズをバイト単位で指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1MBです。

<maximum-size>

オプション

バッファの最大サイズをバイト単位で指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Mが係数として適用されます。有効な値は、1からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は1024MBです。

operation-bundling

使用場所: cachestore-scheme、distributed-scheme、remote-cache-scheme

説明

operation-bundling要素は、特定のバンドリング戦略の構成情報を指定します。

バンドリングとは、複数の個別の操作をいくつかの束(バンドル)にまとめるプロセスです。これは次のような場合に役立ちます。

- 複数のスレッド上に連続的な操作ストリームがパラレルに存在する場合。

- 各操作の(ネットワークまたはデータベースに関連した)待機時間が比較的長い場合。

- 待機時間を(コレクション・サイズに応じて)線形に増加させることなく、単一引数のかわりに引数のコレクションを取る、機能的に類似したバルク操作が存在する場合。

注意:

- 他のバンドリング・アルゴリズム同様、リソース使用率とリクエストの平均待機時間との間には必然的なトレードオフが存在します。この機能を有効化することによって全体的なアプリケーションのパフォーマンスが向上するか低下するかは、各アプリケーションの使用パターンによって異なります。

- 操作バンドリングは、キャッシュ・ストアの操作に影響します。操作バンドリングを構成すると、熟成エントリが1つのみの場合であっても、CacheStore.storeAll()メソッドが常にコールされます。

実装の詳細は、com.tangosol.net.cache.AbstractBundlerを参照してください。

要素

表B-46は、operation-bundling要素のサブ要素について説明しています。

表B-46 operation-bundlingのサブ要素

要素

必須/
オプション

説明

<bundle-config>

必須

1つ以上のバンドル可能な操作を記述します。

optimistic-scheme

使用場所: caching-schemes、near-scheme、overflow-scheme

オプティミスティック・スキームは、サービスを実行するすべてのクラスタ・ノードに自身の全データを完全にレプリケートするキャッシュを定義します(<service-name>サブ要素を参照)。オプティミスティック・キャッシュの詳細は、「オプティミスティック・キャッシュの理解」を参照してください。

オプティミスティック・ロック

replicated-schemeやdistributed-schemeのキャッシュと異なり、オプティミスティック・キャッシュでは並行処理制御(ロック)がサポートされません。エントリに対する個々の操作はアトミックですが、キャッシュに格納された値がアトミック操作間で変更されない保証はありません。並行処理制御がないため、オプティミスティック・キャッシュでは非常に高速な書込み操作が実現されます。

キャッシュ記憶域(バッキング・マップ)

キャッシュの記憶域は<backing-map-scheme>サブ要素を使用して指定します。たとえば、バッキング・マップにlocal-schemeを使用するオプティミスティック・キャッシュでは、キャッシュ・エントリがメモリー内に格納されます。

要素

表B-47で、optimistic-scheme要素のサブ要素を説明します。

表B-47 optimistic-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

このスキームで作成されたキャッシュを管理するサービス名を指定します。サービスは、tangosol-coherence.xmlの<services>パラメータで構成します。詳細は、付録A「オペレーション構成の要素」を参照してください。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「OptimisticCacheサービスのパラメータ」のreliable-transportパラメータを参照してください。

<request-timeout>

オプション

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「ReplicatedCacheサービスのパラメータ」のrequest-timeoutパラメータを参照してください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<member-listener>

オプション

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。<member-listener>要素は、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

<backing-map-scheme>

オプション

キャッシュ・サーバー内でのエントリの格納に使用するキャッシュのタイプを指定します。有効な値は次のとおりです。

- local-scheme

- external-scheme

- paged-external-scheme

- overflow-scheme

- class-scheme

- flashjournal-scheme

- ramjournal-scheme

キャッシュの一貫性を確保するため、オプティミスティック・キャッシュのバッキング・マップでは、キャッシュ・エントリのロードにリードスルー・パターンを使用しません。キャッシュ・サービスの外部でキャッシュアサイド・パターンを使用するか、クラスタ化キャッシュのリードスルーをサポートするdistributed-schemeに切り替えます。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

outgoing-message-handler

使用場所: acceptor-config、initiator-config

説明

outgoing-message-handlerは、クライアントからクラスタへの接続の切断を検出するために使用される構成情報を指定します。コネクションレスのプロトコルを使用する接続イニシエータおよび接続アクセプタでは、この情報は、切断された接続に割り当てられていたリソースを検出および解放するために必要です。この情報は、接続指向のイニシエータおよびアクセプタでも、接続の切断を検出するための追加メカニズムとして使用できます。

要素

表B-48で、outgoing-message-handler要素のサブ要素を説明します。

表B-48 outgoing-message-handlerのサブ要素

要素

必須/
オプション

説明

<heartbeat-interval>

オプション

pingリクエストの間隔を指定します。pingリクエストは接続の整合性を保証するために使用されます。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。値0はpingリクエストがないことを意味します。デフォルト値は0です。

<heartbeat-timeout>

オプション

基礎となる接続を閉じるまでの、ハートビートpingリクエストへのレスポンスに対する最大待機時間を指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<max-message-size>

オプション

Coherence*Extend接続で送信されるメッセージのサイズ制限を指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、Kが係数として適用されます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、これはメッセージ・サイズに制限がないことを示します。

<request-timeout>

オプション

レスポンス・メッセージがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、リクエストが破棄されます。<heartbeat-timeout>値に達するまで接続は閉じません。

注意: プロキシはExtendクライアントにリクエストを送信しないため、プロキシ・サービス・アクセプタはこの要素を使用しません。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。デフォルト値は無限のタイムアウト(0s)です。

overflow-scheme

使用場所: caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、read-write-backing-map-scheme

説明

overflow-schemeは、高速でサイズ制限のあるフロント層キャッシュと、低速でより大容量のバック層キャッシュで構成される2層キャッシュを定義します。サイズ制限のあるフロント層が一杯になると、削除されたエントリが透過的にバック層に移動されます。キャッシュ・ミス発生時は、エントリがバック層からフロント層に移動することがあります。一般的なデプロイメントでは、フロント層にはlocal-schemeが、バック層にはexternal-schemeが使用され、JVMヒープよりも容量の大きい高速のローカル・キャッシュが実現されます。このようなデプロイメントでは、local-scheme要素のhigh-unitsおよびeviction-policyによってフロント・キャッシュからバック・キャッシュへのエントリの転送(削除)が制御されます。

注意:
標準のキャッシュ記憶域におけるオーバーフローに依存することはお薦めしません。これは、構成された容量を記憶域所要量が一時的に超えた場合に、削除処理に付随するデータの損失を回避する目的でのみ使用してください。一般に、オーバーフローのオンディスク記憶域は空のままにします。

実装

com.tangosol.net.cache.OverflowMapまたはcom.tangosol.net.cache.SimpleOverflowMapのいずれかで実装されます。詳細は、expiry-enabledを参照してください。

エントリの有効期限

オーバーフローでは、<expiry-delay>サブ要素の構成に従って、値の有効期間に基づいたエントリの自動失効がサポートされます。

要素

表B-49で、overflow-scheme要素のサブ要素を説明します。

表B-49 overflow-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

オーバーフロー・キャッシュのカスタム実装を指定します。カスタム実装は、com.tangosol.net.cache.OverflowMapまたはcom.tangosol.net.cache.SimpleOverflowMapクラスを拡張し、完全に同一のpublicなコンストラクタを宣言する必要があります。

<init-params>

オプション

カスタム・オーバーフロー・キャッシュの実装で使用する初期化パラメータを指定します。

<front-scheme>

必須

フロント層キャッシュとして使用するキャッシュを指定します。

<back-scheme>

必須

バック層キャッシュの作成に使用する cache-scheme を指定します。

<miss-cache-scheme>

オプション

キャッシュ・ミス情報を保持するcache-schemeを指定します。expiry-enabled(<expiry-enabled>サブ要素を参照)が指定されていないキャッシュでは、miss-cacheを使用して、フロント層およびバック層の両方で、キャッシュ・ミスの発生したキーが追跡されます。いずれの層にもキーが存在しないという情報により、速度が遅くなるバック層への問合せを回避できるため、一部の操作では実行速度が向上します。サイズが制限されたスキームを使用すると、追跡するミスの数を制御できます。値を指定しないと、キャッシュ・ミスのデータは保持されません。有効な値は次のとおりです。

- local-scheme

<expiry-enabled>

オプション

com.tangosol.net.cache.CacheMap APIの規定に従って、自動失効データのサポートを有効にします。有効化すると、overflow-schemeの実装に、com.tangosol.net.cache.SimpleOverflowMapではなくcom.tangosol.net.cache.OverflowMapが使用されます。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<expiry-delay>

オプション

前回の更新からエントリが期限切れとなるまでの、キャッシュでエントリが保持される期間を指定します。期限切れになったキャッシュ内のエントリはクライアントからアクセス不能となり削除されます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。値0は期限がないことを意味します。デフォルト値は0です。

注意: expiry-delayのパラメータ (cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

paged-external-scheme

使用場所: caching-schemes、distributed-scheme、replicated-scheme、optimistic-scheme、near-scheme、overflow-scheme、read-write-backing-map-scheme

説明

external-scheme同様、paged-external-schemesは、より大きな記憶域容量の使用を可能にする非JVMヒープ・ベースのキャッシュを定義します。paged-externalスキームは、ページングの方法を使用して、LRUエビクションを最適化します。ページ・キャッシュ機能の詳細は、第16章「シリアライズ・ページ・キャッシュ」を参照してください。

実装

このスキームは、com.tangosol.net.cache.SerializationPagedCacheクラスによって実装されます。

ページング

キャッシュ・エントリは一連のページに対して維持されます。ページはそれぞれ、構成済のストレージ・マネージャ(「プラガブルなストレージ・マネージャ」を参照)から取得した別々のcom.tangosol.io.BinaryStoreです。ページは作成時点において現在のページと見なされ、すべての書込み操作がこのページに対して実行されます。構成された時間間隔(<page-durationサブ要素を参照)で現在のページが閉じられ、新しい現在のページが作成されます。特定のキーの読取り操作は、対象キーが格納された最後のページに対して実行されます。ページ数が構成済の最大値(<page-limitサブ要素を参照)を超過すると、最も古いページが破棄され、そのページが閉じられてから更新されていないアイテムは削除されます。

たとえば、1ページ当たり10分の間隔でキャッシュを構成し、最大値を6ページとすると、最大で1時間分のエントリがキャッシュされることになります。ページングでは、キャッシュ・エントリの削除や消去が行われるため、ストレージ・マネージャに対する削除操作を個別に実行する必要がなくなり、パフォーマンスが向上します。そのかわり、キャッシュはそれらのエントリに対する参照を解放するのみとなり、すべてのページ・エントリに使用されていた記憶域の解放は最終的に1回の操作で行われるページ全体の破棄に依存します。

プラガブルなストレージ・マネージャ

外部スキームはプラガブルなストア・マネージャを使用して、ページの作成と破棄、およびこれらのページ内のエントリへのアクセスを実行します。サポートされるストア・マネージャは次のとおりです。

- async-store-manager: 他のストア・マネージャの実装に対して非同期の書込み機能を提供するラッパー。

- custom-store-manager: ストア・マネージャのカスタム実装を定義します。

- bdb-store-manager: Berkeley Database JEを使用してオンディクス・キャッシュを実装します。

- nio-file-manager: NIOを使用してメモリーマップ・ファイル・ベースのキャッシュを実装します。

- nio-memory-manager: NIOを使用してJVMヒープ外キャッシュ(インメモリー・キャッシュ)を実装します。

注意:
NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。

永続性(長期記憶域)

外部ページ・キャッシュは、大きなデータ・セットの一時記憶域(たとえば、overflow-schemeのバック層)として使用されます。これらのキャッシュは長期記憶域(永続)としては使用されず、JVMの存続期間を超えて保持できません。クラスタ化の永続性は、distributed-schemeのread-write-backing-map-schemeを使用して構成します。非クラスタの永続キャッシュが必要な場合は、「永続性(長期記憶域)」を参照してください。

要素

表B-50で、paged-external-scheme要素のサブ要素を説明します。

表B-50 paged-external-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

外部ページ・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.SerializationPagedCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタム外部ページ・キャッシュの実装で使用する初期化パラメータを指定します。

<async-store-manager>

オプション

他のストレージ・マネージャに対して非同期のストレージ・マネージャ・ラッパーを使用するよう外部ページ・キャッシュを構成します。詳細は、「プラガブルなストレージ・マネージャ」を参照してください。

<bdb-store-manager>

オプション

キャッシュ記憶域にBerkeley Database JEのオンディスク・データベースを使用するよう外部ページ・キャッシュを構成します。

<custom-store-manager>

オプション

ストレージ・マネージャのカスタム実装を使用するよう外部ページ・キャッシュを構成します。

<nio-file-manager>

オプション

キャッシュ記憶域にメモリーマップ・ファイルを使用するよう外部ページ・キャッシュを構成します。

<nio-memory-manager>

オプション

キャッシュ記憶域にJVMヒープ外のメモリー領域を使用するよう外部ページ・キャッシュを構成します。

<page-limit>

オプション

キャッシュが管理する最大ページ数を指定します。この数を超えると、古いページは破棄されます。有効な値は、ゼロまたは2 - 3600の間の正の整数です。デフォルト値は0です。

<page-duration>

オプション

キャッシュ内のページが現在のページと見なされる時間を秒単位で指定します。この時間を超過すると、ページは閉じられ、現在のページが新規に作成されます。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。有効な値は、ゼロまたは5 - 604800秒(1週間)の値です。デフォルト値は0です。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

partition-listener

使用場所: distributed-scheme

説明

com.tangosol.net.partition.PartitionListenerインタフェースの実装を指定します。これにより、パーティション分散イベントの受信が可能になります。

要素

表B-51で、partition-listener要素のサブ要素を説明します。

表B-51 partition-listenerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

PartitionListenerインタフェースを実装するクラスの名前。この実装には、パラメータがゼロのpublicなコンストラクタが必要です。デフォルト値は、tangosol-coherence.xmlディスクリプタのpartition-listenerパラメータに指定された値です。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

<class-factory-name>

オプション

実装クラス・インスタンスを作成するための、ファクトリ・クラスの完全修飾名を指定します。

この要素は、<class-name>要素と一緒には使用できません。<method-name>要素と一緒に使用されます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

partitioned-quorum-policy-scheme

使用場所: distributed-scheme

説明

partitioned-quorum-policy-scheme要素には、パーティション・キャッシュ・サービス用のクォーラム・ポリシー設定を記述します。

要素

表B-52で、partitioned-quorum-policy-scheme要素のサブ要素を説明します。

表B-52 partitioned-quorum-policy-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<distribution-quorum>

オプション

パーティション分散を行うために必要な、パーティション・サービスの所有権が有効なメンバーの最小数を指定します。

値は負ではない整数である必要があります。

<restore-quorum>

オプション

失われたプライマリ・パーティションをバックアップからリストアするために必要な、パーティション・サービスの所有権が有効なメンバーの最小数を指定します。

値は負ではない整数である必要があります。

<read-quorum>

オプション

読取りリクエストを処理するために必要な、キャッシュ・サービスの記憶域メンバーの最小数を指定します。読取りリクエストとは、キャッシュの状態や内容を変化させないリクエストです。

値は負ではない整数である必要があります。

<write-quorum>

オプション

書込みリクエストを処理するために必要な、キャッシュ・サービスの記憶域メンバーの最小数を指定します。書込みリクエストとは、キャッシュの状態や内容を変化させる可能性のあるリクエストです。

値は負ではない整数である必要があります。

<class-name>

オプション

カスタム・クォーラム・ポリシーを提供するクラスを指定します。この要素は、デフォルトのクォーラム要素または<class-factory-name>要素と一緒には使用できません。

クラスは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。初期化パラメータは、<init-params>要素を使用して指定できます。

<class-factory-name>

オプション

カスタム・アクション・ポリシー・インスタンスを作成するためのファクトリ・クラスを指定します。この要素は、デフォルトのクォーラム要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用されます。アクション・ポリシーは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

provider

使用場所: ssl、identity-manager、trust-manager

説明

provider要素には、java.security.Providerクラスを拡張するセキュリティ・プロバイダの構成情報を記述します。

要素

表B-53は、provider要素で定義可能なサブ要素について説明しています。

表B-53 providerのサブ要素

要素

必須/
オプション

説明

<name>

オプション

java.security.Providerクラスを拡張するセキュリティ・プロバイダの名前を指定します。

クラス名は、この要素を使用するか、<class-name>要素または<class-factory-name>要素を使用して入力できます。

<class-name>

オプション

java.security.Providerクラスを拡張するセキュリティ・プロバイダの名前を指定します。

この要素は、<name>要素または<class-factory-name>要素と一緒には使用できません。

<class-factory-name>

オプション

Providerインスタンスを作成するためのファクトリ・クラスを指定します。インスタンスは、java.security.Providerクラスを実装する必要があります。

この要素は、<name>要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用できます。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

プロバイダ実装のクラス初期化パラメータを記述します。

この要素は、<name>要素と一緒には使用できません。

proxy-config

使用場所: proxy-scheme

説明

proxy-config要素は、プロキシ・サービスによって管理されるクラスタ化サービス・プロキシの構成情報を指定します。サービス・プロキシは、リモート・クライアント(接続アクセプタを使用してクラスタに接続)と、リモート・クライアントが使用するクラスタ化サービスとの間を媒介します。

要素

表B-54で、proxy-config要素のサブ要素を説明します。

表B-54 proxy-configのサブ要素

要素

必須/
オプション

説明

<cache-service-proxy>

オプション

プロキシ・サービスによって管理されるキャッシュ・サービス・プロキシの構成情報を指定します。

<invocation-service-proxy>

オプション

プロキシ・サービスによって管理される起動サービス・プロキシの構成情報を指定します。

proxy-scheme

使用場所: caching-schemes

説明

proxy-scheme要素には、クラスタ化サービスの構成情報を記述します。これにより、Coherence*Extendクライアントは、クラスタへの接続が可能になり、クラスタに参加しなくてもクラスタ化サービスを使用できるようになります。

要素

表B-55で、proxy-scheme要素のサブ要素を説明します。

表B-55 proxy-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

サービスの名前を指定します。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。デフォルト値は、tangosol-coherence.xmlディスクリプタのservice-priorityパラメータに指定された値です。詳細は、「プロキシ・サービスのパラメータ」を参照してください。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタのevent-dispatcher-priorityパラメータに指定された値です。詳細は、「プロキシ・サービスのパラメータ」を参照してください。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「プロキシ・サービスのパラメータ」のreliable-transportパラメータを参照してください。

<thread-count>

オプション

プロキシ・サービスで使用されるデーモン・スレッドの数を指定します。正確なスレッド数を含むスレッド・プールを作成する値を指定します。プロキシ・サービス・スレッドは、アプリケーションのコールのかわりに操作を実行します。したがって、スレッド数を明示的に設定する場合は、値は同時操作と同じ数に設定します。

注意: デフォルトのプロキシ・サービス構成は、プロキシ・サービスの負荷に基づいて自動的にスレッド数を調整する動的スレッド・プールを使用します。一般に、動的スレッド・プーリングの使用がお薦めです。動的スレッド・プーリングを使用する場合は、この要素を使用しないでください。動的スレッド・プールのしきい値を調整するには、thread-count-maxおよびthread-count-min要素を使用します。詳細は、「プロキシ・サービス・パラメータ」を参照してください。

スレッド・プールを無効化してすべてのタスクがプロキシ・サービス・スレッドで実行されるよう強制するには、この要素を使用せずに、thread-count-maxおよびthread-count-minパラメータを0に設定します。一般に、この構成の使用はお薦めしません。

<thread-count-max>

オプション

動的スレッド・プールで許容されるデーモン・スレッドの最大数を指定します。この要素は、<thread-count>要素が使用されていない場合にのみ有効です。有効な値は、正の整数または0です。この要素および<thread-count-min>要素の両方に0を指定すると、デーモン・スレッドは作成されず、すべてのクライアント・リクエストはプロキシ・サービス・スレッドで処理されます。デフォルト値は、tangosol-coherence.xmlディスクリプタのthread-count-maxパラメータに指定された値です。詳細は、「プロキシ・サービスのパラメータ」を参照してください。

<thread-count-min>

オプション

動的スレッド・プールで許容される(および最初に作成される)デーモン・スレッドの最小数を指定します。この要素は、<thread-count>要素が使用されていない場合にのみ有効です。有効な値は、正の整数または0です。この要素および<thread-count-max>要素の両方に0を指定すると、デーモン・スレッドは作成されず、すべてのクライアント・リクエストはプロキシ・サービス・スレッドで処理されます。デフォルト値は、tangosol-coherence.xmlディスクリプタのthread-count-minパラメータに指定された値です。詳細は、「プロキシ・サービスのパラメータ」を参照してください。

<worker-priority>

オプション

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタのworker-priorityパラメータに指定された値です。詳細は、「プロキシ・サービスのパラメータ」を参照してください。

<task-hung-threshold>

オプション

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。ポストされ、まだ開始されていないタスクはハングしたとみなされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「プロキシ・サービスのパラメータ」のtask-hung-thresholdパラメータを参照してください。

<task-timeout>

オプション

サービス・ワーカー・スレッド上で実行するリクエストのタイムアウト値をミリ秒単位で指定します。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。zeroが指定された場合は、デフォルトのservice-guardian <timeout-milliseconds>値が使用されます。有効な値は正の整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。「プロキシ・サービスのパラメータ」のtask-timeoutパラメータを参照してください。

<request-timeout>

オプション

他の同名のプロキシに送信されるリクエストがくるまでプロキシが待機する最大時間を指定します。プロキシ間でリクエストが送信されることはないため、この要素を使用しないでください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<member-listener>

オプション

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、サービス・ライフサイクル・イベントを受信します。<member-listener>要素は、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

<acceptor-config>

必須

接続アクセプタの構成を記述します。サービスでは、この接続アクセプタを使用してCoherence*Extendクライアントからの接続を受け入れ、クライアントがクラスタに参加していなくても、クラスタの提供するサービスを使用できるようにします。

<proxy-config>

オプション

このサービスによって管理されるクラスタ化サービス・プロキシの構成を記述します。

<load-balancer>

オプション

プロキシ・サービスで一連のクラスタ・プロキシ・サービス・メンバーにクライアント接続を分散する際に使用されるプラガブルな戦略を指定します。有効な値は次のとおりです。

- proxy - (デフォルト)この戦略では、既存の接続数、接続制限、送受信メッセージのバックログおよびデーモン・プールの使用率に基づいて、プロキシ・サービス・メンバーにクライアント接続を均等に分散します。

- client - この戦略では、クライアント・アドレス・プロバイダの実装に依存して、プロキシ・サービス・メンバーへのクライアントの分散を指定します。クライアント・アドレス・プロバイダが実装されていない場合は、接続が成功するまで、拡張クライアントが各プロキシ・サービスをランダムに試行します。

- カスタム・クラス - <instance>のサブ要素を使用して、com.tangosol.net.proxy.ProxyServiceLoadBalancerインタフェースを実装するクラスの構成情報が提供されます。

<proxy-quorum-policy-scheme>

オプション

プロキシ・サービス用のクォーラム・ポリシー設定を指定します。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このサービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

proxy-quorum-policy-scheme

使用場所: proxy-scheme

説明

proxy-quorum-policy-scheme要素には、プロキシ・サービス用のクォーラム・ポリシー設定を記述します。

要素

表B-55で、proxy-quorum-policy-scheme要素のサブ要素を説明します。

表B-56 proxy-quorum-policy-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<connect-quorum>

オプション

クライアント接続を可能にするために必要な、プロキシ・サービスのメンバーの最小数を指定します。

値は負ではない整数である必要があります。

<class-name>

オプション

カスタム・クォーラム・ポリシーを提供するクラスを指定します。この要素は、<connect-quorum>要素または<class-factory-name>要素と一緒には使用できません。

クラスは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。初期化パラメータは、<init-params>要素を使用して指定できます。

<class-factory-name>

オプション

カスタム・アクション・ポリシー・インスタンスを作成するためのファクトリ・クラスを指定します。この要素は、<connect-quorum>要素または<class-name>要素と一緒には使用できません。

この要素は、<method-name>要素と一緒に使用されます。アクション・ポリシーは、com.tangosol.net.ActionPolicyインタフェースを実装する必要があります。

<method-name>

オプション

オブジェクトのインスタンス化を実行する、ファクトリ・クラスのstaticなファクトリ・メソッドの名前を指定します。

<init-params>

オプション

実装クラスのクラス初期化パラメータを記述します。

ramjournal-scheme

使用場所: back-scheme、backing-map-scheme、caching-schemes、internal-cache-scheme

説明

ramjournal-scheme要素には、バッファ(ジャーナル・ファイル)にインメモリーでデータを格納するスキームの構成情報を記述します。RAMジャーナルの動作は、RAMジャーナル・リソース・マネージャで制御します。RAMジャーナルの動作の構成の詳細は、「ramjournal-manager」を参照してください。

このスキームでは、com.tangosol.net.cache.CompactSerializationClassクラスをバッキング・マップ実装として使用し、com.tangosol.io.journal.JournalBinaryStoreを使用してバイナリ・キー値のペアのジャーナルへの格納と取得を行います。

要素

表B-57で、ramjournal-scheme要素のサブ要素を説明します。

表B-57 ramjournal-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

簡単なシリアライズ・マップ・キャッシュのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.CompactSerializationCacheクラスを拡張し、完全に同一のpublicなコンストラクタのセットをスーパークラスとして宣言する必要があります。

<init-params>

オプション

カスタム・シリアライズ・マップ・キャッシュの初期化パラメータを指定します。

<eviction-policy>

オプション

使用するエビクション・ポリシーのタイプを指定します。有効な値は次のとおりです。

- LRU - 最低使用頻度(Least Recently Used)によるエビクション・ポリシーでは、最後にアクセスされた時間を基準として削除対象エントリが選択されます。アクセスされていない期間が最も長いエントリから順番に削除されます。

- LFU - 最低アクセス頻度(Least Frequently Used)によるエビクション・ポリシーでは、アクセス頻度を基準として削除対象エントリが選択されます。アクセス頻度が最も低いエントリから順番に削除されます。

- HYBRID(デフォルト) - ハイブリッド・エビクション・ポリシーでは、アクセス頻度およびアクセス時間の組合せ(加重スコア)を基準として削除対象エントリが選択されます。アクセス頻度が低く、アクセスされていない期間が最も長いエントリから順番に削除されます。

- <class-scheme> - class schemeとして指定されたカスタム・エビクション・ポリシー。このスキームで指定されたクラスは、ConfigurableCacheMap.EvictionPolicyインタフェースを実装するか、AbstractEvictionPolicyクラスを拡張する必要があります

<high-units>

オプション

キャッシュのサイズ制限を指定します。この値は、プルーニングが開始されるまでキャッシュに配置できる単位の最大数を表します。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。この制限を超えると、キャッシュでプルーニング・プロセスが開始され、エビクション・ポリシーに従ってエントリが順番に削除されます。有効な値は、0からInteger.MAX_VALUE (2147483647).の間の正の整数です。デフォルト値は0で、値に制限はありません。

注意: 値はデフォルトで約2GBに制限されます。より大きな値を指定するには、<unit-factor>要素を使用して、<high-units>値を乗算する係数を変更します。

<low-units>

オプション

プルーニングを実行する際にどこまでキャッシュを小さくするかを示す単位の最小数を指定します。プルーニングによりキャッシュにこの数の単位が含まれるとはかぎりませんが、これより少ない数になることはありません。別のunit calculator(<unit-calculator>サブ要素を参照)によってオーバーライドされないかぎり、エントリは測定単位になります。プルーニングの実行時は、このサイズに達するまでエビクション・ポリシーに従ってエントリが順番に削除されていきます。有効な値は、正の整数またはゼロです。ゼロはデフォルト値を意味します。デフォルト値はhigh-units設定の80%です(つまり、<high-units>の設定が1000である場合、<low-units>のデフォルト値は800になります)。

<unit-calculator>

オプション

使用する単位換算カリキュレータのタイプを指定します。単位換算カリキュレータは、特定のオブジェクトのコスト(単位)の決定に使用されます。この要素は、<high-units>要素が正の数値に設定されている場合にのみ使用されます。有効な値は次のとおりです。

- FIXED - すべてのキャッシュ・オブジェクトに対して均等加重1を割り当てる単位換算カリキュレータ。

- BINARY (デフォルト) - オブジェクトに対して、そのオブジェクトをキャッシュに配置するために必要なメモリーのバイト数に相当する加重を割り当てる単位換算カリキュレータ。このカリキュレータは、シリアライズされたバイナリ形式でデータをキャッシュするパーティション・キャッシュに使用します。詳細は、com.tangosol.net.cache.BinaryMemoryCalculatorを参照してください。

- <class-scheme - class schemeとして指定されたカスタムの単位換算カリキュレータ。このスキームで指定されたクラスは、com/tangosol/net/cache/ConfigurableCacheMap.UnitCalculatorインタフェースを実装する必要があります。

<unit-factor>

オプション

<low-units>および<high-units>設定の調整に使用する係数を指定します。たとえば、BINARY単位換算カリキュレータでは、係数1048576を使用してバイトをメガバイトに換算できます。

注意: この要素は、<low-units>および<high-units>の設定のタイプを32ビット値から64ビット値に変更することを回避するためにのみ導入されたものであり、<high-units>要素が正の数値に設定されている場合にのみ使用されます。

有効値は正の整数です。デフォルト値は1です。

<expiry-delay>

オプション

前回の更新からエントリが期限切れとなるまでの、キャッシュでエントリが保持される期間を指定します。期限切れになったキャッシュ内のエントリはクライアントからアクセス不能となり削除されます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。値0は期限がないことを意味します。デフォルト値は0です。

注意: expiry-delayのパラメータ (cExpiryMillis)は整数として定義し、ミリ秒単位で表します。そのため、最大期間はInteger.MAX_VALUE (2147483647)ミリ秒数を超えることはできず、おおよそ24日間になります。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

read-write-backing-map-scheme

使用場所: caching-schemes、distributed-scheme

説明

read-write-backing-map-schemeは、永続ストアのサイズ制限されたキャッシュを提供するバッキング・マップを定義します。詳細は、第15章「データ・ソースのキャッシュ」を参照してください。

実装

read-write-backing-map-schemeは、com.tangosol.net.cache.ReadWriteBackingMapクラスによって実装されます。

外部ストアのキャッシュ

読取り/書込みバッキング・マップでは、外部の永続キャッシュ・ストア(<cachestore-scheme>サブ要素を参照)でバッキングされるキャッシュを保持します。キャッシュ・ミスでは、バックエンドのストアまでリードスルーしてデータが取得されます。書込み可能なストアが提供されている場合は、キャッシュへの書込みがキャッシュ・ストアに伝播します。

リフレッシュアヘッド・キャッシング

これが有効な場合(<refreshahead-factor>サブ要素を参照)、失効時期が近い、最近アクセスされたエントリがキャッシュによって監視され、キャッシュ・ストアから非同期でリロードされます。アイテムは定期的に期限切れになるため、アプリケーションでキャッシュ・ストアの読取りが遅くなる事態を回避できます。

ライトビハインド・キャッシング

これが有効な場合(<write-delay>サブ要素を参照)、キャッシュによるバックエンド・キャッシュ・ストアへの書込みが遅延されます。これにより、書込みをより効率的な更新ブロックにバッチ化できます(<write-batch-factor>サブ要素を参照)。これは、クライアント・スレッドとは非同期に実行されます。

要素

表B-58で、read-write-backing-map-scheme要素のサブ要素を説明します。

表B-58 read-write-backing-map-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<class-name>

オプション

読取り/書込みバッキング・マップのカスタム実装を指定します。カスタム実装では、com.tangosol.net.cache.ReadWriteBackingMapクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。

<init-params>

オプション

カスタム読取り/書込みバッキング・マップの実装で使用する初期化パラメータを指定します。

<internal-cache-scheme>

必須

エントリのキャッシュに使用されるcache-schemeを指定します。有効な値は次のとおりです。

- local-scheme

- external-scheme

- paged-external-scheme

- overflow-scheme

- class-scheme

- flashjournal-scheme

- ramjournal-scheme

<write-max-batch-size>

オプション

1回のstoreAll操作で書き込むエントリの最大数を指定します。有効な値は、正の整数またはゼロです。デフォルト値は128個のエントリです。ライトビハインドが無効な場合、この値は無効です。

<miss-cache-scheme>

オプション

キャッシュ・ミス情報を保持するcache-schemeを指定します。miss-cacheは、キャッシュ・ストアに見つからなかったキーの追跡に使用されます。キャッシュ・ストアにキーがないことを事前に知っておくことで、一部の操作がより迅速に実行されます。処理に時間がかかる可能性のあるキャッシュ・ストアへの問合せを回避できるからです。サイズが制限されたスキームを使用すると、キャッシュされるキャッシュ・ミスの数を制御できます。値を指定しないと、キャッシュ・ミスのデータは保持されません。有効な値は次のとおりです。

- local-scheme

<cachestore-scheme>

オプション

キャッシュするストアを指定します。指定しない場合、キャッシュ・データは内部キャッシュにのみ配置され(<internal-cache-scheme>サブ要素を参照)、そのキャッシュに対して実行された操作のみを反映します。

<read-only>

オプション

読取り専用にするかどうかを指定します。trueの場合、キャッシュはデータをキャッシュ・ストアからロードして読取り操作を行い、キャッシュが更新されたときにキャッシュ・ストアへの書込みは実行しません。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<write-delay>

オプション

ライトビハインド・キューに関して、キャッシュ・ストアへの非同期書込みの遅延期間を指定します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、秒が単位として適用されます。0の場合、キャッシュ・ストアへの同期書込み(キューイングなし)が行われます。それ以外の場合、キャッシュ内の値が最後に更新されてから指定された期間だけ遅延して、書込みが非同期で実行されます。デフォルト値は0です。

この要素は、<write-delay-seconds>要素と一緒には使用できません。

<write-delay-seconds>

オプション

ライトビハインド・キューに関して、キャッシュ・ストアへの非同期書込みの遅延時間を秒数で指定します。0の場合、キャッシュ・ストアへの同期書込み(キューイングなし)が行われます。それ以外の場合、キャッシュ内の値が最後に更新されてから指定された秒数だけ遅延して、書込みが非同期で実行されます。

この要素は、<write-delay>要素と一緒には使用できません。

<write-batch-factor>

オプション

write-batch-factor要素は、ライトビハインド・キュー・エントリのソフト熟成時間の計算に使用されます。キューのエントリは、ライトビハインド・キューにwrite-delay期間以上格納されると、書込み操作用に十分に熟成している(適切な書込み時である)と見なされます。ソフト熟成時間は、実際の熟成時間より前の時点になります。これより後では、エントリが(その他のすべての熟成エントリとソフト熟成エントリとともに)CacheStoreに対するバッチ化された非同期の書込み操作に組み込まれます。つまり、ソフト熟成エントリは、次の期間よりも長くライトビハインド・キューに配置されていたエントリです。

D' = (1.0 - F) * D。D = write-delayの間隔、F = write-batch-factor。

概念的には、バッチ化された更新を実行する際に、write-behindスレッドでは次のロジックが使用されます。

1. スレッドは、キューに入れられたエントリが熟成するのを待ちます。

2. エントリが熟成すると、キュー内の熟成エントリおよびソフト熟成エントリのすべてが、スレッドでデキューされます。

3. 次に、スレッドではstore()(熟成エントリが1つのみの場合)またはstoreAll()(熟成/ソフト熟成エントリが複数存在する場合)を使用して、熟成およびソフト熟成のすべてのエントリを書き込みます。注意: 操作バンドリング(<operation-bundling>)が構成されている場合は、熟成エントリが1つのみの場合であっても、storeAll()が常にコールされます。

4. その後、スレッドは(1)を繰り返します。

この要素は、非同期の書込みが有効で(つまり、write-delay要素の値が0より大きくて)、CacheStoreでstoreAll()メソッドが実装されている場合にのみ適用されます。要素の値は、write-delay間隔の割合で表します。有効な値は、1.0以下の正のダブルになります。デフォルト値は0です。

<write-requeue-threshold>

オプション

追加のアクションを実行できるライトビハインド・キューのサイズを指定します。ゼロの場合、ライトビハインドの再キューは無効になります。それ以外の場合、この値は、対応するログ・メッセージの頻度を制御します。たとえば、この値が100の場合、ライトビハインド・キューのサイズが100の倍数になるたびにログ・メッセージが生成されます。有効な値は、正の整数またはゼロです。デフォルト値は0です。

<refresh-ahead-factor>

オプション

refresh-ahead-factor要素は、キャッシュ・エントリのソフト失効時間の計算に使用されます。ソフト失効時間は、実際の失効時間より前の時点になります。これより後では、エントリへのアクセス・リクエストによって、エントリに対する非同期のロード・リクエストがスケジュール化されます。この属性は、内部キャッシュがlocal-schemeで、<expiry-delay>サブ要素が構成されている場合にのみ適用されます。この値は、内部的なLocalCache失効間隔の割合で表します。ゼロの場合、スケジュール先行リフレッシュは無効になります。1.0の場合、get操作によって非同期のリロードがただちにトリガーされます。有効な値は、1.0以下の正のダブルになります。デフォルト値は0です。

<cachestore-timeout>

オプション

CacheStoreの読取りおよび書込み操作に使用するタイムアウト時間を指定します。CacheStoreの操作がタイムアウトになると、実行スレッドが中断されて、最終的にキャッシュ・サービスが終了することがあります。非同期のCacheStore操作(ライトビハインド、リフレッシュアヘッドなど)のタイムアウトでは、サービスは終了しません。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。0を指定すると、デフォルトのservice-guardianの<timeout-milliseconds>値が使用されます。指定がない場合のデフォルト値は0です。

<rollback-cachestore-failures>

オプション

同期のキャッシュ・ストア操作でキャッチされた例外が、コール元のスレッドに再スローされるかどうかを指定します(ネットワークを介してリモート・メンバーに送信されることもあります)。有効な値は、trueまたはfalseです。この要素の値がfalseの場合、同期のキャッシュ・ストア操作でキャッチされた例外はローカルでログに記録され、内部キャッシュは更新されます。この値がtrueの場合、例外がコール元のスレッドに再スローされ、内部キャッシュは変更されません。この操作をトランザクション・コンテキスト内でコールした場合は、現在のトランザクションをロールバックするのと同様の操作になります。デフォルト値はtrueです。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

remote-addresses

使用場所: tcp-initiator

説明

remote-addresses要素には、1つ以上のTCP/IPアクセプタのアドレス(IPまたはDNS名とポート)を記述します。TCP/IPイニシエータは、この情報を使用してリモート・クラスタのプロキシ・サービスとの接続を確立します。TCP/IPアクセプタは、proxy-scheme要素内で構成されます。TCP/IPイニシエータは、記載されたアドレスをすべて試すか、接続が確立されるまで、アドレスへの接続をランダムに試行します。詳細および構成例については、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

注意:
name-service-addresses要素は、リモート・クラスタ上のプロキシ・サービスとの接続を確立するためにも使用できます。詳細は、「name-service-addresses」を参照してください。

次の構成例は、イニシエータに対して192.168.0.2:9099および192.168.0.3:9099にランダムに接続するよう指示します。

<remote-addresses>
<socket-address>
<address>192.168.0.2</address>
<port>9099</port>
</socket-address>
<socket-address>
<address>192.168.0.3</address>
<port>9099</port>
</socket-address>
</remote-addresses>

要素

表B-59で、remote-addresses要素のサブ要素を説明します。

表B-59 remote-addressesのサブ要素

要素

必須/
オプション

説明

<socket-address>

オプション

TCP/IPアクセプタがリスニングを行うアドレス(IPまたはDNS名およびポート)を指定します。複数の<socket-address>要素を<remote-addresses>要素内で使用できます。

<address-provider>

オプション

TCP/IPアクセプタがリスニングを行うアドレス(IPまたはDNS名およびポート)またはそのアドレスを提供するcom.tangosol.net.AddressProviderの実装の構成を指定します。address-provider要素では、ソケット・アドレス参照もサポートされています。

<remote-addresses>要素には、<socket-address>要素または<address-provider>要素のいずれかを含めることができますが、両方を含めることはできません。

remote-cache-scheme

使用場所: cachestore-scheme、caching-schemes、near-scheme

説明

remote-cache-scheme要素には、クラスタの外部からCoherence*Extendを使用してクラスタ化キャッシュを利用する際に必要な構成情報を記述します。

要素

表B-60で、remote-cache-scheme要素のサブ要素を説明します。

表B-60 remote-cache-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

このスキームで作成されたキャッシュを管理するサービス名を指定します。

<proxy-service-name>

オプション

このリモート・サービスの接続先のプロキシ・サービス名を指定します。この要素は、このリモート・サービスがネーム・サービスを使用してプロキシ・サービスを検索する場合にのみ使用します。ネーム・サービスの構成の詳細は、「name-service-addresses」を参照してください。

この値は、プロキシ・サービスの<service-name>値に一致している必要があります。この要素は、このリモート・サービスの<service-name>値がプロキシ・サービスの<service-name>値に一致している場合は省略できます。プロキシ・サービスの定義の詳細は、「proxy-scheme」を参照してください。

<operation-bundling>

オプション

バンドリング戦略の構成情報を指定します。

<initiator-config>

必須

クラスタへの接続を確立するためにサービスで使用される接続イニシエータの構成を記述します。

<defer-key-association-check>

オプション

キー・アソシエーションの処理を、拡張クライアントによって行うか、クラスタ側まで遅延するかを指定します。有効な値は、trueとfalseです。falseはキー・アソシエーションの処理を拡張クライアントによって行うことを示します。この値をtrueに設定する場合、.NETクライアントおよびC++クライアントには、クラスタ・キャッシュ・サーバー上のキー・クラスのパラレルJava実装を含める必要があります。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「RemoteCacheサービスのパラメータ」を参照してください。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

remote-invocation-scheme

使用場所: caching-schemes

説明

remote-invocation-scheme要素には、最初にクラスタに参加せずにクラスタ内でタスクを実行する際に必要な構成情報を記述します。このスキームは、Coherence*Extendを使用してクラスタに接続します。

要素

表B-61で、remote-invocation-scheme要素のサブ要素を説明します。

表B-61 remote-invocation-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

サービスの名前を指定します。

<proxy-service-name>

オプション

このリモート・サービスの接続先のプロキシ・サービス名を指定します。この要素は、このリモート・サービスがネーム・サービスを使用してプロキシ・サービスを検索する場合にのみ使用します。ネーム・サービスの構成の詳細は、「name-service-addresses」を参照してください。

この値は、プロキシ・サービスの<service-name>値に一致している必要があります。この要素は、このリモート・サービスの<service-name>値がプロキシ・サービスの<service-name>値に一致している場合は省略できます。プロキシ・サービスの定義の詳細は、「proxy-scheme」を参照してください。

<initiator-config>

必須

クラスタへの接続を確立するためにサービスで使用される接続イニシエータの構成を記述します。

replicated-scheme

使用場所: caching-schemes、near-scheme、overflow-scheme

説明

レプリケート・スキームは、指定したサービスを実行する各クラスタ・ノードに、すべてのキャッシュ・エントリを完全にレプリケートするキャッシュを定義します。レプリケート・キャッシュの詳細は、「レプリケート・キャッシュの理解」を参照してください。

クラスタ化された並列処理制御

レプリケート・キャッシュでは、クラスタ全体を対象とするキーベースのロック機能がサポートされるため、更新の欠落といった従来の問題を発生させることなく、クラスタ内のデータを変更できます。明示的ロックを行わずに実行された操作もすべてアトミックですが、キャッシュに格納された値がアトミック操作間で変更されない保証はありません。

キャッシュ記憶域(バッキング・マップ)

キャッシュの記憶域はbacking-map-schemeを使用して指定します(<backing-map>サブ要素を参照)。たとえば、バッキング・マップにlocal-schemeを使用するレプリケート・キャッシュでは、キャッシュ・エントリがメモリー内に格納されます。

要素

表B-62で、replicated-scheme要素のサブ要素を説明します。

表B-62 replicated-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

このスキームで作成されたキャッシュを管理するサービス名を指定します。サービスは、tangosol-coherence.xmlファイルの<services>要素で構成します。詳細は、付録A「オペレーション構成の要素」を参照してください。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたservice-priority値です。詳細は、「ReplicatedCacheサービスのパラメータ」を参照してください。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたevent-dispatcher-priority値です。詳細は、「ReplicatedCacheサービスのパラメータ」を参照してください。

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「ReplicatedCacheサービスのパラメータ」のreliable-transportパラメータを参照してください。

<standard-lease-milliseconds>

オプション

標準的なリースの継続時間をミリ秒単位で指定します。リースがこのミリ秒数を超過すると、ロックは自動的に解放されます。期限切れが発生しないリースを指定するには、この値をゼロに設定します。この設定の目的は、スタック・スレッドを原因とするデッドロックまたはブロックが発生しないようにすることです。最長の予想ロック継続時間より高い(たとえば、トランザクション・タイムアウトより高い)値を設定する必要があります。また、packet-delivery/timeout-millisecondsの値より高い値を設定することをお薦めします。有効な値は、桁数の多い正の数値またはゼロです。デフォルト値は、tangosol-coherence.xmlディスクリプタのpacket-delivery/timeout-millisecondsに指定された値です。詳細は、「ReplicatedCacheサービスのパラメータ」を参照してください。

<lease-granularity>

オプション

リース所有権の精度を指定します。有効な値は次のとおりです。

- thread

- member

値がthreadの場合、ロックはそのロックを取得したスレッドによって保持され、そのスレッドによってのみ解放されます。値がmemberの場合、ロックはクラスタ・ノードによって保持され、ロックを取得したクラスタ・ノード上で実行されるスレッドによって解放できます。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたlease-granularity値です。詳細は、「ReplicatedCacheサービスのパラメータ」を参照してください。

<request-timeout>

オプション

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「ReplicatedCacheサービスのパラメータ」のrequest-timeoutパラメータを参照してください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<member-listener>

オプション

com.tangosol.net.MemberListenerインタフェースを実装するクラスの構成情報を指定します。実装には、publicなデフォルト・コンストラクタが必要です。

MemberListener実装は、キャッシュ・サービス・ライフサイクル・イベントを受信します。<member-listener>要素は、サービスでMapListenerをプログラムによって追加するための代替手段として使用されます。

<backing-map-scheme>

オプション

キャッシュ・サーバー内でのエントリの格納に使用するキャッシュのタイプを指定します。有効な値は次のとおりです。

- local-scheme

- external-scheme

- paged-external-scheme

- overflow-scheme

- class-scheme

- flashjournal-scheme

- ramjournal-scheme

キャッシュの一貫性を確保するため、レプリケート・キャッシュのバッキング・マップでは、キャッシュ・エントリのロードにリードスルー・パターンを使用しません。キャッシュ・サービスの外部でキャッシュアサイド・パターンを使用するか、クラスタ化キャッシュのリードスルーをサポートするdistributed-schemeに切り替えます。

<listener>

オプション

キャッシュ上で発生しているイベントの通知を受け取るcom.tangosol.util.MapListenerの実装を指定します。

<autostart>

オプション

autostart要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

resource-config

使用場所: http-acceptor

説明

resource-config要素には、com.sun.jersey.api.core.ResourceConfigクラスを拡張するクラスの構成情報を記述します。このインスタンスは、HTTPアクセプタが、指定されたコンテキスト・パスにマップされたCoherence RESTアプリケーション用のリソース・クラスおよびプロバイダ・クラスをロードする際に使用されます。複数のリソース構成クラスを構成して、別々のコンテキスト・パスにマップできます。

要素

表B-63で、resource-config要素のサブ要素を説明します。

表B-63 resource-configのサブ要素

要素

必須/
オプション

説明

<context-path>

オプション

RESTアプリケーションのルートURIパスを指定します。パスの先頭の文字は/である必要があります。デフォルト値は/です。

<instance>

オプション

com.sun.jersey.api.core.ResourceConfigクラスを拡張するクラスの構成情報を記述します。デフォルトのインスタンスは、com.tangosol.coherence.rest.server.DefaultResourceConfigクラスです。

serializer

使用場所: acceptor-config、defaults、distributed-scheme、initiator-config、invocation-scheme、optimistic-scheme、replicated-scheme、transactional-scheme

説明

serializer要素には、com.tangosol.io.Serializer実装のクラス構成情報を記述します。

serializer要素は、シリアライザ構成への参照またはシリアライザのフル構成のいずれかを受け入れます。ベスト・プラクティスは、オペレーション構成ファイルで定義されている構成を参照する方法です。オペレーション構成ファイルには、Java用(デフォルト)とPOF用の2つのシリアライザ・クラス構成が含まれています。「serializer」を参照してください。

次の例では、オペレーション構成ファイル内のPOFシリアライザ定義を参照しています。

...
<serializer>pof</serializer>
...

次の例は、フル・シリアライザ・クラス構成を示します。

...
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>my-pof-config.xml</param-value>
</init-param>
</init-params>
</instance>
</serializer>
...

要素

表B-64で、serializer要素のサブ要素を説明します。

表B-64 serializerのサブ要素

要素

必須/
オプション

説明

<instance>

オプション

com.tangosol.io.Serializer実装のクラス構成情報を記述します。

socket-address

使用場所: address-provider、remote-addresses

説明

socket-address要素は、TCP/IPアクセプタがリスニングを行うアドレスとポートを指定します。

要素

表B-65で、socket-address要素のサブ要素を説明します。

表B-65 socket-addressのサブ要素

要素

必須/
オプション

説明

<address>

必須

TCP/IPアクセプタ・ソケットがリスニングを行うIPアドレス(IPまたはDNS名)を指定します。アドレスがバインド・アドレスである場合、そのアドレスはサブネットおよびマスクとしてCIDR注釈を使用して(たとえば192.168.1.0/24と)入力することもでき、それにより、使用可能なローカルIPアドレスに対するランタイム解決が可能になります。

<port>

必須

TCP/IPアクセプタ・ソケットがリスニングを行うポートを指定します。有効な値は1から65535です。

socket-provider

使用場所: tcp-acceptor、tcp-initiator、defaults、ssl、memcached-acceptor

説明

<socket-provider>要素には、ソケットおよびチャンネル・ファクトリの構成情報を記述します。<tcp-acceptor>要素および<tcp-initiator>要素内で構成されるソケット・プロバイダは、Coherence*Extendで使用されます。<http-acceptor>要素内で構成されたソケット・プロバイダは、Coherence RESTによって使用されます。<memcached-acceptor>要素内で構成されたソケット・プロバイダは、memcachedクライアントによって使用されます。TCMPのソケット・プロバイダは、オペレーション・オーバーライドにおいて、<unicast-listener>要素内で構成されます。

<socket-provider>要素は、ソケット・プロバイダ構成への参照またはソケット・プロバイダのフル構成のいずれかを受け入れます。ベスト・プラクティスは、オペレーション構成ファイルで定義されている構成を参照する方法です。「socket-provider」を参照してください。使用可能なソケット・プロバイダは、system (デフォルト)、ssl、tcpおよびsdpです。ソケット・プロバイダ構成は、id属性名を使用して参照されます。次の例は、事前定義のSSLソケット・プロバイダ構成を参照します。

<socket-provider>ssl</socket-provider>

事前構成済オーバーライド値はtangosol.coherence.socketproviderです。

要素

表B-66は、socket-provider要素で定義可能なサブ要素について説明しています。

表B-66 socket-providerのサブ要素

要素

必須/
オプション

説明

<system>

オプション

JVMのデフォルトのソケットおよびチャンネル実装のインスタンスを作成するソケット・プロバイダを指定します。

<ssl>

オプション

SSLを使用するソケットおよびチャンネル実装を作成するソケット・プロバイダを指定します。

<tcp>

オプション

TCPベースのソケットおよびチャンネル実装を生成するソケット・プロバイダを指定します。

<sdp>

オプション

JVMおよび基礎となるネットワーク・スタックでSDPがサポートされている場合、SDPベースのソケットおよびチャネルの実装を生成するソケット・プロバイダを指定します。

ssl

使用場所: socket-provider

説明

<ssl>要素には、SSLを使用するソケットおよびチャンネル実装を作成するソケット・プロバイダの構成情報を記述します。

要素

表B-67は、ssl要素で定義可能なサブ要素について説明しています。

表B-67 sslのサブ要素

要素

必須/
オプション

説明

<protocol>

オプション

SSLソケット・プロバイダによって作成されたソケットおよびチャンネル実装が使用するプロトコルの名前を指定します。デフォルト値はTLSです。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<executor>

オプション

java.util.concurrent.Executorインタフェースの実装の構成情報を指定します。

<class-name>サブ要素は、Executorインタフェースを実装するクラスの名前を提供するために使用されます。代替策としては、<class-factory-name>サブ要素で、Executorインスタンスおよび(オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定する)<method-name>サブ要素を作成するためのファクトリ・クラスを指定できます。いずれの方法でも、<init-params>要素を使用して初期化パラメータを指定できます。

<identity-manager>

オプション

アイデンティティ・マネージャ・インスタンスを初期化するための構成情報を指定します。

<trust-manager>

オプション

トラスト・マネージャ・インスタンスを初期化するための構成情報を指定します。

<hostname-verifier>

オプション

javax.net.ssl.HostnameVerifierインタフェースの実装の構成情報を指定します。SSLハンドシェイク時に、URLのホスト名とサーバーの識別ホスト名が一致しない場合、検証メカニズムによってこのインスタンスがコールバックされ、接続を許可するかどうかが決定されます。

<class-name>サブ要素は、HostnameVerifierインタフェースを実装するクラスの名前を提供するために使用されます。代替策としては、<class-factory-name>サブ要素で、HostnameVerifierインスタンスおよび(オブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドの名前を指定する)<method-name>サブ要素を作成するためのファクトリ・クラスを指定できます。いずれの方法でも、<init-params>要素を使用して初期化パラメータを指定できます。

<socket-provider>

オプション

SSLの委譲プロバイダの構成情報を指定します。有効な値は、tcpおよびsdpです。デフォルト値はtcpです。

tcp-acceptor

使用場所: acceptor-config

説明

tcp-acceptor要素は、Coherence*ExtendクライアントからのTCP/IPを介した接続を受け入れる接続アクセプタの構成情報を指定します。詳細および構成例については、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

要素

表B-68で、tcp-acceptor要素のサブ要素を説明します。

表B-68 tcp-acceptorのサブ要素

要素

必須/
オプション

説明

<socket-provider>

オプション

ソケットおよびチャンネル・ファクトリの構成を指定します。

<local-address>

オプション

TCP/IPサーバー・ソケット(接続アクセプタによって開かれる)がバインドされるローカル・アドレス(IPまたはDNS名およびポート)を指定します。

<address-provider>

オプション

TCP/IPサーバー・ソケットがバインドされるローカル・アドレス(IPまたはDNS名およびポート)またはプログラムでソケット・アドレスを提供するcom.tangosol.net.AddressProviderインタフェースの実装のいずれかを指定します。address-provider要素では、ソケット・アドレス参照もサポートされています。

<tcp-acceptor>要素には、<local-address>要素または<address-provider>要素のいずれかを含めることができますが、両方を含めることはできません。

<reuse-address>

オプション

TCP/IPソケットを、現在使用しているアドレスまたは最近使用したアドレスにバインドできるかどうかを指定します。

オペレーティング・システムの実装によって結果の動作が大きく異なるため、この設定は非推奨です。JVMでは一般に、ターゲットのオペレーティング・システムに対して安全とされる適切なデフォルト設定が選択されます。

有効な値は、trueとfalseです。デフォルト値はオペレーティング・システムによって異なります。

<keep-alive-enabled>

オプション

SO_KEEPALIVEオプションが、TCP/IPソケットで有効にされているかどうかを示します。SO_KEEPALIVEオプションは、アイドル・ソケットを検出し、ソケットを閉じるかどうかを決定します。有効な値は、trueとfalseです。デフォルト値はtrueです。

<tcp-delay-enabled>

オプション

TCP遅延(Nagleアルゴリズム)が、TCP/IPソケットで有効にされているかどうかを示します。有効な値は、trueとfalseです。デフォルトでは、TCP遅延は無効です。

<receive-buffer-size>

オプション

基礎となるTCP/IPソケット・ネットワーク受信バッファのサイズを構成します。受信バッファ・サイズを増やすと、大量の接続におけるネットワークI/Oのパフォーマンスが向上します。受信バッファ・サイズを減らすと、未処理の受信データが削減されます。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は、オペレーティング・システムに依存します。

<send-buffer-size>

オプション

基礎となるTCP/IPソケット・ネットワーク送信バッファのサイズを構成します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は、オペレーティング・システムに依存します。

<listen-backlog>

オプション

TCP/IPサーバー・ソケットの未処理キューのサイズを構成します。有効値は正の整数です。デフォルト値は、オペレーティング・システムに依存します。

<linger-timeout>

オプション

TCP/IPソケットのSO_LINGERオプションの値を指定します。SO_LINGERオプションは、ソケットを強制的に閉じるまでの待機時間を制御します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。デフォルト値は-1であり、これにより遅延タイムアウトは無効化されます。遅延タイムアウトは、この値がゼロよりも大きい場合にのみ設定されます。

<authorized-hosts>

オプション

このTCP/IPアクセプタへの接続が許可される、TCP/IPイニシエータ・ホストのIPアドレス・コレクションです。

<suspect-protocol-enabled>

オプション

不正なCoherence*Extendクライアント接続を検出して閉じるため、疑いのあるプロトコルを有効にするかどうかを指定します。疑いのあるプロトコルはデフォルトで有効です。

有効な値は、trueとfalseです。

<suspect-buffer-size>

オプション

対応するクライアント接続が疑いありとマークされるまでの送信接続バックログ(バイト単位)を指定します。疑いのあるクライアント接続は、疑いがなくなるまで、またはメモリー不足からプロキシ・サーバーを保護するためにその接続が閉じられるまでモニターされます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は10000000です。

<suspect-buffer-length>

オプション

対応するクライアント接続が疑いありとマークされるまでの送信接続バックログ(メッセージ単位)を指定します。疑いのあるクライアント接続は、疑いがなくなるまで、またはメモリー不足からプロキシ・サーバーを保護するためにその接続が閉じられるまでモニターされます。デフォルト値は10000です。

<nominal-buffer-size>

オプション

その時点で疑いのあるクライアント接続の疑いが晴れたと見なされる送信接続バックログ(バイト単位)を指定します。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は2000000です。

<nominal-buffer-length>

オプション

その時点で疑いのあるクライアント接続の疑いが晴れたと見なされる送信接続バックログ(メッセージ単位)を指定します。デフォルト値は2000です。

<limit-buffer-size>

オプション

メモリー不足からプロキシ・サーバーを保護するため、その時点で対応するクライアント接続を閉じる必要のある送信接続バックログ(バイト単位)を指定します。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt (テラ、2^40)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は100000000です。

<limit-buffer-length>

オプション

メモリー不足からプロキシ・サーバーを保護するため、その時点で対応するクライアント接続を閉じる必要のある送信接続バックログ(メッセージ単位)を指定します。デフォルト値は60000です。

tcp-initiator

使用場所: initiator-config

説明

tcp-initiator要素は、Coherence*Extendクライアントからリモート・クラスタへのTCP/IPを介した接続を有効にする接続イニシエータの構成情報を指定します。詳細および構成例については、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

要素

表B-69で、tcp-initiator要素のサブ要素を説明します。

表B-69 tcp-initiatorのサブ要素

要素

必須/
オプション

説明

<socket-provider>

オプション

ソケットおよびチャンネル・ファクトリの構成を指定します。

<local-address>

オプション

TCP/IPクライアント・ソケット(TCP/IPイニシエータによって開かれる)がバインドされるローカル・アドレス(IPまたはDNS名およびポート)を指定します。

<name-service-addresses>

オプション

1つ以上のネーム・サービスTCP/IPアクセプタのアドレス(IPまたはDNS名およびポート)を記述します。TCP/IP接続イニシエータは、この情報を使用してリモート・クラスタとの接続を確立します。

この要素は、リモート・アドレスの構成にremote-addresses要素が使用されている場合は使用できません。

<remote-addresses>

オプション

1つ以上のTCP/IP接続アクセプタのアドレス(IPまたはDNS名およびポート)を記述します。TCP/IP接続イニシエータは、この情報を使用してリモート・クラスタとの接続を確立します。

この要素は、name-service-addresses要素が使用されている場合は使用できません。

<reuse-address>

オプション

TCP/IPソケットを、現在使用しているアドレスまたは最近使用したアドレスにバインドできるかどうかを指定します。

オペレーティング・システムの実装によって結果の動作が大きく異なるため、この設定は非推奨です。JVMでは一般に、ターゲットのオペレーティング・システムに対して安全とされる適切なデフォルト設定が選択されます。

有効な値は、trueとfalseです。デフォルト値はオペレーティング・システムによって異なります。

<keep-alive-enabled>

オプション

SO_KEEPALIVEオプションが、TCP/IPソケットで有効にされているかどうかを示します。SO_KEEPALIVEオプションは、アイドル・ソケットを検出し、ソケットを閉じるかどうかを決定します。有効な値は、trueとfalseです。デフォルト値はtrueです。

<tcp-delay-enabled>

オプション

TCP遅延(Nagleアルゴリズム)が、TCP/IPソケットで有効にされているかどうかを示します。有効な値は、trueとfalseです。デフォルトでは、TCP遅延は無効です。

<receive-buffer-size>

オプション

基礎となるTCP/IPソケット・ネットワーク受信バッファのサイズを構成します。受信バッファ・サイズを増やすと、大量の接続におけるネットワークI/Oのパフォーマンスが向上します。受信バッファ・サイズを減らすと、未処理の受信データが削減されます。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は、オペレーティング・システムに依存します。

<send-buffer-size>

オプション

基礎となるTCP/IPソケット・ネットワーク送信バッファのサイズを構成します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は、オペレーティング・システムに依存します。

<connect-timeout>

オプション

非推奨です。<connect-timeout>要素は、<initiator-config>要素内で指定されるようになりました。

<linger-timeout>

オプション

TCP/IPソケットのSO_LINGERオプションの値を指定します。SO_LINGERオプションは、ソケットを強制的に閉じるまでの待機時間を制御します。この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。デフォルト値は-1であり、これにより遅延タイムアウトは無効化されます。遅延タイムアウトは、この値がゼロよりも大きい場合にのみ設定されます。

transactional-scheme

使用場所: caching-schemes

説明

transactional-scheme要素は、トランザクションを保証する専用の分散キャッシュであるトランザクション・キャッシュを定義します。複数のtransactional-scheme要素を定義して様々な構成をサポートできます。アプリケーションは、次の3つのうちのいずれかの方法でトランザクション・キャッシュを使用します。

- アプリケーションは、CacheFactory.getCache()メソッドを使用して、トランザクション・キャッシュのインスタンスを取得します。この場合、キャッシュ操作を行う際、暗黙にトランザクションが保証されます。ただし、デフォルトのトランザクション動作を変更することはできません。

- アプリケーションは、明示的にトランザクション・フレームワークAPIを使用して、トランザクション・キャッシュを使用するConnectionインスタンスを作成します。この場合、キャッシュ操作はトランザクション内で行われ、アプリケーションは必要に応じてデフォルトのトランザクション動作の変更をすべて制御できます。

- Java EEアプリケーションは、Coherenceリソース・アダプタを使用して、トランザクション・キャッシュを使用するトランザクション・フレームワークAPIのConnectionインスタンスを作成します。この場合、キャッシュ操作は、分散(グローバル)トランザクションの一部として参加できるトランザクション内で実行されます。アプリケーションは、一部のデフォルト・トランザクション動作を変更できます。

要素

表B-70で、transactional-scheme要素のサブ要素を説明します。

表B-70 transactional-schemeのサブ要素

要素

必須/
オプション

説明

<scheme-name>

オプション

スキームの名前を指定します。この名前は構成ファイル内で一意である必要があります。

<scheme-ref>

オプション

継承元の別のスキーム名を指定します。詳細は、「スキームの継承の使用」を参照してください。

<service-name>

オプション

このスキームで作成されたキャッシュを管理するサービス名を指定します。サービス名が指定されていない場合のデフォルト・サービス名はTransactionalCacheです。

<service-priority>

オプション

サービス・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

<event-dispatcher-priority>

オプション

各サービスのイベント・ディスパッチャ・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は10です。

<serializer>

オプション

ユーザー定義型のシリアライズおよびデシリアライズに使用するcom.tangosol.io.Serializer実装のクラス構成情報を指定するか、またはオペレーション構成ファイルで定義されているシリアライザ・クラス構成を参照します(「serializer」を参照)。

<reliable-transport>

オプション

信頼性の高いポイントツーポイント通信を実現するためにこのサービスで使用されるトランスポート・プロトコルを指定します。<unicast-listener>要素で定義される共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスを使用することを示す値を指定します。サービス固有のトランスポート・インスタンスを使用すると、パフォーマンスは向上しますが、リソース消費が増加するため、優先度の高い重要なサービスではあまり使用されません。一般に、共有トランスポート・インスタンスはサービス固有のトランスポート・インスタンスよりもリソース使用量が少なくてすみます。有効な値は次のとおりです。

- datagram – UDPプロトコル

- tmb – TCP/IPメッセージ・バス・プロトコル

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSには、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- sdmb – ソケット・ダイレクト・プロトコル(SDP)メッセージ・バス。SDMBは、Oracle Exalogicシステムでのみ使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。「socket-provider」を参照してください。

- imb (Exalogicのデフォルト) – InfiniBandメッセージ・バス。IMBはOracle Exalogicシステムでのみ使用でき、TCMPがSSLとあわせて構成されていないかぎり自動的に使用されます。

デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された<reliable-transport>値です。詳細は、「DistributedCacheサービスのパラメータ」のreliable-transportパラメータを参照してください。

<thread-count>

オプション

パーティション・キャッシュ・サービスで使用されるデーモン・スレッドの数を指定します。有効な値は、正の整数、0または-1です。値0は、すべての関連するタスクがそのサービス・スレッドで実行されることを示します。値-1は、可能な場合はタスクがコール元のスレッドで実行されることを示します。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたthread-count値です。詳細は、「DistributedCacheサービスのパラメータ」のthread-countパラメータを参照してください。

スレッド数を指定すると、トランザクション記憶域およびリカバリに使用されるトランザクション・フレームワークの内部トランザクション・キャッシュのデフォルト動作が変更されます。

<worker-priority>

オプション

ワーカー・スレッドの優先度を指定します。有効な値は1から10の範囲で、10が最も高い優先度です。デフォルト値は5です。

<local-storage>

オプション

クラスタ・ノードをクラスタの記憶域として機能させる(つまり、パーティションを保持する)かどうかを指定します。無効化した場合、そのノードはキャッシュ・クライアントと見なされます。

通常、構成ファイル内ではこの値を未指定にしておき、システム・プロパティtangosol.coherence.distributed.localstorageを使用し、プロセスごとに設定します。これによって、キャッシュ・クライアントとキャッシュ・サーバーは、同じ構成ディスクリプタを使用できます。

有効な値は、trueまたはfalseです。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたlocal-storage値です。詳細は、「DistributedCacheサービスのパラメータ」のlocal-storageパラメータを参照してください。

<partition-count>

オプション

パーティション(分散)キャッシュを分割するパーティションの数を指定します。パーティション・キャッシュ・サービスを実行し、local-storage(<local-storage>サブ要素)オプションがtrueに設定されたメンバーのそれぞれが、公平な(偏りのない)数のパーティションを管理します。

パーティションの数は素数とし、いずれのパーティションも50MBを超えることのないように十分なパーティション数を指定する必要があります。

次に、サンプルのサービス記憶域サイズの適切なデフォルト設定を示します。

service storage     partition-count
_______________     ______________
100M                  257
1G                  509
10G                 2039
50G                 4093
100G                 8191

最初の1,000個の素数のリストについては、次のサイトを参照してください。

http://primes.utm.edu/lists/

有効値は正の整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「DistributedCacheサービスのパラメータ」のpartition-countパラメータを参照してください。

<high-units>

オプション

トランザクション記憶域のサイズを指定します。トランザクション記憶域のサイズに達すると、エビクション・ポリシーが適用され、記憶域から使用可能なエントリの25%が削除されます。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]?

前述の文字は(左から右へ)それぞれ、先行する10進数値に乗じる係数を示しています。

- Kまたはk(キロ、2^10)

- Mまたはm(メガ、2^20)

- Gまたはg(ギガ、2^30)

- Tまたはt(テラ、2^40)

値に係数が含まれていない場合は、1が係数として適用されます。デフォルト値は10MBです。

<transfer-threshold>

オプション

プライマリ・バケット分散のしきい値をキロバイト単位で指定します。パーティション・キャッシュ・サービスに新しいノードが結合する場合、またはサービスのメンバーのいずれかの結合が解除される場合、残りのノードによって、バケット所有権の再分散タスクが実行されます。このプロセスでは、所有権情報とともに既存のデータの均衡化が再実行されます。このパラメータでは、データ転送通信で優先されるメッセージ・サイズを示します。この値を低く設定すると、分散プロセスの所要時間は長くなりますが、このアクティビティ実行中のネットワーク帯域幅の使用量は軽減されます。有効な値は、ゼロより大きな整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtransfer-threshold値です。詳細は、「DistributedCacheサービスのパラメータ」のtransfer-thresholdパラメータを参照してください。

<backup-count>

オプション

パーティション・キャッシュ・サービスのうち、各保存単位のバックアップ・データをキャッシュに保持するメンバーの数を指定します。この値が0になっていると、異常終了した場合にキャッシュ内のデータの一部が失われます。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたbackup-count値です。tangosol-coherence.xmlディスクリプタに指定されたbackup-countパラメータの値を参照してください。詳細は、「DistributedCacheサービスのパラメータ」を参照してください。

<partition-assignment-strategy>

オプション

パーティション・サービスでパーティション分散を管理する際に使用する戦略を指定します。有効な値は、legacy、simpleまたはcom.tangosol.net.partition.PartitionAssignmentStrategyインタフェースを実装するクラスです。レガシー割当て戦略では、パーティション分散は各クラスタ・メンバーで個々に管理されます。単純な戦略は、マシンの安全性を確保しながらパーティション分散のバランスを取ることを試みる集中管理型分散戦略であり、レガシー戦略よりも決定論的で効率的です。デフォルト値はsimpleです。カスタム戦略は、<instance>要素を使用して指定します。

<task-hung-threshold>

オプション

タスクが実行できる時間をミリ秒単位で指定します。この時間を超過すると、ハングしたと見なされます。注意: ポストされたタスクがまだ開始されていない場合は、ハングと見なされません。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定されたtask-hung-threshold値です。詳細は、「DistributedCacheサービスのパラメータ」のtask-hung-thresholdパラメータを参照してください。

<task-timeout>

オプション

サービス・ワーカー・スレッド上で実行するリクエストのタイムアウト値をミリ秒単位で指定します。この属性は、スレッド・プールが使用されている(thread-countの値が正数である)場合にのみ適用されます。zeroが指定された場合は、デフォルトのservice-guardian <timeout-milliseconds>値が使用されます。有効な値は正の整数です。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。「DistributedCacheサービスのパラメータ」のtask-timeoutパラメータを参照してください。

<request-timeout>

オプション

レスポンスがくるまでクライアントが待機する最大時間を指定します。この時間を超過すると、元のリクエストが破棄されます。リクエスト時間はクライアント側で測定されるもので、対応するサーバー・ノードに対して実行のためのリクエストが送信されてからの経過時間に次の時間を加えたものです。

- 実行側のノード(サーバー)にリクエストを配信するための所要時間

- タスクが受信されてサービス・キューに入れられてから実行が開始されるまでの間隔

- タスクの実行時間

- クライアントに結果を返信するための所要時間

有効な値は、正の整数またはゼロです(ゼロの場合は、デフォルト・タイムアウトがないことを示します)。デフォルト値は、tangosol-coherence.xmlディスクリプタに指定された値です。詳細は、「DistributedCacheサービスのパラメータ」のrequest-timeoutパラメータを参照してください。

<guardian-timeout>

オプション

サービスおよび依存するスレッドをガードするために使用するガーディアンのタイムアウト値を指定します。指定のサービスに対して要素が指定されていない場合、デフォルトのガーディアンのタイムアウト(<timeout-milliseconds>オペレーション構成要素で指定)が使用されます。<service-guardian>を参照してください。

この要素の値は、次の形式で指定する必要があります。

(\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]?

前述の文字は(左から右へ)それぞれ、次の時間間隔の単位を示しています。

- MSまたはms(ミリ秒)

- Sまたはs(秒)

- Mまたはm(分)

- Hまたはh(時)

- Dまたはd(日数)

値に単位が含まれていない場合は、ミリ秒が単位として適用されます。

<service-failure-policy>

オプション

動作が異常なサービス・スレッドをサービス・ガーディアンが正常に終了できないときに実行するアクションを指定します。

有効な値は次のとおりです。

- exit-cluster - (デフォルト)応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。

- exit-process - 応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。

- logging - 検出された問題をログに記録しますが、修正処置は実行されません。

- カスタム・クラス - <instance>のサブ要素が使用されて、com.tangosol.net.ServiceFailurePolicy実装のクラス構成情報が提供されます。

<partitioned-quorum-policy-scheme>

オプション

パーティション・キャッシュ・サービス用のクォーラム・ポリシー設定を指定します。

<autostart>

オプション

この要素は、キャッシュ・サーバー(つまり、com.tangosol.net.DefaultCacheServer)で使用することを目的としています。この要素は、このキャッシュ・スキームに関連付けられたキャッシュ・サービスをクラスタ・ノードで自動的に起動するかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

trust-manager

使用場所: ssl

説明

<trust-manager>要素には、javax.net.ssl.TrustManagerインスタンスを初期化するための構成情報を記述します。

トラスト・マネージャは、信頼の決定を行う際に使用されるトラスト・マテリアルを管理し、ピアが提示した資格証明を受け入れるかどうかを決定します。

有効なtrust-manager構成には、少なくとも1つの子要素が記述されます。

要素

表B-71は、trust-manager要素で定義可能なサブ要素について説明しています。

表B-71 trust-managerのサブ要素

要素

必須/
オプション

説明

<algorithm>

オプション

トラスト・マネージャによって使用されるアルゴリズムを指定します。デフォルト値はSunX509です。

<provider>

オプション

セキュリティ・プロバイダ・インスタンスの構成を指定します。

<key-store>

オプション

キー・ストア実装の構成を指定します。

属性リファレンス

表B-72で、キャッシュ構成デプロイメント・ディスクリプタで使用可能なシステム・プロパティ属性を説明します。

表B-72 キャッシュ構成デプロイメント・ディスクリプタの属性

属性

必須/
オプション

説明

system-property

オプション

この属性は、任意の要素のシステム・プロパティ名を指定するために使用します。システム・プロパティは、Javaコマンド行から要素の値をオーバーライドする際に使用します。この機能により、すべてのクラスタ・ノードで同じオペレーション・ディスクリプタ(およびオーバーライド・ファイル)を使用し、システム・プロパティで各ノードをカスタマイズできます。この機能の詳細は、付録D「システム・プロパティのオーバーライド」を参照してください。

C POFユーザー定義型の構成要素

この付録では、POF構成デプロイメント・ディスクリプタのリファレンスと、ディスクリプタの簡単な概要を示します。バイナリ形式の詳細は、付録E「PIF-POFバイナリ形式」を参照してください。

この付録では次の項について説明します。

- POF構成デプロイメント・ディスクリプタ

- 要素の索引

C.1 POF構成デプロイメント・ディスクリプタ

POF構成デプロイメント・ディスクリプタは、POFを使用してシリアライズおよびデシリアライズされているオブジェクトの非固有の型(ユーザー定義型)を指定するために使用します。POF構成デプロイメント・ディスクリプタの名前と場所はオペレーション・デプロイメント・ディスクリプタで指定され、pof-config.xmlにデフォルト設定されます。サンプルのPOF構成ディスクリプタがcoherence.jarライブラリのルートに配置されており、アプリケーションのクラスパス内でcoherence.jarファイルより前にカスタムのpof-config.xmlファイルが検出されないかぎり、これが使用されます。すべてのクラスタ・メンバーで使用するPOF構成デプロイメント・ディスクリプタを統一してください。

POF構成デプロイメント・ディスクリプタ・スキーマは、coherence-pof-config.xsdファイルで定義します。このXSDファイルは、coherence.jarライブラリのルートおよび次のWeb URLにあります。

http://xmlns.oracle.com/coherence/coherence-pof-config/1.2/coherence-pof-config.xsd

<pof-config>要素はPOF構成デプロイメント・ディスクリプタのルート要素であり、通常はXSDおよびCoherenceネームスペース・リファレンスと、coherence-pof-config.xsdファイルの場所が含まれます。例:

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">

注意:

- coherence.jarライブラリにあるスキーマは、xsi:schemaLocation属性がWeb URLを参照する場合であっても、常に実行時に使用されます。

- xsi:schemaLocation属性を省略すると、スキーマ検証を無効にできます。

- デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、デプロイメント・ディスクリプタ・ファイルがASCII形式であり、ランタイム環境にバイナリ形式でデプロイされることを確認してください。

Coherenceに固有のユーザー定義型は、同じくcoherence.jarライブラリのルートにあるcoherence-pof-config.xmlファイルで定義します。pof-config.xmlファイルを作成するときは、このファイルを次のように参照する必要があります。

<?xml version='1.0'?>

<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-pof-config.xml</include>
</user-type-list>
...
</pof-config>

要素の索引

表C-1は、POF構成デプロイメント・ディスクリプタのすべての非終端要素を示しています。

表C-1 POFの構成要素

要素

使用場所

default-serializer

pof-config

init-param

init-params

init-params

serializer

pof-config

ルート要素

serializer

user-type

user-type

user-type-list

user-type-list

pof-config

default-serializer

使用場所: pof-config

説明

この要素は、pof-config要素内で定義されるすべてのユーザー定義型のシリアライズおよびデシリアライズの際に使用するPofSerializerを指定します。シリアライザがuser-type内に指定されている場合、そのユーザー定義型にはデフォルトのシリアライザのかわりにそのシリアライザが使用されます。

default-serializer要素を省略すると、特定のユーザー定義型に対して定義されたシリアライザが使用されます。そのユーザー定義型のserializer要素も省略すると、ユーザー定義型によってPortableObjectインタフェースが実装され、PortableObjectSerializer実装がPofSerializerとして使用されることになります。

default-serializer要素からinit-params要素を省略した場合は、そのPofSerializer実装に対して次の4つのコンストラクタが、ここに示された順序で試行されます。

- (int nTypeId, Class clz, ClassLoader loader)

- (int nTypeId, Class clz)

- (int nTypeId)

- ()

要素

表C-2で、default-serializer要素のサブ要素を説明します。

表C-2 default-serializerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

PofSerializer実装の完全修飾名を指定します。

<init-params>

オプション

(それぞれがinit-paramとして)ゼロ個以上の引数を指定し、それらの引数は、構成されているクラスのコンストラクタのパラメータに対応します。

init-param

使用場所: init-params

説明

init-param要素では、構成パラメータの型、および引数として渡す対応値を指定します。

要素

表C-3は、init-param要素のサブ要素を示しています。

表C-3 init-paramのサブ要素

要素

必須/
オプション

説明

<param-type>

必須

param-type要素は、初期化パラメータのJavaタイプを指定します。サポートされているタイプは次のとおりです。

- string: 値がjava.lang.Stringであることを示します。

- boolean: 値がjava.lang.Booleanであることを示します。

- int: 値がjava.lang.Integerであることを示します。

- long: 値がjava.lang.Longであることを示します。

- double: 値がjava.lang.Doubleであることを示します。

- decimal: 値がjava.math.BigDecimalであることを示します。

- file: 値がjava.io.Fileであることを示します。

- date: 値がjava.sql.Dateであることを示します。

- time: 値がjava.sql.Timedatetimeであることを示します。

- datetime: 値がjava.sql.Timestampであることを示します。

- xml: 値がinit-param XmlElement全体であることを示します。

値は指定された型に変換されます。インスタンス化を正常に実行するには、ターゲットのコンストラクタまたはメソッドにその型のパラメータが存在している必要があります。

<param-value>

必須

param-value要素は、初期化パラメータの値を指定します。この値は、パラメータの型に固有の形式にします。指定できる値が4つ予約されています。これらの値がそれぞれ、実行時に特定の値に置換されてから、コンストラクタが起動されます。

- {type-id}: ユーザー定義型のタイプIDに置換されます。

- {class-name}: ユーザー定義型のクラスの名前に置換されます。

- {class}: ユーザー定義型のクラスに置換されます。

- {class-loader}: ConfigurablePofContextのContextClassLoaderに置換されます。

init-params

使用場所: serializer、default-serializer

説明

init-params要素には、(それぞれがinit-paramとして)ゼロ個以上の引数を記述し、それらの引数は、構成されているクラスのコンストラクタのパラメータに対応します。

要素

表C-4は、init-params要素のサブ要素を示しています。

表C-4 init-paramsのサブ要素

要素

必須/
オプション

説明

<init-param>

必須

init-param要素では、構成パラメータの型、および引数として渡す対応値を指定します。

pof-config

ルート要素

説明

pof-config要素は、POFユーザー定義型のディスクリプタのルート要素です。

要素

表C-5で、pof-config要素のサブ要素を説明します。

表C-5 pof-configのサブ要素

要素

必須/
オプション

説明

<user-type-list>

必須

user-type-list要素には、ゼロ個以上のuser-type要素を記述します。使用されるPOFユーザー定義型はそれぞれ、user-type-listに一覧表示されている必要があります。user-type-list要素には、ゼロ個以上のinclude要素も記述できます。それぞれのinclude要素は、別のpof-configファイルで定義されたuser-type要素の追加に使用されます。

<allow-interfaces>

オプション

allow-interfaces要素は、user-type class-nameでJavaクラス・タイプ以外にJavaインタフェース・タイプも指定できるかどうかを示します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<allow-subclasses>

オプション

allow-subclasses要素は、user-type class-nameで抽象的なJavaクラス・タイプを指定できるかどうか、および、指定したuser-type class-nameのサブクラスが実行時に許可され、シリアライザの取得を目的として指定したスーパークラスに自動的にマップされるかどうかを示します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<enable-references>

オプション

enable-references要素は、Identity/Reference型のサポートを有効にするかどうかを指定します。有効な値は、trueまたはfalseです。デフォルト値はfalseです。

<default-serializer>

オプション

default-serializerは、POF構成ファイルで定義されたすべてのユーザー定義型のシリアライズおよびデシリアライズに使用するシリアライザを指定します。特定のシリアライザが定義されているuser-typeでは、デフォルトのシリアライザのかわりに、そのシリアライザが使用されます。

serializer

使用場所: user-type

説明

serializer要素は、特定のユーザー定義型のシリアライズおよびデシリアライズに使用するPOFシリアライザを指定します。PofSerializer実装は、POFストリームとの間でのユーザー定義型の値のシリアライズおよびデシリアライズに使用されます。

serializer要素を省略すると、ユーザー定義型によってPortableObjectインタフェースが実装され、PortableObjectSerializer実装がPOFシリアライザとして使用されることになります。POF注釈を使用する場合は、PofAnnotationSerializer実装がPOFシリアライザとして使用されます。

init-params要素を省略した場合は、そのPofSerializer実装に対して次の4つのコンストラクタが、ここに示された順序で試行されます。

- (int nTypeId, Class clz, ClassLoader loader)

- (int nTypeId, Class clz)

- (int nTypeId)

- ()

要素

表C-6で、serializer要素のサブ要素を説明します。

表C-6 serializerのサブ要素

要素

必須/
オプション

説明

<class-name>

必須

PofSerializer実装の完全修飾名を指定します。

<init-params>

オプション

init-params要素には、(それぞれがinit-paramとして)ゼロ個以上の引数を記述し、それらの引数は、構成されているクラスのコンストラクタのパラメータに対応します。

user-type

使用場所: user-type-list

説明

user-type要素には、POFユーザー定義型の宣言を記述します。POFユーザー定義型は、一意の識別、移植、バージョニングが可能なオブジェクト・クラスで、言語、オペレーティング・システム、ハードウェアおよび場所に関係なく、システム間で通信できます。

user-type要素の中ではtype-id要素を省略できますが、スキーマのバージョニングおよび進化をサポートできるように、使用することを強くお薦めします。

user-type要素の中にはclass-name要素が必要であり、ユーザー定義型のすべての値にタイプの割当てが可能なJavaクラスまたはJavaインタフェースの完全修飾名を指定します。

serializer要素を省略すると、ユーザー定義型によってPortableObjectインタフェースが実装され、PortableObjectSerializer実装がPofSerializerとして使用されることになります。

要素

表C-7で、user-type要素のサブ要素を説明します。

表C-7 user-typeのサブ要素

要素

必須/
オプション

説明

<type-id>

オプション

type-id要素は、ユーザー定義型を一意に識別する整数値(n >= 0)を指定します。user-type要素のいずれもtype-id要素を記述していない場合には、ユーザー定義型の型IDは、user-type-listに表示される順序に基づきます。そこでは、最初に割り当てられるユーザー定義型の型IDが0、2番目に割り当てられるユーザー定義型の型IDが1になります(以下同様)。ただし、スキーマのバージョニングおよび進化をサポートできるように、ユーザー定義型のIDを常に指定することを強くお薦めします。最初の1000個のIDは、Coherenceの内部使用に予約されているため、使用できません。

<class-name>

必須

class-name要素は、ユーザー定義型のすべての値にタイプの割当てが可能なJavaクラスまたはJavaインタフェースの完全修飾名を指定します。

<serializer>

オプション

serializer要素は、特定のユーザー定義型のシリアライズおよびデシリアライズに使用するPofSerializerを指定します。PofSerializerは、POFストリームとの間でのユーザー定義型の値のシリアライズおよびデシリアライズに使用されます。serializer要素の中にはclass-name要素が必要であり、init-params要素の中にはゼロ個以上のコンストラクタ・パラメータを定義できます。

serializer要素を省略すると、ユーザー定義型によってPortableObjectインタフェースが実装され、PortableObjectSerializer実装がPofSerializerとして使用されることになります。

serializer要素からinit-params要素を省略した場合は、そのPofSerializer実装に対して次の4つのコンストラクタが、ここに示された順序で試行されます。

- (int nTypeId, Class clz, ClassLoader loader)

- (int nTypeId, Class clz)

- (int nTypeId)

- ()

user-type-list

使用場所: pof-config

説明

user-type-list要素には、ゼロ個以上のuser-type要素を記述します。使用されるPOFユーザー定義型はそれぞれ、user-type-listに一覧表示されている必要があります。

user-type-list要素には、ゼロ個以上のinclude要素も記述できます。それぞれのinclude要素は、別のpof-configファイルで定義されたuser-type要素の追加に使用されます。

要素

表C-8で、user-type-list要素のサブ要素を説明します。

表C-8 user-type-listのサブ要素

要素

必須/
オプション

説明

<user-type>

オプション

user-type要素には、POFユーザー定義型の宣言を記述します。POFユーザー定義型は、一意の識別、移植、バージョニングが可能なオブジェクト・クラスで、言語、オペレーティング・システム、ハードウェアおよび場所に関係なく、システム間で通信できます。任意の数の<user-type>要素を指定できます。

user-type要素の中ではtype-id要素を省略できますが、スキーマのバージョニングおよび進化をサポートできるように、使用することを強くお薦めします。

user-type要素の中にはclass-name要素が必要であり、ユーザー定義型のすべての値にタイプの割当てが可能なJavaクラスまたはJavaインタフェースの完全修飾名を指定します。

serializer要素を省略すると、ユーザー定義型によってPortableObjectインタフェースが実装され、PortableObjectSerializer実装がPofSerializerとして使用されることになります。

<include>

オプション

include要素は、user-type要素のロード元であるPOF構成ファイルの場所を指定します。この値は、ロード先のファイルの場所を特定するロケータ文字列(有効なパスとURLのいずれか)です。任意の数の<include>要素を指定できます。

D システム・プロパティのオーバーライド

この付録では、システム・プロパティのオーバーライド機能について説明し、Coherenceのデフォルト設定を変更するために使用できる多数の事前定義済システム・プロパティをリストします。

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

- システム・プロパティのオーバーライドの概要

- オーバーライドの例

- 事前構成されているオーバーライド値

D.1 システム・プロパティのオーバーライドの概要

Coherenceオペレーション構成デプロイメント・ディスクリプタtangosol-coherence.xmlおよびCoherenceキャッシュ構成デプロイメント・ディスクリプタcoherence-cache-config.xmlは両方とも、ディスクリプタに定義された任意の要素に、Javaコマンド行オプション名を割り当てることができます。一部の要素には、事前定義されたオーバーライドがあります。オーバーライドは独自に作成することも、事前定義されたものを変更することもできます。

この機能は、単一のJVMの設定を変更する必要がある場合や、別のディスクリプタを使用しないで設定の異なる別のアプリケーションを起動できるようにする場合に役立ちます。最も一般的なアプリケーションでは、マルチキャストの別のアドレス、ポートまたはその両方を渡すことによって、別のアプリケーションで別のクラスタを作成できるようにします。

コマンド行設定オーバーライドを作成するには、system-property属性を追加して、オーバーライドを作成する要素にJavaコマンド行オプションの名前として割り当てる文字列を指定します。次に、Javaコマンド行で先頭を-Dとして指定します。

D.2 オーバーライドの例

たとえば、マルチホーム・サーバーのIPアドレスにオーバーライドを作成し、デフォルトのlocalhostが使用されないようにして、インタフェースに特定のIPアドレス(例、192.168.0.301)を指定できます。このオーバーライドをtangosol.coherence.localhostと呼びます。

まず、cluster-config要素、unicast-listener要素またはaddress要素にsystem-propertyを追加します。次に例を示します。

<address system-property="tangosol.coherence.localhost">localhost</address>

次に、Javaコマンド行を変更し、デフォルトのlocalhost以外のIPアドレスを指定します。

java -Dtangosol.coherence.localhost=192.168.0.301 -jar coherence.jar

D.3 事前構成されているオーバーライド値

表D-1には、事前構成されているオーバーライド値がすべて一覧表示されています。

表D-1 事前構成されているシステム・プロパティのオーバーライド値

オーバーライド・オプション

設定

tangosol.coherence.cacheconfig

キャッシュ構成ディスクリプタのファイル名。「configurable-cache-factory-config」を参照してください。

tangosol.coherence.cluster

クラスタ名。「member-identity」を参照してください。

tangosol.coherence.clusteraddress

クラスタ(マルチキャスト)のIPアドレス。「multicast-listener」の<multicast-listener-address>サブ要素を参照してください。

tangosol.coherence.clusterport

クラスタ(マルチキャスト)のIPポート。「multicast-listener」の<multicast-listener-port>サブ要素を参照してください。

tangosol.coherence.distributed.backup

データ・バックアップ記憶域の場所。「DistributedCacheサービスのパラメータ」のbackup-storage/typeサブ要素を参照してください。

tangosol.coherence.distributed.backupcount

データ・バックアップの数。「DistributedCacheサービスのパラメータ」のbackup-countサブ要素を参照してください。

tangosol.coherence.distributed.localstorage

有効化されているローカル・パーティション管理。「DistributedCacheサービスのパラメータ」のlocal-storageサブ要素を参照してください。

tangosol.coherence.distributed.threads

スレッド・プールのサイズ。「DistributedCacheサービスのパラメータ」のthread-countサブ要素を参照してください。

tangosol.coherence.distributed.transfer

パーティション送信のしきい値。「DistributedCacheサービスのパラメータ」のtransfer-thresholdサブ要素を参照してください。

tangosol.coherence.edition

製品のエディション。「license-config」を参照してください。

tangosol.coherence.invocation.threads

起動サービスのスレッド・プールのサイズ。「起動サービスのパラメータ」のthread-countサブ要素を参照してください。

tangosol.coherence.localhost

ユニキャストのIPアドレス。「unicast-listener」の<unicast-listener-address>サブ要素を参照してください。

tangosol.coherence.localport

ユニキャストのIPポート。「unicast-listener」の<unicast-listener-port>サブ要素を参照してください。

tangosol.coherence.localport.adjust

ユニキャストのIPポートの自動割当て。「unicast-listener」の<unicast-listener-auto>サブ要素を参照してください。

tangosol.coherence.log

ロギング先。「logging-config」の<logging-config-destination>サブ要素を参照してください。

tangosol.coherence.log.level

ロギング・レベル。「logging-config」の<logging-config-level>サブ要素を参照してください。

tangosol.coherence.log.limit

ログ出力文字制限。「logging-config」の<logging-config-limit>サブ要素を参照してください。

tangosol.coherence.machine

machine-name要素で定義されているコンピュータの名前。「member-identity」を参照してください。

tangosol.coherence.management

JMX管理のモード。「management-config」を参照してください。

tangosol.coherence.management.readonly

JMX管理の読取り専用フラグ。「management-config」を参照してください。

tangosol.coherence.management.remote

リモートJMX管理の有効フラグ。「management-config」を参照してください。

tangosol.coherence.member

メンバー名。「member-identity」を参照してください。

tangosol.coherence.mode

操作モード。「license-config」を参照してください。

tangosol.coherence.override

デプロイメント構成のオーバーライド・ファイル名。

tangosol.coherence.priority

優先度。「member-identity」を参照してください。

tangosol.coherence.process

プロセス名。「member-identity」を参照してください。

tangosol.coherence.proxy.threads

Coherence*Extendサービスのスレッド・プールのサイズ。「プロキシ・サービスのパラメータ」のthread-countサブ要素を参照してください。

tangosol.coherence.rack

ラック名。「member-identity」を参照してください。

tangosol.coherence.role

ロール名。「member-identity」を参照してください。

tangosol.coherence.security

キャッシュ・アクセス・セキュリティの有効フラグ。「security-config」を参照してください。

tangosol.coherence.security.keystore

セキュリティ・アクセス・コントローラのキーストア・ファイル名。「security-config」を参照してください。

tangosol.coherence.security.permissions

セキュリティ・アクセス・コントローラの権限ファイル名。「security-config」を参照してください。

tangosol.coherence.shutdownhook

シャットダウン・リスナー・アクション。「shutdown-listener」を参照してください。

tangosol.coherence.site

サイト名。「member-identity」を参照してください。

tangosol.coherence.tcmp.enabled

TCMPの有効フラグ。「packet-publisher」の<packet-publisher-enabled>サブ要素を参照してください。

tangosol.coherence.ttl

マルチキャスト・パケットの有効時間(TTL)。「multicast-listener」の<mulitcast-listener-ttl>サブ要素を参照してください。

tangosol.coherence.wka

既知のIPアドレス。「well-known-addresses」を参照してください。

tangosol.coherence.wka.port

既知のIPポート。「well-known-addresses」を参照してください。

E PIF-POFバイナリ形式

この付録では、プラットフォームおよび言語に依存することなくオブジェクトをシリアライズするために使用されるPortable Object Format (POF)およびPortable Invocation Format (PIF)のバイナリ・ストリームについて説明します。

この付録では次の項について説明します。

- PIF-POFバイナリ形式の概要

- ストリーム形式

- 事前定義型のバイナリ形式

- ユーザー定義型のバイナリ形式

E.1 PIF-POFバイナリ形式の概要

Portable Object Format (POF)では、オブジェクト値の元のプラットフォーム/言語とは関係なく、それらが未知であっても、そのオブジェクト値をバイナリ・ストリームにエンコードできます。Portable Invocation Format (PIF)では、メソッド呼出しを同様にバイナリ・ストリームにエンコードできます。これら2つの形式(PIF-POFと呼ばれます)は、共通のバイナリ・エンコード基盤から派生したものです。ここではバイナリ形式を参考のために記載してありますが、PIF-POF使用時の要件を示すものではありません。このPIF-POFの使用の詳細は、第20章「Portable Object Formatの使用」を参照してください。

E.2 ストリーム形式

PIF-POFストリーム形式はオクテットを基準としており、PIF-POFストリームはオクテット値のシーケンスです。あいまいさを回避するため、このドキュメントではすべてのオクテットを0x00から0xFF (10進法の0から255に相当)の範囲の無署名の8ビット整数値として扱います。(PIF-POFでは)無署名の8ビット整数値で表される特定のオクテット値が、常に同じ無署名の8ビット整数値として書き込まれたり読み込まれたりするため、バイト順序はまったく重要ではありません。

PIFストリームには呼出しが1つだけ格納されます。呼出しは、その呼出しの残りの部分の長さを表す整数値を格納する最初のPOFストリーム、その直後に続く、対話IDの整数値を格納するPOFストリーム、さらにその直後に続く、メッセージ・オブジェクトのユーザー定義型値を格納するPOFストリームで構成されます。残りの部分の長さは、対話IDとメッセージ・オブジェクトのエンコードに使用されるオクテットの合計数を示しており、それによって、呼出しの受信プロセスでその呼出しの受信完了を判別できるようになります。TCP/IPでは特定のIPアドレスに対して複数の論理ポート番号を割り当てられますが、それと同様に対話IDは、1つの接続を通じて多重化される複数の論理クライアントおよびサービスをサポートするために使用されます。メッセージ・オブジェクトは、特定の高水準の対話プロトコルによって定義されます。

1つのPOFストリームには値が1つだけ格納されます。この値には型IDが格納され、型IDが値を示さない場合は、その後に型IDによって形式が定義されたデータ構造が続きます。

E.2.1 整数値

ストリーム形式は、圧縮形式での整数値のエンコード機能に大きく依存します。Coherenceでは、この整数バイナリ形式をパック整数と呼んでいます。この形式は、最初のオクテットと1つ以上の後続オクテットが必要に応じて使用される、可変長形式です。

表E-1は、最初のオクテットの3つの領域を示しています。

表E-1 パック整数の最初のオクテットの各領域

領域マスク

説明

0x80

継続インジケータ

0x40

負のインジケータ

0x3F

整数値(6つのバイナリLSD)

表E-2は、後続オクテットの2つの領域を示しています。

表E-2 パック整数の後続オクテットの各領域

領域マスク

説明

0x80

継続インジケータ

0x7F

整数値(次の7つのバイナリLSD)

例E-1は、Coherenceでサポートされるオクテット・ストリームに対する32ビット整数値の書込みを示しています。

例E-1 オクテット・ストリームに対する32ビット整数値の書込み

public static void writeInt(DataOutput out, int n)
throws IOException
{
int b = 0;
if (n < 0)
{
b = 0x40;
n = ~n;
}
b |= (byte) (n & 0x3F);
n >>>= 6;
while (n != 0)
{
b |= 0x80;
out.writeByte(b);
b = (n & 0x7F);
n >>>= 7;
}
out.writeByte(b);
}

例E-2は、Coherenceでサポートされるオクテット・ストリームからの32ビット整数値の読込みを示しています。

例E-2 オクテット・ストリームからの32ビット整数値の読込み

public static int readInt(DataInput in)
throws IOException
{
int b = in.readUnsignedByte();
int n = b & 0x3F;
int cBits = 6;
boolean fNeg = (b & 0x40) != 0;
while ((b & 0x80) != 0)
{
b = in.readUnsignedByte();
n |= ((b & 0x7F) << cBits);
cBits += 7;
}
if (fNeg)
{
n = ~n;
}
return n;
}

このドキュメントで使用される整数値で、明示的な型IDがない場合は、10進数-2^31から2^31-1の範囲の32ビット整数値と見なされます。

表E-3は、いくつかの整数値の例を示しています。

表E-3 型IDがない整数値のバイナリ形式

値

バイナリ形式

0

0x00

1

0x01

2

0x02

99

0xA301

9999

0x8F9C01

-1

0x40

-2

0x41

-99

0xE201

-9999

0xCE9C01

E.2.2 型ID

型IDは、整数値としてバイナリ・ストリームにエンコードされます。ゼロ以上の型IDは、ユーザー定義型のIDです。ゼロ未満の型IDは、事前定義(固有)型のIDです。

表E-4は、事前定義型のIDのリストです。

表E-4 事前定義型のID

型ID

説明

-1 (0x40)

int16

-2 (0x41)

int32

-3 (0x42)

int64

-4 (0x43)

int128*

-5 (0x44)

float32

-6 (0x45)

float64

-7 (0x46)

float128*

-8 (0x47)

decimal32*

-9 (0x48)

decimal64*

-10 (0x49)

decimal128*

-11 (0x4A)

boolean

-12 (0x4B)

octet

-13 (0x4C)

octet-string

-14 (0x4D)

char

-15 (0x4E)

char-string

-16 (0x4F)

date

-17 (0x50)

year-month-interval*

-18 (0x51)

time

-19 (0x52)

time-interval*

-20 (0x53)

datetime

-21 (0x54)

day-time-interval*

-22 (0x55)

collection

-23 (0x56)

uniform-collection

-24 (0x57)

array

-25 (0x58)

uniform-array

-26 (0x59)

sparse-array

-27 (0x5A)

uniform-sparse-array

-28 (0x5B)

map

-29 (0x5C)

uniform-keys-map

-30 (0x5D)

uniform-map

-31 (0x5E)

identity

-32 (0x5F)

reference

-33以下の型IDは、型と値の組合せです。この形式は、通常使用される値のスペースを削減するために使用されます。

表E-5は、型と値を組み合せた型IDのリストです。

表E-5 型と値を組み合せた型ID

型ID

説明

-33 (0x60)

boolean:false

-34 (0x61)

boolean:true

-35 (0x62)

string:zero-length

-36 (0x63)

collection:empty

-37 (0x64)

reference:null

-38 (0x65)

floating-point:+infinity

-39 (0x66)

floating-point:-infinity

-40 (0x67)

floating-point:NaN

-41 (0x68)

int:-1

-42 (0x69)

int:0

-43 (0x6A)

int:1

-44 (0x6B)

int:2

-45 (0x6C)

int:3

-46 (0x6D)

int:4

-47 (0x6E)

int:5

-48 (0x6F)

int:6

-49 (0x70)

int:7

-50 (0x71)

int:8

-51 (0x72)

int:9

-52 (0x73)

int:10

-53 (0x74)

int:11

-54 (0x75)

int:12

-55 (0x76)

int:13

-56 (0x77)

int:14

-57 (0x78)

int:15

-58 (0x79)

int:16

-59 (0x7A)

int:17

-60 (0x7B)

int:18

-61 (0x7C)

int:19

-62 (0x7D)

int:20

-63 (0x7E)

int:21

-64 (0x7F)

int:22

E.3 事前定義型のバイナリ形式

ここでは、PIF-POFでサポートされる事前定義(固有)型IDのバイナリ形式について説明します。対象の型は、int、Decimal、Floating Point、Boolean、Octet、Octet String、Char、Char String、Date、Year-Month Interval、Time、Time Interval、Date-Time、Date-Time Interval、Collection、Array、Sparse Array、Key-Value Map(ディクショナリ)、IdentityおよびReferenceです。

E.3.1 Int

int16、int32、int64およびint128の4つの符号付き整数型がサポートされます。ストリーム内に整数型の型IDが存在する場合は、その直後に整数値が続きます。

この4つの符号付き整数型は、その型の最大値をサポートするために必要な長さのみが異なり、共通の2の補数バイナリ形式を使用します。ストリーム内では、int16、int32、int64またはint128のいずれかの型IDの後ろに整数値が続きます。整数値が、型でサポートされる範囲(int16は、-2^15から215-1、int32は、-2^31から231-1、int64は、-2^63から263-1、int128は-2^127から2127-1)に含まれない場合、結果は未定義になり、ビット単位の切捨てまたは例外が発生することがあります。

さらに簡潔さを保つためにintの指定と値をシングル・バイトに結合する型IDがいくつかあります。その結果、それらの型IDに値が組み込まれるため、ストリーム内で型IDの後に整数値が続くことはなくなります。

表E-6は、これらの型IDを示しています。

表E-6 intデータ型と値を結合する型ID

値

int16

int32

int64

int128

0

0x69

0x69

0x69

0x69

1

0x6A

0x6A

0x6A

0x6A

2

0x6B

0x6B

0x6B

0x6B

99

0x40A301

0x41A301

0x42A301

0x43A301

9999

0x408F9C01

0x418F9C01

0x428F9C01

0x438F9C01

-1

0x68

0x68

0x68

0x68

-2

0x4041

0x4141

0x4241

0x4341

-99

0x40E201

0x41E201

0x42E201

0x43E201

-9999

0x40CE9C01

0x41CE9C01

0x42CE9C01

0x43CE9C01

対応するJavaデータ型は、short (int16)、int (int32)、long (int64)およびBigInteger (int128)です。BigIntegerは、非常に大きい値を表すことができるため、すべてのBigInteger値をint128形式でエンコードすることはできません。int128の範囲に含まれない値は基本的にサポートされないため、例外が発生します。それを避けるには、文字列エンコードなどの別のエンコードを使用します。

E.3.1.1 整数型の強制変換

数値データ型を効率的に表せるようにするため、ストリームの受信側によって整数型が次のいずれかの型に強制変換されます。

表E-7 他の型に強制変換される可能性がある整数型の型ID

型ID

説明

-1 (0x40)

int16

-2 (0x41)

int32

-3 (0x42)

int64

-4 (0x43)

int128

-5 (0x44)

float32

-6 (0x45)

float64

-7 (0x46)

float128

-8 (0x47)

decimal32

-9 (0x48)

decimal64

-10 (0x49)

decimal128

-12 (0x4B)

octet

-14 (0x4D)

char

言い換えると、受信側でストリームから前述のいずれかの型が読み込まれ、エンコードされた整数値が検出されると、その値が所定の型に自動的に変換されることになります。この機能によって、一連の一般的な(つまり、重要度が大きくない)オクテット型、文字型、整数型、10進型および浮動小数点型の値は、単一オクテット整数型(-41から-64の範囲の型ID)を使用してエンコードされるようになります。

無署名のデータ型については、整数値-1が、octet型では0XFFに、char型では0xFFFFに変換されます。(char型の場合、これは、UTF-16プラットフォームのエンコードを意味するように思われますが、ストリーム形式の明示的な要件のいずれにも違反していません。)

E.3.2 Decimal

decimal32、decimal64およびdecimal128の3つの浮動小数点10進型がサポートされます。ストリーム内に10進型の型IDが存在する場合は、その直後に2つのパック整数値が続きます。最初の整数値は非スケール値で、その次の値はスケール値です。これらの値は、JavaのBigDecimalクラスのコンストラクタjava.math.BigDecimal(BigInteger unscaledVal, int scale)のパラメータに相当します。

「整数型の強制変換」で説明している、整数値からサポートされる10進値への強制変換に加え、表E-8にリストされた定数型と値IDも、IEEE 754rでサポートされる特別な値の指定に使用されます。

表E-8 10進値を示すことが可能な型ID

型ID

説明

-38 (0x65)

floating-point:+infinity

-39 (0x66)

floating-point:-infinity

-40 (0x67)

floating-point:NaN

Javaには標準の(つまり、移植可能な)10進型はなく、BigDecimalが実装されていますが、これは本来Javaの暗号インフラストラクチャでの内部使用を目的としたものです。Javaでは、正および負の無限大の10進値および非数(NaN)はサポートされません。

E.3.3 Floating Point

float32、float64およびfloat128の3つのbase2浮動小数点型がサポートされます。ストリーム内に浮動小数点型の型IDが存在する場合は、その直後に、バイナリ形式がIEEE 754/IEEE754rで定義された固定長の浮動小数点値が続きます。浮動小数点数は、IEEE754形式を使用してストリームに書き込まれ、float128型の場合はIEEE754r形式が使用されます。

「整数型の強制変換」で説明している、整数値から10進値への強制変換に加え、表E-9の定数も、IEEE-754でサポートされる特殊な値の指定に使用されます

表E-9 IEEE 754の特殊な値を示すことが可能な型ID

型ID

説明

-38 (0x65)

floating-point:+infinity

-39 (0x66)

floating-point:-infinity

-40 (0x67)

floating-point:NaN

IEEE-754で定義されるその他の特殊な値は、完全な32ビット、64ビットまたは128ビット形式を使用してエンコードされますが、すべてのプラットフォームでサポートされるわけではありません。特に、Javaでは、これらを区別する手段がなく、NaN値が1つだけサポートされます。

E.3.4 Boolean

ストリーム内にBooleanの型IDが存在する場合は、その後に整数値が続きます。整数値ゼロはブール値falseを、それ以外の整数値はすべてtrueを表します。

「整数型の強制変換」で説明しているように、ブール値をエンコードすることはできますが、ブール型の値はtrueとfalseのみです。したがって、ブール値に対して予期されるバイナリ形式は、表E-10に示された事前定義(および圧縮)された形式のみになります。

表E-10 ブール値を示すことが可能な型ID

型ID

説明

-33 (0x60)

boolean:false

-34 (0x61)

boolean:true

E.3.5 Octet

ストリーム内にOctetの型IDが存在する場合は、その後に範囲0から255 (0x00から0xFF)で定義されたオクテット値自体が続きます。「整数型の強制変換」で説明しているように、オクテット値には整数値の圧縮形式を使用可能であり、整数値-1は0xFFに変換されます。

表E-11は、オクテット値として使用可能な整数値のリストです。

表E-11 オクテット値として使用可能な整数値

値

Octet

0 (0x00)

0x69

1 (0x01)

0x6A

2 (0x02)

0x6B

99 (0x63)

0x4B63

254 (0xFE)

0x4BFE

255 (0xFF)

0x68

E.3.6 Octet String

ストリーム内にOctet Stringの型IDが存在する場合は、その後に文字列の長さを表す整数値nが続き、さらにその後にn個のオクテット値が続きます。

長さゼロのOctet Stringは、型IDのstring:zero-lengthを使用してエンコードされます。

E.3.7 Char

ストリーム内にCharの型IDが存在する場合は、その後にUTF-8エンコード文字が続きます。「整数型の強制変換」で説明しているように、文字型値には整数値の圧縮形式を使用可能であり、整数値-1は0xFFFFに変換されます。

注意:
POFは、可能な場合は各文字に1バイトのみを使用することでStringデータの格納を最適化します。カスタムPOF文字コーデック(たとえば、ASCII)は不要であり、それによってパフォーマンスは向上しません。

例E-3は、オクテット・ストリームへの文字型値の書込みを示しています。

例E-3 オクテット・ストリームへの文字型値の書込み

public static void writeChar(DataOutput out, int ch)
throws IOException
{
if (ch >= 0x0001 && ch <= 0x007F)
{
// 1-byte format: 0xxx xxxx
out.write((byte) ch);
}
else if (ch <= 0x07FF)
{
// 2-byte format: 110x xxxx, 10xx xxxx
out.write((byte) (0xC0 | ((ch >>> 6) & 0x1F)));
out.write((byte) (0x80 | ((ch ) & 0x3F)));
}
else
{
// 3-byte format: 1110 xxxx, 10xx xxxx, 10xx xxxx
out.write((byte) (0xE0 | ((ch >>> 12) & 0x0F)));
out.write((byte) (0x80 | ((ch >>> 6) & 0x3F)));
out.write((byte) (0x80 | ((ch ) & 0x3F)));
}
}

例E-4は、オクテット・ストリームからの文字型値の読込みを示しています。

例E-4 オクテット・ストリームからの文字型値の読込み

public static char readChar(DataInput in)
throws IOException
{
char ch;

int b = in.readUnsignedByte();
switch ((b & 0xF0) >>> 4)
{
case 0x0: case 0x1: case 0x2: case 0x3:
case 0x4: case 0x5: case 0x6: case 0x7:
// 1-byte format: 0xxx xxxx
ch = (char) b;
break;

case 0xC: case 0xD:
{
// 2-byte format: 110x xxxx, 10xx xxxx
int b2 = in.readUnsignedByte();
if ((b2 & 0xC0) != 0x80)
{
throw new UTFDataFormatException();
}
ch = (char) (((b & 0x1F) << 6) | b2 & 0x3F);
break;
}

case 0xE:
{
// 3-byte format: 1110 xxxx, 10xx xxxx, 10xx xxxx
int n = in.readUnsignedShort();
int b2 = n >>> 8;
int b3 = n & 0xFF;
if ((b2 & 0xC0) != 0x80 || (b3 & 0xC0) != 0x80)
{
throw new UTFDataFormatException();
}
ch = (char) (((b & 0x0F) << 12) |
((b2 & 0x3F) << 6) |
b3 & 0x3F);
break;
}

default:
throw new UTFDataFormatException(
"illegal leading UTF byte: " + b);
}

return ch;
}

E.3.8 Char String

ストリーム内にChar Stringの型IDが存在する場合は、その後にUTF-8で表される文字列の長さnをオクテットで表した整数と、このUTF-8のエンコードを構成するn個のオクテット値が続きます。文字列-エンコード形式の長さは、文字の長さではなくオクテットの長さであることに注意してください。

長さゼロのChar Stringは、string:zero-length型IDによってエンコードされます。表E-12は、Char String形式を示しています。

表E-12 Char String形式の値

値

Char String形式

0x62(または0x4E00)

"ok"

0x4E026F6B

E.3.9 Date

Date値は、ISO8601セマンティックを使用して渡されます。ストリーム内にDateの型IDが存在する場合は、その後にISO8601で定義されている範囲の年、月および日を表す3つの整数値が続きます。

E.3.10 Year-Month Interval

ストリーム内にYear-Month Intervalの型IDが存在する場合は、その後に年単位と月単位の間隔を表す2つの整数値が続きます。

E.3.11 Time

Time値は、ISO8601セマンティックを使用して渡されます。ストリーム内にTimeの型IDが存在する場合は、その後に5つの整数値が続き、さらにその後に2つの整数値が続く場合もあります。最初の4つの整数値は、時間、分、秒および小数秒を示します。小数秒は、次の3つの方法のいずれかでエンコードされます。

- 0は、小数秒がないことを示します。

- [1..999]は、ミリ秒数を示します。

- [-1..-999999999]は、ナノ秒の負の数値を示します。

5番目の整数値は、タイム・ゾーンのインジケータであり、次の3つの方法のいずれかでエンコードされます。

- 0は、タイム・ゾーンがないことを示します。

- 1は、協定世界時(UTC)を示します。

- 2は、タイム・ゾーンのオフセットを示し、その後にISO8601に従って時間のオフセットと分のオフセットを表す2つの整数値が続きます。

小数部とタイム・ゾーンを様々な方法でエンコードできると、Time値の解析は複雑になりますが、バイナリが非常に簡潔になるだけではなく、ISO8601標準および時計の精度のばらつきにより完全に対応できるようになります。Time値には小数エンコードやミリ秒エンコードがないことも多くありますが、長期的には時間分解能は精密化される傾向にあります。

E.3.12 Time Interval

ストリーム内にTime Intervalの型IDが存在する場合は、その後に時間、分、秒およびナノ秒単位の間隔を表す4つの整数値が続きます。

E.3.13 Date-Time

Date-Time値は、ISO8601セマンティックを使用して渡されます。ストリーム内にDate-Timeの型IDが存在する場合は、その後にDate値およびTime値を構成する整数値に対応する8から10の整数値が続きます。

E.3.13.1 日付および時間の型の強制変換

Date値はDate-Time値に強制変換できます。Time値はDate-Time値に強制変換できます。Date-Time値は、Date値またはTime値に強制変換できます。

E.3.14 Day-Time Interval

ストリーム内にDay-Time Intervalの型IDが存在する場合は、その後に日、時間、分、秒およびナノ秒単位の間隔を表す5つの整数値が続きます。

E.3.15 Collections

バッグ、セットまたはリストなどの値のコレクションは、POFストリームでCollection型を使用してエンコードされます。ストリーム内では、型IDの直後に、コレクション内の値の数を示す0以上の整数で表されたコレクション・サイズが続きます。コレクション・サイズの後ろには、コレクションの最初の値(存在する場合)自体が、値としてエンコードされて続きます。コレクションの値は連続しており、ストリームにはちょうどn個の値が存在します。nは、コレクションのサイズと同じです。

コレクションのすべての値が同じ型である場合は、共通コレクション形式が使用されます。ストリームでは、型ID (uniform-collection)の直後にコレクションの共通型の値が書き込まれ、その後ろにコレクションのサイズを表す整数値nが続き、さらにn個の値が型IDなしで続きます。共通コレクション内の値にはIDを割り当てることはできず、(明示的な型エンコードの副作用として)空の共通コレクションにはコンテンツの型が明示的に指定されることに注意してください。

表E-13は、複数値のコレクションおよび共通コレクション形式の例を示しています。

表E-13 様々な値のコレクションおよび共通コレクション形式

値

コレクション形式

共通コレクション形式

0x63(または0x5500)

N/A

1

0x55016A

0x56410101

1,2,3

0x55036A6B6C

0x564103010203

1, "ok"

0x55026A4E026F6B

N/A

E.3.16 Array

POFストリームでは、値の索引付き配列が、Array型を使用してエンコードされます。ストリーム内では、型IDの直後に、配列内の要素数を示す0以上の整数で表された配列サイズが続きます。配列サイズの後ろには、配列内に1つ以上の要素が存在する場合は、配列の最初の要素の値(ゼロ索引)が続きますが、それ自体も値としてエンコードされています。配列の要素の値は連続しており、ストリームにはちょうどn個の値が存在します。nは、配列のサイズと同じです。

配列の要素のすべての値が同じ型である場合は、共通配列形式が使用されます。ストリームでは、型ID (uniform-array)の直後に配列の要素の共通型の値が書き込まれ、その後ろに配列のサイズを表す整数値nが続き、さらにn個の値が型IDなしで続きます。共通配列内の値にはIDを割り当てることはできず、(明示的な型エンコードの副作用として)空の共通配列には配列の要素の型が明示的に指定されることに注意してください。

表E-14は、複数値の配列および共通配列形式の例を示しています。

表E-14 様々な値の配列および共通配列形式

値

配列形式

共通配列形式

0x63(または0x5700)

0x63(または0x584100)–この例は、Int32型の要素の場合を示しています。

1

0x57016A

0x58410101

1,2,3

0x57036A6B6C

0x584103010203

1, "ok"

0x57026A4E026F6B

N/A

E.3.17 Sparse Array

要素値がスパースである配列には、Sparse Array形式を使用すると索引を明示的にエンコードできるほか、欠落した索引にはデフォルト値が設定されます。デフォルト値は、ブール型の場合はfalse、数値型、オクテット型および文字型の場合はゼロ、参照型の場合はすべてnullになります。スパース配列は、型ID (sparse-array)の後ろに、配列サイズを表す整数値nが続き、その後にn個以内の索引/値のペアが続く形式になっています。このペアはそれぞれ、直前の要素の配列索引より大きな値の整数値i (0 <= i < n)としてエンコードされた配列索引と、値としてエンコードされた要素値で構成されます。スパース配列は最終的に無効索引-1で終了します。

スパース配列の要素のすべての値が同じ型である場合は、共通スパース配列形式が使用されます。ストリームでは、型ID (uniform-sparse-array)の直後に、スパース配列の要素の共通型の値が書き込まれ、その後に配列サイズを表す整数値nが続き、さらにその後にn個以内の索引/値のペアが続きます。このペアはそれぞれ、直前の要素の配列索引より大きな値の整数値i (0 <= i < n)としてエンコードされた配列索引と、型IDなしの値としてエンコードされた要素値で構成されます。共通スパース配列は最終的に無効索引-1で終了します。共通スパース配列内の値にはIDを割り当てることはできず、(明示的な型エンコードの副作用として)空の共通スパース配列には配列の要素の型が明示的に指定されることに注意してください。

表E-15は、複数値のスパース配列および共通スパース配列の例を示しています。

表E-15 様々な値のスパース配列および共通スパース配列形式

値

スパース配列形式

共通スパース配列形式

0x63(または0x590040)

0x63(または0x5A410040)–この例は、Int32型の要素の場合を示しています。

1

0x5901006A40

0x5A4101000140

1,2,3

0x5903006A016B026C40

0x5A410300010102020340

1,,,,5,,,,9

0x5909006A046E087240

0x5A410900010405080940

1,,,,"ok"

0x5905006A044E026F6B40

N/A

E.3.18 Key-Value Map(ディクショナリ)

キー/値のペアには、Key-Value Map(ディクショナリ・データ構造とも呼ばれます)形式が使用されます。Key-Value Mapバイナリ・エンコードには次の3つの形式があります。

- 汎用的なmapエンコードは、キーと値のシーケンスです。

- uniform-keys-mapエンコードは、共通型のキーとそれに対応する値のシーケンスです。

- uniform-mapエンコードは、共通型のキーと、共通型の対応値のシーケンスです。

Key-Value Mapは、型ID (map)の後に、キー-値マップのサイズを表す整数値nが続き、さらにその後に、値としてエンコードされたキーと値としてエンコードされた対応値で構成される、n個のキー/値のペアが続く形式になっています。

表E-16は、キー/値のペアとそれに対応するバイナリ形式のいくつかの例を示しています。

表E-16 キー/値のペアのバイナリ形式

値

バイナリ形式

0x63(または0x5B00)

1="ok"

0x5B016A4E026F6B

1="ok", 2="no"

0x5B026A4E026F6B6B4E026E6F

Key-Value Mapのすべてのキーの型が共通の場合、エンコードではさらに簡潔な形式が使用されます。型ID (uniform-keys-map)で始まり、その後にKey-Value Mapのキーの共通型の型IDが続き、さらにその後にKey-Value Mapのサイズを表す整数値n、値としてエンコードされたキー(型IDなし)および値としてエンコードされた対応値で構成されるn個のキー/値ペアが続きます。

表E-17は、キーの型が共通の場合の、キー/値のペアのバイナリ形式の例をいくつか示しています。

表E-17 キーの型が共通の場合の、キー/値のペアのバイナリ形式

値

バイナリ形式

0x63(または0x5C4100)

1="ok"

0x5C4101014E026F6B

1="ok", 2="no"

0x5C4102014E026F6B024E026E6F

Key-Value Mapのすべてのキーの型が共通で、マップのすべての対応値の型も共通である場合、エンコードではさらに簡潔な形式が使用されます。型ID (uniform-map)で始まり、その後にKey-Value Mapのキーの共通型の型IDが続き、さらにその後にKey-Value Mapの値の共通型の型ID、Key-Value Mapのサイズを表す整数値n、型IDなしで値としてエンコードされたキーと型IDなしで値としてエンコードされた対応値で構成されるn個のキー/値のペアの順に続きます。

表E-18は、キーと値の型が共通の場合の、キー/値のペアのバイナリ形式の例をいくつか示しています。

表E-18 キーと値の型が共通の場合の、キー/値のペアのバイナリ形式

値

バイナリ形式

0x63(または0x5D414E00)

1="ok"

0x5D414E0101026F6B

1="ok", 2="no"

0x5D414E0201026F6B02026E6F

E.3.19 Identity

ストリーム内にIdentityの型IDが存在する場合は、その後にIDを表す整数値が続きます。IDの後には識別される値が続きますが、それ自体が値としてエンコードされています。

POFストリーム内で複数回出現する値にはすべてIDのラベルが付けられ、同じPOFストリーム内の2回目以降に出現する値は、参照に置き換えられます。「by reference」セマンティックをサポートするプラットフォームの場合、IDは、実際のオブジェクトIDのシリアライズ形式を表します。

IDは、ゼロ以上の整数値です。POFストリーム内の値には最大で1つのIDがあります。共通データ構造内の値にはIDを割り当てることができます。

E.3.20 Reference

Referenceは、現在のPOFストリーム内ですでに出現しているIDに対するポインタまたはnullポインタです。

「by reference」セマンティックをサポートするプラットフォームの場合、POFストリーム内の参照は、実現された(デシリアライズされた)オブジェクト内の参照となり、POFストリーム内のnull参照は、実現されたオブジェクト内のnull参照になります。「by reference」セマンティックをサポートしないプラットフォームの場合や、POFストリームで非参照値(例: Javaのプリミティブ・プロパティ)に対するnull参照が出現した場合には、その型の値のデフォルト値が使用されます。

表E-19は、いくつかの「by reference」セマンティックのバイナリ形式の例を示しています。

表E-19 「By Reference」セマンティックのバイナリ形式

値

バイナリ形式

Id #1

0x5F01

Id #350

0x5F9E05

null

0x60

前方参照および外部参照のサポートは、POFでは必要ありません。POFでは、参照されるIDとそのIDが参照する値の両方が、そのPOFストリーム内にすでに出現しています。前者の場合、未出現のIDは参照されません。また、後者の場合は、複雑な値(コレクションやユーザー定義型など)内からその複雑な値自体が参照されることはありません。

E.4 ユーザー定義型のバイナリ形式

非固有の型はすべてユーザー定義型と呼ばれます。ユーザー定義型は、それぞれが型IDを持つゼロ個以上の索引付きの値(フィールド、プロパティおよび属性とも呼ばれます)で構成されます。さらに、ユーザー定義型は、バージョニングされており、上位および後方互換性をサポートしています。

ユーザー定義型には、ゼロ以上の値の型IDが指定されます。型ID自体は、ストリーム内で明示的または自己記述的な意味を持つわけではありません。つまり、値には型(またはクラス)定義は含まれません。そのかわりに、エンコーダ(送信側)とデコーダ(受信側)がコンテキストと呼ばれる情報を暗黙のうちに共有します。このコンテキストには、ユーザー定義型の定義などの必要なメタデータが含まれます。

ユーザー定義型のバイナリ形式は、スパース配列と非常によく似ています。ユーザー定義型は、概念的にはプロパティ値のスパース配列と見なすことができます。ユーザー定義型は、型ID(ゼロ以上の整数値)の後ろに、バージョンID(ゼロ以上の整数値)が続き、その後に直前のプロパティ索引より大きい値の整数値i (0 <= i)としてエンコードされるプロパティ索引と、値としてエンコードされるプロパティ値で構成される、索引/値のペアが続く形式になっています。ユーザー定義型は、最終的に-1の無効なプロパティ索引で終了します。

スパース配列と同様に、ユーザー定義型のエンコードに含まれないプロパティには、デフォルト値が設定されます。デフォルト値は、ブール型の場合はfalse、数値型、オクテット型および文字型の場合はゼロ、参照型の場合はすべてnullになります。

E.4.1 ユーザー定義型のバージョニング

ユーザー定義型のバージョニングでは、ユーザー定義型へのプロパティの追加がサポートされますが、以前のバージョンの既存プロパティの置換や削除はサポートされません。一般的なバイナリ規定にバージョニング機能を組み込むことによって、下位および上位の互換性のサポートが可能になります。

送信側がバージョンv1のユーザー定義型値を、それに相当するバージョンv2のユーザー定義型をサポートする受信側に送信した場合、受信側は、v2のユーザー定義型に存在し、v1には存在しない追加プロパティに対して、デフォルト値を使用します。

送信側がバージョンv2のユーザー定義型値を、それに相当するバージョンv1のユーザー定義型しかサポートしない受信側に送信した場合、受信側は、v2のユーザー定義型に存在し、v1には存在しない追加プロパティを、不明なプロパティとして処理します。受信側で、値を(永続的に)保存する必要がある場合や、値を後で送信する可能性がある場合、受信側では、後日エンコードできるように、それらの不明な追加プロパティを保存しておきます。その場合、受信側が型指定された形式またはバイナリ形式で不明なプロパティ値を取り出すことができるようにするための十分な型情報が含まれます。受信側がこのユーザー定義型を再エンコードする場合は、元のままの状態のv2のプロパティが含まれているため、バージョン・インジケータv2を使用する必要があります。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。